# ElizaOS Developer Update (2026-02-19 → 2026-02-25)

This update summarizes core framework work, plugin ecosystem changes, and developer-facing migration notes observed across GitHub activity and core-dev Discord discussions.

---

## 1) Core Framework

### V2 runtime direction: multi-language core + slimmer distribution
Work continues on the V2 line that restructures ElizaOS around a smaller “runtime-first” core with multi-language support and fewer bundled “product” surfaces:

- **Next-gen multi-language core (Rust + Python + TypeScript)**: PR **#6485** (“next generation multi-language Eliza”) proposes/continues:
  - Rust/Python/TypeScript core packages and native plugin ports
  - removal of default app/client/server scaffolding from the default distribution
  - bootstrap capabilities integrated into core (basicCapabilities by default)
  - new runtime behaviors like responding without `roomId/worldId`, and configurable `planningMode`
  - actions supporting **typed arguments** (tool-like invocation)
  - PR: https://github.com/elizaos/eliza/pull/6485

Related long-running branch work:
- **V2.0.0 branch**: PR **#6351** (large working branch)  
  https://github.com/elizaos/eliza/pull/6351  
- **“next” branch**: PR **#6474** (similar multi-language theme)  
  https://github.com/elizaos/eliza/pull/6474

### Database refactor + migration policy cleanup (RLS preserved)
A key focus is the V2 database refactor, including simplifying upgrade assumptions and preserving row-level security patterns:

- **DB refactor / migration cleanup**: PR **#6521** removes legacy auto-migration paths (notably 1.4.x → 1.6.x auto-migration code), with the expectation that users should be on newer V1 before attempting V2. Discussed in core-dev Discord as a substantial deletion (~2.6k LOC) and intended to be easy to rebase onto other DB refactor work.  
  PR: https://github.com/elizaos/eliza/pull/6521

Developer context from Discord (2026-02-22 → 2026-02-23):
- RLS is expected to remain intact in the broader refactor.
- Consideration: instead of auto-migrating from very old versions, **throw an explicit error** instructing users to migrate to 1.6.x first, then to V2.

### Prompt-size control and runtime efficiency work
Prompt bloat and baseline token usage were recurring pain points in Discord, especially with many plugins enabled (reports of hitting ~200k token contexts). Two framework-level efforts address this:

- **Action filtering to reduce prompt bloat**: PR **#6475** introduces an `ActionFilterService` that selects a small relevant subset of actions/providers (vector search + BM25 reranking) so the LLM sees ~15 relevant actions instead of hundreds.  
  PR: https://github.com/elizaos/eliza/pull/6475

- Discord discussion also mentions further optimization opportunities around **MCP loading** and “metatool search actions”, with the key finding that the largest token growth was coming from **recent messages + reflections** aggregation rather than “actions” alone (core-dev Discord, 2026-02-23).

---

## 2) New Features

