# ElizaOS Weekly Newsletter — Dec 21, 2025 to Dec 27, 2025 ## 1) Executive Summary This week was about **making ElizaOS Cloud feel real in day-to-day use** while laying groundwork for the next stage of decentralization. - **ElizaOS Cloud usability & responsiveness improved**: The team continued pushing UX refinements in the agent builder and expanded real-time behavior across the stack (notably **true SSE** and broader **streaming support**), making chats and updates feel more immediate rather than “poll-y” or delayed. - **Core framework sturdiness and developer ergonomics advanced**: Type-safety upgrades (including **generic typing for custom event handlers**) and plugin modernization work reduced “mystery failures” and gave plugin authors cleaner extension points. - **A new infrastructure narrative emerged: “Jeju”**: In core-dev discussions, Shaw outlined **Jeju**, an ambitious distributed cloud platform with **TEE-based security**, proof-of-cloud concepts, and a distributed KMS approach—positioning “Eliza Cloud” as something that can ultimately run on credibly decentralized rails. ## 2) Development Updates (Key Technical Changes) ### Core platform: real-time + extensibility - **True Server-Sent Events (SSE)** landed as a major step toward consistent real-time updates, replacing less efficient approaches. This aligns with the broader push to make agent interactions and platform state updates feel instantaneous. - Reference: elizaos/eliza issue **#5930** (SSE upgrade) - **Typed plugin extensibility improved** via generic type support for custom event handlers—small on the surface, but huge for plugin authors maintaining complex payload contracts. - Reference: elizaos/eliza PR **#6277** (generic types for `registerEvent`) ### Streaming: moving from “works” to “feels good” - Streaming has been a consistent theme across December, and this week included ongoing integration and UX notes: - Community devs noted streaming was added to a component, but **multi-step UI rendering** still lags behind the “otaku” experience. Stan committed to reviewing and improving the client chat UI behavior for multi-step interactions. - Previously shipped streaming groundwork is reflected in December work such as “enhance streaming support in text generation” (elizaos/eliza PR **#6212**) and the OpenAI plugin streaming work (elizaos-plugins/plugin-openai PR **#21**, noted as awaiting broader integration earlier in the week). ### Bug reports from the field (Cloud + CLI) A few issues surfaced directly from builders using Eliza Cloud: - **Agent naming edge cases**: Creating agents named `"null"` or purely numeric names (`"1"`, `"69"`, `"666"`) caused failures ranging from “doesn’t save” to client-side exceptions. Interestingly, an agent named `"$"` worked normally—suggesting validation and serialization edge cases rather than a blanket “special char” restriction. - Action: tighten validation + ensure UI and API agree on constraints. - **Deployment friction (ECR credentials / repo not found)**: Reports indicate failures during `elizaos deploy` related to ECR repository/credentials assumptions. This is a classic “works internally, fails externally” papercut and a good candidate for clearer preflight checks + docs. - **File upload optimization continues**: Multi-file uploads were discussed as “should work,” but optimization is still in progress—expect incremental improvements to agent asset handling. ## 3) Community Spotlight (Discord Highlights) ### Builders helping builders - **Migration support**: Odilitime repeatedly helped community members understand migration errors (especially the confusing **“max amount reached”** message) and redirected users to the correct support channel when needed. - **Troubleshooting culture**: DorianD’s agent-name bug report is exactly the kind of field feedback that hardens the platform—repro steps, comparisons (`"null"` vs numeric vs `"$"`), and clear error outcomes. ### “Show your work” momentum - **Zoria “bonded”** and was called out as an **Eliza Cloud project**, triggering a broader discussion: projects should explicitly identify themselves as built on **“elizaos cloud”** to improve discoverability and distribution inside the community. - Several members pushed for a more formal structure (e.g., a dedicated sub-channel) to make Eliza Cloud projects easier to find and support. ### API endpoint discoverability - A simple but recurring theme: builders want the **Eliza Cloud API endpoints** easier to locate. The answer (“they’re on the site”) is fine—**but a doc link and pinned message** would reduce repeated questions and help new devs ramp faster. ## 4) Token Economics (AI16Z → ElizaOS, and auto.fun) ### Migration reality: snapshot-based, strict eligibility This week’s clearest token update was clarification (and frustration) around migration rules: - **Only tokens held at the snapshot are eligible**, and **post-snapshot purchases are not migrated** (policy). - The migrator error **“max amount reached”** was clarified to mean: *the wallet is not in the snapshot set*. This helps explain why some users see “0 eligible” even when they currently hold tokens—eligibility is historical, not current-balance-based. ### Token utility narrative (what’s public vs what’s not) - Community members pressed for clarity on whether **ElizaOS will be the native token** of the upcoming Jeju system. The response from the team was effectively: **plans exist, but aren’t being shared externally yet**. - Publicly stated utility points that surfaced in discussion this week: - Migration away from **token2022** was partly driven by exchange support constraints. - **Cross-chain requirements** (e.g., Chainlink CCIP) can require tokens to remain **mintable** for bridging mechanics. - A frequently repeated high-level model: **cloud revenues → buybacks** (discussed as the current framing). ### auto.fun No concrete, week-specific auto.fun releases were captured in the provided logs. What did show up strongly is the *demand signal*: the community wants clearer explanations of token utility, distribution mechanics, and how “cloud + Jeju + token” link together. If auto.fun is part of that story, the community is ready for a more explicit update. ## 5) Coming Soon (What to Watch) - **Jeju platform progression**: Expect more technical details to emerge—especially around TEE operations, proof-of-cloud, key sharding, and how “Eliza Cloud” services map onto Jeju primitives. - **Distributed SQLite effort**: Shaw’s distributed SQLite project needs a name (“sqlit”, “sqliite”, “ShawQLite”, “sq-lit”)—but more importantly, it hints at a future where agent state can live on resilient, distributed storage. - **Client chat UX for streaming multi-step interactions**: Work is queued to improve the UI presentation to match best-in-class internal examples (“otaku”). - **Validation + reliability fixes**: Agent naming constraints, deploy preflight checks, and login/app errors reported by users are all ripe for fast iteration. - **Docs and comms upgrades**: Migration eligibility, API endpoint links, and token utility documentation are high-leverage improvements the community explicitly requested. ## 6) Resources (Links & Pointers) **Core / Framework** - True SSE upgrade: https://github.com/elizaos/eliza/issues/5930 - Generic types for custom event handlers: https://github.com/elizaos/eliza/pull/6277 - December streaming expansion (reference from monthly activity): https://github.com/elizaos/eliza/pull/6212 **Plugins** - OpenAI plugin streaming PR (referenced as awaiting integration earlier in the week): https://github.com/elizaos-plugins/plugin-openai/pull/21 **Community discussion topics to revisit** - Token migration eligibility + “max amount reached” meaning (Discord 🥇-partners) - Agent naming crash cases and deployment friction (Discord 💬-coders) - Jeju architecture + distributed SQLite naming thread (Discord core-devs) --- If you shipped something on Eliza Cloud this week, consider posting it with a clear “Built on ElizaOS Cloud” tag—discoverability is becoming a growth lever, and the community is actively asking for more projects to surface.