# ElizaOS Developer Update (2025-12-15 → 2025-12-21)

## 1) Core Framework

### Messaging API standardization across core + plugins
Ongoing work continues to align all inbound/outbound message handling through the **MessageService** pipeline (vs legacy event-driven hooks). This is already reflected in core and is now being propagated into social plugins:

- Telegram unified messaging refactor: https://github.com/elizaos-plugins/plugin-telegram/pull/22  
- Discord internal message handling refactor: https://github.com/elizaos-plugins/plugin-discord/pull/32  

This aligns with the broader “Unified API” direction in core (serverless/node targets were introduced earlier this month):  
- Core Unified API PR: https://github.com/elizaos/eliza/pull/6201  
- Weekly summary context (Dec 14–20): `plugin-telegram` + `plugin-discord` refactors called out explicitly: https://github.com/elizaos/eliza (see weekly summary: `2025-12-14.md` in the provided data)

### Provider execution performance work (in review)
In `#core-devs` Discord, a performance-oriented change was discussed: **parallel provider execution with a configurable timeout** (default suggested ~1s) to prevent slow providers from stalling the pipeline, with warnings for caching opportunities.

- PR under discussion: https://github.com/elizaos/eliza/pull/6263  
- Related discussion: elizaOS Discord (`#core-devs`, 2025-12-18)

**Implementation intent (as described in discussion):**
- Run providers in parallel
- Abort/short-circuit if provider stage exceeds timeout
- Emit diagnostic logs like: “Provider X took 2500ms — consider caching”

### Package versioning policy reaffirmed
Core maintainers reiterated that plugins should **pin `@elizaos/*` versions** rather than using `latest` to avoid mismatches during rapid iteration.

- Discord reference: elizaOS Discord (`#core-devs`, 2025-12-18)

Example (recommended):
```json
{
  "dependencies": {
    "@elizaos/core": "1.7.0",
    "@elizaos/plugin-sql": "1.7.0"
  }
}
```

## 2) New Features

### v1.7.0 shipped: streaming + npm release fixes
A new core release was announced in Discord:

- Release: https://github.com/elizaos/eliza/releases/tag/v1.7.0  
- Mentioned in `#core-devs` and `#coders` (2025-12-20)

While the Discord note is brief, v1.7.0 is positioned as the release that unlocks end-to-end **streaming** readiness (core/runtime + client/server wiring), plus **npm-related fixes** (token changes on npm were also mentioned as a release blocker in earlier discussions).

#### Example: enabling streaming for text generation
If your runtime/model layer supports streaming, the typical pattern is to request streaming and consume incremental deltas (exact method names vary by provider plugin, but the architectural expectation is consistent post-1.7.x):

```ts
import { AgentRuntime } from "@elizaos/core";

const runtime = new AgentRuntime({ character, plugins });
await runtime.initialize();

// Pseudocode: stream response chunks
const stream = await runtime.elizaos.generateText({
  prompt: "Summarize the last 20 messages.",
  stream: true
});

for await (const chunk of stream) {
  process.stdout.write(chunk.delta ?? chunk.text ?? "");
}
```

### Cloud MVP shipping (operational milestone)
In Discord, the team indicated they are preparing to ship the **Cloud MVP** “on Monday” (immediately following 2025-12-20). This matters for developers because Cloud is increasingly the default “happy path” for provisioning inference + storage.

- Mentioned by Borko in `#discussion` (2025-12-20)
- Related earlier CLI direction (Cloud as default provider): https://github.com/elizaos/eliza/pull/6208

### Knowledge/analytics endpoints (ecosystem tooling)
The community referenced a “knowledge repository” and new JSON endpoints for leaderboards/summaries (daily/weekly/monthly). This is adjacent to ElizaOS development but relevant if you’re building agents that reason over ecosystem activity.

- Mentioned in Discord (`2025-12-19`)
- If you’re integrating these endpoints, treat them as external data sources and cache aggressively (ties into provider-performance discussion).

## 3) Bug Fixes

### Conversation creation blocking when no summary exists
A bug was called out in Discord: chat creation could fail when a conversation “summary” record didn’t exist. This was described as fixed, reducing hard-fail conditions during room/session creation.

- Mentioned in Discord (`2025-12-19`)

**Practical impact:** if you maintain custom message servers or session initializers, ensure you handle the “no summary yet” state as a valid empty initial condition rather than an exception path.

