# ElizaOS Developer Update (2026-03-02 → 2026-03-05)

## 1) Core Framework

### Task scheduling: align “cron-like” plugins with `plugin-bootstrap` task service
A community “Heartbeat” plugin was updated (per framework guidance) to **use the task service exposed by `plugin-bootstrap`** instead of running an independent scheduler. This reduces duplicated scheduling logic and ensures consistent lifecycle management (start/stop, environment binding, and future observability hooks) across agents.

**Developer takeaway:** if you’re implementing periodic work (pollers, refreshers, keepalives), prefer the framework task service rather than `setInterval()`/custom cron in plugin code.

> Reference (discussion context): heartbeat plugin refactor guidance in Discord (2026-03-02)

### Potential technical debt: “reply action optimization” discovered but usage unclear
A “reply action optimization” path was discovered in the codebase, but it’s not clear whether:
- it’s unused (dead code),
- partially wired (missing docs/tests),
- or active but opaque.

**Action for contributors:** audit call sites and runtime behavior; either (a) document & test it, (b) complete integration, or (c) remove if obsolete.

> Reference (discussion context): reply optimization investigation request (Discord, 2026-03-03)

### Docs & repo hygiene
- Auto-generated framework documentation for **`elizaos-eliza`** is now published on Mintlify: https://elizaos-eliza.mintlify.app/introduction  
- PR lists were consolidated/cleaned and labeled for easier triage (administrative but impactful for contributor throughput).

## 2) New Features

### MEM0 integration plugin (persistent, self-updating “RAG-ish” memory)
A community plugin integrating **MEM0** was shared as a “base URL for inference” concept: every response is routed through a DB-backed layer before returning an answer, enabling highly persistent conversations.

While the exact implementation details weren’t posted in the dataset, the architectural pattern is clear:

- Treat memory as a first-class middleware in the model call pipeline.
- Persist conversational state (and possibly embeddings) continuously.
- Make memory retrieval/update implicit rather than an explicit “tool call”.

**Illustrative integration sketch (middleware wrapper):**
```ts
import { createClient } from "@elizaos/client"; // illustrative
import { Mem0 } from "@mem0/client";            // illustrative

const mem0 = new Mem0({ baseUrl: process.env.MEM0_BASE_URL!, apiKey: process.env.MEM0_API_KEY! });

async function mem0WrappedCompletion(input: {
  userId: string;
  messages: Array<{ role: "system" | "user" | "assistant"; content: string }>;
}) {
  // 1) Pull context
  const memoryContext = await mem0.memory.getContext({ userId: input.userId });

  // 2) Append memory context (implementation-specific)
  const messages = [
    { role: "system", content: `Relevant memory:\n${memoryContext}` },
    ...input.messages,
  ];

  // 3) Run inference (your provider can be OpenAI-compatible)
  const client = createClient({
    provider: "openai-compatible",
    baseUrl: process.env.LLM_BASE_URL!,
    apiKey: process.env.LLM_API_KEY!,
  });

  const output = await client.chat.completions.create({
    model: process.env.LLM_MODEL!,
    messages,
  });

  // 4) Upsert memory after responding
  await mem0.memory.ingest({
    userId: input.userId,
    messages: input.messages.concat([{ role: "assistant", content: output.choices[0].message.content }]),
  });

  return output;
}
```

**Next requested work:** formalize this as an ElizaOS memory provider (or documented plugin pattern) so newcomers asking “memU/mem0 wiring” have a canonical recipe.

> Reference (discussion context): MEM0 plugin description + newcomer memory question (Discord, 2026-03-02 / 2026-03-03)

### Skill-loader plugin: convert OpenClaw skills → ElizaOS plugins
A “skill-loader” plugin was proposed to translate OpenClaw `skill` / `skill.md` artifacts into ElizaOS plugins, reducing friction for teams migrating skills across ecosystems.

**Developer takeaway:** expect a path where skill definitions can be ingested and surfaced as ElizaOS actions/tools without rewriting everything by hand.

> Reference (discussion context): skill-loader plugin announcement (Discord, 2026-03-02)

### APEX Oracle v0.5.0 plugin action for Solana trading agents
APEX Oracle introduced an ElizaOS plugin exposing an `APEX_TOKEN_SCAN` action returning structured JSON optimized for LLM context. The aim is to detect market manipulation patterns that basic checks miss (Sybil clusters, wash trading, MEV toxicity).

