Most terminal coding agents are architecturally similar: a loop, a tool registry, some context management, a TUI. Reasonix picks a different thing to optimize for, and it is a thing that shows up on your bill rather than in a demo video.
The tagline is "engineered around prefix-cache stability — leave it running." That phrase is doing a lot of work, so let's unpack it.
DeepSeek's API, like several others, caches the prefix of your prompt. If the next request starts with the exact same token sequence as the previous one, the provider serves those tokens from cache and bills them at a small fraction of the normal input rate. Cache hits are dramatically cheaper than cache misses.
Here is the catch: it is a prefix cache. The match has to start at token zero and run forward. Change one character near the top of your context and every token after it is a miss.
Now think about what a typical agent harness does over a long session. It re-summarizes the conversation. It injects a fresh timestamp or a re-scanned directory tree at the top. It reorders tool definitions. It rewrites the system prompt when you switch modes. Every one of those is a mutation near the front of the context, and every one of them silently invalidates the entire cache.
The result is an agent that feels fine and costs several times what it should. You do not notice, because nothing errors. You just watch the number go up.
Reasonix's central design constraint is: don't do that. Keep the front of the context stable, append rather than mutate, and put churn where it costs least.
cat
result from twenty turns ago is not still sitting in your prefix.That last one is the neatest idea in the project. The naive way to add a planner is to inject planning turns into the same conversation, which trashes cache stability for both roles. Keeping them in separate sessions means each one's prefix stays intact.
A single static Go binary. CGO_ENABLED=0
, cross-compiles to six targets, and the only dependency is a TOML parser. No Node runtime, no Python venv, no dependency tree to audit.
Config-driven, not model-hardcoded. Providers, agent settings, enabled tools, and plugins all live in a reasonix.toml
. DeepSeek ships as a preset, but any OpenAI-compatible endpoint is a config entry rather than a code change. Secrets come from the environment and are never written into the config file. Despite the repo name, this is not DeepSeek-only, and it is not an official DeepSeek project — it is a community project that treats DeepSeek as the first-class default.
MCP client. External tools run as subprocesses over stdio JSON-RPC, or over Streamable HTTP for remote servers. If you already have an .mcp.json
, drop it in the project root and it is read as-is. Server prompts show up as slash commands, and resources are pulled into a message with @server:uri
.
Permissions and sandbox are separate mechanisms. Permissions are policy: each tool call is evaluated deny, then ask, then allow, then fallback, and approvals are stored as reusable rules like Bash(go test:*)
rather than one-off clicks. The sandbox is enforcement: file writers refuse any path outside the workspace root, resolving symlinks and ..
so a link cannot tunnel out.
One caveat worth knowing before you use the autonomous mode: bash
itself is jailed via Seatbelt on macOS, but on other platforms it currently runs unconfined. On Linux or Windows, your deny list is the real boundary, not the sandbox. Write it accordingly.
npm i -g reasonix # or: brew install esengine/reasonix/reasonix
reasonix setup # pick a provider, set your key
reasonix # start an interactive session
That is genuinely the whole first run. There is also a desktop app and a VS Code extension that drive the same local engine, plus prebuilt archives on every release if you would rather not go through npm. Everything else — the TOML schema, permission rules, MCP plugins, custom slash commands, two-model setup — is in the Guide, and none of it is required to try the thing.
Two commands worth knowing on day one: /init
generates project instructions, and /branch <turn>
forks the conversation from an earlier checkpointed turn. That second one is a much better recovery move than clearing context and re-explaining everything when the agent goes down a bad path.
Yes, if: you already pay for DeepSeek or another OpenAI-compatible endpoint and run long agent sessions, you are cost-sensitive enough to care about cache hit rates, or you want a single static binary instead of a Node or Python install. The MCP support, config-first design, and permission rules are all solid, and the project has real traction — tens of thousands of stars, an active contributor list, CI, code-signed Windows builds, and a bilingual Discord.
Probably not, if: you are locked into a provider without prefix caching, in which case the core optimization is irrelevant and you should pick a harness on other merits. Also skip it if you need a mature autonomous-mode sandbox on Linux or Windows today — that is still on the roadmap.
Things to go in knowing. The active branch is main-v2
, not main
, which is mildly confusing when you clone. If you are on a 0.x config, there is a migration guide, and your old MCP servers are still read as a lowest-priority source. The issue and PR counts are large, which is what you would expect from a fast-moving project at this size — read it as activity, not instability, but check the changelog before upgrading anything you depend on. And the repo name genuinely does mislead people: this is a community project, not something DeepSeek ships.
The reason I would look at it even if you never install it is the design argument. Most agent harnesses treat context management as a correctness problem: keep the model informed, drop the irrelevant. Reasonix treats it as an economics problem too, where the ordering and stability of your context is a cost variable you control. That reframing is worth twenty minutes of reading whatever tool you end up using.