DeepSeek Prefix Caching for Coding Agents

DeepSeek prefix caching changes the economics of a long coding session when the agent can send the provider the same prompt prefix, byte for byte, on each turn. Reasonix is a terminal-native coding agent built around that constraint. Its loop is append-only, its history is designed to remain byte-stable, and its documentation reports cache-hit rates above 90% in long sessions, with cached input billed at about one fifth of the usual input-token rate.

That is a specific architectural choice. How does DeepSeek prefix caching reduce coding-agent cost, and what has to stay true for the saving to hold?

What is DeepSeek prefix caching in a coding agent?

A coding agent repeatedly sends a model a large working prompt. That prompt can include the system instructions, tool definitions, repository map, prior conversation, tool results, task list, and the user’s next request. In an ordinary loop, each new turn includes much of the same growing context again.

Reasonix describes the expensive version plainly: agents can pay full price for the same growing prompt on every turn. Its alternative is to replay the identical prefix and add only the new material at the end. The provider can reuse the computation associated with that already-seen prefix, while the model computes the new request.

The shape of a cache-friendly session looks like this:

Turn 1
[system instructions][tools][repository map][task][tool output]

Turn 2
[system instructions][tools][repository map][task][tool output]
[assistant response][new tool output][next request]

Turn 3
[system instructions][tools][repository map][task][tool output]
[assistant response][new tool output][next request]
[assistant response][new tool output][next request]

The earlier text must remain the same at the byte level. A prompt that is semantically similar but reordered, reformatted, truncated, or regenerated may no longer share the cacheable prefix Reasonix is trying to preserve.

The documentation calls this an append-only history aligned to DeepSeek’s byte-stable prefix cache. In the project’s model, the session gets a cold start first, then later turns replay the previous context from cache and compute only newly appended tokens. Its example terminal session reports a cache rate increasing from 94.2% to 95.1% over an 18-minute session.

Why long coding sessions make the cache valuable

A coding task is unusually good at accumulating repeated context. The agent needs to remember the request, inspect files, make edits, run tests, read failures, and decide what to do next. A repository map and tool schema may be useful for every step. The conversation history also becomes relevant when a test failure is caused by a decision made several turns earlier.

That usefulness creates a cost problem. If a fresh request carries the whole history at the normal input rate every time, the cost grows with the context. Reasonix’s approach keeps the history available while seeking a lower rate for the repeated part.

The project’s stated target is 90% or higher cache hits during long sessions. At that point, the majority of input tokens are replayed from the cached prefix rather than newly computed. Its documentation says cached input tokens cost roughly one fifth of the normal input-token price.

This does not mean the total request costs one fifth as much. A real turn still includes uncached material:

In practice, the input side of a long session can become materially cheaper when most of the working context remains stable. The output side, and every newly appended tool result, still consume fresh model work.

What must stay byte-stable for the cache to work?

“Byte-stable” is stricter than “same information.” The coding agent must avoid changing earlier content in a way that changes the request prefix.

That requirement affects the loop design: a cache-first loop should append a new event instead of rewriting the old transcript, avoid regenerating a repository map each turn, keep tool definitions in a stable order, and resist compacting or summarizing earlier context in place if doing so changes the prompt's initial bytes.

Reasonix says it maps the codebase once and keeps that map in the warm prefix. A repository map can be expensive context to resend repeatedly, yet it is also a candidate for cache reuse if it remains unchanged.

Codebases are not static, though. An agent editing files is changing the repository while the session continues. A cache-first design therefore needs to treat the original map as historical context and append updates, diffs, tool output, or refreshed observations after it. Replacing the old map inside the prompt would disturb the cached prefix.

This gives the agent competing concerns:

• It needs stable history to preserve the cache.
• It needs current information to avoid reasoning from stale code.
• It needs a controlled way to append current observations without rewriting the history.

Reasonix’s append-only design directly addresses the first concern. The user still has to judge whether the agent’s current context is accurate enough for the task. Cache efficiency does not validate the code, the plan, or the test result.

