# ElizaOS Developer Update (2026-01-18 → 2026-01-21)

This update aggregates GitHub activity, PR review context, and developer Discord discussions for the past week.

---

## 1) Core Framework (Runtime / Architecture / Plugins)

### V2 runtime direction: “runtime-first” + dynamic execution (in progress)
Work continues toward ElizaOS **v2.0.0** with a runtime-first architecture that strips out “non-essentials” (app/server/CLI) in favor of a smaller core runtime surface and a clearer plugin boundary.

- **V2.0.0 working branch (large refactor)**: https://github.com/elizaos/eliza/pull/6351  
  > Notes: this PR is intentionally sweeping (removes app/server/CLI and focuses on Rust/TypeScript runtimes + critical plugins). Expect churn until it stabilizes.

- **Dynamic execution engine for v2.0.0 (opened; context-handling tests underway)**  
  Referenced in Discord as active work; track via the v2.0.0 PR/branch above until the execution-engine PR is linked publicly.

### WASM runtime support (v2 track)
A major enabler for “run agents anywhere” is making the Rust runtime WASM-compatible.

- **WASM agent runtime (v2.0.0)**: https://github.com/elizaos/eliza/pull/6363  
  Adds platform-aware trait bounds and a real `WasmAgentRuntime` wrapper around `AgentRuntime` for browser/Node.js environments.

### Multi-step reliability + entity initialization review feedback
Multi-step robustness work is already in flight, but this week included important review feedback about entity handling and batching.

- **Multi-step retry logic + parsing robustness**: https://github.com/elizaos/eliza/pull/6286  
- Discord reviewer feedback (core-dev): PR **#6286** should likely refactor to an `ensureEntities([...])`-style batch API instead of repeated per-entity operations. This is relevant for:
  - reducing DB round-trips
  - preventing partial initialization failures
  - keeping runtime init idempotent

---

## 2) New Features (with technical detail + examples)

### (Planned) “Context window gating” to reduce chattiness & inference spend
In `💬-coders`, a concrete tactic was proposed to reduce unwanted agent interjections and hallucinations: pass **the last N messages (e.g., 20)** to a lightweight “should respond?” decision step.

**Developer intent**
- Make response triggering depend on conversational context (mentions, direct questions, agent role), not just the most recent message.
- Avoid paying inference cost when the message is not directed at the agent.

**Sketch: prompt gating pattern (TypeScript-like pseudocode)**
```ts
// Example: pre-inference gate before full response generation
async function shouldRespond(runtime: AgentRuntime, roomId: string, incoming: Message) {
  const recent = await runtime.getMessages({ roomId, limit: 20 }); // proposed pattern
  const gatePrompt = buildGatePrompt(recent, incoming);

  const verdict = await runtime.useModel(ModelType.TEXT_SMALL, {
    prompt: gatePrompt,
    temperature: 0.0,
  });

  return verdict.text.includes("RESPOND=true");
}

if (await shouldRespond(runtime, roomId, incoming)) {
  await runtime.handleMessage(incoming);
}
```

**Follow-ups**
- Verify whether entity tracking / mention detection already exists in core (DorianD noted similar behavior on X/Twitter).
- If it exists, expose it as a reusable `shouldRespond()` utility (core or plugin-bootstrap).

### “Swarm” deployment pattern (multi-bot single host)
A “swarm” deployment was described as a cost-optimized architecture: **one large ElizaOS instance running multiple bots** sharing the same environment/resources (currently used for Babylon’s Discord).

**Why it matters**
- Lower per-agent overhead (shared caches, shared DB pools, shared plugin processes)
- Better utilization for many low-traffic bots

**Expected future direction**
- Integrate swarm orchestration into **ElizaCloud** so developers can choose:
  - isolated runtime per agent (strong isolation)
  - shared swarm runtime (cost-optimized)

---

## 3) Bug Fixes (critical fixes with context)

### Fixed: embedding dimension hardcoded to `dim_1536` (SQL adapter)
A critical DB error was resolved where the database adapter was hardcoding a `dim_1536` column, which broke:
- entity creation
- deployments that do **not** use OpenAI embeddings
- deployments where `USE_OPENAI_EMBEDDING` should control embedding behavior

**Impact**
- Removes a class of schema mismatch failures when embedding providers/dimensions differ.
- Restores respect for `USE_OPENAI_EMBEDDING` configuration.

> Tracking note: the Discord daily report confirms this fix is completed/closed; link the PR/commit once it’s published in the repository history.

### Open integration issues to track (not fixed yet)
- Discord plugin compatibility with ElizaCloud reported in Discord (unresolved):  
  *Investigate `elizaos-plugins/plugin-discord` package behavior in cloud deployment pipeline.*
