# ElizaOS Developer Update (2025-12-28 → 2025-12-31)

## 1) Core Framework

### Unified hooks (multi-transport) — in review
Work continued on a *unified hooks* layer that can deliver agent/runtime events over multiple transports: **HTTP**, **SSE**, and **WebSocket**. This is intended to remove duplicated “hook” implementations and standardize event delivery semantics across transports (ordering, de-dupe, replay behavior).

- PR: **Unified hooks with multi-transport support (HTTP/SSE/WebSocket)** — [elizaOS/eliza#6300](https://github.com/elizaOS/eliza/pull/6300) *(open)*  
- Discord context: core-devs notes indicate a fix for **duplicate events** emitted by server package transports on the message bus.

**Developer impact**
- If you are building custom dashboards, webhook consumers, or embedded UIs, expect an eventual consolidation around a single hooks surface (with transport selection as configuration rather than separate implementations).
- Pay attention to event idempotency on the client side; even after upstream de-dupe, consumers should treat hook payloads as *at-least-once* delivery.

### Streaming runtime observability (DB logging)
A critical runtime bug was fixed where **streaming LLM calls were not being logged** due to logging code being unreachable in the streaming path.

- PR (merged): **Log streaming LLM calls to database** — [elizaOS/eliza#6296](https://github.com/elizaOS/eliza/pull/6296)

This restores parity between non-streaming and streaming inference calls in:
- model call logs / action viewers in the client
- downstream analytics (costing, tracing, evaluation)

---

## 2) New Features

### Hooks: single subscription interface (HTTP/SSE/WS) *(in review)*
While [#6300](https://github.com/elizaOS/eliza/pull/6300) is still under review, you can start planning for a unified consumer pattern where transport is selected by environment constraints:

- **SSE** for browser-friendly streaming without WS infrastructure
- **WebSocket** for bi-directional control + lower overhead for high-frequency updates
- **HTTP** for simple webhook-style fanout / polling-compatible environments

**Example: SSE consumer sketch**
```ts
// Pseudocode: final endpoint/event shape may change while #6300 is in review.
const source = new EventSource(`${ELIZA_SERVER_URL}/api/hooks/sse?agentId=${agentId}`);

source.addEventListener("message", (evt) => {
  const payload = JSON.parse((evt as MessageEvent).data);
  // payload should be treated as at-least-once
  handleHookEvent(payload);
});

source.addEventListener("error", (err) => {
  console.error("SSE hook error", err);
});
```

### ElizaCloud: embedding an agent into your website (API-based)
Discord discussions clarified the basic flow for integrating an ElizaCloud agent into a website:
1) Use your API key to query the ElizaCloud API for your agents
2) Extract the **agentId**
3) Use that agentId to route chat/messages from your site

**Example: fetch agent list → pick agentId**
```bash
curl -sS "https://api.elizacloud.example/v1/agents" \
  -H "Authorization: Bearer $ELIZACLOUD_API_KEY"
```

```ts
// Pseudocode: exact endpoint/shape may differ depending on your ElizaCloud environment.
type Agent = { id: string; name: string };

async function getAgentIdByName(name: string): Promise<string> {
  const res = await fetch(`${process.env.ELIZACLOUD_API}/v1/agents`, {
    headers: { Authorization: `Bearer ${process.env.ELIZACLOUD_API_KEY}` },
  });
  const agents: Agent[] = await res.json();
  const agent = agents.find(a => a.name === name);
  if (!agent) throw new Error(`Agent not found: ${name}`);
  return agent.id;
}
```

Community reference implementations:
- Skills repo (community): https://github.com/Merlinthewizord/Skills_elizaos
- OpenSouls integration plugin (community): https://github.com/Merlinthewizord/plugin-opensouls

---

## 3) Bug Fixes (critical)

### Streaming LLM calls missing from DB logs (fixed)
**Symptom**
- When `stream: true` (or equivalent streaming pathway) was used, model calls (e.g., `TEXT_SMALL`, `TEXT_LARGE`) would not appear in the Model Calls / action viewer logs.

**Root cause**
- The streaming control flow returned early, leaving logging code **after the return** and therefore unreachable.

**Fix**
- Logging moved into the streaming path so calls are persisted consistently.