**Illustrative agent usage pattern:**
```ts
// Pseudocode: incorporate APEX_TOKEN_SCAN into a decision loop
const scan = await agent.actions.invoke("APEX_TOKEN_SCAN", {
  mint: "So11111111111111111111111111111111111111112",
  lookbackSlots: 50_000,
});

if (scan.oar < 0.35 || scan.mevToxicityScore > 0.7) {
  return agent.reply("Skipping trade: token shows high recycling/MEV risk.");
}

return agent.reply(`Risk looks acceptable. OAR=${scan.oar}, MEV=${scan.mevToxicityScore}`);
```

**Call for devs:** stress-test the v0.5.0 API with real trading workloads and report impact on decision quality / win rate.

> Reference (discussion context): APEX Oracle v0.5.0 + action contract summary (Discord, 2026-03-02)

## 3) Bug Fixes (Critical / High impact)

### Heartbeat plugin scheduling correctness & lifecycle integration
**Issue:** cron-like plugins that self-schedule can drift from agent lifecycle management (duplicate timers after hot reload, missed shutdown cleanup, inconsistent environment/config binding).  
**Fix direction:** integrate with `plugin-bootstrap` task service so the runtime owns scheduling and teardown.

**Impact:** fewer “ghost intervals,” predictable start/stop, better future compatibility with centralized task observability.

> Reference (discussion context): heartbeat plugin updated to use task service (Discord, 2026-03-02)

### Operational issue reported: auto.fun “stuck balances”
Multiple users reported stuck balances on auto.fun; one user indicated it was resolved but without posted steps. This is not a core ElizaOS fix, but it’s relevant if your agents automate interactions with that platform.

**Recommendation:** if you maintain an integration, add:
- idempotent retries,
- explicit settlement status polling,
- and user-visible “pending” state handling.

> Reference (discussion context): auto.fun stuck balance reports (Discord, 2026-03-02)

## 4) API Changes

No concrete, merged API signature changes were identified in the provided GitHub/Discord dataset for this window.

**However, there is an emerging “soft contract”:**
- Periodic work should be expressed via the framework task service (rather than ad-hoc timers).
- Memory integrations are trending toward middleware-style wrapping of inference calls (MEM0-like “base URL” pattern).

If you publish plugins, consider documenting:
- required runtime services (task service, memory adapter),
- expected JSON schemas for actions (as APEX does),
- and provider compatibility assumptions (OpenAI-compatible, etc.).

## 5) Social Media Integrations (Twitter / Telegram / Discord / Farcaster)

No plugin changes for Twitter, Telegram, Discord, or Farcaster were captured in the provided dataset for 2026-03-02 → 2026-03-05.

**Related note:** a “Profile Plugin” concept (auto-build user profiles from social sources) exists in prior roadmap discussions; if you’re building social ingest, consider aligning your data model with that direction.

## 6) Model Provider Updates

### OpenAI-compatible APIs: confirmed supported “since day one”
ElizaOS continues to support **OpenAI-compatible** providers, which is increasingly important as third-party inference APIs proliferate.

**Minimal configuration example (OpenAI-compatible):**
```ts
const client = createClient({
  provider: "openai-compatible",
  baseUrl: process.env.OPENAI_COMPAT_BASE_URL!, // e.g. "https://api.your-provider.com/v1"
  apiKey: process.env.OPENAI_COMPAT_API_KEY!,
});

const resp = await client.chat.completions.create({
  model: "your-model-name",
  messages: [{ role: "user", content: "hello" }],
});
```

**Why this matters:** it enables swapping providers without changing agent logic—especially when providers mimic the OpenAI schema but differ in rate limits, tokenization, tool-call quirks, or streaming semantics.

> Reference (discussion context): OpenAI-compatible API support confirmation (Discord, 2026-03-03)

## 7) Breaking Changes (V1 → V2 migration warnings)

No new breaking changes were reported in the provided dataset this week.

**Migration caution (practical):**
- If you are moving V1-era plugins that use their own schedulers, expect to refactor toward the V2 task service patterns (as with the Heartbeat plugin).
- If you are adopting new memory backends (memU/mem0), avoid tightly coupling memory to a single provider; wrap it as a middleware/adapter so you can swap stores without rewriting agent logic.

## References & Links
- Framework docs (Mintlify): https://elizaos-eliza.mintlify.app/introduction  
- Discord invite (shared for onboarding): https://discord.gg/elizaos  
- Prior core PR references (latest available in provided data snapshot):
  - DB refactor: https://github.com/elizaos/eliza/pull/6509
  - SAID protocol: https://github.com/elizaos/eliza/pull/6510
  - N8N workflow REST API: https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/16