## User Feedback Analysis — 2026-02-12 (covering inputs observed through 2026-02-09 → 2026-02-11)

### Data sources referenced
- Discord: **💬-discussion**, **💬-coders**, **core-devs** (2026-02-09/10/11)
- GitHub (elizaos/eliza): open issues incl. **#6486** (URL triggers duplicate LLM calls), **#6490** (custom OpenAI-compatible endpoint), **#6447** (character/prompt iteration); plus recently closed items related to auth/events/docs

---

## 1) Pain Point Categorization (Top recurring 5–7)

> Frequency is approximated from ~**21 distinct** user-reported friction items/questions across Discord + GitHub in this slice. Severity reflects likelihood to block adoption or create trust risk.

### A. UX/UI (High frequency, High severity)
**Most common problems**
- **ElizaCloud billing/top-up is confusing and brittle**: VPN recharge failures + unclear “add USD” flow (reported via **5 non-coding testers** gathered by yojo; echoed in Discord discussion).
- **Account creation / welcome bonus bug**: “double account creation for one email” + duplicated $5 bonus behavior.
- **Roadmap discoverability**: users couldn’t find roadmap via “standard research” despite it existing on GitHub.

**Who it impacts most**
- Non-coders / evaluators (investors, prospective users) hitting friction in the first 5 minutes.

---

### B. Documentation (High frequency, Medium–High severity)
**Most common problems**
- **Unclear target audience & product intent** (coders vs non-coders; B2B vs B2C): repeated confusion around what ElizaCloud.ai “is for” and what a user should do next.
- **Irregular updates / where to look for truth**: recurring requests for weekly progress updates; users cite month-long gaps enabling social-media FUD.
- **Migration instructions & trust signals**: repeated questions about what’s official, what wallet/address is legitimate, and what to do if a window is missed.

**Who it impacts most**
- Newcomers, token holders, and anyone trying to evaluate seriousness/continuity.

---

