# ElizaOS Developer Update — Week of 2026-02-08 to 2026-02-14

This update summarizes GitHub activity across `elizaos/eliza` and key plugin repos, plus notable developer Discord discussions relevant to builders shipping on ElizaOS.

---

## 1) Core Framework (Architecture / Runtime / Plugin System)

### Multi-language “next-gen” runtime direction (TypeScript + Rust + Python)
Work continued on the v2 line focused on a runtime-first distribution with native Rust/Python packages and ported “core” plugins, while stripping non-essentials (app/server/CLI) from the default bundle:

- PR (open): **“feat: next generation multi-language Eliza with Rust, Python and TypeScript support”** — https://github.com/elizaos/eliza/pull/6485  
- PR (open): **“next”** — https://github.com/elizaos/eliza/pull/6474  
- PR (open): **“V2.0.0”** — https://github.com/elizaos/eliza/pull/6351

Key runtime semantics called out in the v2 PR descriptions:
- Agents can respond without `roomId`/`worldId` (addresses common onboarding friction and aligns with “Chat-style” use cases).
- `planningMode` can be toggled to skip planning for game-like/simple agents.
- Actions can be invoked with **arguments**, closer to “tool call” ergonomics.

### Per-request entity settings via RequestContext (multi-tenant readiness)
A new request-context mechanism was introduced to allow **per-entity (per-user / per-tenant) settings resolution** without threading entity IDs through every call site.

- PR (merged): **feat(core): add request context for per-user entity settings** — https://github.com/elizaos/eliza/pull/6457

**Technical impact**
- `runtime.getSetting()` now checks **RequestContext** first (entity-scoped settings), then falls back to agent/global settings.
- Implemented using AsyncLocalStorage (Node) to propagate request-scoped identity.

**Example usage**
```ts
import { RequestContext } from "@elizaos/core";

// Wrap inbound requests (HTTP, Socket.IO, etc.)
await RequestContext.withEntitySettings(
  { entityId: "org_123:user_456", settings: { OPENAI_API_KEY: "..." } },
  async () => {
    // Any downstream code can now resolve per-entity settings
    const key = runtime.getSetting("OPENAI_API_KEY");
    // ...
  }
);
```

### ActionFilterService to reduce prompt bloat (vector search + BM25 rerank)
ElizaOS added a dynamic filtering layer that selects the most relevant actions/providers before constructing model context.

- PR (merged): **feat: ActionFilterService — vector search + BM25 reranking** — https://github.com/elizaos/eliza/pull/6475

**Why it matters**
- Reduces the “200+ actions in context” problem to ~10–20 highly relevant entries, lowering token usage and improving tool selection precision.
- Two-stage ranking:
  1) vector similarity search
  2) BM25 reranking for lexical precision

---

## 2) New Features (with developer-facing details & examples)

### JWT authentication & user management (server + client + DB schema)
A comprehensive JWT auth layer landed, enabling safer multi-user operation and external identity provider integrations.

- PR (merged): **feat(auth): implement JWT authentication and user management** — https://github.com/elizaos/eliza/pull/6200

**Activation / behavior**
- Gated by `ENABLE_DATA_ISOLATION=true` (per PR notes).
- Adds server middleware, credential endpoints, and DB schema updates (`plugin-sql` schema additions) for user management and isolation.

**Related docs**
- Environment variable reference: https://github.com/elizaos/eliza/pull/6377  
  (renders as `docs/environment-variables.md` in repo)

### V2 dynamic execution engine (validation-aware prompt execution)
A new schema-driven prompt execution path was introduced across TS/Rust/Python v2 runtimes.

- PR (merged): **V2.0.0: dynamic execution engine** — https://github.com/elizaos/eliza/pull/6384

This adds a safer execution path intended to detect/avoid context explosions and enforce schema validation during prompt compilation/execution.

### Plugin ecosystem expansion (registry + chain plugins)
This week’s plugin work continued pushing ElizaOS toward production-grade onchain + “real-world data” integrations:

- Registry:
  - Proofgate transaction guardrails — https://github.com/elizaos-plugins/registry/pull/254  
  - Escrow services — https://github.com/elizaos-plugins/registry/pull/246  
  - Sportradar sports data — https://github.com/elizaos-plugins/registry/pull/250  
  - MoltBazaar (agent job marketplace on Base) — https://github.com/elizaos-plugins/registry/pull/255

- Solana:
  - Cloud Proxy routing (Birdeye/Helius fallback strategy) — https://github.com/elizaos-plugins/plugin-solana/pull/26  
  - Transaction refactor (Token-2022 support, exchange-driven swaps) — https://github.com/elizaos-plugins/plugin-solana/pull/24  

- EVM:
  - Multi-provider RPC abstraction with fallback — https://github.com/elizaos-plugins/plugin-evm/pull/25  
  - EVMService redesign (wallet mgmt, portfolio, multicall) — https://github.com/elizaos-plugins/plugin-evm/pull/24  

### OpenAI provider: persistent media caching (cost + latency reduction)
- PR (merged): **persistent media caching for audio/images** — https://github.com/elizaos-plugins/plugin-openai/pull/23

This avoids re-uploading / re-processing identical media, reducing redundant calls and speeding up responses.

---

## 3) Bug Fixes (critical fixes + technical context)

### “Object.entries requires…” runtime crashes in bootstrap and settings utilities
Several production-impacting crashes were fixed by adding defensive guards around null/undefined values.

