DeepSeek-Reasonix: a terminal coding agent built around prefix-cache stability

The problem Reasonix targets: an agent you can leave running

Most terminal coding agents are optimized for a single impressive session. You start one, it plans, it edits, it exits, and the next session pays full price to re-read the same repository context. Reasonix is explicit about the opposite goal. The README calls it "a coding agent you can leave running," and the feature list backs that up with cache-aware context maintenance: startup injects a small stable environment summary, stale tool output is snipped or pruned before summary compaction, and the built-in tool schema contract is documented so changes to it can be reviewed for regressions.

The intended user is a developer who keeps an agent open across a working day, or across several days on the same project, and who is billed per token by DeepSeek. Prefix-cache stability is a billing concern before it is a latency concern. If the system prompt, tool schemas, and environment summary stay byte-stable between turns, the provider can serve the cached prefix instead of reprocessing it. Every time the agent rewrites its own preamble, that cache is invalidated and the next turn costs more. Reasonix treats that as an engineering constraint rather than an afterthought.

The project is written in Go, licensed MIT, and describes itself as a single Go binary. It is not a wrapper around a hosted service. The engine runs locally, and the model calls go out to whichever endpoint you configure.

One engine, four entry points, and why the split matters

Reasonix separates the engine from its interfaces. The README states that the CLI/TUI, desktop app, and VS Code extension all use the same local Reasonix engine, and that the engine can be reached four ways: terminal, desktop app, browser, or an editor over ACP.

That architecture has a practical consequence. The VS Code extension does not bundle the CLI. According to the README, you complete the CLI install first, and the extension then starts your local reasonix acp backend and adds chat, editor context, tool-call approvals, model selection, and workspace sessions on top. So the binary is the dependency, and the editor integration is a client of it. If the binary is missing or the wrong version, the extension has nothing to talk to.

Configuration is likewise centralized. Providers, the agent, enabled tools, and plugins are declared in reasonix.toml, and the README states there are no hardcoded models. DeepSeek ships as a preset; any OpenAI-compatible endpoint is a config entry rather than new code. Secrets do not live in that file. The .env.example is explicit: only secrets belong in .env, while a provider's base_url and model are configured in reasonix.toml, where api_key_env points at those variables. The example file lists DEEPSEEK_API_KEY and MIMO_API_KEY.

Two details in the repository layout reinforce the design. The go.mod pins Go 1.26.0 with a toolchain directive at go1.26.6, and the dependency list includes tree-sitter grammars for JavaScript, Python, Rust, and TypeScript, an MCP SDK, and a TOML parser. Parsing source with tree-sitter rather than shipping everything to the model is a deliberate cost decision.

Installing the Reasonix CLI and running a first task

The README gives four install paths. Path A is the CLI and TUI, which is the one everything else depends on. On any supported platform you install the native binary through npm, which pulls a prebuilt binary; on macOS there is also a Homebrew formula.

npm i -g reasonix
brew install esengine/reasonix/reasonix

Prebuilt archives covering darwin, linux, and windows across amd64 and arm64, plus a SHA256SUMS file, are attached to every GitHub release. If you prefer to build, the CLI requires Go 1.25 or later according to the README, and the module pins a toolchain directive, so keep GOTOOLCHAIN=auto set or install the pinned toolchain yourself.

git clone https://github.com/esengine/DeepSeek-Reasonix.git
cd DeepSeek-Reasonix
make build

The Makefile builds with CGO_ENABLED=0 and writes the result to bin/reasonix. A comment in that file explains the choice: disabling cgo keeps the install working where a stray clang on PATH shadows the toolchain and breaks runtime/cgo. The same file offers make cross for the six-target dist/ output.

Once the binary is on your PATH, configure a provider and model, then start a session or hand it a task directly.

reasonix setup
reasonix
reasonix run "implement the TODOs in main.go"

The README notes that inside an interactive session you run /init when you want Reasonix to create project instructions. That is the first thing worth doing on an existing repository, because the generated instructions are what the agent will carry into later turns. The desktop app is a separate download from the official page and does not need these CLI commands; the VS Code extension does need the CLI, and its extension ID is SivanLiu.reasonix-agent.

Where Reasonix is the wrong tool