### C. Technical Functionality (Medium frequency, High severity)
**Most common problems**
- **Agent crash on fresh install**: `skill.description.toLowerCase is not a function` in `agent_skill_instructions` provider (reported by azsxdc; confirmed “known bug”).
- **Group chat not working** (core-devs report by user “s”; no resolution posted).
- **Webapp doubles LLM calls when a URL is present** (GitHub **#6486**): processes message as both text + attachment preview → duplicated streaming output and ~2× token cost.
- “Normal vs ignorable errors” is unclear: users asked which logs to ignore (server ID/ownership vs pluginRegistry 401 WIP).

**Who it impacts most**
- Developers trying first-run deployments; anyone cost-sensitive on LLM usage.

---

### D. Integration (Medium frequency, Medium–High severity)
**Most common problems**
- **OpenAI provider lacks custom endpoint URL** (GitHub **#6490**) blocking OpenAI-compatible providers (e.g., SiliconFlow).
- **Cloud/agent access friction**: agents can’t easily self-provision or use ElizaCloud via CLI/API; users question value of endpoints like `llms.txt` if agent-access is still hard.
- Competitive comparisons to OpenClaw: desire for **WhatsApp/Telegram integration** + “4-minute wizard” onboarding style.

**Who it impacts most**
- Builders integrating into existing agent stacks (OpenClaw, external inference vendors, messaging platforms).

---

### E. Community / Trust & Safety (Medium frequency, High severity)
**Most common problems**
- **Migration-related scams**: multiple warnings about scam “support desk” Discords and scam DMs; users unsure which instructions are official.
- **Legitimacy concerns**: anxiety about using a wallet address for migration (confirmed legitimate by staff, but the fact it had to be asked indicates missing trust UX).
- Token utility / delisting confusion: recurring panic loops that require staff/community intervention.

**Who it impacts most**
- Token holders and newcomers; reputational risk for the project.

---

### F. Performance / Cost (Lower frequency, Medium severity)
**Most common problems**
- The URL duplication bug (**#6486**) is explicitly a **cost/perf regression** (2× calls).
- Users are also sensitive to “prompt bloat” and unnecessary work (context for why ActionFilterService matters, even if not explicitly requested here).

---

## 2) Usage Pattern Analysis (Actual vs intended)

### How users are actually using elizaOS / ElizaCloud
- **“Agents operating other agents” / cross-framework composition**: azsxdc is running **Eliza’s Twitter plugin inside OpenClaw** because it’s “higher quality” and safer for ban-risk—shows Eliza plugins are being treated as *best-in-class modules* even outside Eliza runtime.
- **ElizaCloud as an agent backend, not just a human dashboard**: DorianD’s repeated theme is “agents need easy CLI/API + auth + key issuance,” implying ElizaCloud should be *machine-first* in addition to human-first.
- **Non-coders evaluating as a product**: yojo’s 5-investor test shows a “prompt-only” expectation: sign up → add funds → run a useful agent quickly, without plugin hunting.
- **Token-holder lens overlays product feedback**: questions about migration windows, utility, delistings, and wallets heavily influence perception of dev progress.

### Emerging / unexpected use cases
- **Plugin portability as a growth vector**: Twitter plugin “wins” vs competitor implementation; suggests focusing on “exportable” integrations and compatibility layers.
- **Proof-of-agent / capability-gated access**: proposal to earn/receive access via coding tasks (agent proving itself) before receiving API credentials.

### Feature requests that align with observed usage
- **App-store-like plugin marketplace + guided plugin bundles** aligns with prompt-only evaluators and non-coders.
- **Agent-native auth + API key provisioning** aligns with machine-first ElizaCloud usage.
- **Custom OpenAI endpoint config** aligns with builders standardizing on OpenAI-compatible APIs across vendors.

---

## 3) Implementation Opportunities (2–3 concrete solutions per major pain point)

### Pain Point 1 — ElizaCloud billing/top-up confusion + VPN recharge failures (UX/UI)
**High impact / Medium effort**
1. **Single “Add Funds” flow with explicit steps + inline validation**
   - Show: payment method → currency → min deposit → confirmation → balance updated.
   - Add clear error messaging for VPN/geo/payment rails (“Your payment was blocked due to risk controls; try X”).
   - *Comparable*: Stripe Checkout + clear decline reasons; many SaaS dashboards use a single top-up wizard.

**High impact / Low–Medium effort**
2. **Instrument funnel analytics + session replays for top-up path**
   - Track drop-offs at each step; tag “VPN detected” to quantify impact.
   - *Comparable*: PostHog/FullStory-driven onboarding fixes.

**Medium impact / Low effort**
3. **Mark ElizaCloud.ai as “Beta” in-product until top-up + account bugs are resolved**
   - Sets expectations; reduces trust damage from early evaluator experiences.

---

### Pain Point 2 — Plugin discovery/reliability + lack of guided recommendations (UX/UI + Integration)
**High impact / Medium–High effort**
1. **Curated marketplace layer (“Certified / Recommended”) + use-case collections**
   - “Starter kits”: Social autoposter, Trading sentinel, Customer support bot, Research agent.
   - Include compatibility badges (Cloud-ready, requires keys, cost level).
   - *Comparable*: VS Code Marketplace “Recommended”; Home Assistant’s curated integrations.

**High impact / Medium effort**
2. **Guided plugin selection wizard**
   - Ask 3–5 questions → suggests plugin bundle + auto-config templates.
   - *Comparable*: Vercel/Render deployment templates; n8n workflow templates.

**Medium impact / Low effort**
3. **Plugin “trust metadata” standard**
   - Owner verification, last update, known issues, permissions requested (esp. wallet/keys).
   - *Comparable*: browser extension permission prompts; Hugging Face model cards.

---

### Pain Point 3 — Token migration misses + support delays + scam exposure (Community + UX)
**High impact / Medium effort**
1. **In-dashboard “Migration status” page**
   - Detect if wallet is eligible, show deadline status, show “Open ticket” CTA, and show *official* addresses only.
   - Include signed announcements (hash / signature) for canonical instructions.

**High impact / Low–Medium effort**
2. **Ticket SLA + public queue transparency**
   - Even a simple banner: “Tickets before Feb 4 are being processed; current backlog: X days.”
   - Auto-replies requesting ticket number + wallet + proof in a standardized format.

**High impact / Medium effort**
3. **Anti-scam hardening**
   - Auto-moderation: detect “support desk” phrases, suspicious invite links, wallet posting; auto-warn users opening migration topics.
   - *Comparable*: major crypto Discords use auto-mod + keyword triggers + “Only staff will never DM you” banners.

---

### Pain Point 4 — Core runtime stability issues + duplicated LLM calls (Technical Functionality + Performance)
**High impact / Low–Medium effort**
1. **Fix URL double-processing bug (GitHub #6486) with a single canonical message representation**
   - Ensure URL preview metadata is attached without creating a second content path that triggers a second model call.
   - Add regression test for “message contains URL.”

**High impact / Medium effort**
2. **“First-run health check” command + log classifier**
   - `elizaos doctor`: highlights critical vs ignorable errors; checks plugin registry auth status; validates agent skills provider types.
   - *Comparable*: `docker diagnose`, `next telemetry` checks, Supabase CLI diagnostics.

**Medium impact / Low effort**
3. **Harden provider type expectations in agent skills**
   - Defensive checks + schema validation to prevent `.toLowerCase` on non-strings; return actionable error.
   - *Comparable*: Zod-based runtime validation patterns widely used in TS tooling.

---

### Pain Point 5 — Agent access to ElizaCloud (auth + key provisioning) is hard (Integration + Technical)
**High impact / Medium–High effort**
1. **Ship SIWE-based agent auth + “API key minting” (already committed)**
   - Provide a documented flow: sign challenge → obtain scoped key → rotate/revoke.
   - Aligns with DorianD’s “agent signup” and proof-of-agent concept.

**High impact / Medium effort**
2. **CLI-first Cloud onboarding**
   - `elizaos cloud login` → `elizaos cloud key create` → `elizaos deploy`.
   - *Comparable*: Fly.io / Vercel CLIs that provision tokens and projects in minutes.

**Medium impact / Medium effort**
3. **Capability-scoped keys + rate-limit controls**
   - Addresses questions about rate limits/aggregator behavior; reduces fear of runaway usage.

---

### Pain Point 6 — OpenAI-compatible provider support gaps (Integration)
**High impact / Low effort**
1. **Add configurable `baseURL/endpoint` to OpenAI provider** (GitHub #6490)
   - Unblocks SiliconFlow and other OpenAI-compatible endpoints immediately.
   - *Comparable*: LangChain/LlamaIndex expose base URL overrides as standard.

**Medium impact / Medium effort**
2. **Provider compatibility matrix**
   - Table of “OpenAI / OpenAI-compatible / local (Ollama) / etc.” with required env vars.

---

## 4) Communication Gaps (expectations vs reality)

### Where expectations don’t match reality
- **“Is anyone working on ElizaCloud?”** indicates visible progress isn’t reaching users (despite active work).
- **Users expect consumer SaaS polish**, but are encountering beta-grade onboarding bugs (billing/VPN, welcome bonus duplication).
- **Agent-readiness expectation**: users see endpoints/roadmap items and assume agents can already consume Cloud easily; current friction suggests otherwise.
- **Token-holder expectations vs open-source cadence**: lack of predictable updates creates a vacuum filled by price-action narratives.

### Recurring questions indicating onboarding/documentation gaps
- “Where is the roadmap?” (despite being at `github.com/elizaos/roadmap`)
- “What is SIWE/SIWA?” “Can agents sign up?”
- “Is there staking?” “Is there a bridge?” “What’s official support?”
- “Which errors are normal vs critical on first install?”

### Specific improvements
- Add **“Start here”** hub: “I’m a developer” vs “I’m evaluating” vs “I’m integrating existing agents.”
- Add **Known Issues** + **Status page** for ElizaCloud (billing, auth changes, plugin marketplace WIP).
- Publish a **weekly changelog digest** even if milestone-based dev continues (can be automated; PAR format suggestion is aligned with community request).

---

## 5) Community Engagement Insights

### Power users & what they need
- **yojo**: strong UX/product feedback + wants structured comms; needs a clear product narrative + in-dashboard feedback loops.
- **DorianD**: pushing Cloud to be agent-accessible (CLI/API, auth, rate limits); wants “minor changes” enabling OpenClaw agents.
- **azsxdc**: practical integrator; contributes forks; needs stable plugin APIs + clear contribution path for sharing integrations.
- **Odilitime**: key technical responder; needs tooling/process to reduce repetitive support load (docs, doctor command, canned responses).
- **jin / Seppmos**: producing update videos; can be leveraged as an official community comms pipeline.

### Newcomer questions (onboarding friction signals)
- Migration missed → “are tokens lost?”
- “Is this support Discord real?”
- “Where do I stake / bridge?”
- “Does Eliza have heartbeat/cron like OpenClaw?” (answered: “tasks”)

### Converting passive users into contributors
- Create “Good first issue” tracks specifically for:
  - Cloud dashboard copy improvements (payments, add USD)
  - Plugin marketplace metadata schema
  - `elizaos doctor` checks + tests
- Recognize community forks (e.g., OpenClaw Twitter plugin fork) with an “Adopters/Integrations” directory and lightweight review process.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord**: great for rapid troubleshooting and sentiment, but issues get lost; repeated questions (roadmap, migration, staking) suggest missing pinned canonical answers.
- **GitHub issues**: strong for reproducible bugs (e.g., #6486) and clear feature asks (#6490), but non-coders rarely file issues there.
- **ElizaCloud in-product**: appears to lack structured, always-available feedback capture for evaluators.

### Improvements for more structured, actionable feedback
1. **In-dashboard feedback widget** (ElizaCloud)
   - “Report a bug” (auto-attaches browser/version), “Request a plugin,” “Billing issue.”
2. **Standardized Discord intake**
   - Pinned “Support checklist” + bot that converts tagged messages into GitHub issues (with user confirmation).
3. **Monthly onboarding usability test**
   - Repeat yojo’s “5 tester” approach systematically; track success metrics (time-to-first-successful-run, time-to-top-up).

### Underrepresented segments
- **Non-coders** beyond the small evaluator sample (need continuous input)
- **Enterprise / team admins** (multi-user, permissions, audit)
- **International users** affected by VPN/geo/payment constraints
- **Plugin maintainers** who need distribution/trust tooling

---

## Prioritized High-Impact Actions (next 2–4 weeks)
1. **Fix high-cost UX/perf bugs immediately**
   - Ship resolution for **URL double-processing** (GitHub **#6486**) + patch the **agent_skill_instructions crash**.
2. **Stabilize ElizaCloud onboarding for non-coders**
   - Repair **welcome bonus/account duplication** + redesign **Add USD/top-up** flow with explicit steps and VPN-aware error handling.
3. **Reduce trust/safety incidents around migration**
   - Add an **official migration status + instructions page** (and pin everywhere), publish SLA/backlog status, and expand Discord anti-scam automation.
4. **Make Cloud agent-access real (not aspirational)**
   - Deliver **SIWE + scoped API key minting** and a **CLI happy-path** (“login → key → deploy”) with docs.
5. **Close the communication loop**
   - Publish an automated **weekly digest** (Discord + X + roadmap delta) and add a “Start here” page clarifying target audiences and intended workflows.