# ElizaOS Developer Update (2026-01-29 → 2026-02-04)

## 1) Core Framework (Architecture / Plugin System / Agent Runtime)

### Skill invocation reliability: explicit activation sequencing (Cloud + framework pattern)
Discord testing surfaced a major reliability problem: **skills/tools were not invoked in ~56% of evaluation cases even when docs were available**. The most effective mitigation discussed was to enforce an explicit “evaluate → activate → implement” sequence at the **prompt hook layer** (e.g., `UserPromptSubmit`), similar in spirit to Composio / Zapier MCP patterns.

**Reference discussion (Discord, 2026-02-02)**: skill invocation failure rate + working hook strategy.

**Recommended pattern (framework-side prompt policy):**
```ts
// Pseudocode illustrating the policy; adapt to your runtime’s hook API.
runtime.hooks.on("UserPromptSubmit", async (ctx) => {
  ctx.systemPreamble += `
You MUST follow this sequence:

1) For EACH available skill/tool: decide YES/NO if it is needed (include brief reason).
2) If YES: call the tool immediately (Skill(...)) with the minimal args.
3) Only after tool calls: write the final response / implementation.

Do not skip step 2.`;
  return ctx;
});
```

**Why this helps technically**
- Moves tool selection from an implicit model behavior to an explicit contract enforced at the orchestration layer.
- Reduces “I’ll just answer from prior knowledge” responses when tools should be called.
- Makes evaluation deterministic: you can unit-test that step (2) occurred before step (3).

---

### Branch guidance: `odi-dev` diverges from `main`
Core devs advised builders to use the **`odi-dev` branch** due to “numerous improvements and bug fixes” not yet in `main`.

**Actionable**
```bash
git fetch origin
git checkout odi-dev
pnpm i
pnpm test
```

**Reference**: core-devs Discord notes (2026-02-03).

---

### PR review workflow tooling: `prr`
A new internal PR review tool, **`prr`**, was shared as a way to “sit on pull requests until they are ready” (useful for batching review cycles and preventing premature merges).

**Reference (Discord, 2026-02-03)**: tool announcement + usage discussion.

---

## 2) New Features (with technical detail + examples)

### OpenClaw skills support: `plugin-cskills` reference implementation
A reference plugin repository was shared for OpenClaw-style “skills” integration:
- Repo: https://github.com/odilitime/plugin-cskills  
- Intended to demonstrate plugin capability patterns and act as a base for skill packaging.

**Planned enhancements (security-related, but also enables richer “skill marketplace” workflows)**
- Add **scanner skills** (static/dynamic checks)
- Add a **rewrite/adaptation phase** (transform packaged skill code into an Eliza-compatible form)
- Add **LLM-based skill review** prior to execution/publication

**Reference**: coders Discord thread (2026-02-03).

---

### DIaaS (Data Infrastructure as a Service) integration via plugins (Solana signals)
A developer building a Solana token DIaaS (on-chain analysis → filtered signals) confirmed that **Eliza agents can consume arbitrary signal APIs by implementing a plugin**.

**Minimal plugin sketch (signals → tool):**
```ts
import { z } from "zod";

export const diassSignalsTool = {
  name: "diass.getSignals",
  description: "Fetch trading signals from DIaaS for a given token mint.",
  inputSchema: z.object({
    mint: z.string(),
    horizon: z.enum(["5m", "1h", "1d"]).default("1h"),
  }),
  async handler({ mint, horizon }, ctx) {
    const res = await fetch(`${ctx.secrets.DIASS_BASE_URL}/signals?mint=${mint}&h=${horizon}`, {
      headers: { "Authorization": `Bearer ${ctx.secrets.DIASS_API_KEY}` },
    });
    if (!res.ok) throw new Error(`DIaaS error: ${res.status}`);
    return await res.json();
  },
};
```

**Operational guidance**
- Treat DIaaS responses as **untrusted input** (validate schema, cap payload size).
- If signals can trigger transactions, put an explicit **human-in-the-loop** policy in your agent prompt or tool gating layer.

**Reference**: coders Discord (0xbbjoker supporting Lucas Alpes, 2026-02-03).

---

## 3) Bug Fixes (critical fixes with technical context)

### Skill invocation “silent failure” (mitigation now; root-cause work pending)
While not a code-merged fix this week, the team converged on a pragmatic mitigation: enforce explicit activation via a `UserPromptSubmit`-style hook (see Core Framework section). This addresses the observed failure mode where the model proceeds to answer without tool calls.

**Next steps for a proper fix**
- Audit tool/skill descriptions: ambiguous descriptions correlate strongly with non-invocation.
- Add telemetry: log “skills available vs. skills called” per turn for regression detection.

**Reference**: Discord (2026-02-02).

---

### Eliza Cloud account duplication risk (Proton email aliasing)
A critical UX/data integrity issue was reported: using both `@proton.me` and `@protonmail.com` for the same Proton inbox appeared to create **duplicate accounts**, causing an agent to “disappear” from the dashboard.