How Reasonix exposes the cache-first loop

Reasonix provides a CLI and TUI, a desktop app, and a local browser UI using what it describes as the same local engine. The terminal install shown in its documentation is:

npm i -g reasonix

The project also documents a Homebrew installation path and says its version 1.1.0 implementation is a single CGO-free Go binary cross-compiled for macOS, Linux, and Windows across amd64 and arm64. It presents that binary approach as removing the need to install or maintain a Node runtime.

The local browser interface is started with:

reasonix serve

Its documentation recommends token or password authentication before exposing a tunnel or remote port, and gives this example:

reasonix serve --auth token

That advice matters because a local coding-agent UI can carry repository context, task history, approvals, and potentially tool access. A local browser UI is only local in where it starts, so it still warrants authentication before any exposure.

The agent also includes a session display with cache percentage, duration, selected model, and cost. In the sample, Reasonix edits two Go files, runs go test ./internal/net/, and displays a cache rate of 95.1%. A visible cache metric is useful because the claimed benefit depends on a property that can otherwise be hard to inspect. If the rate falls after an agent or workflow change, that is a concrete signal that the stable prefix is no longer stable.

How plan mode and sandboxing fit a long-running loop

Long sessions change the cost profile, but they also lengthen the period in which an agent can make edits. Reasonix includes a plan mode and sandboxing features alongside its cache-first loop.

According to the project documentation, /plan holds the session read-only until approval. Its writers are constrained to the workspace. Those are separate controls with different purposes:

A read-only planning stage can preserve a clear separation between inspection and file modification, and a workspace constraint narrows where writes can go. Neither control makes a proposed change correct. The model can still misunderstand a requirement, select the wrong files, or produce a plausible patch that needs review.

For a long task, the useful operating rhythm is to keep the agent reading and planning until there is a bounded change to approve, then inspect the diff and test output after it writes. Reasonix’s own workflow language points in this direction: queue tasks, review diffs, and resume sessions.

Does MCP work with a cache-first DeepSeek agent?

Reasonix lists MCP as a first-class feature and supports stdio, SSE, and streamable HTTP transports. It says external servers merge their tools into a single registry under a prefix.

That design can be useful when the agent needs external tools, but it also interacts directly with the cache strategy. Tool definitions are part of the repeated context. If the same servers and definitions load in a stable order, they are candidates for inclusion in the cached prefix. If tools appear, disappear, reorder, or change their schemas during a session, the request prefix can change and cache reuse can suffer.

The project’s tool registry prefixing also addresses a practical collision problem. Multiple external servers can expose tools with similar names. A prefixed registry gives the agent a stable namespace and makes it easier to identify which server owns a tool. The source does not describe the exact prefix format, so it is safer to treat the behavior as a namespacing mechanism rather than assume a command syntax.

MCP is therefore compatible with the cache-first approach, subject to the same prompt-discipline rule: load what the task needs, keep its definitions stable for the session, and expect changes in the tool layer to affect the cache.

When should you use a cache-first agent loop?

Reasonix is best aligned with a task that has continuity: a repository to inspect, a sequence of edits to make, test feedback to interpret, and follow-up work that benefits from preserving the prior context. Its documentation explicitly frames the product around long, inexpensive sessions and recommends leaving a session running so tasks can be queued, diffs reviewed, and work resumed.

It is less compelling when every request is isolated or when the agent must continually reconstruct its context from changing material. A short, one-off request has less repeated prefix to reuse. A workflow that rewrites the prompt or refreshes all repository context on each turn undermines the core cache assumption.

Measure more than the headline cache percentage: watch whether the agent preserves the context needed to make correct decisions, whether its current view of edited files remains accurate, and whether the cached input share stays high as the task evolves. Reasonix makes a clear technical bet: a coding agent can retain long-lived context without repeatedly paying the full input price, provided its loop is designed around the provider’s cache boundary.