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

This update summarizes core engineering work, plugin ecosystem changes, and key developer discussions observed on GitHub and Discord during the week.

---

## 1) Core Framework

### Database layer refactor (in progress)
Work continued on a large DB architecture overhaul in `elizaos/eliza` intended to decouple storage concerns from core runtime types and improve performance.

- PR: **“chore(examples-art): v2 update dependencies, training pipeline, and tests for 2048 game”** (example-side, but reflects v2 tooling alignment)  
  https://github.com/elizaos/eliza/pull/6461
- PR (major): **“chore(examples-art): v2 update dependencies, training pipeline, and tests for 2048 game”** was complemented by the ongoing **“the great database refactor”** effort:  
  **PR #6509 — “chore(examples-art): v2 update dependencies, training pipeline, and tests for 2048 game”** (DB refactor is #6509)  
  https://github.com/elizaos/eliza/pull/6509

Key technical direction in **#6509**:
- Moves Drizzle-specific logic out of `@elizaos/core` (separation of concerns).
- Unifies SQL plugin strategy (merging/aligning `plugin-mysql`/`plugin-sql` towards a “plugin-drizzle” style interface per PR description).
- Batch-first CRUD redesign + wrappers moved to `AgentRuntime` for consistency.
- Adds pagination parameters (`limit/offset`) to query methods.
- Introduces a plugin storage system that avoids hard coupling plugins to Drizzle types.

**Developer impact:** if you maintain a storage-backed plugin, expect follow-up work to standardize DB access patterns across plugins and runtimes once #6509 lands. Track the PR for schema/type migration notes.

---

### Per-request context propagation
A `RequestContext` based on `AsyncLocalStorage` landed earlier in the month but is relevant for developers building multi-tenant / multi-entity services this week (notably discussed as part of beta readiness).

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

This enables runtime services to access the originating entity context without threading parameters through every call.

---

### V2 runtime direction: multi-language + lean core (active WIP)
The v2 line remains in heavy development and is the source of several migration concerns.

- PR: **#6474 — “next”**  
  https://github.com/elizaos/eliza/pull/6474
- PR: **#6485 — “feat: next generation multi-language Eliza with Rust, Python and TypeScript support”**  
  https://github.com/elizaos/eliza/pull/6485
- PR: **#6351 — “V2.0.0”** (large working branch)  
  https://github.com/elizaos/eliza/pull/6351

Notable v2 behavioral changes called out in the PR descriptions:
- Agents can respond without `roomId/worldId` in some flows.
- `planningMode` can be disabled to skip planning and execute a single action (useful for games / realtime sims).
- Actions can accept arguments and be invoked more directly (tool-like).

---

## 2) New Features

### SAID Protocol: on-chain Solana identity on `elizaos create` (pending PR)
A new identity bootstrap flow was added to the CLI create path so new agents can be registered with SAID Protocol (Solana AI Identity) using an Ed25519 keypair generated with Node’s built-in `crypto` (no new deps).

- PR: **#6510 — “feat: add SAID Protocol on-chain Solana identity for ElizaOS agents”**  
  https://github.com/elizaos/eliza/pull/6510
- Registry addition: **`@elizaos/plugin-said`**  
  https://github.com/elizaos-plugins/registry/pull/264

