# ElizaOS Developer Update (2026-02-15 → 2026-02-21)

## 1) Core Framework

### Database layer refactor + storage decoupling (in progress)
Work this week continued toward a major persistence/DB architecture cleanup in core:

- **“The great database refactor”**: batch-first CRUD APIs, pagination support, unified SQL interfaces, and reduced coupling to Drizzle ORM internals.  
  PR: https://github.com/elizaos/eliza/pull/6509

Key technical themes:
- **Separation of concerns**: moving Drizzle-specific concerns out of `@elizaos/core`.
- **Plugin storage**: enabling plugins to persist custom data without binding to Drizzle types.
- **Performance**: refactor notes cite large improvements for multi-item operations (batch operations + API redesign).

Developer impact:
- Plugin authors that were importing/depending on Drizzle table types from core should expect churn as the “generic schema definitions” land.
- Expect follow-up updates for plugin compatibility checks (explicitly listed as TODO in the PR).

### Request-scoped entity settings via AsyncLocalStorage
To support multi-entity / data-isolated deployments without threading “entity” through every call, core added a request context:

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

This introduces `RequestContext` and helpers like `withEntity(...)`, allowing runtime methods to infer the originating entity implicitly.

### v2 runtime direction: multi-language core (Rust/Python/TypeScript)
The v2 line remains active and large in scope:

- v2 umbrella PR: https://github.com/elizaos/eliza/pull/6351
- “Next generation multi-language Eliza” PR: https://github.com/elizaos/eliza/pull/6485
- “next” branch PR: https://github.com/elizaos/eliza/pull/6474

Notable runtime behavior changes called out in v2 PR descriptions:
- Agents can respond **without requiring `roomId`/`worldId`**.
- `planningMode` can be disabled to skip planning and run a single action (useful for games / tight loops).
- Actions support **arguments**, enabling tool-like calling without an extra step.

### Spartan dev environment friction (Discord)
Developers reported Spartan installation issues: `bun install` hanging and missing plugins requiring manual cloning (`@elizaos/plugin-evm`, `plugin-farcaster`, `plugin-jupiter`, `plugin-knowledge`, `plugin-mysql`, `plugin-solana`). Docker files exist but are currently non-functional. Plugin install order **does not matter**, but setup is acknowledged as “not polished yet” due to ongoing plugin upgrades.  
Context (Discord 2026-02-17): Spartan setup + missing plugin list + Docker status.

A Feb 19 PR in `elizaos/spartan` was also mentioned as addressing **core-compat layers and service/build issues** (compat/staging work). Repo: https://github.com/elizaos/spartan

---

## 2) New Features

### SAID Protocol: automatic on-chain Solana identity at project creation
ElizaOS CLI can now provision an identity for new agents on SAID Protocol:

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

Implementation details:
- `packages/elizaos/src/utils/said.ts`: Ed25519 keypair generation using Node `crypto` (no new deps).
- SAID registration via REST API.
- Key persisted to `.said-wallet.json` (must be gitignored).
- Designed to be **opt-out / non-fatal**: errors are caught and do not crash `elizaos create`.

Example output (from PR description):
```text
✨ Project created successfully!

⚡ SAID Protocol identity created
  Wallet: 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAs
  Profile: https://saidprotocol.com/agents/7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAs

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

Recommended `.gitignore` addition:
```gitignore
.said-wallet.json
```

### Action filtering to reduce prompt bloat: vector search + BM25 reranking
A new `ActionFilterService` reduces the set of actions/providers shown to the model by ranking for relevance:

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

Why it matters:
- Many agents accumulate 200+ actions/tools; sending all of them drives context usage and cost.
- This service targets reducing the action list to a small relevant subset (PR notes ~15).

At a high level:
- Tier 1: vector similarity search (cosine similarity over embeddings).
- Tier 2: BM25 reranking to improve precision.

### JWT auth + user management for isolated deployments
JWT-based authentication and user management landed (behind a flag):

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

Activation detail:
- Requires `ENABLE_DATA_ISOLATION=true` to enable JWT auth mode.

This lays groundwork for running ElizaOS in multi-tenant environments and integrating external JWT providers.

### n8n workflow control plane (plugin)
The n8n workflow plugin added a REST “control panel” to manage workflows without natural language:

- PR: https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/16

This is especially useful for deterministic ops (enabling/disabling workflows, querying status, etc.) driven by external systems.

Example (illustrative) curl-style usage:
```bash
curl -X GET "http://localhost:PORT/n8n/workflows" \
  -H "Authorization: Bearer $N8N_CONTROL_TOKEN"
