# ElizaOS Developer Update (2026-01-22 → 2026-01-28)

This week continued the V1 hardening work while the core team publicly pivoted V2 toward *workflow automation as the primary product surface*, with n8n as the workflow substrate and Eliza acting as the conversational workflow generator + runtime.

---

## 1) Core Framework

### V2 direction: agent platform + workflow automation (n8n-first)
Core-dev discussions converged on using **n8n’s plugin architecture** as the primary integration surface (rather than building one-off native plugins for every SaaS). Proposed architecture:

- **Layer 3 — AI Workflow Generator:** NL → workflow draft (starting from prefabs, then “closest-match” generation using Claude Opus; generated workflows are marked experimental and iterated with users)
- **Layer 2 — Workflow Engine:** orchestration + scheduling (`TaskService`/cron) to run workflows reliably
- **Layer 1 — OAuth Gateway:** multi-tenant credential storage and scoped token access

V2 is being published for early testing as `@elizaos/core@next` and includes “computer use” + “browser use” capabilities (based on working OSS implementations), positioning Eliza as an operator agent capable of both API-based workflows (n8n) and UI-based automation (browser/computer use).

**Install for evaluation**
```bash
npm install @elizaos/core@next
# or
bun add @elizaos/core@next
```

### Runtime initialization & embedding startup optimization (V1)
To reduce startup latency and avoid extra embedding calls, core gained support for configuring embedding dimensionality directly:
- PR: **`feat(core): support EMBEDDING_DIMENSION setting to skip API call`** ([elizaos/eliza#6357](https://github.com/elizaos/eliza/pull/6357))

This is particularly relevant for agents that always use a known embedding model (and therefore fixed dimensions) and want to avoid the extra “dimension detection” API hit on boot.

---

## 2) New Features

### Streaming + Python runtime parity improvements (V2 track)
A major Python pass landed, improving examples and runtime ergonomics and adding streaming primitives:
- PR: **`fix(v2.0.0): Python example testing & fixes`** ([elizaos/eliza#6358](https://github.com/elizaos/eliza/pull/6358))

Highlights developers will feel immediately:
- **True token streaming** support added to the Python examples (SSE-style token-by-token)
- Example hardening: `.env` loading, `inmemorydb` plugin included where needed
- Runtime ergonomics: `AgentRuntime.get_available_actions()`, `AgentRuntime.get_entity()` alias, `get_memories()` kwargs support

**Minimal Python example (conceptual)**
```python
from elizaos.runtime import AgentRuntime

runtime = AgentRuntime(...)
print(runtime.get_available_actions())
```

### External MCP servers via Eliza Cloud API
Developers discussed adding external MCP servers to agents by registering them with Eliza Cloud, allowing Eliza to proxy calls for tool use / red teaming.

**API**
- `POST /api/v1/mcps` (register an external MCP server; Eliza Cloud proxies calls)

**Example request (shape illustrative; confirm final schema in Cloud docs once published)**
```bash
curl -X POST "$ELIZA_CLOUD_URL/api/v1/mcps" \
  -H "Authorization: Bearer $ELIZA_CLOUD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-redteam-mcp",
    "baseUrl": "https://mcp.example.com",
    "description": "External MCP server for red teaming tools"
  }'
```

---

## 3) Bug Fixes

### CLI project generation failure (`ERR_PACKAGE_PATH_NOT_EXPORTED`)
A high-impact onboarding bug was reported where `elizaos create` failed due to importing a non-exported subpath (`@elizaos/cli/dist/index.js`). This breaks first-run developer experience on newer Node/bun configurations.

- Issue: **“Can not generate project”** ([elizaos/eliza#6388](https://github.com/elizaos/eliza/issues/6388)) (closed)
- Fix: **Use the package alias import instead of `/dist/index.js`** ([elizaos/eliza#6389](https://github.com/elizaos/eliza/pull/6389))

If you maintain tooling or wrappers around the CLI, ensure you are not relying on deep imports into `@elizaos/cli/*` paths that aren’t exported.

### Knowledge plugin: misconfiguration + unexpectedly high cost profiles
Two critical operational issues surfaced in community debugging:

1) **Config validation error**
- Symptom: `Invalid enum value` for `EMBEDDING_PROVIDER` when set to `openrouter`
- Root cause: embedding provider enum only allows `'openai' | 'google'` (OpenRouter is not a valid *embedding provider* in that config path)

2) **High per-query cost**
- Symptom: small markdown docs causing *tens of thousands of tokens per query* (~$0.03–0.04) in the Knowledge plugin
- Root cause: **contextual embeddings enabled** (`CTX_KNOWLEDGE_ENABLED=true`), which expands context/token usage materially

Immediate mitigations discussed:
- Disable contextual embeddings unless you explicitly need them
- Use a small embedding model for ingestion (e.g., `text-embedding-3-small`) and validate chunking behavior
- Document and/or surface `ctx-embeddings.ts` behavior so operators understand why token usage spikes

---

## 4) API Changes

### `serverId` → `messageServerId` migration (V1)
A compatibility fix landed to complete the migration from `serverId` to `messageServerId` throughout bootstrap actions/providers and related SQL schema references:

- PR: **`fix: plugin-bootstrap (+ sql minor) actions/providers for serverId => messageServerId change`** ([elizaos/eliza#6333](https://github.com/elizaos/eliza/pull/6333))

**Developer impact**
- If your plugins/actions/providers read `message.content.serverId` or log `serverId`, update to `room.messageServerId` / `world.messageServerId` as appropriate.
- Test fixtures and mocks must be updated accordingly.

---

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

### Discord + Telegram plugin alignment with core
Plugins were updated to keep pace with core releases and payload expectations:

- Discord: **Version alignment / lockfile refresh** ([elizaos-plugins/plugin-discord#44](https://github.com/elizaos-plugins/plugin-discord/pull/44))
- Telegram: **TypeScript/payload alignment with `@elizaos/core` 1.7.x** ([elizaos-plugins/plugin-telegram#24](https://github.com/elizaos-plugins/plugin-telegram/pull/24))
- Telegram CI/quality: **structured logging + linting** ([elizaos-plugins/plugin-telegram#21](https://github.com/elizaos-plugins/plugin-telegram/pull/21))

### Action handler callbacks: “only first callback received” reports
A developer-reported issue on `@elizaos/core@1.7.2` suggested action callbacks only delivered the first message. Core-devs reiterated that **multiple callbacks are supported**; troubleshooting focused on task planner configuration (one-step vs multi-step) and expectations about *when* callbacks are emitted (immediate vs completion response).

If you rely on incremental progress updates, validate your planner mode and confirm your transport (Discord/Telegram/etc.) surfaces intermediate callbacks rather than only final completion payloads.

---

## 6) Model Provider Updates

### CI: Claude Opus 4.5 in automated workflows
The project’s Claude-powered CI workflows were upgraded to use Opus 4.5 (and additional security/maintenance jobs were added earlier in the month; still relevant as teams standardize on Opus for coding + workflow generation):

- PR: **`feat(ci): upgrade Claude workflows with Opus 4.5 and add security/maintenance jobs`** ([elizaos/eliza#6324](https://github.com/elizaos/eliza/pull/6324))

Community sentiment this week strongly favored Opus 4.5 for workflow generation and agent reasoning.

### OpenAI-compatible “chat completions” endpoint interoperability (investigation)
Developers raised an open question about supporting OpenAI-compatible JSON APIs across providers (OpenRouter, Kobold, etc.). No merged change yet, but if you maintain provider adapters, expect upcoming design work around a unified “OpenAI-compatible” facade.

---

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

### V2 packaging/shape is intentionally minimal
The V2 working branch explicitly removes non-essentials (app/server/CLI) to focus on runtimes + critical plugins:
- PR (open): **`V2.0.0`** ([elizaos/eliza#6351](https://github.com/elizaos/eliza/pull/6351))

**Migration implication:** if you are building against the monorepo “full stack” assumptions from V1 (server + CLI + app in one place), V2 expects you to compose your own distribution and treat Eliza as a runtime/SDK.

### Field rename fallout: `messageServerId`
Even though [#6333](https://github.com/elizaos/eliza/pull/6333) was framed as a compatibility fix, downstream code that still assumes `serverId` in room/world/message contexts will break or silently lose metadata. Audit custom plugins and transports.

### Knowledge plugin operational defaults
If you are migrating knowledge-heavy agents:
- Treat `CTX_KNOWLEDGE_ENABLED` as a cost/perf “high gear” mode, not a default
- Ensure embedding provider enums/config match current validation (OpenRouter usage must be configured via the supported knobs, not by setting it as the embedding provider enum)

---

### References
- Core repo: https://github.com/elizaos/eliza
- Docs: https://docs.elizaos.ai/
- V2 testing install: `npm install @elizaos/core@next`