- PR (merged): **fix: add null checks to Object.entries calls in settings utilities** — https://github.com/elizaos/eliza/pull/6471  
- PR (merged): **fix(plugin-bootstrap): add null check for runtime.providers** — https://github.com/elizaos/eliza/pull/6473  
- Related (open, large/scope-mixed): https://github.com/elizaos/eliza/pull/6470

**What was happening**
- Providers (e.g., relationships/actionState/recentMessages) were calling `Object.entries()` on values that can legitimately be nullish in partially-initialized states or edge-case messages, causing agent crashes and “IGNORE” behavior.

**Developer takeaway**
- If you author providers, treat all persisted/remote data as nullable—especially `metadata`, `workingMemory`, and action result payloads.

### MESSAGE_SENT event not emitted when forwarding to central server
- PR (merged): **fix(server): emit MESSAGE_SENT event after sending to central server** — https://github.com/elizaos/eliza/pull/6378  
Fixes issue where downstream systems relying on MESSAGE_SENT (metrics, audit trails, UI state) were not seeing the event for centralized bus delivery paths.

### CLI reliability fixes for remote auth + template resolution
- PR (merged): **fix(cli): load .env files in agent commands for authentication** — https://github.com/elizaos/eliza/pull/6376  
- PR (merged): **fix(cli): always use 'latest' for @elizaos deps in created projects** — https://github.com/elizaos/eliza/pull/6362  
- PR (merged): **fix(cli): validate directory path in ensureDir** — https://github.com/elizaos/eliza/pull/6379  

These resolve common failures when using a secured remote server (`ELIZA_SERVER_AUTH_TOKEN`) and when generating projects from a linked monorepo/alpha version context.

---

## 4) API Changes (what to update in your code)

### Auth surface area additions (server API)
JWT auth introduced/expanded endpoints and middleware chains:
- See merged PR for routes and tests: https://github.com/elizaos/eliza/pull/6200  
- Env var docs: https://github.com/elizaos/eliza/pull/6377

**Action item for integrators**
- If you proxy ElizaOS server APIs, ensure your gateway forwards `Authorization` headers and supports JWT verification behavior when `ENABLE_DATA_ISOLATION=true`.

### Settings resolution precedence changed (RequestContext first)
Because RequestContext now participates in `runtime.getSetting()`, settings can be different per request/entity even under the same runtime process:

- PR: https://github.com/elizaos/eliza/pull/6457

**Migration note**
- Code that assumed `getSetting()` returns a single global value may now observe different values under different request wrappers. This is intended for multi-tenant deployments.

---

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

### X (Twitter) first-post failures tied to `roomId`
Discord reported an agent failing to make its first post on X due to a `roomId`-related error (investigation ongoing). This aligns with broader work in v2 to allow responses without `roomId/worldId`, but no merged fix was linked this week.

- Discord context (Feb 13): user report “roomId error preventing first post”; follow-up requested by Odilitime.

**If you hit this now (workaround guidance)**
- Ensure your social plugin pipeline creates/derives a room/thread identifier before the first outbound post, or run on the v2 runtime line once that behavior is merged/released (see PRs #6474/#6485).

No Telegram/Discord/Farcaster plugin PRs were surfaced in the provided GitHub summary for this week.

---

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

### OpenAI
- Media caching landed: https://github.com/elizaos-plugins/plugin-openai/pull/23
- New request (open issue): **custom endpoint URL for OpenAI-compatible providers** (e.g., SiliconFlow)  
  https://github.com/elizaos/eliza/issues/6490

**Expected direction**
- Likely addition of an `OPENAI_BASE_URL` (or similar) to support OpenAI-compatible APIs. If you maintain providers, avoid hardcoding base URLs.

### DeepSeek (community implementation note)
A community dev (funboy) implemented a DeepSeek-chat based solver for Moltbook’s anti-bot “verification_required” flow by:
- intercepting verification responses,
- extracting obfuscated math problems,
- solving within 30 seconds,
- posting formatted answers (e.g., `"25.00"`).

This is not yet a merged ElizaOS plugin PR, but it is a concrete integration pattern for hostile/verified endpoints.

---

## 7) Breaking Changes / V1 → V2 Migration Warnings (read before upgrading)

### V2 removes “non-essentials” from the default distribution
The v2 PRs explicitly remove the default app/server/CLI and center the runtime + multi-language packages.

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

**Implications**
- If your deployment relies on the monorepo-provided server/webapp scaffolding, you should not assume v2 ships those components in the same way.
- Expect changes in:
  - bootstrapping entrypoints
  - package layout
  - examples as the canonical starting point (instead of a bundled app)

### Runtime behavior changes
From v2 descriptions (subject to change until merged/released):
- Responses may no longer require `roomId/worldId`.
- `planningMode=false` changes control flow (skips planning; calls a single action).
- Actions accepting arguments may change how tool invocations are authored and logged.

### Recommendation
- Treat v2 as a new integration target; plan a migration pass rather than an in-place upgrade.
- Start by reviewing:
  - v2 runtime PR: https://github.com/elizaos/eliza/pull/6485
  - core concepts / plugin dev docs (merged): https://github.com/elizaos/eliza/pull/6356

---

### Appendix: Operational Notes from Discord (platform/admin relevant to devs)

- **Token migration is closed** (ai16z → elizaOS, 1:6 ratio). Migration support channels are locked; only pre-deadline tickets are processing. (Operational; not a code change.)
- **Cloud credits** can be manually updated via DB `UPDATE`, and OAuth-created accounts may require lookup by org slug or account ID (email not always searchable immediately). This surfaced as a practical constraint for internal tooling/ops flows.