# ElizaOS Developer Update (2026-04-20 → 2026-04-26)

This update summarizes core framework work, automation/runtime changes, and integration notes captured across GitHub activity and developer Discord discussions through **2026-04-26** (published **2026-04-27**).

---

## 1) Core Framework

### Runtime event bus → trigger pipeline (event-kind triggers)
ElizaOS now has a first-class bridge from the runtime event bus to the trigger handler pipeline via **`TriggerEventBridge`**, enabling “event-kind triggers” (Discord `MESSAGE_RECEIVED`, Telegram `MESSAGE_RECEIVED`, webhooks, etc.) to actually dispatch into the trigger execution flow.

- PR: **feat(triggers): wire event-kind triggers to the runtime event bus** — https://github.com/elizaOS/eliza/pull/7116  
- Follow-up fixes/unblocks for Automations scope routing:
  - **fix(triggers): unblock CREATE_TRIGGER_TASK dispatch on page-automations** — https://github.com/elizaOS/eliza/pull/7119  
  - **fix(triggers): CREATE_TRIGGER_TASK page-automations unblock + LIFE handler hardening** — https://github.com/elizaOS/eliza/pull/7124  
  - **fix(lifeops): scope-reject LIFE on foreign page-* scopes** — https://github.com/elizaOS/eliza/pull/7123

**Why it matters:** triggers are no longer “configuration-only”; inbound events can deterministically wake the trigger engine without needing ad-hoc polling or UI-driven execution.

### Workflow generation/deploy hardening: validate & repair pre-deploy
A new **`validateAndRepair` pre-deploy pass** was added to reduce workflow deployment failures caused by LLM hallucinations and inconsistent credential wiring. The pass also includes deterministic credential injection.

- Mentioned in daily engineering summary (2026-04-26): validate+repair pre-deploy with anti-hallucination defenses + deterministic credential injection  
- Related route wiring that unblocked end-to-end credential resolution for the “hero chat” workflow create path:
  - **fix(n8n): hero-chat workflow create resolves credentials end-to-end** — https://github.com/elizaOS/eliza/pull/7118  
  - **test(n8n): pin handleGenerateWorkflow deployWorkflow path** — https://github.com/elizaOS/eliza/pull/7126  

### Concurrency primitives unified: batch queue / drains
Core now shares a common concurrency + retry + drain abstraction across embeddings, prompt batching, and knowledge embedding paths.

- PR: **feat(core): shared batch-queue drains and bounded knowledge embeddings** — https://github.com/elizaOS/eliza/pull/6722  
- Docs: **Batch Queue** — `packages/docs/runtime/batch-queue.mdx` (repo path)  
  https://github.com/elizaOS/eliza/tree/develop/packages/docs/runtime

### Desktop/app runtime surfaces: apps as managed native windows
App surfaces can now open in managed Electrobun windows, keeping detached windows attached to page-scoped chat/control context.

- PR: **feat: open app surfaces in managed desktop windows** — https://github.com/elizaOS/eliza/pull/7092  
- PR: **feat(app-core): apps as native windows + App Details page** — https://github.com/elizaOS/eliza/pull/7115  

---

## 2) New Features

### x402: paid plugin routes + seller middleware (agent monetization primitives)
Agents can now expose plugin routes protected by an **x402 payment gate** (seller middleware), including startup validation and replay protection. This is the key building block for agent-as-a-service deployments where *the agent runtime itself* can collect per-call payments for routes.

- PR: **feat(agent): x402 paid plugin routes and test harness hardening** — https://github.com/elizaOS/eliza/pull/7100  

**Developer usage (route protection)**
Conceptually, plugin routes can opt into payment protection by attaching x402 configuration (price, asset, facilitator/standard mode) and letting the middleware enforce payment before the handler executes.

```ts
// Pseudocode illustrating intent — exact API names may differ by plugin route wrapper.
import { applyPaymentProtection } from "@elizaos/agent/middleware/x402";

router.post(
  "/plugins/my-plugin/run",
  applyPaymentProtection({
    price: { amount: "0.01", currency: "USDC" },
    mode: "standard", // or facilitator
    replayProtection: true,
  }),
  async (req, res) => {
    const result = await runPaidCapability(req.body);
    res.json(result);
  }
);
```

**Ecosystem context:** In Discord, the team discussed token utility and minimizing user friction by accepting any payment method and using revenue for buybacks (rather than forcing token-only payments). This aligns well with x402’s “payment-method agnostic” direction.
- Discussion recap (2026-04-26): token utility strategy and v3 nearing completion  
  https://discord.com/channels/1253563208833433701/1253563209462448241  
