Council Briefing

Key Deliberations

Developer Onboarding Reliability (Inference Plugin + Updates)

A coder encountered TEXT_LARGE errors even on minimal prompts, traced to missing inference plugin registration; subsequent plugin installation issues were attributed to outdated packages, reinforcing that default paths must be resilient and self-healing.

Should the runtime fail fast with an explicit “No inference provider registered” diagnostic (and guided fix), rather than surfacing generic runtime errors like TEXT_LARGE?

coders (2025-12-13): Thirtieth: "TEXT_LARGE error even when I just write 'hi'"
coders (2025-12-13): sayonara: "OpenAI or any other ai plugin is not registered it seems"

1Yes—introduce a dedicated boot-time validation that blocks start until an inference plugin is configured.

Reduces support load and preserves trust by making misconfiguration unmissable, at the cost of stricter startup behavior.

2Partially—allow startup but degrade to a “configuration required” interactive wizard in CLI/UI.

Maintains a smoother first run while still guiding remediation, but requires UX work and careful edge-case handling.

3No—keep current behavior and rely on docs/support for configuration troubleshooting.

Minimizes engineering changes now, but increases churn risk and undermines “reliability over features.”

4Other / More discussion needed / None of the above.

Do we standardize on an “elizaos update” prerequisite check (and auto-run prompt) before any plugin install to prevent version drift failures?

coders (2025-12-13): sayonara: "Likely due to outdated packages; recommended running 'elizaos update'"

1Yes—make plugin install invoke a version compatibility preflight and offer automatic update.

Improves success rate and aligns with Execution Excellence, but increases CLI complexity and requires robust rollback semantics.

2Only for known-problem plugins (e.g., inference + db) and only when incompatibility is detected.

Targets highest-impact failures while limiting CLI changes, but may miss new classes of drift issues.

3No—keep updates manual and document “update first” as a best practice.

Fastest in the short term, but repeats the same onboarding failure pattern and erodes DX.

4Other / More discussion needed / None of the above.

Should we publish a single canonical “Minimum Viable Agent” recipe that enforces the required plugin set (db + inference) and prevents ambiguous partial setups?

coders (2025-12-13): Root cause identified as missing AI plugin integration (OpenAI).

1Yes—ship an opinionated starter template that always includes db + inference, with toggles for providers.

Raises first-run success and ecosystem consistency, but reduces perceived flexibility for advanced builders.

2Provide two official paths: “quickstart opinionated” and “bare-metal advanced,” clearly separated.

Balances DX and flexibility, but requires sustained documentation and template maintenance.

3No—keep templates minimal and let plugins remain fully a la carte.

Maximizes composability, but makes early-stage failures more frequent and costly to support.

4Other / More discussion needed / None of the above.

ElizaOS Cloud Launch Readiness (CLI Defaults + Key Management)

Cloud is being positioned as the default AI provider in the CLI and a large Cloud integration PR is in flight; community questions indicate confusion about whether provider keys must be wired into Cloud, signaling a need for a crisp identity/key story before launch.

Do we make ElizaOS Cloud the default inference/storage path for new projects (with automatic login + key provisioning), even if it reduces early emphasis on self-hosting?

PR #6208 (completedItems): "feat: Add ElizaOS Cloud as Default AI Provider in CLI"
PR #6216 (topPRs): "CLI should auto log them in, provision API key and make sure project is set up"

1Yes—Cloud-first by default; self-hosting remains an explicit alternative path.

Maximizes onboarding reliability and aligns with “seamless UX,” but risks alienating builders who expect local-first defaults.

2Dual-default—prompt users with a strong recommendation for Cloud but keep local-first as equal choice.

Preserves open-source posture while nudging toward reliability, but may dilute conversion and increase decision fatigue.

3No—keep local-first as default until Cloud has a proven stability and billing track record.

Conservative on trust, but slows Cloud adoption and keeps support burden on heterogeneous local environments.

4Other / More discussion needed / None of the above.

What is the canonical key-management model we want developers to understand: bring-your-own-provider keys, Cloud-managed keys, or both with clear boundaries?

coders (2025-12-13): Thirtieth: "Do I need to connect that [OpenAI API key] to elizacloud?"

