# ElizaOS Developer Update (2026-02-08 → 2026-02-14)

## 1) Core Framework

### Multi-language “Next” runtime direction (TS + Python + Rust)
Work this week continued toward the V2/“next” architecture: ElizaOS core runtime and key plugins are being expanded beyond TypeScript into **Python and Rust**, with a corresponding repo/layout shift that de-emphasizes bundled “app/server/CLI” in favor of a lean runtime + examples.

Relevant PRs (tracking/active):
- V2 working branch: **“next”** ([elizaos/eliza#6474](https://github.com/elizaos/eliza/pull/6474))
- Next-gen multi-language support: ([elizaos/eliza#6485](https://github.com/elizaos/eliza/pull/6485))
- Large V2 umbrella branch: ([elizaos/eliza#6351](https://github.com/elizaos/eliza/pull/6351))

Key runtime behavior changes called out in the V2/next PR descriptions:
- Agents can respond without requiring `roomId` / `worldId` (important for “stateless” or external transport adapters).
- `planningMode` can be disabled to force a single action pass (useful for games/simple agents).
- Actions can accept **arguments**, enabling “tool-like” calls without extra orchestration steps.

### Security & multi-tenant foundations: JWT auth + request-scoped settings
Two foundational security/multi-user initiatives landed recently and were heavily referenced in week context:

- **JWT authentication & user management** (gated behind `ENABLE_DATA_ISOLATION=true`)  
  PR: [elizaos/eliza#6200](https://github.com/elizaos/eliza/pull/6200)

- **RequestContext (AsyncLocalStorage) for per-entity settings resolution**  
  PR: [elizaos/eliza#6457](https://github.com/elizaos/eliza/pull/6457)

The net effect: `runtime.getSetting(key)` can now resolve settings from the **originating request/entity context**, instead of only from global agent settings—critical for shared runtimes (e.g., SaaS / ElizaCloud / multiplexed deployments).

### Prompt bloat reduction: ActionFilterService
A new filtering layer reduces the number of actions/providers pushed into model context by ranking for relevance:
- PR: [elizaos/eliza#6475](https://github.com/elizaos/eliza/pull/6475)

Implementation highlights:
- Two-stage ranking: **vector similarity** + **BM25 reranking**
- Typical reduction: ~200+ actions → ~15 “most relevant” actions presented to the LLM

### Plugin runtime stability & performance work in plugin-bootstrap
Ongoing hardening and optimization in `plugin-bootstrap`:
- Robustness/perf improvements: [elizaos/eliza#6476](https://github.com/elizaos/eliza/pull/6476)
- CI repair mentioned by core devs: [elizaos/eliza#6477](https://github.com/elizaos/eliza/pull/6477) (Discord callout focused on CI stability)

### MCP multi-tenant safety
`plugin-mcp` reworked connection handling to prevent cross-user leakage in shared environments:
- PR: [elizaos-plugins/plugin-mcp#24](https://github.com/elizaos-plugins/plugin-mcp/pull/24)

## 2) New Features

### Per-request entity settings via RequestContext (multi-tenant safe configuration)
PR: [elizaos/eliza#6457](https://github.com/elizaos/eliza/pull/6457)

This enables patterns like “same runtime, different upstream credentials per user/session” without threading settings through every call.

**Example (TypeScript): request-scoped settings**
```ts
import { RequestContext } from "@elizaos/core";

await RequestContext.withEntity(
  {
    entityId: "user_123",
    settings: {
      OPENAI_API_KEY: process.env.OPENAI_KEY_FOR_USER_123,
      TWITTER_ACCESS_TOKEN: process.env.TW_USER_123_TOKEN,
    },
  },
  async () => {
    // getSetting() will resolve from the current entity context first
    const key = runtime.getSetting("OPENAI_API_KEY");
    const modelResult = await runtime.useModel("TEXT_LARGE", {
      messages: [{ role: "user", content: "Hello from a tenant-scoped key." }],
    });

    return modelResult;
  }
);
```

### ActionFilterService (vector + BM25) to reduce context size and cost
PR: [elizaos/eliza#6475](https://github.com/elizaos/eliza/pull/6475)

If you maintain large plugin suites, expect materially smaller prompts and fewer “tool confusion” failures.

**Practical impact**
- Lower token usage (especially with many installed plugins)
- Faster inference
- Better tool selection precision

### ElizaCloud authentication roadmap: SIWE (EIP-4361) planned
From core-dev Discord discussions (2026-02-11): ElizaCloud is adding **SIWE** to support agent-native signup and **API key generation via signature**, building toward a “proof-of-agent” registration flow.
- Discord context: SIWE commitment by Odilitime; collaboration with Privy; agents generating API keys for cloud access.
- Public roadmap referenced: https://github.com/elizaos/roadmap

**Developer note:** This is not merged in the framework repo yet, but it will affect how cloud clients authenticate (expect wallet-signature flows and/or Privy-backed identity options).

## 3) Bug Fixes (with technical context)

### Prevent runtime crashes from null/undefined metadata in bootstrap providers
Several crashes were caused by unsafe `Object.entries()` / property access when provider inputs were null-ish.

Fixes:
- `@elizaos/core` settings utility null guards: [elizaos/eliza#6471](https://github.com/elizaos/eliza/pull/6471)
- `plugin-bootstrap` provider null guard for `runtime.providers`: [elizaos/eliza#6473](https://github.com/elizaos/eliza/pull/6473)

**Why it mattered:** these faults could crash an agent mid-turn, often manifesting as “IGNORE” behavior or missing context when the provider chain failed.

### MESSAGE_SENT event emission restored after central-bus submission
Bug: plugins listening for `EventType.MESSAGE_SENT` weren’t triggered when responses were submitted to `/api/messaging/submit`.

Fix:
- PR: [elizaos/eliza#6378](https://github.com/elizaos/eliza/pull/6378)
- Original issue: [elizaos/eliza#5216](https://github.com/elizaos/eliza/issues/5216)

**Impact:** event-driven plugins (analytics, notifications, external sinks) regain reliable delivery semantics.

### CI stability work
Core dev mention: CI fix PR [elizaos/eliza#6477](https://github.com/elizaos/eliza/pull/6477) (Discord 2026-02-10).  
If you pin to main and saw intermittent CI failures, track that PR and the corresponding workflow updates.

### Open regressions/bugs to watch
- Webapp duplicate LLM calls when message contains a URL (processed as text + attachment):  
  Issue: [elizaos/eliza#6486](https://github.com/elizaos/eliza/issues/6486)
- Babylon feedback “share to Farcaster” link incorrect (Discord report; not yet linked to a GH issue in provided data).

## 4) API Changes (developer-facing)

### Auth: JWT mode + CLI auth ergonomics
- JWT auth system: [elizaos/eliza#6200](https://github.com/elizaos/eliza/pull/6200)
- CLI now loads `.env` for agent commands when connecting to secured servers:  
  PR: [elizaos/eliza#6376](https://github.com/elizaos/eliza/pull/6376)
- Environment variable reference added:  
  Docs PR: [elizaos/eliza#6377](https://github.com/elizaos/eliza/pull/6377)

**Server-side config (example)**
```bash
export ENABLE_DATA_ISOLATION=true
export ELIZA_SERVER_AUTH_TOKEN="your-server-token"
```

### Settings resolution now supports request-scoped override
If you rely on `runtime.getSetting()`, note the new precedence path when RequestContext is active (entity-scoped settings can override agent defaults):
- Feature PR: [elizaos/eliza#6457](https://github.com/elizaos/eliza/pull/6457)

### CLI scaffolding now pins @elizaos dependencies to “latest”
This reduces “alpha tag not found” failures when creating projects with a locally linked CLI:
- PR: [elizaos/eliza#6362](https://github.com/elizaos/eliza/pull/6362)

## 5) Social Media Integrations

### Twitter / X plugin: adoption via OpenClaw adapter fork
Discord (2026-02-11): developers reported successfully using **Eliza’s Twitter plugin** inside OpenClaw instead of OpenClaw’s native Twitter implementation, citing:
- better operational quality
- reduced ban-risk approaches

Action item from Discord: a community fork is expected to be published on GitHub by the contributor (`azsxdc`). Track Discord thread for the repo link until it’s posted.

### Farcaster
- Known issue: Babylon feedback “share to farcaster” link rendering incorrectly (reported in Discord 2026-02-10). Recommend postponing reliance on that share link until fixed/verified.

### Discord / Telegram
No merged plugin PRs were referenced in the provided week data, but ElizaCloud discussions continue to highlight “agent-accessible” API/CLI flows as a priority (which will affect how social bots authenticate against cloud services).

## 6) Model Provider Updates

### OpenAI plugin: persistent media caching (cost + latency reduction)
- PR: [elizaos-plugins/plugin-openai#23](https://github.com/elizaos-plugins/plugin-openai/pull/23)

**What changed:** image/audio outputs are cached to avoid repeated generation and redundant API billing.

### OpenAI-compatible endpoints requested (third-party inference)
Open issue requesting configurable base URL for OpenAI provider:
- Issue: [elizaos/eliza#6490](https://github.com/elizaos/eliza/issues/6490)

If you run OpenAI-compatible providers (e.g., SiliconFlow-style endpoints), follow this issue; it likely implies a future provider config expansion like `OPENAI_BASE_URL`.

### ElizaCloud LLM integration update planned
Discord (2026-02-11): after recent cloud API improvements, the next step called out is updating cloud-side LLM functionality (details pending).

## 7) Breaking Changes / V1 → V2 Migration Warnings

### V2 (“next”) removes bundled defaults and changes project shape
The V2/next branches explicitly:
- remove default application/client/server scaffolding in favor of runtime + examples
- introduce multi-language core packages (Rust/Python/TS)
- change some runtime assumptions (e.g., response without `roomId/worldId`, new action argument patterns)

Tracking PRs:
- [elizaos/eliza#6474](https://github.com/elizaos/eliza/pull/6474)
- [elizaos/eliza#6485](https://github.com/elizaos/eliza/pull/6485)
- [elizaos/eliza#6351](https://github.com/elizaos/eliza/pull/6351)

**Migration guidance (high-level)**
- Do not assume `packages/server` / webapp client remain the default entrypoints in V2.
- If you depend on current plugin bootstrap/provider behavior, re-test with ActionFilterService enabled (tool visibility changes can alter agent behavior).
- If you run multi-tenant workloads, prefer RequestContext patterns rather than globally-scoped env settings.

### Cloud auth direction will shift (SIWE/Privy)
ElizaCloud’s authentication flow is expected to evolve toward signature-based onboarding (SIWE) and agent-friendly API key provisioning. Plan for auth integration changes if you maintain cloud automation tooling.

**Docs & references**
- Public roadmap: https://github.com/elizaos/roadmap
- Core docs landing (architecture, concepts, plugins, deployment, API reference): [elizaos/eliza#6356](https://github.com/elizaos/eliza/pull/6356)
- Environment variables doc: [elizaos/eliza#6377](https://github.com/elizaos/eliza/pull/6377)