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

This update summarizes core framework and plugin work, with additional technical context pulled from developer Discord discussions.

---

## 1) Core Framework

### Agent runtime: deployment workflows (GPU training)
A repeatable **GPU training/deployment** workflow is being standardized around **Docker Compose**. The current recommended flow (per core-devs) is:

1) Create a `docker-compose.yml` locally  
2) Submit it for review (analysis/corrections)  
3) Launch once validated (aiming for “seamless launch” parity across environments)

This is not yet codified as an official doc page, but is being used as the operational process for porting and running GPU workloads.

Related discussion: core-devs (Agent Joshua ₱ | TEE) guidance to collaborate with Shelven on the porting effort.

### Knowledge/RAG architecture exploration: PageIndex via MCP
Core devs are evaluating **PageIndex** as a complementary RAG strategy: **document trees instead of embeddings**, positioned as “custom encyclopedias using tree structures.” The proposed integration path is via **MCP (Model Context Protocol)** to make PageIndex query/navigation available as agent tools.

Discord context: core-devs and daily summary references to PageIndex and MCP integration planning.

---

## 2) New Features

### MCP plugin: Dynamic MCP tool actions (v1.8.0)
`elizaos-plugins/plugin-mcp` shipped a major feature release:

- **feat!: Dynamic MCP tool actions (v1.8.0)** — merged via PR **#22**  
  https://github.com/elizaos-plugins/plugin-mcp/pull/22

What this enables:
- Tools exposed by an MCP server can now be mapped to **dynamic actions** in the agent runtime, rather than requiring static action wiring.
- This is a foundational step toward “tool registries” and runtime tool discovery (especially relevant to upcoming x402/agent-index discovery work).

**Example (conceptual)**
If your MCP server exposes tools like `pageindex.search` or `github.listPullRequests`, the agent can surface these as runtime actions without hardcoding each action in a plugin.

```ts
// Pseudocode illustrating the intent of dynamic tool->action wiring
import { createMcpClient, actionsFromMcpTools } from "@elizaos/plugin-mcp";

const mcp = await createMcpClient({
  endpoint: process.env.MCP_ENDPOINT!,
});

const tools = await mcp.listTools();
const actions = actionsFromMcpTools(tools, {
  // optional: naming, allow/deny lists, auth passthrough
  allow: ["pageindex.*", "github.*"],
});

agent.registerActions(actions);
```

> Note: Exact API names may differ; see plugin-mcp PR #22 for the canonical implementation and migration notes.

---

### MCP transport: StreamableHTTP + custom headers
Two related improvements landed in the MCP stack:

- **StreamableHTTP transport + code quality improvements** — PR **#21**  
  https://github.com/elizaos-plugins/plugin-mcp/pull/21
- **StreamableHTTP transport and custom headers** — PR **#20**  
  https://github.com/elizaos-plugins/plugin-mcp/pull/20

What this enables:
- Running MCP over an HTTP transport that supports streaming semantics.
- Attaching **custom headers** (useful for gateway auth, multi-tenant routing, or proxying through hosted services).

**Example: configure headers for an MCP endpoint**
```ts
// Pseudocode showing the target configuration style
const mcp = await createMcpClient({
  transport: {
    type: "streamableHttp",
    url: process.env.MCP_URL!,
    headers: {
      Authorization: `Bearer ${process.env.MCP_TOKEN}`,
      "X-Client": "elizaos-agent",
    },
  },
});
```

---

### OpenRouter plugin: header support for X-Title + HTTP-Referer
A feature PR was opened to improve OpenRouter compatibility/telemetry:

- `elizaos-plugins/plugin-openrouter` — **Add `X-Title` and `HTTP-Referer` header support** — PR **#23**  
  https://github.com/elizaos-plugins/plugin-openrouter/pull/23

This is useful when:
- You need OpenRouter request attribution or better dashboard visibility.
- You’re routing multiple agents/apps through a shared OpenRouter key and want cleaner separation.

---

### Registry: new plugin entries
Two registry PRs were opened to expand discoverability:

- `elizaos-plugins/registry` — Add **AsterPay** plugin reference — PR **#251**  
  https://github.com/elizaos-plugins/registry/pull/251
- `elizaos-plugins/registry` — Add **Agent Index plugin for x402 endpoint discovery** — PR **#252**  
  https://github.com/elizaos-plugins/registry/pull/252

The x402 discovery entry is particularly relevant to ongoing discussions about:
- letting agents **pay/top-up** programmatically (instead of credit cards)
- enabling a network where nodes can advertise paid capabilities via endpoints

---

## 3) Bug Fixes (with technical context)

