# ElizaOS Intel — 2026-02-21

## 1) Data Pattern Recognition (Dev + Community)

### Development velocity & trend
- **Month-to-date (2026-02-01 → 2026-03-01, elizaos/eliza):**
  - **35 PRs opened / 18 merged** (≈ **51% merge rate**)
  - **41 new issues / 65 closed** (net backlog **-24**)
  - **34 active contributors**
  - Code churn reported: **+18,576 / -3,807 across 160 files; 136 commits** (high activity, moderate deletion—suggests additive feature work + incremental cleanup)
- **Most recent day signal (2026-02-20):**
  - Shipping + instrumentation work noted: **baseline beta metrics established**, landing page updated (Discord added as 4th messaging option), and **critical n8n plugin fix** (multi-step confabulation).

**Trend callout:** Engineering throughput is strong (issues closing > opening), but community-perceived “product readiness” is being dominated by **ElizaCloud UX regressions** and **unclear platform semantics (keys/pricing/migration)**—a classic “velocity ≠ felt progress” gap.

### Community engagement patterns
- Engagement concentrated in **support/clarification loops**:
  - Token migration confusion ($ai16z vs $elizaos), chain validity questions, and “how to contact Shaw / where updates are.”
  - Multiple **unanswered questions recurring** across days (BYOK, migration remaining count, Milady chain validity, live agent availability).
- **Developer supply present, demand unclear:**
  - Multiple devs offered help (backend/security/UX), but community responded with “no projects,” indicating **missing task intake / contribution routing** rather than lack of talent.

### Pain point correlation across channels
| Pain point | Where it appears | Correlated impact |
|---|---|---|
| ElizaCloud dashboard usability + API explorer broken | 💬-coders + daily report | Blocks adoption, reduces trust in “best-in-class APIs” narrative |
| Keys/pricing clarity (“use a different key”, per-model pricing) | 💬-coders | Prevents conversion to paid usage; increases support load |
| Migration + token identity confusion | 💬-discussion + 02-19 | Drives negative sentiment; creates partner/community rumor surface |
| Leadership + partner communications fragmentation (Twitter vs Farcaster) | 💬-discussion + 🥇-partners | Amplifies negative narratives; increases “monitor 2 platforms” friction |

---

## 2) User Experience Intelligence (What users are actually experiencing)

### Feedback categorization (impact × theme)

**A) High impact / immediate blockers (ElizaCloud)**
- **Broken mousepad scrolling** on API explorer and other dashboard pages; scrollbar is hard to see.
- **“Send request” tester fails**: returns **“api key is required”** while UI shows a key present.
  - User interpretation: “the platform is not reliable / not production-ready.”

**B) High impact / trust & conversion blockers (clarity)**
- **BYOK ambiguity**: “use a different key” not clearly explained; users compare to OpenRouter’s BYOK model.
- **Pricing transparency**: request for **per-model price breakdown in-dashboard**.

**C) Medium impact / ecosystem support gaps**
- Migration support: users asking for help to avoid losing coins; no clear **ticketing/escalation** path.
- Recurring unanswered Q: “Is there still a live Eliza agent for latest codebase questions?”

**D) Sentiment drivers**
- Negative sentiment is being driven less by feature absence and more by:
  - **Communication fragmentation** (Twitter vs Farcaster split)
  - **Partner comms weakness** causing “unnecessary negative sentiment from influential groups”
  - Unclear token utility narrative tied to **ElizaCloud adoption** (“building year” framing accepted, but needs concrete traction signals)

### Usage patterns vs intended design (inferred)
- Users are trying to evaluate ElizaCloud like a developer platform:
  - Expect **API explorer to work flawlessly** (scroll + test request) as a baseline credibility check.
  - Expect **pricing + key management** to be self-serve, not Discord-dependent.
- Community expects Discord to function as the “source of truth,” but updates are split across external networks; this mismatch is creating repeated Q&A churn.

### Implementation opportunities (fast wins)
- Treat the API explorer as an onboarding funnel:
  - Fix scroll + request tester + add “copy cURL / SDK snippet” + explicit key state messaging.
- Convert repeated questions into “single-link answers” inside product UI and pinned Discord messages.

---

## 3) Strategic Prioritization (Next moves, impact vs risk)

### Priority initiatives (ranked)
| Initiative | User impact | Tech risk | Effort | Why now / dependency |
|---|---:|---:|---:|---|
| 1) **ElizaCloud API Explorer reliability patch** (scroll + request tester key bug) | Very High | Medium | Small–Med | Unblocks evaluation + adoption; prerequisite for “well-documented APIs” positioning |
| 2) **Key management + BYOK clarification (UI + docs)** | High | Low–Med | Small | Reduces support load; improves conversion; directly addresses unanswered questions |
| 3) **Pricing transparency (per-model table in dashboard)** | High | Low | Small | Builds trust; reduces “hidden costs” fear; supports upcoming cost-aware tooling narrative |
| 4) **Migration support ops** (status, how-many-left metric, support workflow) | Med–High | Low | Small | Stops recurring confusion; reduces reputational damage |
| 5) **Comms unification layer** (weekly digest + partner-ready updates) | Med–High | Low | Small–Med | Addresses partner negativity + “monitor 2 platforms” friction; scales leadership bandwidth |

### Critical path dependencies
- **ElizaCloud adoption → token utility narrative credibility**: Community explicitly links recovery to Cloud usage growth; Cloud UX regressions currently break this chain.
- **Support + clarity → partner sentiment**: Partner groups amplify confusion; resolving ambiguity reduces negative propagation.
- **Metrics baseline established (02-20) → use it externally**: If metrics exist, publish at least 1–2 “traction/quality” indicators regularly (uptime, API success rate, explorer request success rate) to counteract sentiment.

### Recommended resource allocation (next 7 days)
1. **1 Frontend engineer (or contractor) for 1–2 days**
   - Fix scroll behavior (trackpad wheel events, overflow containers) across dashboard pages
   - Improve scrollbar visibility/accessibility (contrast/width) as a quick UX patch
2. **1 Full-stack engineer for 1–2 days**
   - Diagnose API explorer “api key required” mismatch:
     - likely state propagation / wrong header injection / environment mismatch (test vs prod key store)
   - Add explicit inline diagnostics: “Key loaded from X, sending header Y”
3. **1 PM/DevRel for 0.5–1 day**
   - Ship a **single canonical FAQ**: BYOK meaning, pricing link, migration steps, Milady chain validity, where updates live
   - Pin in Discord + link from dashboard (“Need help?”)
4. **Community ops**
   - Create a lightweight intake: “Good first issues / bounty board” to convert dev availability into shipped fixes

### Actionable recommendations (tight scope)
- **Ship within 48 hours:**
  - (A) API explorer scroll fix + scrollbar visibility tweak
  - (B) “Send request” fix or clear error explaining why key is not applied
- **Ship within 72 hours:**
  - Add **per-model pricing table** in dashboard + link to full billing docs
  - Clarify “use a different key” in-product (tooltip + docs) with explicit statement: *supports BYOK? which providers? where stored?*
- **Within 7 days:**
  - Publish **weekly unified update digest** (Discord post that aggregates Twitter + Farcaster highlights)
  - Stand up a **migration support workflow** (form/ticket or dedicated Discord thread with escalation rules) and answer: “How many still need to migrate?” with a tracked metric
  - Partner comms: produce a **partner-ready changelog snippet** (what shipped, what’s next, known issues, ETAs) to prevent avoidable negative sentiment

---