# ElizaOS Developer Update (2026-01-25 → 2026-01-31)

This week focused on restoring onboarding reliability (CLI/project generation), hardening runtime initialization and secrets handling, and pushing forward the Eliza v2 architecture work (automation via n8n, streaming/structured execution, and MCP-backed knowledge bootstrapping).

Relevant links:
- GitHub weekly summary: https://github.com/elizaOS/knowledge/blob/main/github_summaries_week_latest_2026-01-25.md  
- Discord daily summary (2026-01-28): https://github.com/elizaOS/knowledge/blob/main/ai_news_elizaos_daily_md_2026-01-28.md  

---

## 1) Core Framework

### Runtime initialization performance + correctness
Runtime startup got meaningful performance work via parallelization/atomic upserts:
- **PR:** “optimize runtime initialization with parallelization and atomic upserts” (cold start ~-30%, warm ~-40%)  
  https://github.com/elizaos/eliza/pull/6342

If you maintain custom adapters or lifecycle hooks, re-check assumptions about initialization ordering (operations that used to be sequential may now be parallel).

### Multi-transport messaging + client hooks alignment
Eliza’s messaging stack continues consolidating around a transport-agnostic client hook with HTTP/SSE/WebSocket support:
- **PR:** “unified hooks with multi-transport support (HTTP/SSE/WebSocket)”  
  https://github.com/elizaos/eliza/pull/6300

Discord feedback this week indicates real-world SSE deployments still commonly fail with proxy/backend misconfiguration (“MIME_TYPE_MISMATCH”), and socket.io is often the fastest path to a stable production setup (see **Bug Fixes** below).

### MCP-backed knowledge + org tracking infrastructure (elizaos.github.io)
Core-devs discussed and shipped infrastructure that moves ElizaOS toward **self-maintaining configuration** for repos/channels and better agent bootstrapping via MCP (Model Context Protocol). The implementation landed in the web/analytics repo:
- GitHub analytics server launch: https://github.com/elizaos/elizaos.github.io/pull/238  
- Ensure all org repos tracked/visible: https://github.com/elizaos/elizaos.github.io/pull/231  
- Framework upgrades (Next.js 16.1.4): https://github.com/elizaos/elizaos.github.io/pull/236, https://github.com/elizaos/elizaos.github.io/pull/237  

Discord context (core-devs): MCP support + dynamic tracking of GitHub repos and Discord channels is intended to enable agents to self-bootstrap against docs, GitHub activity, and channel knowledge, reducing “time to first useful answer.”

---

## 2) New Features

### Faster embedding initialization via configured embedding dimension
If you already know your embedding model’s output dimension, you can now skip an expensive “dimension discovery” call during agent init:
- **PR:** https://github.com/elizaos/eliza/pull/6357 (“support `EMBEDDING_DIMENSION` setting to skip API call”)

**Example (character / runtime config):**
```json
{
  "name": "my-agent",
  "settings": {
    "EMBEDDING_PROVIDER": "openai",
    "EMBEDDING_MODEL": "text-embedding-3-small",
    "EMBEDDING_DIMENSION": 1536
  }
}
```

**Why it matters:** reduces cold-start latency for agents that frequently spawn/scale or run in short-lived serverless contexts.

### Claude CI workflow upgrades (Opus 4.5) + security/maintenance jobs
CI automation now standardizes on the stable Claude action and upgrades default model usage:
- **PR:** https://github.com/elizaos/eliza/pull/6324 (“upgrade Claude workflows with Opus 4.5 and add security/maintenance jobs”)
- **PR:** https://github.com/elizaos/eliza/pull/6328 (allow cursor bot to trigger Claude workflows)

If your team relies on @claude review output as part of the dev loop, expect different style/coverage due to model changes.

### Plugin-SQL: Neon serverless support + improved RLS
Neon support landed alongside RLS hardening:
- **PR:** https://github.com/elizaos/eliza/pull/6343 (“add Neon serverless support & improve RLS security”)

If you deploy multi-tenant agents on Neon, validate RLS policies against your message server/world separation assumptions.

### n8n workflow automation direction (V2)
The most important architectural direction this week is adopting **n8n** as the primary workflow automation layer for Eliza v2:
- **Issue (P0):** https://github.com/elizaos/eliza/issues/6429 (“Integrate N8N Workflow Engine”)

Discord notes outlined a 3-layer approach:
1) AI workflow generator (NL → workflow JSON)  
2) Workflow engine (TaskService/cron execution)  
3) OAuth gateway (multi-tenant credentials)

While much of the work is still in-flight (plugin-n8n-workflow reported ~30% complete on Discord), developers building integrations should prefer workflow-first designs over one-off native plugins when possible.

---

## 3) Bug Fixes (with technical context)

### Critical onboarding blocker: `elizaos create` failing (ERR_PACKAGE_PATH_NOT_EXPORTED)
A “front door” regression prevented new projects from being generated:
- **Issue:** https://github.com/elizaos/eliza/issues/6388  
- **Fix PR:** https://github.com/elizaos/eliza/pull/6389 (“update import statement in elizaos.js to use package alias”)
- **Docs fix:** https://github.com/elizaos/docs/pull/83 (update install instructions to the scoped `@elizaos/cli`)