- Telegram plugin crash during image processing:
  - Issue: https://github.com/elizaos-plugins/plugin-telegram/issues/23

---

## 4) API Changes (developer-visible)

### CLI documentation reference (but upgrade docs missing)
- CLI reference exists: https://docs.elizaos.ai/cli-reference/overview  
- Missing: “how to upgrade CLI” instructions (acknowledged in `core-devs`). Please watch docs updates; until then, pin CLI versions in CI to avoid surprise upgrades.

### serverId → messageServerId migration (recent but still affecting devs)
Although merged earlier in January, it continues to surface as a practical integration concern (Discord plugin compatibility).

- Fix/migration PR: https://github.com/elizaos/eliza/pull/6333  
If you maintain plugins or custom transports, confirm you are using `messageServerId` in room/world contexts.

**Quick audit tip**
```bash
rg "serverId" packages/ plugins/ examples/ -g'*.ts' -g'*.tsx'
```

---

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

### Discord
- Voice/channel utilities overhaul (ongoing): https://github.com/elizaos-plugins/plugin-discord/pull/42  
- “Undefined sendMessage” bug report (new): https://github.com/elizaos-plugins/plugin-discord/issues/43  
- Cloud compatibility report (Discord discussion): not yet linked to a GitHub issue—recommended to open one with:
  - ElizaCloud deployment logs
  - plugin version (`elizaos-plugins/plugin-discord`)
  - core runtime version (e.g., `1.7.2` mentioned in community)

### Telegram
- Community demonstrated a production Telegram moderation bot (“Solimp”) with:
  - spam/scam deletion
  - **exponential mute timeouts** (60s → 120s → 240s → …)
  - admin review/unmute flow  
This is a useful reference architecture for moderation-focused agents; consider extracting it into an example plugin/project once the crash issue above is resolved.

### Twitter / X
- “Agentic onboarding” demo: migrating a Twitter profile “to space” with a single prompt (Sentient Space platform). This highlights where social identity ingestion + agent bootstrap flows are heading, but no PR is linked yet.

*(No Farcaster-specific changes were reported this week.)*

---

## 6) Model Provider Updates (OpenAI / Anthropic / DeepSeek / etc.)

### OpenAI embeddings configuration respected again
The embedding dimension SQL fix restores correct behavior when `USE_OPENAI_EMBEDDING` is toggled, reducing provider-coupled assumptions in storage.

### Experimental provider work: RLM prototype (draft)
A draft PR proposes integrating a Recursive Language Model provider into the Python core as an opt-in backend:

- Draft PR: https://github.com/elizaos/eliza/pull/6383

**Key developer note**
- This is exploratory and not registered by default.
- Treat it as an experiment in “provider boundary design” (reasoning backend swap) rather than a supported provider.

---

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

### V2.0.0 is not a drop-in upgrade
The v2.0.0 effort explicitly removes or de-emphasizes components many v1 developers rely on (app/server/CLI packaging assumptions), favoring a smaller runtime core.

- Track: https://github.com/elizaos/eliza/pull/6351

**What to expect**
- **Project layout changes** (monorepo structure, package entrypoints)
- **Runtime API shifts** as Rust/TS parity is established
- **Plugin porting requirements** (critical plugins first; long-tail later)
- New runtime targets (WASM) will introduce environment-specific constraints (no threads / `Send` differences) as seen in: https://github.com/elizaos/eliza/pull/6363

**Migration guidance (practical)**
- If you ship production agents today, pin to v1.x and upgrade intentionally.
- Avoid relying on internal paths that are likely to be deleted as v2 trims the surface area.
- Plugin authors should validate compatibility around:
  - message server identity (`messageServerId`)
  - entity initialization semantics (`ensureConnection`, `ensureEntities` direction)
  - storage embedding dimension assumptions (now fixed, but plugins may still assume 1536)

---

### Relevant links recap
- CLI reference: https://docs.elizaos.ai/cli-reference/overview  
- V2.0.0 branch PR: https://github.com/elizaos/eliza/pull/6351  
- WASM runtime PR: https://github.com/elizaos/eliza/pull/6363  
- Multi-step retry PR: https://github.com/elizaos/eliza/pull/6286  
- serverId → messageServerId PR: https://github.com/elizaos/eliza/pull/6333  
- Discord voice utilities PR: https://github.com/elizaos-plugins/plugin-discord/pull/42  
- Discord sendMessage bug: https://github.com/elizaos-plugins/plugin-discord/issues/43  
- Telegram image crash: https://github.com/elizaos-plugins/plugin-telegram/issues/23  
- Draft RLM provider PR: https://github.com/elizaos/eliza/pull/6383