DeepSeek Harness: When an Agent’s History Becomes Part of Inference Economics (#AI4SDLC)

I watched Cloud Codes’ breakdown of DeepSeek Harness. It is a useful continuation of my longread on the co-evolution of the AI development stack: it shows how inference economics changes the architecture of an agent’s history.

DeepSeek Harness has one simple rule: once the model has seen something, the corresponding journal entry is never rewritten. A session is not a mutable array of messages but an append-only journal of typed events. Everything visible to the model must be recorded there or in a linked object. A fresh session instance can reconstruct a request byte for byte and compare it with the live loop’s request. This makes the formula Agent = Model + Harness more concrete: the harness is responsible not only for tools and prompts, but also for the provable provenance of context.

Why be so strict? At every step, the model API receives the history again, while the prefix cache saves compute only when the beginning of the request matches. The video’s author derives a 120× saving from the API pricing table available at the time of recording. But on August 18, 2026, V4 Pro pricing listed $0,022 versus $0,66 off-peak and $0,044 versus $1,32 at peak—a 30× difference. That does not make the whole session 30-fold cheaper: the factor applies only to input tokens and excludes output, tools, and infrastructure. The architectural incentive is still strong.

The neatest example is compaction The old summarizer began its request with a new system prompt, breaking the warmed prefix exactly when the history was longest. The fix is almost comical: replay the previous system prompt, tools, and messages byte for byte, then append the “compress this conversation” instruction as the final user message. Even unused tool schemas remain in place to keep token alignment stable.

The authors correctly separate correctness from savings. A cache hit is best effort: the model, route, request header, or compaction range may differ. The journal remains the source of truth, while an independent invariant rebuilds the request and prevents the live session’s cache from validating itself. This echoes my review of Loop Engineering: the strongest part of a loop is a mechanism that can prove the system did not lose state or cross a boundary.

The repository also contains hundreds of Agent Notes with implemented, archived, proposed, and rejected statuses, plus a mandatory alternatives-considered section. Code shows what was done; a note explains why the other options were rejected. It is almost a literal implementation of my post about PRDs, ADRs, and BDD for humans and AI.

The stack’s co-evolution is even clearer in the minimal preset. The repository explicitly describes it as an RL-agent composition:

• a fixed, short prompt
• persistent bash and str\_replace\_editor reproduce the training environment The resulting loop is harness → траектории → post-training → тот же harness. But the open-source code does not prove that user sessions are used for training; it demonstrates an architectural possibility, not an actual data policy.

I would therefore refine the video’s closing claim. The product is not the harness alone, but an evolving combination of model + serving + harness + tools + traces. For an ordinary company, the conclusion is unchanged: there is no need to build yet another generic agent loop. It is more useful to separate the stack into layers and retain ownership of reproducible episodes, outcome evals, tool contracts, identity, and access policies.

In practical terms, I would take four checks from DeepSeek Harness:

• Can every request be reconstructed from a durable journal?
• Does compaction preserve both the meaning of the history and a stable prefix?
• Is there an independent invariant that does not trust the live loop?
• Do we measure the cost of a useful result, rather than only the cache hit?

DeepSeek Harness is still a developer preview: the repository warns about future breaking changes. The video offers no neutral quality benchmark. I would therefore postpone a rating, but study the architecture closely.

#AI4SDLC #AI #Agents #Architecture #DevTools #Evals #Engineering