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.
Why prefix caching is the whole pitch 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.
What that looks like in practice A small, stable environment summary is injected at startup rather than regenerated each turn.
Stale tool output gets snipped and pruned before summary compaction kicks in, so a giant result from twenty turns ago is not still sitting in your prefix.
The built-in tool schema contract is documented and regression-reviewed, because a silent tool-definition reshuffle is a cache invalidation with no visible symptom.
Two-model mode (executor plus planner) runs each model in its own separate, cache-stable session instead of interleaving them into one context.
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.
The rest of the architecture A single static Go binary. , 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 .
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 , 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 .
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 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: 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.
Getting star