Capuchin is the AI that powers MonkeysCode by default. This post is about what it actually does, how it's served, and, since we've gotten this question a lot, what it isn't.
Two modes, one model
Coding tasks aren't uniform. Autocomplete and small edits need to feel instant. Planning a multi-file refactor or chasing a gnarly bug benefits from actually thinking it through. Most tools pick one tradeoff and apply it everywhere. Capuchin doesn't:
- Capuchin Flash. Thinking off, sub-second responses. This is the 80% of coding work: completions, small edits, quick questions.
- Capuchin Reason. Step-by-step reasoning, budgeted so "thinking" never turns into "spinning." This is the 20% that's actually hard: multi-file plans, debugging, tradeoffs. MonkeysCode routes between them automatically based on the task, or you can pin one yourself. The point isn't "slow but smart" vs "fast but dumb." It's picking the right tool per step, inside a single session.
Why we can afford to include unlimited usage
The honest answer is efficiency. Capuchin is built to activate only a fraction of its total capacity per token. The architecture spends its weights on software-engineering tasks specifically, rather than spreading capacity across everything a general chat model tries to do. That's what makes it both sharper on real coding work and cheap enough to serve that we can bundle generous usage into a subscription instead of metering every token.
Practically, that shows up as:
- Speculative decoding and caching keep response times low even under load
- A fair-use ceiling, not literal infinity. "Unlimited" is generous, not unbounded, so the economics stay sane for everyone ## Built to use tools, not just talk about them
Capuchin is tuned specifically for agentic work: it calls your terminal, git, test runner, browser, and MCP servers and uses the results accurately across long sessions, the kind of 20-30-tool-call runs that real refactors actually take, not a single-shot completion. It plans before it acts, executes across files in parallel, and runs your tests before handing back. If something fails, it sees the failure and fixes it rather than reporting success prematurely.
It's also polyglot by design, strong across Python, JavaScript/TypeScript, Go, Rust, Java, and more, because most of us aren't working in a single language, and a model that's only good at one is a model you'll outgrow.
What it is not: a local model
This is worth being precise about, because we've seen the confusion. Capuchin is a managed cloud service, the same delivery model as Claude, ChatGPT, or Codex. It is not something you download and run on your laptop.
If you need fully offline or air-gapped work, that's a real, fully supported path in MonkeysCode. It's just a different one: point the IDE at your own model, local (Ollama, llama.cpp, vLLM) or on your own server. Capuchin is the managed default; your own model is the offline path. Two clean, non-overlapping stories, not one confused one.
How it gets better
We start from a strong open foundation and specialize it hard for real software-engineering work inside MonkeysCode, rather than training something narrow from scratch. Improvement after that is:
- Opt-in only. Free, Pro, and Team users choose whether usage signals contribute to improving the model. The default is off.
- Never from enterprise, self-hosted, or air-gapped installs. No exceptions, regardless of any general opt-in setting.
- Signal over source. Where opt-in is given, we prefer derived signals (was the edit kept? did tests pass?) over retaining raw code.
- Gated releases. Every new checkpoint has to beat the current one on our internal benchmark before it ships. No regressions allowed through. ## Try it
Capuchin is included with unlimited usage on every paid MonkeysCode plan, and free to try for a month during our founding-user promo.
If you've got questions about the Flash/Reason routing, the fair-use design, or where the local/managed line actually sits, ask away in the comments. Happy to get into the weeds.
Top comments (2)
The "not the only option" point is healthy. Model choice is becoming more like infrastructure choice: latency, reliability, cost, eval fit, and integration surface matter as much as benchmark headlines. The best model is often the one that fits the workflow.
Exactly; that is why the user is given multiple options to decide which model is the best fit.