- Related Discord demo: `@elisym/plugin-elizaos-elisym` (agent marketplace) using Nostr discovery + Solana settlement (devnet)  
  (Discord summary 2026-04-24)

### Automations UX: 6-stage workflow generation progress UI
Workflow generation now shows a multi-stage progress card instead of a generic “Building workflow…” chip, improving usability during 10–30s structured-output generations.

- PR: **feat(automations): WorkflowGenerationProgress — multi-stage progress card** — https://github.com/elizaOS/eliza/pull/7127  

### Prompt output format override for non-Claude models
`dynamicPromptExecFromState` can now be influenced via `PROMPT_OUTPUT_FORMAT`, which is useful when models don’t reliably emit TOON encapsulation (e.g., Gemini, local Llama/Ollama).

- PR: **feat(core): PROMPT_OUTPUT_FORMAT env var for dynamicPromptExecFromState** — https://github.com/elizaOS/eliza/pull/6978  

```bash
# Example: prefer JSON output format on deployments where TOON is unreliable
export PROMPT_OUTPUT_FORMAT=json
```

---

## 3) Bug Fixes (critical / high-impact)

### Telegram triggers not firing (MESSAGE_RECEIVED emission)
Telegram inbound messages were not emitting `MESSAGE_RECEIVED` onto the runtime event bus in the in-process shim path, so event-kind triggers would register but never fire.

- PR: **fix(telegram): emit MESSAGE_RECEIVED on Telegram messages so event-kind triggers fire** — https://github.com/elizaOS/eliza/pull/7122  

**Technical root cause:** trigger dispatch relied on runtime bus emissions; Telegram’s shim path bypassed emission, so the `TriggerEventBridge` had nothing to match.

### Workflow + chat room state cleanup on deletion
Deleting workflows left `workflow:<id>` rooms behind, causing orphan conversations and noisy aggregations.

- PR: **fix(automations): delete chat conversation when workflow is deleted + skip orphan workflow rooms in aggregator** — https://github.com/elizaOS/eliza/pull/7121  

### Streaming generation timeout increased (90s → 180s)
Complex LLM workloads (workflow generation, tool-use structured outputs, long-context reflection) frequently exceeded 90 seconds; routes would timeout mid-stream.

- PR: **fix(chat): bump streaming generation timeout 90s -> 180s** — https://github.com/elizaOS/eliza/pull/7117  

### Planner robustness: tolerate malformed action XML
Planner output occasionally produced unclosed `<action>` wrappers. The runtime now tolerates these malformed XML cases and continues parsing.

- PR: **fix(message): tolerate malformed planner action XML** — https://github.com/elizaOS/eliza/pull/7099  

### Reduce prompt bloat (long-context cap pressure)
Multiple providers/evaluators were redundantly shipping oversized context, causing long-context blowups and cost spikes.

- PR: **fix(reflection,providers): reduce prompt bloat blowing long-context cap** — https://github.com/elizaOS/eliza/pull/7013  

### Prevent internal leakage in user-visible replies
Several fixes targeted leakage of internal scheduler/task state and internal mechanism wording in failure replies:

- **fix(agent): stop workbench task list from leaking runtime scheduler tasks** — https://github.com/elizaOS/eliza/pull/7095  
- **fix(message): stop leaking internal mechanism words in transient-failure replies** — https://github.com/elizaOS/eliza/pull/7098  
- **fix(message): drop passive bookkeeping actions when delegation owns the turn** — https://github.com/elizaOS/eliza/pull/7097  

### Swarm synthesis delivery: post back to triggering room
Task agents could finish without posting results back into the originating room due to broken routing in swarm synthesis.

- PR: **fix(agent): deliver swarm synthesis to the triggering room** — https://github.com/elizaOS/eliza/pull/7090  

---

## 4) API Changes (developer-facing)

### Streaming callback type unification (TTS garbling fix)
A single canonical `StreamChunkCallback` type alias replaces multiple inline definitions, also removing a dual-extractor path that caused TTS garbling.

- PR: **fix(core): consolidate StreamChunkCallback, remove dual-extractor CAUSING TTS garbling** — https://github.com/elizaOS/eliza/pull/6690  
- Docs updated:
  - `packages/docs/guides/streaming-responses.mdx`
  - `packages/docs/runtime/messaging.mdx`
  - `packages/docs/runtime/types-reference.mdx`

**Action for plugin authors:** if you referenced a bespoke `onStreamChunk` signature (copy/pasted or redefined), align to the canonical exported type to avoid subtle streaming/TTS regressions.