The strongest constraint is the one the project advertises. Reasonix is DeepSeek-native. DeepSeek ships as a preset, and other providers must be OpenAI-compatible endpoints declared in reasonix.toml. If your organization runs a model behind a proprietary protocol, or a gateway that does not speak the OpenAI chat format, there is no documented path for you short of writing an integration.

The second constraint is the install chain. The npm package pulls a prebuilt binary per platform, which is convenient, but it means the CLI, the desktop app, and the editor extension are three separately versioned artifacts sharing one engine. The README does not document rollback for a bad upgrade, and it does not describe a compatibility matrix between CLI versions and extension versions. On a machine where the extension auto-updates and the CLI does not, that gap is where you will spend your afternoon.

Third, the desktop build is materially heavier than the CLI. It requires Node 24 or later and pnpm 10 for the frontend, plus a Wails CLI matching the .wails-version pin, and the README points to a desktop build guide for platform webview dependencies and Linux build tags. If you only want the agent in a terminal, do not start there.

Finally, "leave it running" is not the same as "supervise nothing." The README lists plan mode, permissions, a workspace sandbox, and per-turn checkpoints as the mechanisms that keep a long run readable and undoable. Those are guardrails, not a substitute for reading diffs.

Reasonix compared with OpenCode and with a plain API script

The comparison people search for is Reasonix against OpenCode. The available documentation describes Reasonix only, so the honest framing is about approach rather than a feature table. Reasonix is a provider-agnostic engine with a DeepSeek preset, config-driven through reasonix.toml, distributed as a compiled static binary, and extended through MCP servers plus an Extension Protocol v1 sidecar mechanism that can intercept runtime events, contribute providers and structured UI, and ship versioned plugin packages. Its distinguishing engineering bet is that context maintenance and prefix-cache stability deserve first-class treatment: stale tool output is snipped or pruned before summary compaction, and the tool schema contract is documented for regression review.

A second alternative is a script you write yourself against the DeepSeek API. That gives you total control over what is sent, which is exactly the property Reasonix is trying to protect. The trade is that you also own tool dispatch, sandboxing, checkpointing, and the terminal interface. Reasonix bundles those; a script does not.

The middle option is another OpenAI-compatible agent framework configured to point at DeepSeek. You would get the same model and lose the cache-oriented context handling, unless the framework happens to do the same pruning before compaction. That is the specific thing to check when comparing, not the length of a feature list.

Maintenance, upgrade cost, and the MIT licence

The repository is not archived, and the last push was on 2026-08-29, which is recent enough that the project is under current development. The release history is dense: v1.32.0 and v1.32.1 both landed on 2026-08-28, and v1.33.0 followed on 2026-08-29. A cadence of three releases in two days is a signal about both velocity and churn. If you pin versions, expect to move the pin often; if you track the default branch, expect to read release notes.

Upgrade cost depends on which front end you use. The CLI is a single binary, so an upgrade is a binary swap. The desktop app is a separate download. The VS Code extension installs from the Visual Studio Marketplace or the Open VSX Registry under the ID SivanLiu.reasonix-agent, and its source lives in a different repository from the engine. That means three upgrade paths that must stay roughly in step, with no documented compatibility matrix in the README.

For contributors, the Makefile documents the local gates CI runs: make lint runs golangci-lint at the version pinned in .golangci-version and then go run ./tools/repolint. A comment warns that modernize findings in particular never surface in go vet, so skipping the lint step locally trades a second for a ten-minute CI round trip.

The licence is MIT. That is permissive and places few obligations on how you redistribute or modify the code. It also means the project offers no warranty, and the README does not describe commercial support or an SLA. This is not legal advice; if you are embedding Reasonix in a product, read the LICENSE file in the repository and get your own counsel.

Editorial conclusion

Adopt Reasonix if you already pay for DeepSeek tokens, want a single static binary on a server or laptop, and care about what a long autonomous run costs per turn. Skip it if you need a hosted service with an SLA, or if your provider is not OpenAI-compatible and you are unwilling to write a config entry. Before committing, run reasonix setup and confirm the model you intend to use appears, then start an interactive session and watch whether /init produces instructions that match your repository layout rather than a generic template.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes