# ElizaOS Developer Update (2025-12-18 → 2025-12-24)

This update covers core runtime and messaging work landing in `elizaos/eliza`, plus operational updates from Discord related to Eliza Cloud beta readiness and plugin consistency work.

---

## 1) Core Framework

### Typed custom events in the agent runtime (core)
Core runtime now supports **generic typing for custom event payloads**, making plugin-defined events type-safe end-to-end. This is primarily a DX + correctness improvement: event emitters and handlers can agree on payload shape without casting.

- PR: **fix(core): add generic type support for custom event handlers** — https://github.com/elizaOS/eliza/pull/6277 (merged)
- Duplicate PR (not needed): https://github.com/elizaOS/eliza/pull/6276

**Why it matters**
- Plugins that extend the runtime event bus no longer need `any` payloads.
- Reduces runtime schema drift between emitters and listeners.
- Improves inference-time tooling and refactor safety in large plugin stacks.

**Example (plugin-side custom event typing)**
```ts
import type { EventPayload } from "@elizaos/core";
import { AgentRuntime } from "@elizaos/core";

interface ToolTelemetryPayload extends EventPayload {
  tool: string;
  durationMs: number;
  ok: boolean;
  error?: string;
}

export function registerTelemetry(runtime: AgentRuntime) {
  runtime.registerEvent<ToolTelemetryPayload>("tool.telemetry", async (payload) => {
    if (!payload.ok) {
      runtime.logger.warn({ tool: payload.tool, error: payload.error }, "tool failed");
    }
  });
}
```

### Cloud build-mode streaming stabilization (ops/runtime integration)
Core dev discussion confirms a fix for **streaming issues in “cloud build mode”** landed/was completed operationally this week (implementation details not posted publicly in the provided logs). The key impact is improved reliability when streaming tokens/events while running in the Cloud build/deploy flow.

- Discord (core-devs): https://discord.com/channels/1253563208833433701/1377726087789940836

---

## 2) New Features

### Async-first message service handlers optimized for cloud execution
A new PR proposes improving message service handlers to perform asynchronous operations and to better support cloud environments (e.g., avoiding blocking flows, enabling awaited pipelines). This aligns with the ongoing initiative to standardize message handling across plugins.

- PR: **Improved message service handlers for async operations + cloud optimization** — https://github.com/elizaOS/eliza/pull/6279 (status: open at time of reporting)

**What to expect (conceptually)**
- Cleaner async boundaries for message ingestion and downstream processing.
- Better compatibility with serverless/cloud runtimes where long synchronous work can cause timeouts or degraded throughput.

**Suggested developer action**
- If you author custom message adapters/plugins, audit for any synchronous heavy work inside handlers and move to awaited async steps (db writes, network calls, tool invocations).

---

## 3) Bug Fixes

### Core: event handler typing bug fix (merged)
Prior to PR #6277, custom event registration could force plugins into `any` payloads or unsafe casts, causing subtle runtime bugs (mismatched payload keys, missing properties) that were not caught by TypeScript.

- Fix: https://github.com/elizaOS/eliza/pull/6277

### Discord plugin fixes (implementation mentioned; PR not provided in dataset)
Core devs report “Discord plugin fixes” completed this week. While no specific PR is referenced in the provided activity list, this work is part of the broader push to standardize cross-plugin message handling.

- Discord (core-devs): https://discord.com/channels/1253563208833433701/1377726087789940836

---

## 4) API Changes

### `registerEvent` now accepts a generic payload type
**Change:** `registerEvent` supports a type parameter for the handler payload, as long as it extends `EventPayload`.

- PR: https://github.com/elizaOS/eliza/pull/6277

**Migration impact**
- Existing calls continue to work.
- Plugins can incrementally adopt generics to remove casts.

---

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

### Discord
- Plugin fixes shipped (see above), plus ongoing refactors to standardize message routing across plugins (“Standardize `Elizaos.handleMessage` across plugins” is explicitly called out as a pending PR to push).

  - Discord (core-devs): https://discord.com/channels/1253563208833433701/1377726087789940836

### Twitter (X) operational guidance
Community/dev discussion reiterates X API constraints and a known-good path:
- `plugin-twitter` is confirmed working for at least one developer using a **$200/mo** X plan by cloning the **1.x branch**.

  - Discord (Dec 21 context): https://discord.com/channels/1253563208833433701/1301363808421543988

**Action for developers**
- If you rely on Twitter posting/reading, pin to a known-compatible plugin-twitter branch and plan for rate-limit/backoff logic due to frequent API policy shifts.

### Telegram / Farcaster
No new merges in this 7-day window were provided for Telegram/Farcaster, but the broader ecosystem work continues around unified messaging APIs and decentralization (see prior registry + plugin refactors referenced in project summaries).

---

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

### Eliza Cloud: beta now live (platform/provider implications)
Eliza Cloud entered **beta** with ecosystem builders being onboarded for production feedback. While Cloud is a product/platform, it directly affects model/provider workflows because it is being positioned as the default “build/deploy/manage agents” surface, including agent registration ahead of the 8004 mainnet/registry push.

- Discord (partners announcement): https://discord.com/channels/1253563208833433701/1301363808421543988

**Developer relevance**
- Expect tighter integration between CLI/project starters and Cloud-backed providers (compute, storage, DB, registration).
- Streaming fixes in cloud build mode unblock token streaming UX for Cloud-hosted agents.

---

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

### Messaging API standardization is still in-flight (watch for breakage)
Core devs explicitly called out a pending PR to **standardize `Elizaos.handleMessage` across plugins**. Based on earlier migration patterns in the repo (moving from event-based message ingestion to `messageService.handleMessage()`), expect more plugins to converge on a single pathway.

- Discord (core-devs): https://discord.com/channels/1253563208833433701/1377726087789940836

**What may break during V1 → V2 style migrations**
- Plugins listening to legacy message events (e.g., older `MESSAGE_RECEIVED` style flows) may stop receiving messages once adapters switch to `messageService.handleMessage()`.
- Custom adapters that assume older message shape fields may need updating as message routing standardizes.

**Recommended mitigation**
- If you maintain a plugin:
  1. Ensure your entrypoint funnels inbound content through the message service.
  2. Add integration tests for at least one end-to-end message path (transport → runtime → action/tool → response).

---

## Relevant Issues & Product Work (FYI)

- Feedback button proposal: https://github.com/elizaOS/eliza/issues/6280  
- Chat renaming: https://github.com/elizaOS/eliza/issues/6278  
- Streaming + state management tracking: https://github.com/elizaOS/eliza/issues/5930  
- Brandkit update request: https://github.com/elizaOS/eliza/issues/6091  

---

## Notes from Developer Discord (Implementation Signals)

- Eliza Cloud beta: onboarding builders now; wider January ramp planned (launch event/PR/influencers).  
- 8004 mainnet target: mid-January (agent registration push before EthDenver).  
- Internal focus: message handling standardization across plugins; analytics for “memories” table in progress; “plugin-wrapped” functionality and image generation for social prep in progress.

Primary threads:
- Partners: https://discord.com/channels/1253563208833433701/1301363808421543988  
- Core devs: https://discord.com/channels/1253563208833433701/1377726087789940836