### Agent HTTP surfaces extended for paid routes (x402)
`@elizaos/core` route/payment types were extended to support x402 paid plugin routes (see PR #7100). If you maintain custom route wrappers, re-run typechecks and ensure your handler registration accounts for the new payment metadata.

---

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

### Telegram
- **MESSAGE_RECEIVED event emission** now enabled for Telegram inbound messages (unblocks trigger automation):
  - https://github.com/elizaOS/eliza/pull/7122
- Dependency bumps for Telegram clients also landed in app surfaces (keeps parity with upstream library changes):
  - e.g. renovate PRs like https://github.com/elizaOS/eliza/pull/7069 (telegram to `v2.26.22`) (where applicable)

### Discord
No single “plugin-discord” PR dominated this week’s merged list in the provided dataset, but Discord integration work showed up indirectly via:
- Trigger event-kind plumbing (Discord `MESSAGE_RECEIVED` is a primary target of `TriggerEventBridge`): https://github.com/elizaOS/eliza/pull/7116
- LifeOps routing fixes impacting cross-channel dispatch behavior (Discord channel routing surfaced in LifeOps fixes earlier in the week):
  - https://github.com/elizaOS/eliza/pull/6971 (LifeOps discord routing fix)

### Farcaster
No Farcaster-specific plugin changes were captured in the aggregated PR list for this week.

---

## 6) Model Provider Updates (OpenAI / Anthropic / DeepSeek / local)

### Anthropic: default model ID corrected (Haiku)
A malformed default Haiku model ID caused 404s on Anthropic requests. This is now corrected in provider switch config + plugin-anthropic config.

- PR: **fix: correct malformed Anthropic Haiku model ID** — https://github.com/elizaOS/eliza/pull/7078  

### Auth UX: distinguish Claude Code CLI credentials vs in-app OAuth
When Claude Code CLI was authenticated on a machine, the in-app subscription panel incorrectly showed “Connected” for in-app OAuth. The UI/runtime now distinguishes these credential sources.

- PR: **fix(auth): distinguish Claude Code CLI credentials from in-app OAuth** — https://github.com/elizaOS/eliza/pull/7094  

### Local / non-Claude structured output reliability
The new `PROMPT_OUTPUT_FORMAT` override (above) is the main lever added this week to improve structured output behavior across Gemini/local Llama/Ollama-style providers.

---

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

> **Read carefully if you maintain plugins or self-hosted deployments.** Several changes this week affect runtime composition, triggers, and streaming signatures.

### Trigger semantics changed for automations
If you previously relied on UI-driven polling or bespoke glue to “kick” triggers, event-kind triggers now have a canonical runtime path (via `TriggerEventBridge`). This is generally a win, but it can reveal latent misconfigurations:
- Triggers that registered but never fired may suddenly fire (after Telegram emission fix) once event routing is corrected.
- Action routing on page scopes was tightened (Automations vs LifeOps) to avoid collisions:
  - https://github.com/elizaOS/eliza/pull/7123
  - https://github.com/elizaOS/eliza/pull/7124

**Migration tip:** ensure your triggers specify the intended channel/page scope and don’t rely on ambiguous “simile” overlap with high-level LIFE actions.

### Streaming type consolidation may break custom integrations
If your code imports/duplicates any of the old `onStreamChunk` type shapes, update to the canonical `StreamChunkCallback` and rerun tests:
- https://github.com/elizaOS/eliza/pull/6690

### Work-in-progress release automation / v2 pipeline
The **V2.0.0 release** PR remains a major ongoing effort and may introduce additional workflow/release automation changes when finalized:
- PR: https://github.com/elizaOS/eliza/pull/6530

---

## Appendix: Open items & dev notes from Discord

- **HTN planning in v2**: devs discussed an HTN-lite → full HTN upgrade path (LLM-based decomposition while keeping triggers/steps stable). If you’re building planners, expect future docs/implementation clarification requests.
  - Discord (2026-04-25) summary: HTN vs HTM clarification; upgrade path discussion
- **Milady Play Store link broken**: community reported a non-functional Play Store link referenced from GitHub (returns “item not available”). Track and fix in docs/README where referenced.
- **Pending review / integration queue** (from engineering summary):
  - Multi-chain agent-to-agent payments integration (7 chains) — pending review
  - Monetization: debit organizational credit balances — pending review
  - Rebuilt auth consent flow — pending review
  - Integration of 29 commits from `shaw/checkpoint-20260426-eliza` — tracked as an open integration issue (see internal tracker mentioned in daily summary)