Running a coding agent in a terminal stopped being a novelty and became a habit. The agent reads, plans, edits, runs the tests, and a project moves forward while you do something else. Then the month's bill arrives and the habit acquires a price that is hard to justify. Every turn sends the system prompt, the tool definitions and the whole history back to the model, and a session that lasts hours resends the same material hundreds of times.

Most of that repetition ought to be free. Model providers discount input that is identical to what they have already seen, but only if the repeated part is at the very beginning of the request and byte for byte unchanged. A general agent that reshuffles its context between turns destroys that arrangement on every call, which is why the discount so rarely shows up where it matters.

One constraint, taken seriously

Reasonix is built around that single fact. Its whole architecture follows from the rule that the opening of a conversation must never change once it has been sent. Nothing here is a wrapper around somebody else's loop with a new coat of paint; the point of the project is to rearrange a terminal agent so the cheap path stays available for hours.

The session is therefore split into three regions with three different behaviours. An immutable prefix holds the system prompt, the tool specifications and the worked examples, injected once when the session opens and then locked. An append-only region carries the history in time order, never reordered and never rewritten. A volatile region holds the scratch thinking of the current turn, the draft of a plan, and that part stays on the local machine without being sent upstream at all.

The economic effect is not subtle. Cached input is billed at a small fraction of the normal rate, but a single changed byte at the front throws the whole cache away. Those two facts explain almost every design decision in the program.

What the saving looks like in practice

Numbers from ordinary use are more convincing than a benchmark. One person put in a full working day through the agent and moved more than four hundred million input tokens; the bill came to twelve dollars, where the same work with no cache would have cost roughly five times as much. The share of requests that hit the cache was above ninety-nine per cent. That is not a laboratory figure, it is one person's Tuesday.

Autonomy you can review while it runs

Cost is only half of the reason people hesitate to leave an agent alone for hours. The other half is not knowing what it did. The answer here is a set of layers, each of which keeps part of the session visible.

A planning mode produces steps before any file is touched, and nothing is written until the plan is approved. Permission gates ask separately about reading, writing and running shell commands, and even an approved action stays inside the bounds of a workspace sandbox. Checkpoints are taken every turn outside the version history, so a session that has run for six hours can be rolled back to any of those points without leaving commits scattered through the repository. And a repair layer catches the habits these models fall into: a tool call swallowed by the reasoning block, an argument list cut off halfway, a burst of calls that arrives out of order.

A small task shows how the layers fit together. Told to add a retry with backoff around an HTTP client, the agent first lists three steps and confirms that two files and one test run are involved. After a yes it edits both files in order and runs the test. Each step gets a checkpoint, and any step that disappoints can be reverted with one command. The whole session took eighteen minutes, nine tool calls and less than five cents.

One binary, several fronts

The program is compiled as a single static binary with no dynamic dependencies, built for the two common processor families across the three desktop platforms. That one artifact backs every way of using it: the terminal itself, a desktop application, and an editor extension that speaks an open agent protocol so the same engine sits inside an editor window.

All of those fronts share one engine, so session lifetime, permission gates, checkpoints, undo and the plugin layer live in one place instead of being reimplemented four times. That avoids the familiar split where the desktop version can do something the command line cannot.

Configuration follows the same principle: no model choice is hard-coded. Providers, agents, tools and plugins are all declared in a single text file. The vendor's own models come with presets for a heavier and a lighter variant, and any compatible endpoint can be added with one short block, including models running on your own machine. Keys are referenced from environment variables rather than pasted into the file, which keeps the configuration safe to commit.

Plugins follow the same no-hard-coding rule. An external tool server can be attached with a short block of configuration, and the built-in sub-agents for exploration, research, review and security review each work in isolation, running in parallel or nested inside one another.

Who should look at it

The project is open source under a permissive licence, began in the spring of 2026 and releases almost daily; a large community has formed around it in a few months. Its argument is narrow but honest: it does not claim to be a faster agent, it claims to make one particular model genuinely cheap to use for hours at a time, while keeping every step visible and reversible. If that model is already part of your working day, an afternoon with this one is worth spending.