### A) Dynamic action/tool selection via `ActionFilterService` (V2 TypeScript runtime)
If you have large plugin sets, dynamically filtering actions/providers before prompt assembly is now a first-class pattern (PR #6475).

**What it enables**
- Smaller system/tool prompts
- Lower token usage and latency
- Better tool relevance for the model

**High-level usage pattern (conceptual)**
```ts
// Pseudocode illustrating intent; see PR #6475 for actual APIs/types.
const filter = runtime.getService("actionFilter");

const { actions, providers } = await filter.selectRelevant({
  query: state.lastUserMessage.content,
  actions: runtime.actions,
  providers: runtime.providers,
  topK: 15,
});

// downstream: only show `actions/providers` to the model for this turn
const response = await runtime.respond(state, { actions, providers });
```

PR: https://github.com/elizaos/eliza/pull/6475

### B) SAID Protocol identity on `elizaos create` (in-flight)
PR **#6510** adds automatic agent identity creation via SAID Protocol (Solana AI Identity). When enabled/available, new agents created via CLI can register an identity and store the generated key locally.

- PR: https://github.com/elizaos/eliza/pull/6510  
- SAID docs: https://saidprotocol.com/docs.html

Expected CLI output (from PR description):
```text
⚡ SAID Protocol identity created
  Wallet: <ed25519 pubkey>
  Profile: https://saidprotocol.com/agents/<pubkey>

  Key saved to .said-wallet.json (add to .gitignore!)
```

### C) Request-scoped entity settings (AsyncLocalStorage)
For multi-tenant / per-entity behavior, ElizaOS added request context propagation (PR **#6457**, already in the February activity set and relevant to ongoing V2 isolation work):

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

This allows runtime code to access originating entity context without threading parameters everywhere.

---

## 3) Bug Fixes

### Defensive null checks in core settings + bootstrap provider plumbing
Two stability hardening changes reduce runtime crashes caused by `null/undefined` values in common code paths:

- **Core settings utilities**: PR **#6471** adds guards before `Object.entries(...)` to prevent runtime exceptions when settings objects are missing.  
  https://github.com/elizaos/eliza/pull/6471

- **plugin-bootstrap providers**: PR **#6473** adds a null check around `runtime.providers` to prevent:
  `TypeError: Cannot read properties of null (reading 'filter')`  
  https://github.com/elizaos/eliza/pull/6473

### Ongoing critical bug to watch: duplicate LLM calls on URL messages (webapp)
Issue **#6486** remains open: URL-containing messages can be processed twice (as text + as attachment preview), causing duplicated SSE output and doubled cost.

- Issue: https://github.com/elizaos/eliza/issues/6486  
Mitigation direction: dedupe message processing earlier in the pipeline so URL content is handled *either* as text *or* attachment, not both.

---

## 4) API Changes (Developer-facing)

### V2 runtime semantics and tool/action invocation
The V2 runtime proposals in PRs **#6485 / #6474** include developer-visible behavioral changes:

- **Actions can accept arguments** and be invoked more like tools (no separate “step” required).
- `planningMode: false` to skip multi-step planning and perform a single action call (useful for games/low-latency agents).
- Agents may respond without `roomId/worldId` in some flows.

Track details here:
- https://github.com/elizaos/eliza/pull/6485
- https://github.com/elizaos/eliza/pull/6474

### Potential migration UX change: explicit “upgrade path required” errors
In DB refactor discussions (PR **#6521**), the team is leaning away from deep legacy auto-migrations. Expect explicit errors if attempting very old V1 → V2 jumps without intermediate migrations.

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

---

## 5) Social Media Integrations

### Twitter / X plugin: stability + media upload (ecosystem)
The February contributor rollup indicates significant work in `elizaos-plugins/plugin-twitter` resolving an auth retry loop and adding media upload support (PR referenced in contributor summary as **#48**). If you deploy X agents, pull the latest plugin-twitter updates and re-check auth handling and upload permissions/scopes.

Repo: https://github.com/elizaos-plugins/plugin-twitter (PR #48 referenced in monthly contributor summary)

### Discord operational note (not code): role/permissions debugging
In Discord (2026-02-24), admin work was needed to grant “core dev”/labs access due to server permission constraints; access to specific rooms required manual intervention in at least one case. This doesn’t affect runtime code, but does affect contributor onboarding and visibility into dev channels.

---

## 6) Model Provider Updates

### OpenAI-compatible endpoints (requested)
Feature request **#6490** asks for a configurable OpenAI base URL to support OpenAI-compatible third-party endpoints (e.g., SiliconFlow).

- Issue: https://github.com/elizaos/eliza/issues/6490  
If you maintain a provider plugin: consider standardizing `baseURL`/`endpoint` configuration across providers to avoid one-off forks.

### Ollama embeddings failing on Linux (ecosystem)
The Ollama plugin has an open issue for embedding failures on Linux:

- Issue: https://github.com/elizaos-plugins/plugin-ollama/issues/17

### Token usage pressure: providers + evaluations
Core-dev Discord notes (2026-02-22) highlight that baseline token usage spikes often come from bootstrap providers and evaluations when many plugins are enabled. This contextualizes why `ActionFilterService` (PR #6475) and bootstrap optimization work are high-priority.

---

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

### A) Default distribution is changing (runtime-first)
V2 work (PR #6485 / #6474 / #6351) removes or de-emphasizes “full product” surfaces (app/server/CLI) from the default core distribution in favor of a runtime + plugin-centric model. If your deployment assumes the monorepo’s historical server/app layout, expect migration work:
- you may need to pin to V1 for existing infrastructure
- or adopt the new examples/templates intended for V2

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

### B) Database migration path: don’t skip intermediate V1 versions
With PR **#6521**, legacy auto-migration code is being removed. Practical guidance:
- **Do not attempt** to upgrade directly from very old V1 releases (e.g., 1.4.x) to V2.
- Upgrade to the required intermediate V1 (notably 1.6.x as discussed) first, then proceed to V2.

PR: https://github.com/elizaos/eliza/pull/6521

### C) Prompt/tool surface changes can affect agent behavior
If you rely on “all tools always visible”, `ActionFilterService` can materially change agent behavior (in a good way, but still behaviorally significant). Validate:
- tool availability assumptions
- any “prompt-injected” instructions that referenced tools that may now be filtered out

PR: https://github.com/elizaos/eliza/pull/6475

---

## Additional Ecosystem Notes (from Discord)

### External agent trading test harness: *fomolt* (community tool)
A new community tool, **fomolt**, was introduced for testing Eliza agents in trading workflows on Base:
- CLI for instant token trading
- paymaster support (USDC for gas)
- API-key auth (no seed phrase)
Shared in Discord **#coders** on 2026-02-24; feedback requested by the author for agent-dev workflows.

Discord context: https://discord.com/channels/1253563208833433701/1300025221834739744

### Plugin recommendation: use `plugin-bootstrap` for image generation actions
In Discord (2026-02-23), `plugin-bootstrap` was recommended over the older `plugin-image-generation` package because bootstrap includes an image generation action in the more current V2-aligned approach.

---

## Links Index
- V2 multi-language core: https://github.com/elizaos/eliza/pull/6485  
- Action filtering (vector + BM25): https://github.com/elizaos/eliza/pull/6475  
- DB refactor migration cleanup: https://github.com/elizaos/eliza/pull/6521  
- SAID identity integration: https://github.com/elizaos/eliza/pull/6510  
- OpenAI custom endpoint request: https://github.com/elizaos/eliza/issues/6490  
- URL triggers duplicate LLM calls: https://github.com/elizaos/eliza/issues/6486  
- Core settings null guards: https://github.com/elizaos/eliza/pull/6471  
- Bootstrap providers null guards: https://github.com/elizaos/eliza/pull/6473  
- Discord coders thread (fomolt): https://discord.com/channels/1253563208833433701/1300025221834739744