The comprehension layer for AI-built apps
Your AI wrote it. Mushi tells you why it broke.
Plain-English explanation of what broke, plus a fix you can paste into Cursor or Claude Code — so a bug costs five minutes, not your whole afternoon.
MIT-licensed SDKs · self-hostable · no second LLM key
- License: SDKs MIT · server AGPLv3 · enterprise edition commercial
- Self-host: Self-host the whole stack with one command.
- No lock-in: Your reports, your keys, your repo — no lock-in.
- Dogfood: Mushi runs on Mushi — we catch our own bugs with it.
60-second proof
npx mushi-mushinpx mushi-mushi setup --ide cursor # then ask Cursor: "what's broken in prod?"50 diagnoses/month on the free tier — no card. Self-host in under five minutes if you want.
See it in action
Admin console tour, SDK dogfood on glot.it, and theme-aware stills — click any frame to open the live surface.What this is (and is not)
Built for solo founders who ship with AI and lose afternoons debugging code they did not fully write. Works inside your editor — not another dashboard. Sentry can plug in later; you do not need it to start.Where to start
Pick the path that matches what you are doing right now — each card links to the right next step.I use Cursor / Claude
Connect Mushi to your editor first — read reports and pull fix prompts without leaving the window.
npx mushi-mushi setup --ide cursorI have a web or mobile app
Drop in the SDK, file the first report, get a plain-English read in about 10 seconds.
npx mushi-mushiI operate the console
Create a project, connect GitHub, and walk through the onboarding checklist.
mushi login && mushi status
Try it
Classification lands in about 10 seconds today; we are chasing sub-10. Pick a starting point:- Incident loopStart here
npx mushi-mushiBroken prod → plain-English read → paste-ready fix prompt in Cursor.
- MCP serverEditor-first
npx mushi-mushi setup --ide cursorAsk your editor what broke — fix briefs from Claude, Cursor, or Codex. No second LLM key.
- React
npx mushi-mushiWizard installs the SDK, writes env vars, optional test report.
- iOS · Android · FlutterNative
pod 'MushiMushi'Native shake, offline queue, and a Sentry bridge already wired up.
Where Sentry stops, this picks up.
| Question | Sentry alone | Mushi |
|---|---|---|
| What it sees | Errors your code throws | Friction your users feel |
| What lands in your queue | A stack trace | A short user note plus the screenshot they were looking at |
| Repeat bugs | Each one shows up as a new issue | The same broken button collapses to one row |
| What you learn from fixes | None — the next dev repeats the mistake | Past fixes become rules your editor sees on the next PR (.mushi/lessons.json) |
| Closing the loop | Assign a ticket and remember to update | An optional draft PR you can merge or ignore |
| Reporter attribution | Anonymous | "Fixed by Kenji" in the changelog; SDK toast on next session |
| From your IDE | Copy the issue ID into Cursor | Cursor reads the report + relevant lessons and proposes the diff |
| Where it runs | Their cloud | Yours, ours, or both |
What happens after a user reports something
- Step 1User reportsSomeone shakes or taps instead of emailing support. Mushi saves what they saw and what they were doing.
- Step 2Plain readSeverity and cause in English your team already uses — not a raw stack trace.
- Step 3One rowTwenty reports about the same broken button collapse to one issue.
- Step 4Draft PROptional: an agent opens a PR. You merge, edit, or ignore it like any other.
See Concepts → Architecture for the wire-level sequence diagram and component-by-component spec.
Running this for a team?
Deeper setup (SSO, audit, adapters) lives in docs/operators on GitHub — the landing page stays on the solo-founder wedge.