# Developer Update (ElizaOS) — Week of 2026-02-01 to 2026-02-07

## 1) Core Framework (architecture / runtime / plugin system)

### Per-request *entity* settings via `RequestContext` (multi-tenant isolation)
Merged: **`feat(core): add request context for per-user entity settings`** ([PR #6457](https://github.com/elizaos/eliza/pull/6457))

ElizaOS core now supports *per-request* settings resolution using `AsyncLocalStorage`, enabling true multi-tenant behavior where multiple users can share a runtime while keeping credentials and settings isolated.

**Key runtime behavior change**
- `runtime.getSetting(key)` now checks the active `RequestContext` first (entity-scoped), then falls back to agent/global settings.
- This removes the need to thread “current user” through every call path and reduces accidental credential leakage in shared deployments.

**Usage example**
```ts
import { RequestContext } from "@elizaos/core";

await RequestContext.withEntity(
  { id: "user_123", metadata: { settings: { OPENAI_API_KEY: process.env.USER123_KEY } } },
  async () => {
    // Inside this callback, settings resolve from the entity first
    const key = runtime.getSetting("OPENAI_API_KEY");
    const res = await runtime.useModel("TEXT_LARGE", {
      messages: [{ role: "user", content: "Hello from a per-user key context" }],
    });
  }
);
```

### Structured, validation-aware execution engine across TS/Python/Rust (V2 track)
Merged: **Dynamic execution engine** ([PR #6384](https://github.com/elizaos/eliza/pull/6384))

This introduces a schema-driven prompt execution path intended to reduce “context blown / truncated structured output” failures by:
- injecting per-field/checkpoint validation codes,
- validating required fields,
- retrying with exponential backoff,
- supporting **JSON + XML** structured formats,
- adding TS streaming helpers (`ValidationStreamExtractor`, `StreamEvent`s).

**Developer-facing entrypoint (TypeScript)**
```ts
const schema = [
  { key: "answer", type: "string", required: true },
  { key: "sources", type: "string", required: false },
] as const;

const out = await runtime.dynamicPromptExecFromState(state, schema, {
  format: "json",
  validationLevel: 2, // 0..3
  maxRetries: 2,
});

if (!out) throw new Error("Model failed validation after retries");
console.log(out.answer);
```

> Note: Review notes flagged potential Python implementation pitfalls in this area; if you are consuming the Python runtime, validate behavior in your environment before depending on advanced validation levels (see PR discussion in [#6384](https://github.com/elizaos/eliza/pull/6384)).

### V2 / “next” branches: large-scale re-architecture in progress (not merged)
Open (not merged):
- **V2.0.0 working branch** ([PR #6351](https://github.com/elizaos/eliza/pull/6351)) — strips app/server/CLI and focuses on runtime + critical plugins.
- **next** ([PR #6474](https://github.com/elizaos/eliza/pull/6474)) — adds Python/Rust core packages, ports plugins across languages, integrates bootstrap capabilities, and changes runtime behavior (see “Breaking Changes” section).

These PRs are substantial and should be treated as **migration targets**, not drop-in updates.

---

## 2) New Features

### Core documentation set (API + architecture + plugin development)
Merged: **docs: core documentation guides** ([PR #6356](https://github.com/elizaos/eliza/pull/6356))

New/updated docs include:
- `docs/ARCHITECTURE.md`
- `docs/CORE_CONCEPTS.md`
- `docs/PLUGIN_DEVELOPMENT.md`
- `docs/DEPLOYMENT_GUIDE.md`
- `docs/API_REFERENCE.md`
- `docs/INTEROP_GUIDE.md`
- `packages/interop/README.md`

This is the canonical starting point for plugin authors and deployment engineers:
- Architecture overview: https://github.com/elizaos/eliza/blob/main/docs/ARCHITECTURE.md  
- Plugin development: https://github.com/elizaos/eliza/blob/main/docs/PLUGIN_DEVELOPMENT.md  
- API reference: https://github.com/elizaos/eliza/blob/main/docs/API_REFERENCE.md  

### Reliability: MESSAGE_SENT event lifecycle made observable (server)
Merged: **emit `MESSAGE_SENT` after sending to central server** ([PR #6378](https://github.com/elizaos/eliza/pull/6378)), fixes **issue #5216** ([EVENT MESSAGE SENT not working](https://github.com/elizaos/eliza/issues/5216))

This restores event-driven plugin workflows that depend on the server successfully submitting the message to `/api/messaging/submit` before emitting the “sent” signal.

**Example: plugin listening for outbound deliveries**
```ts
runtime.bus.on(EventType.MESSAGE_SENT, (evt) => {
  // evt contains message payload metadata after successful submit
  auditLog.write({
    type: "outbound_delivery",
    messageId: evt.messageId,
    transport: evt.transport,
    ts: Date.now(),
  });
});
```

### Ecosystem: Milaidy (Mac-native assistant built on Eliza/OpenClaw)
Community launch (external repo): https://github.com/milady-ai/milaidy

Highlights from core-dev + coders discussions:
- Mac `.app` distribution, **plugin-based minimal-bloat** packaging
- “Agent skills” model aligned with OpenClaw patterns
- Plan: port OpenClaw connectors as Eliza plugins
- Infra exploration: stateful sandboxing model similar to **sprites.dev** (persistent, hardware-isolated execution for agents/untrusted code)

If you’re building desktop runtimes, this project is a live reference architecture for “local-first Eliza + plugin connectors”.

---

## 3) Bug Fixes (critical)

### Server event emission regression: MESSAGE_SENT not firing
Fix shipped in [PR #6378](https://github.com/elizaos/eliza/pull/6378) (issue [#5216](https://github.com/elizaos/eliza/issues/5216))

**Root cause**
- `sendAgentResponseToBus` completed the HTTP submission flow but didn’t emit `EventType.MESSAGE_SENT`, so downstream plugins never observed successful message delivery.

**Impact**
- Any plugin that relied on MESSAGE_SENT hooks (analytics, reconciliation, delivery receipts, post-processing pipelines) silently failed to run.

**Resolution**
- Emit `MESSAGE_SENT` only after successful central server submission, restoring correct event ordering and allowing plugin authors to distinguish “attempted” vs “confirmed submitted”.

### Plugin-bootstrap runtime crashes due to `Object.entries(null|undefined)` (pending PR)
Open PR: **plugin-bootstrap null/undefined guards** ([PR #6470](https://github.com/elizaos/eliza/pull/6470))

This addresses crashes in bootstrap providers when entity metadata or action results contain nullish values, commonly seen in partial/streaming flows or incomplete entity records.

> Important: This PR also includes additional changes beyond the stated title (request context + message service refactors). Review carefully before cherry-picking; consider splitting if you need a low-risk hotfix (see PR notes in [#6470](https://github.com/elizaos/eliza/pull/6470)).

### Babylon production hotfix: profile image upload failure (platform)
From Discord (2026-02-06): profile image updates were failing (“Failed to update profile”); **fix merged and confirmed** by testers. (No PR link in provided data; report via Babylon UI feedback channel.)

---

## 4) API Changes (developer-facing)

### `runtime.getSetting()` now consults `RequestContext`
Merged in [PR #6457](https://github.com/elizaos/eliza/pull/6457)

**Behavioral change**
- If a request is wrapped in `RequestContext.withEntity(...)`, settings resolution becomes entity-first.
- This can change which API keys/tokens are used inside nested calls (model providers, connectors, plugin auth).

**Guidance**
- In shared runtimes, always wrap inbound message handling / webhook handlers in an entity scope to prevent cross-user leakage.
- In single-tenant apps, behavior remains effectively unchanged unless you begin using `RequestContext`.

### Event lifecycle: MESSAGE_SENT emission timing
Merged in [PR #6378](https://github.com/elizaos/eliza/pull/6378)

If your plugin previously assumed MESSAGE_SENT indicated “locally enqueued” behavior, note it now indicates “submitted to central server endpoint successfully”.

---

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

### Telegram webhook registration completed (infra)
Issue closed: **Telegram Webhook Registration** ([#6425](https://github.com/elizaos/eliza/issues/6425))

Telegram routing is now aligned with a webhook-first approach (no polling), ensuring messages can be routed to correct agent instances in cloud environments.

### Discord as AWS service completed (infra)
Issue closed: **Deploy Discord as AWS Service** ([#6424](https://github.com/elizaos/eliza/issues/6424))

Discord plugin is now tracked as a deployable service in AWS for scalable event ingestion and routing.

### Twitter plugin dev friction (local compatibility)
Discord noted unresolved developer question: “which Eliza version works properly with the Twitter plugin locally”. No definitive fix/link in this week’s data; if you maintain the Twitter plugin, consider publishing a compatibility matrix (core version ↔ plugin version) and a minimal local smoke test.

---

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

### Anthropic Opus 4.6 availability window (external tooling)
Discord: Opus 4.6 was available free on bolt.new for 48 hours (with limitations). This is not an ElizaOS provider change, but developers used it for rapid iteration/testing.

### Model selection + validation level controls (V2 execution path)
From [PR #6384](https://github.com/elizaos/eliza/pull/6384):
- validation level configuration (0–3)
- model selection defaults geared toward large text models for structured output reliability
- streaming-aware validation extractors in TS

If you operate cost-sensitive deployments, validate how your `TEXT_SMALL/TEXT_LARGE` mappings interact with schema validation retries (retries can multiply spend unless guarded).

---

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

### V2 branches remove “default app/server/CLI” assumptions
Open PRs (not merged):
- [PR #6351](https://github.com/elizaos/eliza/pull/6351)
- [PR #6474](https://github.com/elizaos/eliza/pull/6474)

**What breaks**
- Projects relying on bundled application/server/CLI scaffolding may no longer build/run unchanged.
- Runtime is being repositioned as the primary deliverable across **Rust + TypeScript + Python**, with examples/starter projects replacing monolithic defaults.

**Runtime behavioral changes (in-progress, per PR #6474)**
- Agents can respond without `roomId/worldId`
- `planningMode=false` enables single-action execution (useful for games/simple agents)
- Actions can accept arguments and be invoked tool-style (may affect existing action invocation conventions)

**Migration guidance (practical)**
1. Pin your dependency versions while V2 PRs are unmerged and moving:
   ```bash
   bun add elizaos@<known-good-version>
   ```
2. If you need multi-tenant safety now, adopt `RequestContext` (merged) without jumping to V2 branches.
3. Track V2 PRs for when a tagged release lands; expect:
   - packaging/layout changes,
   - plugin portability updates,
   - potential refactors to message handling + structured output execution.

---

### Additional operational notes from Discord (security / platform)
- Security concerns were raised about **malicious code in skills** and setup vulnerabilities (no concrete PoC shared publicly). Treat third-party skills/plugins as untrusted: sandbox execution where possible (sprites.dev-style isolated sandboxes were explicitly discussed for this reason).
- ElizaCloud onboarding issues reported: welcome email links routing to `dev.elizacloud.ai` causing duplicate accounts and missing promo credits. This is platform-side but affects developer onboarding funnels; if you embed ElizaCloud flows, verify production link targets and account consolidation paths.