# ElizaOS Developer Update (2026-02-20 → 2026-02-26)

This week focused on (1) stabilizing the **v1.x** developer experience while **v2** work continues, (2) reducing prompt bloat and runtime errors via bootstrap/core hardening, and (3) cleaning up process/tooling issues that affected repo and issue tracking.

---

## 1) Core Framework

### Branch / release-line correction: `develop` contained v2 code unexpectedly
A critical repo hygiene issue surfaced: the `develop` branch unexpectedly contained **2.0.0** code instead of the expected **1.x** line, and the team could not trace a clean PR/commit path to revert it (“unfixable” via normal history inspection). The immediate mitigation is to preserve an explicit v1.x line via a new branch:

- Action: create/standardize a **`v2-develop`** branch for **1.x** users still migrating (discussion context in Discord: `#xfn-framework`)
- Follow-up: ensure docs/README and tooling point v1.x users to the correct branch and tags.

References:
- Discord discussion (version control + mitigation):  
  https://discord.com/channels/1253563208833433701/1377726087789940836

Suggested workflow until this is fully documented:
```bash
# If you are maintaining a v1.x integration:
git fetch origin
git checkout v2-develop
```

### Per-request context propagation (multi-tenant / per-entity runtime settings)
Work earlier this month introduced an important runtime architectural primitive: `RequestContext` via `AsyncLocalStorage`, enabling per-request/per-entity settings access without manually threading context through every call chain.

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

Why it matters:
- Enables cleaner multi-tenant server patterns (JWT/data isolation flows) where plugins/providers need “who is calling” context.
- Reduces accidental cross-entity leakage when running shared runtimes.

---

## 2) New Features

### Action filtering to reduce prompt bloat: vector search + BM25 reranking
A major capability landed for the v2 TypeScript runtime: **ActionFilterService**, which dynamically selects a relevant subset of actions/providers for the LLM instead of dumping an entire tool catalog into the prompt.

- PR: **feat: ActionFilterService — vector search + BM25 reranking for action/provider filtering** #6475  
  https://github.com/elizaos/eliza/pull/6475

Technical highlights:
- Two-stage ranking:
  1) **Vector similarity** shortlist
  2) **BM25 reranking** to improve lexical relevance
- Targets reducing “200+ actions → ~15 relevant actions” (per PR description), improving:
  - latency
  - token usage
  - tool-choice accuracy (less “confabulation” from irrelevant tools)

Example (conceptual usage in runtime initialization; exact API may differ by runtime entrypoint):
```ts
import { Runtime } from "@elizaos/typescript";
import { ActionFilterService } from "@elizaos/typescript/services/action-filter";

const runtime = new Runtime({
  // ...providers, memory, model, plugins
});

// Enable tool/action filtering before generating prompts
runtime.registerService(new ActionFilterService({
  maxActions: 15,
  // optionally tune vector/BM25 weighting if exposed
}));
```

### Bootstrap plugin robustness & performance improvements
The bootstrap plugin continues to be the “default capability surface” for many agents. This week’s theme was making it more resilient and cheaper to run.

- PR: **feat(plugin-bootstrap): comprehensive optimization and robustness improvements** #6476  
  https://github.com/elizaos/eliza/pull/6476

Also noted in Discord: token usage issues were often attributed less to actions themselves and more to **recent messages/reflections collecting excessive data**—aligning with the push to add caching and reduce prompt payload.

Related Discord context (MCP loading / metatool search optimization):
- https://discord.com/channels/1253563208833433701/1377726087789940836

### Ecosystem/product surface (in progress): Payment Infrastructure plugin request
A payment infrastructure layer (agent↔agent / agent↔user) is under discussion:

- Issue: **Payment Infrastructure Plugin** #6443  
  https://github.com/elizaos/eliza/issues/6443

Discord guidance was to add implementation notes and requirements directly to the issue thread:
- https://discord.com/channels/1253563208833433701/1300025221834739744

---

## 3) Bug Fixes (Critical)

### Prevented runtime crashes from null/undefined settings
Two hardening fixes addressed common runtime crash modes when environments provide incomplete configuration objects.

1) **Core settings utilities**: guard `Object.entries()` against null/undefined  
- PR: **fix: add null checks to Object.entries calls in settings utilities** #6471  
  https://github.com/elizaos/eliza/pull/6471

Impact:
- Prevents fatal errors in config-heavy deployments (cloud/serverless) where env merging can yield missing sections.

