3 min read

DeepSeek Reasonix and the Economics of the Agent Prompt Loop

Why 'native' KV-cache design in a coding agent makes context ordering a first-class engineering constraint, not an afterthought.

The cost hiding inside every agent turn

Every turn of a coding agent session re-sends some version of the same material: a system prompt, a block of repo context, then the conversation history to date. If the model charges full input-token price on each uncached call, that overhead is paid on every single turn. Sessions run long. The bills add up faster than the diff output does.

What the KV cache is and why it breaks

Most LLM APIs maintain a KV cache: the model’s running record of attention computations for tokens it has already processed. When your request begins with a prefix that matches what’s already cached, the model skips recomputing those tokens and charges a reduced read price. Conceptually it’s similar to a function memoizing its intermediate results — but only when the inputs are identical from the start.

The cache is prefix-sensitive. The moment any token near the start of your prompt changes — a freshly formatted timestamp, a shuffled list of retrieved file paths, a dynamic instruction injected into the system prompt — the cache invalidates from that position forward. Every token after that point is recomputed at full cost. You’re back to paying as if the session just started.

What DeepSeek released

On May 24, 2026, DeepSeek released Reasonix, described as a “native coding agent” built around its KV cache architecture. It’s worth separating the product layers: V4 Pro is DeepSeek’s underlying model SKU (its price discount was made permanent around the same time); Reasonix is an agent product built on top of it, co-designed with the model’s caching behavior as a first-class constraint. The project page at esengine.github.io/DeepSeek-Reasonix is light on benchmark numbers, so this piece works from the architectural framing rather than specific figures.

How the mechanism works

Prefix caching works only when the beginning of a prompt stays byte-identical across calls. Based on DeepSeek’s framing, “native” agent design means the scaffolding is built so the stable prefix — system prompt plus repo context — is frozen and placed first, with each new conversation turn appended at the tail.

Non-native agents often reconstruct the full prompt each turn in ways that shift the prefix. A common example: injecting the current timestamp or a dynamically sampled few-shot example into the system prompt, then concatenating history beneath it. The prefix shifts, the cache misses, and you pay for full recomputation.

A note before the snippet: DeepSeek model slugs change on new releases — verify the correct slug at platform.deepseek.com before use. The pattern below uses deepseek-reasoner as a placeholder consistent with Reasonix's reasoner framing, but treat it as illustrative.

 # Pattern: freeze the stable prefix; append new turns at the tail.
 import openai

 client = openai.OpenAI(
     api_key="YOUR_DEEPSEEK_KEY",
     base_url="https://api.deepseek.com/v1",
 )

 SYSTEM_PREFIX = "You are a coding agent.\n\nRepo context:\n" + load_repo_context()

 def agent_turn(history: list[dict], user_msg: str) -> str:
     messages = [{"role": "system", "content": SYSTEM_PREFIX}] + history
     messages.append({"role": "user", "content": user_msg})
     resp = client.chat.completions.create(
         model="deepseek-reasoner",  # verify current slug at platform.deepseek.com
         messages=messages,
     )
     return resp.choices[0].message.content

SYSTEM_PREFIX is computed once and never mutated across the session. History is appended at the tail. The cached region grows as wide as possible.

What this changes — and what it gives up

Once the prefix is cached, you pay only for the net-new tokens on each turn. The per-turn cost curve flattens as sessions grow longer relative to the stable prefix, which is exactly the shape you want for a long coding session with a large, static repo context.

The tradeoff is prompt rigidity. You cannot inject per-turn context near the top of the prompt — no live timestamps, no dynamic persona injection, no reordered retrieval results — without triggering a cache miss. Dynamic prompting and cache efficiency are in direct tension. Reasonix’s architectural bet is that for coding agents specifically, the system prompt and repo context are stable enough turn-to-turn that this constraint pays off.

How you order context inside an agent prompt is now an economic decision with a measurable cost function — not a style choice.

Source: https://esengine.github.io/DeepSeek-Reasonix/