```

---

## 3) Bug Fixes

### Bootstrap plugin robustness: null guards + provider safety
Two defensive fixes addressed runtime crashes caused by `null`/`undefined` values:

- Settings utilities guard `Object.entries(...)`: https://github.com/elizaos/eliza/pull/6471  
- Bootstrap provider list null check (`runtime.providers`): https://github.com/elizaos/eliza/pull/6473

Technical context:
- These crashes typically surface in partially initialized runtimes or custom embeddings/providers configurations where an expected array/object is absent.
- The fixes reduce “hard crash” behavior and make bootstrap more resilient in heterogeneous plugin stacks.

### n8n workflow: handling incomplete AI-provided workflow properties
A critical stability fix ensures the plugin doesn’t break when the model omits fields:

- PR: https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/18

This is important in practice because LLM outputs are frequently partial; robust schema handling prevents workflow corruption and repeated retries.

### CLI reliability: template dependency resolution + env loading for remote auth
Key CLI fixes that improve developer onboarding and remote-server workflows:

- Always use `'latest'` for `@elizaos/*` deps in generated projects: https://github.com/elizaos/eliza/pull/6362  
- Validate directory path in `ensureDir` to avoid confusing ENOENT: https://github.com/elizaos/eliza/pull/6379  
- Load `.env` files in `elizaos agent` commands (fixes remote auth token usage): https://github.com/elizaos/eliza/pull/6376

### Known open bug to watch: duplicate LLM calls when a message contains a URL (webapp)
Still open, but high impact (double token usage + duplicated responses):

- Issue: https://github.com/elizaos/eliza/issues/6486

Root cause hypothesis (per issue): URL is processed as both **text** and **attachment/preview**, leading to two completions streamed into one SSE response.

---

## 4) API Changes

### Database API surface is shifting (batch-first + pagination)
The DB refactor PR (6509) implies API changes that plugin authors should anticipate:

- Batch-first CRUD methods with updated return types
- Pagination (`limit`/`offset`) added to query methods
- Plugin storage mechanisms that avoid Drizzle coupling

Track: https://github.com/elizaos/eliza/pull/6509

### RequestContext added to core
New request context utilities enable implicit entity scoping:

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

Illustrative usage pattern:
```ts
import { withEntity } from "@elizaos/core";

await withEntity({ entityId: "entity_123" }, async () => {
  // runtime calls inside here can infer entity context
  await runtime.memory.createMessage({ /* ... */ });
});
```

### Docs added/expanded for core concepts + env vars
If you’re standardizing deployments, these are now canonical references:

- Core docs set (architecture/concepts/plugin dev/deploy/API ref): https://github.com/elizaos/eliza/pull/6356  
- Environment variable documentation: https://github.com/elizaos/eliza/pull/6377  

---

## 5) Social Media Integrations

### Twitter plugin: stability + media uploads
The Twitter/X plugin received substantial work (merged this month, relevant to ongoing integration efforts):

- Media upload + auth retry-loop fix: https://github.com/elizaos-plugins/plugin-twitter/pull/48

If you previously had agents stuck in auth retry cycles or unable to attach media, update the plugin and re-check credentials + rate-limit behavior.

### WhatsApp + Gmail integrations (core tracking issues)
Major platform connectors were finalized/tracked in core:

- WhatsApp tracking issue: https://github.com/elizaos/eliza/issues/6401  
- Gmail tracking issue: https://github.com/elizaos/eliza/issues/6404  

These integrations are part of the push to put agents “where users already work.”

### Discord (community): Babylon “hanging plaza” multi-agent demo
Odilitime highlighted the Babylon Discord deployment (“the hanging plaza”) as the best live demo for agents operating in human digital spaces (Discord 2026-02-19). This is useful context when testing multi-agent coordination patterns and connector reliability.

---

## 6) Model Provider Updates

### OpenAI-compatible endpoints: requested feature (open)
Developers requested the ability to set a **custom OpenAI base URL** for OpenAI-compatible providers (e.g., SiliconFlow):

- Issue: https://github.com/elizaos/eliza/issues/6490

If you need this today, you likely have to implement a custom provider or patch configuration locally until upstream supports `baseURL`.

### Opus 4.5 support (tracked)
- Issue: https://github.com/elizaos/eliza/issues/6368

### Ollama embeddings failing on Linux (investigating)
- Issue: https://github.com/elizaos-plugins/plugin-ollama/issues/17

### Claude Sonnet model chatter (Discord)
Community mentioned “Sonnet 4.6” availability (Discord 2026-02-17). No concrete provider PR was referenced in the aggregated data, but if you rely on Anthropic models, monitor provider/plugin repos for updated model IDs and pricing tables.

---

## 7) Breaking Changes (V1 → V2 migration warnings)

### v2 removes “non-essentials” and reorganizes the product surface
The v2 effort explicitly removes the default app/server/CLI and focuses on a multi-language runtime + ported critical plugins:

- v2 PR: https://github.com/elizaos/eliza/pull/6351  
- next-gen multi-language PR: https://github.com/elizaos/eliza/pull/6485  

If you are migrating from v1:
- Do not assume the **monorepo ships a turnkey webapp/server** the same way; you may need to adopt v2 examples and compose your own deployment.
- Plugin parity is in-flight across TypeScript/Python/Rust; verify each plugin’s v2 readiness before upgrading.

### DB + plugin storage changes may break plugins that depend on Drizzle internals
The DB refactor (6509) explicitly targets decoupling core from Drizzle and renaming/merging SQL plugins (noted in PR text). Expect breakage if your plugin:
- imports Drizzle table types from core
- assumes specific schema objects (e.g., pgTable/mysqlTable)
- relies on old single-item CRUD return types

Track and test against:
- PR: https://github.com/elizaos/eliza/pull/6509

### Spartan setup is not stable yet (practical breaking point for contributors)
From Discord reports (2026-02-17), Spartan currently may require manual plugin cloning and Docker is not working. If your onboarding docs reference Spartan as the default path, add caveats and pin known-good commit ranges until plugin upgrades settle.