**What developers get:** an agent “passport” / profile URL and a local saved key file for later signing/verification flows.

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!)
```

**Operational note:** the registration step is intended to be opt-out and non-fatal (“errors are silently caught, never crashes”), which is important for CI and offline scaffolding use.

---

### Workflow automation: n8n “control panel” + runtime robustness
The `plugin-n8n-workflow` shipped a REST API control panel and hardened several agent↔workflow interaction edges.

- PR: **#16 — REST API “control panel” for workflow management**  
  https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/16
- PR: **#18 — critical property-default ordering fix**  
  https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/18

The **#18** fix is significant for LLM-driven configuration: default values now apply **before** visibility checks. Previously, dependent/conditional fields could disappear if the LLM omitted a structural field, causing invalid node configs and hard-to-debug runtime behavior.

---

### Prompt-size reduction via action filtering (TypeScript runtime)
To reduce “200+ actions” prompt bloat, the runtime gained an `ActionFilterService` that ranks candidate actions/providers using:
1) vector similarity (cosine similarity)
2) BM25 reranking

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

High-level usage pattern (conceptual):
```ts
// Runtime will pre-filter actions shown to the LLM to the top-k relevant set,
// reducing prompt size and improving tool-selection quality.
runtime.services.actionFilter.configure({
  topK: 15,
  rerank: "bm25",
});
```

---

### Developer collaboration tooling: HackMD MCP server
On Discord, the core-devs channel discussed adopting HackMD via MCP for shared notes/doc workflows.

- Repo: https://github.com/yuna0x0/hackmd-mcp  
- Discussion reference (Discord core-devs): https://discord.com/channels/1253563208833433701/1377726087789940836

This is not an ElizaOS core change, but it’s likely to affect how internal specs and migration notes are authored and shared.

---

## 3) Bug Fixes (Critical)

### n8n workflow: default-values applied before visibility checks
As noted above, this was a production-impacting bug because LLMs frequently omit fields. Fix ensures form/schema logic doesn’t hide required dependent fields.

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

**Why it matters:** prevents “incomplete config” spirals where the agent can’t see fields it needs to fill because the UI/schema thinks they’re irrelevant.

---

### Bootstrap/runtime: defensive null checks to prevent crashes
Two targeted hardening fixes reduce runtime crash surface area in common “missing settings/providers” scenarios:

- PR: **#6471 — null checks before `Object.entries()` in settings utilities**  
  https://github.com/elizaos/eliza/pull/6471
- PR: **#6473 — null check for `runtime.providers` in plugin-bootstrap**  
  https://github.com/elizaos/eliza/pull/6473

These address real-world cases where partial runtimes or minimal builds (especially in v2 experimentation) can pass `null/undefined` structures during boot.

---

### CLI create reliability: always use `latest` for `@elizaos/*` deps
A recurring local-dev failure mode was fixed: when the CLI is linked from the monorepo, template projects could reference prerelease versions not published to npm, causing create/install failures.

- PR: **#6362 — “fix(cli): always use 'latest' for @elizaos deps in created projects”**  
  https://github.com/elizaos/eliza/pull/6362

---

## 4) API Changes

### DB API surface: batch-first CRUD + pagination (pending merge)
The DB refactor PR (**#6509**) introduces/standardizes:
- batch-first CRUD semantics (performance-oriented),
- new/adjusted upsert flows,
- pagination via `limit/offset`,
- plugin storage abstraction.

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

**Action for plugin authors:** if your plugin uses internal DB helpers directly, prepare to update imports/types once this merges; the intent is to eliminate Drizzle leakage into core-facing interfaces.

---

### RequestContext: runtime methods can infer entity context
If you’re writing server middleware, agent gateways, or multi-tenant hosting, adopt the context helpers instead of manually passing entity IDs everywhere.

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

---

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

### Twitter plugin: stability + media upload (merged earlier this month, relevant to builders)
The Twitter plugin saw major work to fix auth retry loops and add media upload support.

- Contributor summary reference: `elizaos-plugins/plugin-twitter` PR **#48** (merged)  
  (Track in repo PR list): https://github.com/elizaos-plugins/plugin-twitter/pulls

### Discord/Telegram deployment readiness (planning signals)
Project planning issues referenced this month include infrastructure readiness for Telegram/Discord deployments (not all linked in the aggregated day logs), and Discord discussion continues to surface operational gaps (e.g., lack of a support ticket system for migration issues).

Discord threads referenced:
- Plugin creation guidance (docs): https://docs.elizaos.ai/guides/create-a-plugin  
- Support/process gap surfaced in 💬-discussion: https://discord.com/channels/1253563208833433701/1253563209462448241

### Farcaster + other plugins: Spartan setup friction
Developers reported Spartan setup issues due to missing plugins requiring manual cloning (including `plugin-farcaster`, `plugin-solana`, `plugin-jupiter`, etc.), and Docker files existing but not currently functional.

- Discord context (2026-02-17): https://discord.com/channels/1253563208833433701 (see daily digest excerpts)

**Practical takeaway:** if you distribute templates or “batteries included” stacks, pin exact plugin sources/branches and document required vs optional plugins until the upgrade cycle stabilizes.

---

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

### Anthropic: Sonnet 4.6 mentioned (community signal)
On Discord, **Sonnet 4.6** was mentioned as released (implementation details not discussed in-thread). If you maintain model routing configs, verify naming/version mapping in your provider tables.

- Discord context (2026-02-17): ai model update mention

### OpenAI provider: custom endpoint request (open)
A feature request is active to support OpenAI-compatible third-party endpoints (e.g., SiliconFlow) by allowing a configurable base URL.

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

### Ollama embeddings failure on Ubuntu 24.04 (open)
A community-reported issue indicates embedding calls fail even when Ollama itself works, suggesting either transport/config mismatches or embedding model discovery issues.

- Issue: **plugin-ollama #17 — “Ollama plugin embedding error on Ubuntu 24.04…”**  
  https://github.com/elizaos-plugins/plugin-ollama/issues/17

---

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

V2 workstreams (**#6351**, **#6474**, **#6485**) are intentionally disruptive and are not a drop-in replacement for V1 deployments.

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

### Key breaking vectors called out in PR descriptions
- **Repo composition changes:** V2 branches remove/relocate default app/server/CLI “non-essentials” to focus on runtime + critical plugins across Rust/Python/TypeScript.
- **Behavioral defaults:** bootstrap capabilities enabled by default (`basicCapabilities`) with optional `extendedCapabilities`.
- **Message semantics:** agents responding without `roomId/worldId` (some integrations may assume these always exist).
- **Planning pipeline:** `planningMode=false` changes tool invocation path (single-action execution), which can break agents relying on multi-step planners.
- **Action invocation:** actions with arguments may require updates to tool schemas and any custom tool-call parsers.

### Migration guidance (practical)
If you ship production agents on V1:
- Do **not** track v2 PR branches directly; instead, isolate evaluation in a separate environment.
- Audit any assumptions about:
  - DB adapter types (Drizzle leakage removal),
  - required message metadata (`roomId/worldId`),
  - tool/action schemas (arguments + filtering),
  - plugin availability/branching (“next branch” requirement surfaced on Discord for compatibility).

---

## References / Links Mentioned This Week
- Plugin creation guide: https://docs.elizaos.ai/guides/create-a-plugin  
- SAID plugin registry PR: https://github.com/elizaos-plugins/registry/pull/264  
- SAID core PR: https://github.com/elizaos/eliza/pull/6510  
- DB refactor PR: https://github.com/elizaos/eliza/pull/6509  
- n8n control panel PR: https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/16  
- n8n defaults/visibility fix PR: https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/18  
- Action filtering PR: https://github.com/elizaos/eliza/pull/6475  
- Request context PR: https://github.com/elizaos/eliza/pull/6457  
- OpenAI custom endpoint issue: https://github.com/elizaos/eliza/issues/6490  
- Ollama embeddings issue: https://github.com/elizaos-plugins/plugin-ollama/issues/17  
- HackMD MCP repo: https://github.com/yuna0x0/hackmd-mcp