### MCP plugin stabilization + quality improvements
While PRs #20/#21/#22 are feature-oriented, they also include significant internal changes focused on correctness and maintainability (per contributor notes). In practice, these changes address common pain points when MCP is deployed behind gateways/proxies:
- transport robustness (streaming HTTP)
- header propagation
- reducing fragility in tool invocation plumbing

Links:
- https://github.com/elizaos-plugins/plugin-mcp/pull/20
- https://github.com/elizaos-plugins/plugin-mcp/pull/21
- https://github.com/elizaos-plugins/plugin-mcp/pull/22

### ElizaCloud integration blockers (identified, not yet resolved)
Developers reported two **server-side blockers** while integrating OpenClaw ↔ ElizaCloud MCP apps:

1) **CommonJS/ESM incompatibility** loading `isomorphic-dompurify` in ElizaCloud deployment  
2) A2A endpoint failure: `contentModerationService` function error in `A2A message/send`

These are not confirmed fixed in this interval, but are called out because they can hard-block production integrations and should influence how you bundle/deploy clients (and what you assume about hosted environments).

A2A docs reference shared in Discord:  
https://www.dev.elizacloud.ai/docs/a2a

---

## 4) API Changes (developer-facing)

### MCP plugin v1.8.0 introduces a breaking surface (“feat!”)
The “feat!” in **plugin-mcp PR #22** indicates a breaking change in how MCP tools are represented and/or bound into actions.

**Action required for plugin authors:**
- If you previously depended on a static mapping of tool → action, re-check your integration against v1.8.0.
- Validate any custom middleware around tool invocation (argument shaping, validation, auth) because dynamic tool action generation may change call paths and naming.

PR link (primary reference):  
https://github.com/elizaos-plugins/plugin-mcp/pull/22

---

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

### Twitter: Broker Authentication mode
A security-focused upgrade landed in the Twitter plugin:

- `elizaos-plugins/plugin-twitter` — **Broker Authentication** — PR **#47**  
  https://github.com/elizaos-plugins/plugin-twitter/pull/47

This is aimed at more enterprise/professional automation setups where:
- you do not want to store raw credentials in the agent runtime
- you want a brokered auth flow (separation of duties between agent and credential authority)

### Telegram/WhatsApp: webhook service planning (architecture work)
There’s active planning to expand multi-platform messaging via a **generic webhook service**, enabling WhatsApp/Telegram style integrations without duplicating per-platform glue code.

Relevant Eliza issues created recently:
- Generic webhook service: https://github.com/elizaos/eliza/issues/6430
- Multi-platform messaging planning (WhatsApp/Telegram) referenced previously: https://github.com/elizaos/eliza/issues/6429

---

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

### Cost-aware provider routing via OpenRouter (Kimi 2.5)
Developer discussion highlighted switching high-cost workloads (e.g., “Opus 4.5”) to **Kimi 2.5 via OpenRouter** for better cost/perf during bot-driven testing.

Operational takeaway:
- ElizaOS remains provider-agnostic (“use Eliza with any LLM” per dev support), so you can route inference through OpenRouter for flexible provider selection.

### Local inference / embeddings work
Work is ongoing (on a dev branch) to make **embeddings integration** easier in `plugin-local-ai` (not merged in this interval, but flagged as a near-term improvement for teams trying to reduce hosted inference spend).

---

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

### MCP plugin upgrade risk (v1.8.0)
If your agent depends on MCP tooling:
- Treat `plugin-mcp` **v1.8.0** as a migration point.
- Pin versions during upgrades and verify tool invocation end-to-end (especially if you rely on deterministic action names).

Reference: https://github.com/elizaos-plugins/plugin-mcp/pull/22

### Monorepo stability: integration testing gaps between “1x” and “2x”
Core contributors continue to report recurring breakages across version lines, and are pushing for stronger integration tests (pattern referenced from `plugin-n8n-workflow`). If you ship plugins targeting multiple runtime lines:
- add CI matrices across runtime versions
- add “smoke agents” that validate provider selection + one-shot runs + tool calling

(Provider selection failures in “one-shot mode” were reported on `develop` in discussion; verify your pipelines if you track `develop`.)

---

### Appendix: Developer-Visible Platform Constraints (ElizaCloud)
ElizaCloud API onboarding friction was reported as a practical blocker:
- API key creation fails unless a **payment method (credit card)** is attached—even when accounts have free credits.
- **x402 payments** appear disabled on free tier accounts, blocking bot-based top-ups/testing.

This has downstream impact on:
- CI bots that need ephemeral keys
- open-source contributors who cannot use cards for testing
- automated agent provisioning flows

(Tracked as a dev pain point; no PR link in this interval—watch for forthcoming changes in ElizaCloud auth/billing APIs.)