**Root cause (high level):** CLI bootstrapping referenced a non-exported subpath (`@elizaos/cli/dist/index.js`). Node’s package exports enforcement (esp. newer Node versions) rejected the import.

**What to do:** ensure you install the correct CLI package and that your automation/scripts do not pin the old global install path.

```bash
# recommended (per updated docs)
bun i -g @elizaos/cli
elizaos create
```

### Secrets leakage from shell env → agent secrets/plugin loading
A subtle but serious issue: `dotenv.config()` does not override pre-existing `process.env` values by default, which could cause shell env vars to leak into runtime configuration decisions.
- **PR:** https://github.com/elizaos/eliza/pull/6360 (“prevent shell environment variable leakage into agent secrets”)

**Impact:** unexpected provider selection, plugin enablement, or secret resolution when developers have stale environment variables in their terminal/session.

### SSE streaming deployment failures (“MIME_TYPE_MISMATCH”)
Discord reports showed SSE frequently failing due to backend/proxy configuration mismatches. A common successful workaround was switching to socket.io.

Given the multi-transport support in core (see PR #6300), production deployments that sit behind CDNs/reverse proxies should strongly consider WebSockets/socket.io first unless you explicitly control SSE headers and buffering behavior.

---

## 4) API Changes (Developer-facing)

### `serverId` → `messageServerId` migration (plugin-bootstrap + schema)
A compatibility fix landed to address mismatches between core and plugin-discord expectations:
- **PR:** https://github.com/elizaos/eliza/pull/6333

**What changed:** references to `serverId` in room/world contexts were updated to use `messageServerId`.

**Action for developers:**
- If you have custom providers/actions reading `message.content.serverId` or room/world `serverId`, update to `messageServerId`.
- Update DB queries/migrations that rely on the old field naming.

**Minimal example (TypeScript):**
```ts
// before
const sid = room.serverId;

// after
const sid = room.messageServerId;
```

### Knowledge retrieval behavior reminder: `SEARCH_KNOWLEDGE` returns fragments, not summaries
Discord clarified that `SEARCH_KNOWLEDGE` returns top matching fragments without LLM summarization. If you want “query → synthesize,” you must add a second step (custom action or multi-step plan).

**Pattern (pseudo-TypeScript):**
```ts
const hits = await runtime.actions.SEARCH_KNOWLEDGE({ query });
const summary = await runtime.useModel(ModelType.TEXT_LARGE, {
  prompt: `Summarize these passages:\n${hits.map(h => h.text).join("\n---\n")}`
});
```

---

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

### Twitter plugin: Broker Authentication mode (enterprise-friendly auth)
- **PR:** https://github.com/elizaos-plugins/plugin-twitter/pull/47

This adds a “broker auth” path designed for more secure automation (e.g., separating credential custody from the agent runtime). If you operate agents for multiple brands/tenants, review this mode early; it’s likely to become the recommended default for professional deployments.

### Discord plugin compatibility
The `serverId` → `messageServerId` changes (PR #6333) were motivated by real compatibility issues seen between eliza v1.7.x and plugin-discord (reported in Discord). If you maintain Discord automations, retest mention/room logic after upgrading.

### Telegram plugin stability signals
While not resolved in the provided week’s merges, there is ongoing ecosystem noise around Telegram image-handling crashes (see tracking issue referenced in monthly activity). Treat Telegram media ingestion as potentially unstable until patched; isolate or guard image pipelines.

---

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

### Embeddings provider reliability + v2 direction (“embeddings move to plugins”)
Discord reports this week:
- OpenRouter embeddings have been error-prone for multiple users.
- OpenAI embeddings are currently the most reliable in practice.
- Ollama, OpenAI, and OpenRouter are intended to be supported—but **v2.x plans to move embeddings completely out of runtime into plugins**, reducing tight coupling and improving provider modularity.

### Knowledge plugin cost spike traced to contextual embeddings
A recurring support issue: unexpectedly high token usage and cost per query when contextual embeddings are enabled.
- Discord note: `CTX_KNOWLEDGE_ENABLED=true` can massively increase cost.

**Recommendation:** disable contextual embeddings unless you’ve validated the cost/quality tradeoff for your corpus, and prefer smaller embedding models for large chunking workflows.

---

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

### V2.0.0 architecture is a major pivot (runtime-first; non-essentials removed)
- **PR (large, ongoing):** https://github.com/elizaos/eliza/pull/6351 (“V2.0.0”)

The v2 branch explicitly removes/decouples non-essential components (app/server/CLI) to focus on runtime implementations (Rust/TypeScript) and a smaller set of “critical plugins.” Expect migration work if you rely on the monorepo layout or v1 packaging assumptions.

### Embeddings + knowledge stack will change shape in v2.x
Per Discord core-dev guidance: embeddings are expected to move out of runtime and into plugins. If you built tooling that assumes embeddings are a core runtime responsibility, plan to refactor toward:
- “runtime calls plugin embedding service” rather than “runtime owns embedding provider selection.”

### Transport selection (SSE vs WebSocket) in production
Even though the framework supports SSE, real-world deployment constraints (reverse proxies, CDNs, buffering) are causing frequent failures. If you’re upgrading and you need streaming, prefer socket-based transports unless you can guarantee correct SSE headers/endpoints end-to-end.

---

**Docs & contribution workflow note:** documentation updates are now expected via PRs to https://github.com/elizaOS/docs (per Discord core-devs).