2) **Bootstrap providers provider**: null check for `runtime.providers`  
- PR: **fix(plugin-bootstrap): add null check for runtime.providers** #6473  
  https://github.com/elizaos/eliza/pull/6473

Impact:
- Prevents `TypeError: Cannot read properties of null (reading 'filter')` during provider enumeration.

---

## 4) API Changes (Developer-visible)

### Request-scoped entity configuration access (core runtime)
- PR: #6457 adds `RequestContext` plumbing via `AsyncLocalStorage`.
- Developer implication: services/plugins can now read “current entity” context implicitly, but you must ensure requests are wrapped properly.

Conceptual pattern:
```ts
import { withEntityContext } from "@elizaos/core"; // name may differ by export

await withEntityContext({ entityId: "user_123" }, async () => {
  // Any downstream runtime/plugin code can read entity settings from context
  await runtime.handleMessage(msg);
});
```

### v2 runtime/tooling direction: action arguments + planning mode
Ongoing v2 PRs (still open) indicate API shape changes that v1.x developers should anticipate:

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

Notable developer-facing changes described in these PRs:
- Agents can respond without requiring `roomId/worldId`
- `planningMode: false` to skip planning and execute a single action (useful for games/simple agents)
- Actions can be called with **arguments** (closer to “tools with params” semantics)

These are not merged yet, but they are important for anyone designing plugins/actions today.

---

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

### Twitter plugin: auth loop fix + media upload support (merged)
The Twitter plugin saw substantial stability and capability improvements (auth retry loop + media uploads).

- PR: **(Twitter plugin) fix auth retry loop + media uploads** #48  
  (Repository: `elizaos-plugins/plugin-twitter`; see contributor rollup for details)

Developer impact:
- Media-bearing actions are now feasible without custom forks.
- Reduced risk of runaway retries (rate-limit / account lockouts).

### Discord/Telegram status
No new Telegram/Discord plugin merges were captured in the provided weekly activity slice, but infrastructure planning remains active in the broader Feb roadmap (e.g., deployment readiness, secrets, multi-tenant architecture in earlier issues).

---

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

### OpenAI-compatible endpoints (feature request)
A key integration gap is being tracked: ability to point the OpenAI provider at **custom OpenAI-compatible base URLs** (e.g., SiliconFlow and other compatible gateways).

- Issue: **Support custom OpenAI endpoint URL for OpenAI provider** #6490  
  https://github.com/elizaos/eliza/issues/6490

If you are building against OpenAI-compatible APIs today, plan for:
- temporary provider forks, or
- reverse proxies that preserve the official OpenAI hostname semantics,
until `baseURL`/`endpoint` is first-class in provider config.

### Competitive landscape: trajectory compression as a training/data primitive
The team reviewed Nous Research’s “Hermes Agent” framework; the main technically relevant idea identified was **trajectory compression** (packing training trajectories into token budgets).

- Discord context:  
  https://discord.com/channels/1253563208833433701/1377726087789940836

This is not merged work in ElizaOS yet, but it may inform future:
- scenario/eval tooling
- reflection/memory summarization pipelines
- training data export formats

---

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

### 1.x vs 2.x code-line confusion (immediate risk)
Because `develop` was observed containing v2 code unexpectedly, you should assume:
- **branch names are not currently reliable signals** for API compatibility until the repo is fully cleaned up and documented.
- pin by **tags/commits** for production, and coordinate on the new **`v2-develop`** guidance once formalized.

### v2 removes “non-essentials” (app/server/CLI) and changes default composition (planned/open)
v2 PRs describe a structural break:
- removing default app/client/server/CLI from the main distribution
- focusing on multi-language runtimes (Rust/Python/TS) + critical plugins
- integrating “bootstrap” capabilities into core defaults (in v2 design)

References (open PRs):
- https://github.com/elizaos/eliza/pull/6485
- https://github.com/elizaos/eliza/pull/6474
- https://github.com/elizaos/eliza/pull/6351

Migration guidance (practical):
- If you maintain v1 agents, **freeze** to known-good v1 tags/commits.
- If you are authoring new plugins, avoid relying on:
  - implicit presence of the v1 server/webapp
  - tool lists being fully visible to the model (ActionFilterService changes this assumption)

---

### Appendix: Tooling / Process Notes

- GitHub ↔ Linear bidirectional sync created issue-tracking inconsistencies and requires cleanup (acknowledged in Discord).  
  Context: https://discord.com/channels/1253563208833433701/1377726087789940836