Someone reverse-engineered Claude Code and published the whole harness as a readable book. It shipped as source maps on npm, and Claude Code from Source walks through nearly two thousand extracted files. The punchline I keep coming back to: there are about ten architectural decisions in there that move agent scores, and none of them show up in any benchmark scorecard.
A portable harness no longer has to be a black box
The book isn't a white paper and it isn't vendor marketing. The source maps that went out with the npm package contained a sourcesContent field with the full original TypeScript, so the authors read every one of the roughly two thousand files and distilled the architecture into 18 chapters. That's a real, citable artifact about how the most widely used coding agent is put together, from someone with no reason to flatter Anthropic.
The ten "patterns that make it work" section is the most useful single page in the whole thing. Each one is a harness decision that does real work:
- The agent loop is an async generator, which gives natural backpressure and cancellation instead of a fragile state machine.
- Speculative tool execution starts read-only tools while the model is still streaming, because you already know it's going to grep.
- Concurrent-safe batching runs reads in parallel and serializes writes.
- Fork agents share byte-identical prompt cache prefixes, so spawning parallel children saves roughly 95% of input tokens.
- Context compression runs across four layers, each lighter than the last.
- File-based memory uses an LLM side-query for recall rather than keyword matching.
- Skills load in two phases: frontmatter only at startup, full content on invocation.
- Slot reservation caps output at 8K by default and escalates to 64K only on a hit, saving context in ~99% of requests.
- Hook config gets snapshotted at startup so a runtime change can't rewrite the permission system mid-session.
That list doesn't read like "we tuned the prompt." It's a harness. And it's the concrete object behind the argument I've been making on this beat: a coding-agent score is model plus harness, not model alone. I made the same point about benchmark scaffolds in two Codex CLI models on the same benchmark. This book lets me name the same idea in a shipped product instead of an eval harness.
Where the harness decides the score
Every one of those patterns changes what a benchmark measures. Context compression decides how long working history survives a long task. Slot reservation decides whether a long generation fits in the budget. Speculative execution and parallel tool batching decide how much the agent can do per token. Prompt cache sharing decides how cheap it is to fan out sub-agents. A scored agent is built on all of those, and a benchmark that reports a single number reports the whole stack as if it were the model.
The literature keeps confirming this, and the cleanest single source is Harness-Bench, a diagnostic benchmark built specifically to isolate configuration-level harness effects across models in realistic agent workflows. It found that the harness can move a score more than reasoning effort does. Put the same model behind a harness that skips speculative execution or lazy skills and it does less in the same budget. The model didn't change. The score did.
This matters the moment you try to act on a scorecard. Pick a tool, a model, a prompt template, and you've also picked a harness. Report "we get X% on SWE-2" and you've collapsed model, scaffold, context handling and tool loop into one digit that hides all of them.
The harness is the part that doesn't port
The cleanest proof that the harness is doing real work: it's the only thing you can't carry to another agent. Someone is building exactly that portability layer. txcript is a Rust engine that translates a full session, tool history included, between Claude Code, Codex, OpenCode, Cursor and a dozen more agents. It launched on Hacker News as the open-source core of Skillsync, and its name is a tell: pandoc for AI chats.
The README is upfront about what transfers and what doesn't. The common transcript model carries conversation history, reasoning, tool calls and results, images, metadata and token usage. What does not carry over is the systems and tools: "the destination supplies its own system instructions and tools, and project files must be available separately." That is the harness. It lives in the agent's own storage formats, it is not portable, and it is precisely the part that changes agent behavior in benchmarks.
So when you compare two agents on a benchmark, or hand a team's working set-up to a different tool, you are not comparing models. You're comparing loosely-coupled, non-portable harnesses that happen to contain a model. That's a harder truth to make a decision with than "model A beats model B," which is exactly why vendors keep selling the one-digit version.
Who reviewed the documentation of the docs
One more detail worth a beat, because it's squarely on my beat's recurring trap. The book itself was written by 36 AI agents in about six hours, in four phases: six exploration agents read files, twelve wrote 494KB of raw technical documentation, fifteen rewrote it as narrative chapters, then three reviewers produced 900 lines of feedback that three fixer agents applied. A final audit ensured no verbatim source code remained.
That's a documented toolchain and a genuine dogfood story. But it also lands right on the thing I test for: when the same class of model both writes and reviews, you get a single opinion measured many times, not independent checks. Correlated judges aren't consensus, and a review pass by three more instances of the same model isn't three independent verifications. The result can be excellent, and this one appears to be. The method is just worth naming so nobody mistakes the pipeline for a guarantee.
What I'd actually do with this
As an operator, here's the move: before you trust any agent benchmark, ask where the harness disappears. This book gives you a concrete list of harness decisions in one real product, so you can hold a vendor's scorecard up against it and ask which of these patterns are in the harness they measured, and which are in yours. Can you name the tool loop? The context compression? The cache sharing? The memory recall? If you can't, the number is a vibe, not a measurement.
The useful output of reverse-engineering a harness isn't to copy Anthropic's internals. It's to make the harness a named, checkable variable in every agent evaluation you run, so that the next time someone hands you a one-digit score you can ask a question about the machinery instead of nodding.
Top comments (0)