1Cloud-managed keys only (developers authenticate to Cloud; Cloud handles provider credentials).

Simplifies setup and reduces secret leakage risk, but requires strong trust, compliance posture, and transparent billing.

2Bring-your-own keys only (Cloud stores encrypted user-supplied secrets; we never provide provider credits).

Aligns with decentralization and control, but keeps onboarding complexity and raises support load for provider-specific issues.

3Hybrid—Cloud-managed default with optional BYO for advanced users and enterprise constraints.

Best coverage and flexibility, but demands exceptional documentation to avoid confusion and misconfiguration.

4Other / More discussion needed / None of the above.

Given the scale of Cloud integration changes, do we gate Cloud launch on a dedicated reliability review (tests, rollback plan, docs) rather than merging incrementally?

PR #6216 (topPRs): ~9,989 additions; "may still need some work" and requests thorough review of create→deploy→publish→monetize flow.

1Gate with a formal launch checklist (E2E tests, failure modes, incident runbook, docs), then merge/ship.

Protects trust through shipping discipline, but may delay launch and frustrate momentum.

2Merge behind feature flags and run a limited beta cohort while hardening.

Balances speed and safety, but increases operational complexity and requires flag governance.

3Merge and iterate in production quickly with rapid patch cadence.

Fastest path to shipping, but risks high-visibility instability at the moment we are explicitly prioritizing reliability.

4Other / More discussion needed / None of the above.

Token Migration Trust & Exchange Friction (Bithumb / Transparency)

Migration remains a reputational risk vector, with Korean users reporting blocking issues on Bithumb and community speculation about burn/sell mechanics; transparency steps exist but require clearer, proactive communications to protect developer and market confidence.

Do we escalate the Bithumb migration incident into a time-boxed “war-room” with a public status page and daily updates until resolved?

Discord (2025-12-11): "Korean users are experiencing significant problems with the ELIZA token migration on Bithumb exchange"
Discord (2025-12-11): jasyn_bjorn/Odilitime: "waiting on Bithumb"

1Yes—activate a war-room, publish a status page, and commit to daily public updates.

Maximizes trust and reduces rumor spread, but creates a high-expectation communication burden.

2Partial—internal war-room plus periodic updates only when milestones change.

Reduces noise while still showing ownership, but may be perceived as opacity during user pain.

3No—keep support-ticket based handling and wait for the exchange to resolve.

Lowest operational overhead, but highest reputational risk and lowest perceived accountability.

4Other / More discussion needed / None of the above.

How should we address recurring suspicion about supply handling (burn vs sell) in a way that is verifiable and non-technical users can understand?

Discord (2025-12-11): "Some users questioned whether migrated AI16Z tokens were sold instead of burned"
Discord (2025-12-11): "Team shared the migrator wallet link to demonstrate transparency"

1Publish a concise “Proof of Migration” explainer with on-chain links, diagrams, and a third-party verification note.

Converts uncertainty into auditable truth, strengthening trust beyond core community members.

2Host a live council briefing/AMA focused on migration mechanics and questions, then pin the recording and transcript.

Humanizes transparency and defuses tension, but must be carefully moderated to avoid amplifying misinformation.

3Rely on ad-hoc replies and wallet links in chat/support channels.

Lowest effort, but rumors persist and create ongoing drag on ecosystem credibility.

4Other / More discussion needed / None of the above.

Should we prioritize anti-scam and verification UX in migration support (official channels, signatures, checklists) as part of “execution excellence,” even if it slows support throughput?

Discord (2025-12-11): Hexx 🌐 warned a user about scammers and advised blocking/reporting.
Discord (2025-12-11 Action Items): "Improve verification process for migration support to prevent scams"

1Yes—introduce strict verification steps and official cryptographic proofs for support personnel/messages.

Hardens trust and user safety, reinforcing long-term credibility at the cost of additional process overhead.

2Moderate—pin official guidance + automate warnings, but keep human support lightweight.

Improves baseline safety quickly, though sophisticated scams may still succeed at the margins.

3No—treat scams as a community moderation issue, not a product/process priority.

Avoids process friction, but exposes users to preventable losses that will be blamed on the ecosystem.

4Other / More discussion needed / None of the above.

North Star & Strategic Context

Key Deliberations