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

This update summarizes core framework and plugin work landing (and discussed) during the week, plus notable open items surfaced in Discord and GitHub.

---

## 1) Core Framework

### Multi-language runtime direction (V2 track)
Work continues toward a V2 runtime that supports **TypeScript + Rust + Python** with parity-focused plugin ports:

- **Next-gen multi-language Eliza (Rust/Python/TS)**: PR **[#6485](https://github.com/elizaos/eliza/pull/6485)** (open)  
- Related “next” working branch: PR **[#6474](https://github.com/elizaos/eliza/pull/6474)** (open)  
- V2 working branch cut: PR **[#6351](https://github.com/elizaos/eliza/pull/6351)** (open)

Key architectural notes called out in these PRs:
- V2 work removes/decouples “default app/server/CLI” components in favor of a slimmer runtime-first distribution.
- Runtime behavior changes discussed include:
  - Agents responding without requiring `roomId` / `worldId`
  - Optional `planningMode` to skip planning for game/simple loops
  - Actions callable with arguments (tool-like invocation)

**Migration warning**: See **Breaking Changes** below—V2 is not a drop-in upgrade for V1 deployments.

---

### Auth & multi-tenant safety: JWT + per-request settings context
Two related tracks landed/advanced that materially change how deployments isolate users and secrets:

- **JWT authentication + user management** (merged): **[#6200](https://github.com/elizaos/eliza/pull/6200)**  
  - Guarded by `ENABLE_DATA_ISOLATION=true` (per PR notes).
  - Adds server middleware, client auth flow, and user schema pieces.

- **RequestContext for per-user/entity settings** (merged): **[#6457](https://github.com/elizaos/eliza/pull/6457)**  
  - Introduces an AsyncLocalStorage-backed request context so `runtime.getSetting()` can resolve **entity-scoped** settings (e.g., per-user API keys) without having to thread parameters through every callsite.
  - This is especially relevant for shared runtimes and hosted/multi-tenant environments.

**Practical implication**: settings resolution is no longer “agent-only”; it can be “request entity → fallback to agent”.

Example usage (Node runtimes) from the new pattern:

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

// Example: set per-entity keys for the duration of a single request/message
await RequestContext.withEntitySettings(
  {
    entityId: "user_123",
    settings: {
      OPENAI_API_KEY: process.env.USER_123_OPENAI_KEY,
      // ...any setting your providers/actions read via runtime.getSetting()
    },
  },
  async () => {
    // Any runtime.getSetting("OPENAI_API_KEY") inside this callback
    // can resolve to the entity-scoped value first.
    await runtime.handleMessage(message);
  }
);
```

Docs to reference:
- Core docs bundle (architecture/concepts/plugin dev/API ref): **[#6356](https://github.com/elizaos/eliza/pull/6356)**  
- Environment variable documentation: **[#6377](https://github.com/elizaos/eliza/pull/6377)**

---

### Prompt/token efficiency: ActionFilterService
To reduce “prompt bloat” in larger agents (200+ actions/providers), ElizaOS added a relevance filtering layer:

- **ActionFilterService (vector search + BM25 reranking)** (merged): **[#6475](https://github.com/elizaos/eliza/pull/6475)**

This service dynamically selects a smaller subset of actions/providers to show the model per turn, using a two-stage ranker:
1) vector similarity
2) BM25 reranking

If you maintain large action libraries, review this PR and test for any action discoverability regressions in your domain-specific prompts.

---

## 2) New Features

### n8n workflow automation plugin (recommended consolidation target)
The team is consolidating around **`plugin-n8n-workflow`** rather than the older duplicate `plugin-n8n`, based on feature completeness discussed in `#core-devs`:

- Resilient workflow generation with **auto-correction** of inputs/outputs
- **Drafting + workflow preview** to surface missing clarifications before deploy
- **OAuth-aware node support** (aiming for “zero hallucination” by restricting to known-good/OAuth-supported nodes)
- Dual credential storage modes:
  - manual (env/config)
  - integrated DB mode
- Cloud-friendly integration without vendor lock-in

Weekly summary highlights:
- `plugin-n8n-workflow` **v1.1.0**: modify + redeploy existing workflows; adds schema validation  
  - PRs: [#14](https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/14), [#15](https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/15)

**Build note (important):** several JSON indices are generated at build/release time and are intentionally not committed. Locally, you must generate them via the plugin’s crawl script.

```bash
# inside elizaos-plugins/plugin-n8n-workflow
bun install
bun run crawl
bun run build
```

(If you see TS errors like missing module declarations for `defaultNodes.json` / `schemaIndex.json` / `triggerSchemaIndex.json`, you likely skipped `crawl`.)

---

### Financial safety + ecosystem expansion via registry + chain plugins
This week’s consolidated highlights included several “agent money” hardening and reliability improvements:

- **Transaction validation / guardrails (Proofgate)**:  
  - Registry PRs: [#254](https://github.com/elizaos-plugins/registry/pull/254), [#246](https://github.com/elizaos-plugins/registry/pull/246)

- **EVM plugin: multi-provider RPC + fallback + multicall-oriented service redesign**:  
  - PRs: [plugin-evm#25](https://github.com/elizaos-plugins/plugin-evm/pull/25), [plugin-evm#24](https://github.com/elizaos-plugins/plugin-evm/pull/24)

- **Solana plugin: Cloud Proxy routing (Birdeye/Helius) + Token-2022 support and swap refactors**:  
  - PRs: [plugin-solana#26](https://github.com/elizaos-plugins/plugin-solana/pull/26), [plugin-solana#24](https://github.com/elizaos-plugins/plugin-solana/pull/24)

- **New registry additions** (selected):
  - MoltBazaar job marketplace: [#255](https://github.com/elizaos-plugins/registry/pull/255)
  - Sportradar sports data: [#250](https://github.com/elizaos-plugins/registry/pull/250)

---

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

This reduces redundant generation/re-fetch work and lowers API spend in workflows that repeatedly re-use the same media assets.

---

## 3) Bug Fixes

### MESSAGE_SENT event emission restored (server event bus)
A long-standing issue where plugins listening for `EventType.MESSAGE_SENT` were not triggered when messages were sent to the central server API has been fixed:

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

Impact:
- Event-driven plugins that rely on `MESSAGE_SENT` (analytics, relays, automations) should now receive consistent hooks for central-channel submissions.

---

### Runtime stability: null/undefined hardening (bootstrap + core settings)
Several crash-class bugs were addressed where `Object.entries()` or collection calls were executed on nullish values:

- Core settings utilities null checks: **[#6471](https://github.com/elizaos/eliza/pull/6471)**
- Bootstrap provider null checks for `runtime.providers`: **[#6473](https://github.com/elizaos/eliza/pull/6473)**

Additionally, an in-flight PR contains broader robustness improvements (review carefully due to scope):  
- Bootstrap provider guards (plus extra architectural work in the same PR): **[#6470](https://github.com/elizaos/eliza/pull/6470)** (open)

---

### CI reliability (repo-level)
Discord notes reference a CI fix submitted this week:
- CI fix: **[#6477](https://github.com/elizaos/eliza/pull/6477)** (mentioned in Discord; verify merge status in repo)

If you were seeing failing pipelines on `elizaos/eliza`, rebase and re-run CI after this lands.

---

### CLI reliability improvements
- Ensure created projects use `@elizaos/*@latest` to avoid linked-monorepo version resolution failures: **[#6362](https://github.com/elizaos/eliza/pull/6362)**
- Validate directory paths in `ensureDir` to prevent unclear ENOENT: **[#6379](https://github.com/elizaos/eliza/pull/6379)**
- Load `.env` in agent CLI commands for auth-token secured servers: **[#6376](https://github.com/elizaos/eliza/pull/6376)**

---

## 4) API Changes (Developer-facing)

### Settings resolution now supports per-request overrides
If you updated to include **RequestContext** (PR **[#6457](https://github.com/elizaos/eliza/pull/6457)**), be aware:

- `runtime.getSetting(key)` may now return different values depending on whether execution is within a `RequestContext.withEntitySettings(...)` scope.
- This is intended for multi-tenant isolation, but can surprise integrations that assumed global process/env-only settings.

Recommendation: when debugging “wrong API key” behavior in hosted environments, explicitly log the resolved setting source (entity vs agent default) within your provider initialization.

---

### “Tasks” as cron-equivalent remains the recommended pattern
Discord confirmed the runtime has **tasks** for scheduled behavior (cron-like), and a plugin exists to run “agent instructions” via agent skills. If you’re migrating from OpenClaw’s “heartbeat”, map that to ElizaOS tasks.

(Implementation details vary by version/branch; use your runtime’s task scheduler entrypoints.)

---

## 5) Social Media Integrations

### Twitter
- Developers reported adopting **Eliza’s Twitter plugin** in an OpenClaw integration because it avoids higher ban-risk approaches used elsewhere. A fork was promised to be published to GitHub (Discord, 2026-02-11). Track community repos for the adapter once shared.

### Farcaster
- A bug was reported in Babylon feedback UX: the “share to farcaster” link displays incorrectly (Discord, 2026-02-10). No fix PR was linked this week—if you own Babylon feedback surfaces, validate URL construction and embed formatting for Farcaster casts.

### Telegram / Discord
- No core Telegram/Discord plugin PRs were referenced in the provided GitHub activity this week, but infra conversations continue around hosted deployments and authentication patterns.

---

## 6) Model Provider Updates

### OpenAI provider/plugin
- **Media caching** landed in `plugin-openai` ([#23](https://github.com/elizaos-plugins/plugin-openai/pull/23)), which affects repeated image/audio calls and can materially reduce spend.

### OpenAI-compatible endpoints (feature request)
- Open issue requesting ability to set a **custom OpenAI base URL** for third-party OpenAI-compatible services (e.g., SiliconFlow):  
  - Issue: **[#6490](https://github.com/elizaos/eliza/issues/6490)** (open)

If you maintain provider integrations, consider aligning on a common config key (e.g., `OPENAI_BASE_URL`) and documenting expected compatibility (chat/completions, embeddings, tool calls).

---

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

V2 work is active and large in scope (see PRs [#6485](https://github.com/elizaos/eliza/pull/6485), [#6474](https://github.com/elizaos/eliza/pull/6474), [#6351](https://github.com/elizaos/eliza/pull/6351)). Key migration risks:

1) **Distribution shape changes**
   - V2 branches remove/decouple “default app/server/CLI and non-essentials” in favor of a runtime-first layout.
   - If your deployment assumes the monorepo ships a ready-to-run server/webapp, pin to V1 until a supported V2 packaging story is published.

2) **Plugin version split and backport strategy**
   - Discord indicates active management of **1.x vs 2.x** plugin branches, including:
     - consolidating `cskills` into the **1.x** branch of `plugin-agent-skills`
     - building tooling to “push 1.x updates to 2.x” while **stopping backports** to encourage 2.x adoption
   - If you maintain downstream plugins, plan for dual-compat support or choose a single target line.

3) **Runtime behavior changes**
   - Action invocation semantics (arguments/tool-like calls) and planning behavior (`planningMode`) may impact agents that relied on prior planner/action formatting.

**Recommendation:** For production systems, treat V2 branches as experimental until an official migration guide exists. For new greenfield agents, consider prototyping on V2 only if you explicitly need Rust/Python runtime parity.

---

## References / Useful Links

- Roadmap: https://github.com/elizaos/roadmap  
- Core docs (architecture, plugin dev, API ref): **[#6356](https://github.com/elizaos/eliza/pull/6356)**
- Environment variables: **[#6377](https://github.com/elizaos/eliza/pull/6377)**
- JWT auth system: **[#6200](https://github.com/elizaos/eliza/pull/6200)**
- RequestContext per-entity settings: **[#6457](https://github.com/elizaos/eliza/pull/6457)**
- ActionFilterService: **[#6475](https://github.com/elizaos/eliza/pull/6475)**
- MESSAGE_SENT fix: **[#6378](https://github.com/elizaos/eliza/pull/6378)** / Issue **[#5216](https://github.com/elizaos/eliza/issues/5216)**
- n8n workflow plugin (v1.1.0): [#14](https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/14), [#15](https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/15)
- OpenAI plugin media caching: [plugin-openai#23](https://github.com/elizaos-plugins/plugin-openai/pull/23)
- Custom OpenAI endpoint request: Issue **[#6490](https://github.com/elizaos/eliza/issues/6490)**