**PR**
- [elizaOS/eliza#6296](https://github.com/elizaOS/eliza/pull/6296)

**What to validate in your deployments**
- If you rely on DB logs for cost tracking or audit trails, rerun a streaming session and verify records are created as expected.
- Client surfaces that display action/model call history should now show streaming calls again (also touched by #6296).

### Minor: typo correction
- PR: [elizaOS/eliza#6297](https://github.com/elizaOS/eliza/pull/6297) *(“saftey” → “safety”)*

---

## 4) API Changes (developer-facing)

### Hooks API consolidation *(pending merge)*
- [#6300](https://github.com/elizaOS/eliza/pull/6300) introduces (or prepares) a **new unified hooks API** with transport variants.
- Until merged and documented, treat this as **experimental** and avoid hard-coding endpoint paths without pinning versions.

### Logging/telemetry behavior for streaming
- With [#6296](https://github.com/elizaOS/eliza/pull/6296) merged, developers should expect:
  - **New DB log entries** for streaming sessions that were previously absent
  - More complete action/model call audit trails during streaming runs

### Notable open issues (UI behavior)
Two new issues were filed and are relevant if you embed/extend the dashboard UI:
- Agent card resizing mismatch: [elizaOS/eliza#6291](https://github.com/elizaOS/eliza/issues/6291)
- “Unslop Apps”: [elizaOS/eliza#6299](https://github.com/elizaOS/eliza/issues/6299)

---

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

### Twitter / X
- Discord confirmed there is **no cookie-based authentication** option in the Twitter plugin anymore (developers must use supported auth paths; this also reduces risk from brittle session scraping).
- Ongoing developer concern: **Twitter API pricing** (reported ~$200/month barrier) is driving exploration of alternative deployment targets/platforms.

Community discussion surfaced “Sentient Space” as a possible alternative social surface for agents (not an official integration yet).

### Discord
- A Discord plugin PR was submitted with logging enhancements:
  - PR (plugin-discord): **logging enhancements** — referenced as PR #36 in Discord discussions *(link not provided in the dataset)*  
- Suggested improvement: log using **character name** with a fallback to **agentId** for stability in multi-agent environments.

### Farcaster
No new Farcaster plugin PRs were recorded in the provided week’s core activity, but Farcaster remains a strategic target for self-hosted/social-first agents (see earlier registry work referenced in monthly notes).

---

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

### OpenAI plugin: image generation fix + caching *(external PR referenced)*
Work landed (or is landing) in the OpenAI plugin to:
- fix **image generation**
- add **caching** to prevent redundant media processing (avoid re-transforming or re-uploading identical media)

- Referenced PR: **plugin-openai#23** *(mentioned in Discord; link not provided in dataset)*

**Why this matters**
- Media-heavy agents (social posting, creative tools) can incur repeated compute + storage costs if identical assets are reprocessed.
- Caching at the plugin boundary reduces both latency and cost, and makes runs more deterministic.

### Core + providers: streaming observability restored
Even if provider plugins were already streaming, [#6296](https://github.com/elizaOS/eliza/pull/6296) ensures the **core runtime** logs streaming model calls properly, which is essential for:
- provider cost attribution
- evaluation pipelines
- debugging prompt/tool regressions

---

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

### Eventing & message handling: avoid legacy patterns
If your plugins/agents still rely on legacy event patterns (e.g., older “message received” style event wiring), be aware the platform direction continues toward **service-based message handling** (e.g., `messageService.handleMessage(...)`) and standardized streaming + logging.

**Action for plugin authors**
- Prefer the message service APIs and typed event registration patterns over ad-hoc bus events.
- Design hook consumers to tolerate at-least-once delivery and occasional replay.

### Hooks unification may change integration points *(once #6300 lands)*
If you maintain custom hook endpoints or consumers:
- expect endpoint consolidation and possible payload normalization once [#6300](https://github.com/elizaOS/eliza/pull/6300) merges
- plan to pin versions if you ship production dashboards that consume runtime events

### Plugin versioning friction (ecosystem maintenance)
Core-devs noted plugin authors are manually bumping versions per PR and would benefit from automated release tooling (e.g., “release-please” style CI). Until that exists:
- pin plugin versions explicitly in production
- avoid floating ranges for fast-changing plugins (social/media plugins especially)

---

### References / Links
- Unified hooks (HTTP/SSE/WS): https://github.com/elizaOS/eliza/pull/6300  
- Fix: log streaming LLM calls to DB: https://github.com/elizaOS/eliza/pull/6296  
- Typo fix: https://github.com/elizaOS/eliza/pull/6297  
- Issue: agent cards resizing: https://github.com/elizaOS/eliza/issues/6291  
- Issue: “Unslop Apps”: https://github.com/elizaOS/eliza/issues/6299  
- Tokenomics docs (site reference mentioned in Discord): https://docs.elizaos.ai/tokenomics  
- Community skills repo: https://github.com/Merlinthewizord/Skills_elizaos  
- Community OpenSouls plugin: https://github.com/Merlinthewizord/plugin-opensouls