### SQL plugin migration + safety improvements (recently merged, still highly relevant)
From the weekly summary (Dec 14–20), core stability was improved by making upgrades from older versions less error-prone:

- Smooth data migration for users upgrading from older versions: https://github.com/elizaos/eliza/pull/6215  

If you support long-lived installations (especially self-hosted Postgres/PGLite), validate migrations in staging and ensure `.eliza/` (or equivalent storage dirs) exist (some of this behavior was addressed in earlier fixes, but remains a common failure mode in user projects).

## 4) API Changes

### Migration away from legacy MESSAGE_RECEIVED toward MessageService
Even if you didn’t change code this week, plugin refactors strongly indicate the preferred integration surface is now:

- `messageService.handleMessage(...)` (new path)
- instead of subscribing to deprecated message events

If you have custom plugins, update now to avoid drift as Telegram/Discord converge on the same API shape.

Illustrative pattern:
```ts
// Old (legacy): runtime/events wiring (deprecated in newer examples)
runtime.on("MESSAGE_RECEIVED", handler);

// New: MessageService entrypoint
await runtime.messageService.handleMessage({
  // message payload normalized by your transport
  content: { text: incomingText },
  roomId,
  entityId,
  source: "discord"
});
```

### Message format changes (bootstrap/test utilities)
A fix referenced in the monthly completed items indicates message-format evolution (e.g., dropping `serverId` in favor of other identifiers) and exposes `initPromise` for plugin readiness synchronization.

- PR: https://github.com/elizaos/eliza/pull/6261  

If you maintain test harnesses or starter templates, rebase and ensure you’re not asserting on removed fields.

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

### Twitter (X)
Business-side update: a deal signed with X was confirmed in Discord. No implementation PRs were referenced in the provided activity, but expect follow-up changes in any Twitter/X plugin(s) and/or Cloud account provisioning flows.

- Mentioned by Borko (`#discussion`, 2025-12-20)

### Telegram
- Unified messaging API refactor in progress: https://github.com/elizaos-plugins/plugin-telegram/pull/22  
**Developer implication:** if you wrap Telegram updates into custom events, plan to translate them into the normalized MessageService payload instead.

### Discord
- Core message handling refactor in progress: https://github.com/elizaos-plugins/plugin-discord/pull/32  
- Additional Discord plugin work merged (tiered permission system for bot invite URLs) was referenced in contributor activity:
  - (As noted in the provided data feed) PR: `elizaos-plugins/plugin-discord#33` (link not included in the dataset text, but referenced as merged on 2025-12-19)

### Farcaster
A self-hosted Farcaster integration was added to the plugin registry, enabling users to connect to their **own hub** instead of relying on third-party APIs:

- Registry PR: https://github.com/elizaos-plugins/registry/pull/243  

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

### Streaming becoming the default expectation
This week’s major theme is operationalizing streaming (v1.7.0 release + Cloud streaming readiness). Provider plugins should:
- implement streaming where supported
- avoid synchronous “all-at-once” response assumptions in UI/clients
- cache provider outputs where feasible (ties to provider-timeout work)

### Model-agnostic stance reaffirmed
In Discord, the team reiterated agents will “likely be model agnostic,” consistent with supporting multiple providers behind a common runtime contract.

- Mentioned by Borko (`#discussion`, 2025-12-20)

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

### Cloud-V2 + monorepo release ordering (deployment discipline)
A specific coordination workflow was stated for shipping streaming on Cloud:

1) release monorepo (`elizaos/eliza`) first  
2) review/merge `elizacloud-plugin`  
3) update `cloud-v2` to the latest core version  

- Mentioned in Discord (`2025-12-19`, Stan ⚡)

If you operate downstream deployments, **do not** bump Cloud/plugin versions out of order; you may end up with mismatched streaming/message schemas.

### Plugin API drift: pin versions, don’t float `latest`
Because core + plugin APIs are moving quickly (messaging normalization, streaming context, provider behavior), using `latest` can silently introduce incompatible runtime expectations.

- Discord guidance: pin `@elizaos/*` versions (2025-12-18)

### Token migration support/security (non-code but critical operational risk)
Multiple scam warnings were raised in Discord, especially around token migration. While not a framework breaking change, it directly affects developer support workflows: avoid DM-based “support,” and always link to canonical repos/docs when guiding users.

- Discord (`#discussion`, 2025-12-20)
- Migration deadline reiterated in Discord (Feb 4, 2026): `2025-12-19` discussion

---