**Impact**
- Tenant identity mismatch → resources attached to a different user row/subject.
- Potential loss-of-access symptoms even though data still exists.

**Recommended mitigation (platform-side)**
- Normalize identities by linking providers to a stable subject (OIDC `sub`) or canonicalized email mapping.
- Add UI warnings when an email domain alias is detected.

**Reference**: Discord (2026-02-02).

---

## 4) API Changes (developer-facing)

### MCP plugin evolution: dynamic tool actions + StreamableHTTP transport
Recent plugin-mcp work (merged during this interval) introduced:
- **`feat!` Dynamic MCP tool actions (v1.8.0)** — marked as breaking in the changelog context
- **StreamableHTTP transport** + custom headers support

If you implement MCP servers/clients or rely on prior tool registration semantics, re-check:
- How tools/actions are discovered and bound
- Whether your transport assumptions (SSE vs HTTP streaming) still hold
- Whether you need to pass additional headers (e.g., for routing, tenancy, OpenRouter-style metadata)

**Related activity (headers support)**
- OpenRouter plugin work added support for custom headers such as `HTTP-Referer` / `X-Title` (PR: https://github.com/elizaos-plugins/plugin-openrouter/pull/23)

**Notes**
- Treat `feat!` as a signal to pin versions and test upgrades in staging.
- Add contract tests that assert “tool appears + tool callable + response parsed”.

---

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

### OpenClaw ↔ Eliza rollout timeline (agent integration)
OpenClaw integration was discussed as a phased rollout:
- Everyone gets access to **Eliza first**
- **Custom agent capabilities** follow “a few weeks after launch”

This matters if you’re building multi-channel automations on day-one: plan for a period where the runtime is available but custom integration points may be gated.

**Reference**: coders Discord Q&A (2026-02-03).

### Telegram plugin into Cloud (status)
Work to merge Telegram into Cloud was tracked in `elizaos/eliza` issues and marked closed earlier this week:
- Issue: https://github.com/elizaos/eliza/issues/6397 (closed 2026-02-02)

If you depend on Telegram in Cloud, validate:
- multi-tenant routing
- session binding per user/bot
- webhook retry behavior and idempotency

---

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

### Anthropic: Claude Sonnet 5 watch
Core devs discussed **Claude Sonnet 5** as potentially “a generation ahead” and worth testing. No provider adapter changes were landed in the provided data, but developers should anticipate:
- different tool-call behavior (may improve invocation reliability)
- different cost/performance tradeoffs (noted as significant vs current models)

**Practical recommendation**
- Add a model-switch smoke test suite: “same prompt → tool call expected → response schema stable”.

### OpenRouter metadata headers
If you route via OpenRouter, custom headers support (e.g., `HTTP-Referer`, `X-Title`) is being added/expanded:
- PR: https://github.com/elizaos-plugins/plugin-openrouter/pull/23

---

## 7) Breaking Changes / Migration Warnings (V1 → V2 + ecosystem migration)

### Eliza Cloud V2 workstream: review pending
A Cloud V2 PR was submitted for review:
- PR: https://github.com/elizaos/eliza-cloud-v2/pull/278

Until this merges (and release notes land), assume V1→V2 may involve breaking changes in:
- auth/session tenancy boundaries
- plugin deployment/runtime constraints (serverless vs long-lived)
- tool routing (especially around MCP transport changes)

**Recommendation**
- Keep plugin surfaces narrow: one tool = one responsibility.
- Avoid relying on undocumented Cloud internals; wrap Cloud APIs behind your own adapter.

### Skill marketplace security is becoming a “hard requirement”
Due to concerns about **malicious skills** (notably on “clawhub”), expect upcoming breaking policy changes:
- mandatory scanning/rewrite/review before execution or publication
- possible sandboxing requirement for untrusted skill code

**Reference**: coders Discord security thread (2026-02-03).

### Token migration (ai16z → elizaos): operational risk, not framework API
Multiple users reported severe migration issues and losses; support is being handled in dedicated channels. While not an Eliza framework API break, it **does** impact developer operations (payments, access, community trust) and should be treated as a high-priority documentation + support workflow item.

**Recommendation**
- If your app references token state for gating/credits, add fallback paths and clear UI messaging until migration volatility settles.

---

## PRs / Issues to Watch This Week
- Eliza core PR (review): https://github.com/elizaos/eliza/pull/6457
- Eliza Cloud V2 PR (review): https://github.com/elizaos/eliza-cloud-v2/pull/278
- Character/prompt iteration issue: https://github.com/elizaos/eliza/issues/6447
- Billing tracking issue: https://github.com/elizaos/eliza/issues/6448
- OpenRouter headers PR: https://github.com/elizaos-plugins/plugin-openrouter/pull/23
- OpenClaw skills reference: https://github.com/odilitime/plugin-cskills