All 120 runs passed. We read the transcripts anyway.
A pre-registered move-by-move reanalysis of our 120 public agent runs: the task dictates the opening move, the model-harness pairing dictates everything after it, and exactly one run hired subagents.
Last updated
Last week we published 120 graded agent runs in which every configuration passed every task. One habit still sorts the field cleanly: GPT-5.6 Sol re-read a file it had already opened in 24 of its 24 Claude Code runs. Claude Fable 5 did that in 0 of 24. Kimi K3, 0 of 24. Identical scores, categorically different transcripts. So this week’s experiment spent no new API dollars at all: we pre-registered seven falsifiable hypotheses about what the models actually do move by move, pushed the design, then ran one parser over all 120 public transcripts. Timely, as it happens: the week’s benchmark story is OpenAI auditing Scale AI’s SWE-bench Pro, flagging roughly 30% of its tasks as broken, and retracting its own recommendation to use it. When the number on the leaderboard is noise, the transcript is what’s left.
Four of seven hypotheses hit. The misses first. We predicted 80% of Claude Code runs would open with a shell command rather than a file read; the real rate is 61%, because the opening move turns out to belong to the task, not the model (more below). We predicted Sol would lead with task-list creation in at least 20 of its 24 Claude Code runs; it did so in 15, so that hypothesis is booked as a miss even though its second half (no planning calls at all under Codex) held exactly. And one hypothesis was malformed: we predicted Fable would reach its first edit faster than Sol on at least 7 of 8 tasks, but only four tasks have a tool-based edit to time at all (the other four end in a written report). Of the four, three favored Fable (12s vs 41s to first edit on the bug fix, 13s vs 46s on the refactor) and the synthesis task went to Sol, 18s vs 22s. Two honesty notes with the scorecard: the hypotheses grew out of a disclosed look at 18 of the 120 runs before the design was pushed, so the confirmation lives in the 102 runs and two harnesses we hadn’t read. And since all 120 runs passed, nothing below is evidence any style is better. This is a field guide, not a ranking.
The task picks the opening move
Every model opened the two repair tasks (failing test suite, broken build) by running a shell command, 9 runs out of 9 apiece. Every model opened the synthesis task (implement five functions from docstrings) by reading the spec, 9 of 9 apiece. The two review tasks and two report tasks split. That regularity is a post-hoc observation, found when our 80% hypothesis missed, but it holds across three vendors, and it extends further: in all 30 repair runs across all five configurations, the agent ran the failing checker before its first tracked edit, including all 12 runs in the two vendor CLIs we had never read when the design was pushed.
Here is the whole first act of the bug-fix task (lrucache, two planted defects), three models in Claude Code, first runs, trimmed but in order. Illustrative, not confirmatory: this task is one of the two we had already read when the hypotheses were written; the statistics above carry the out-of-sample weight.
claude-fable-5/run-1 (8 calls, 43s)
"I'll look at the repository structure and run the test suite to see what's failing."
Bash find ... *.py Bash pytest -q
Read cache.py Read test_cache.py
"Two bugs found ... `get` never refreshes recency ... `put` evicts even when
it's just updating an existing key. Fixing both:"
Edit cache.py Edit cache.py Bash pytest -q Write SOLUTION.md
gpt-5.6-sol/run-1 (22 calls)
TaskCreate "Run failing test suite"
TaskCreate "Fix lrucache library bugs"
TaskCreate "Verify tests and document fixes"
TaskUpdate #1 in_progress
Bash pytest -q
Read cache.py Read test_cache.py Read cache.py (again)
... Read README.md, __init__.py, Edit, pytest, SOLUTION.md,
then: pytest && git diff --check && git status, rm -rf __pycache__
kimi-k3/run-1 (5 calls)
Bash find ... *.py && pytest -q
Read cache.py
"Two bugs visible: `get` doesn't refresh recency, and `put` evicts even
when updating an existing key."
Edit cache.py Bash pytest -q Write SOLUTION.md
Three diagnoses, word for word the same two bugs, three passes. Kimi’s run never opened the test file; it ran the suite twice and fixed the library from the source alone (its other two runs did read the tests). The task told all three models what to do first. What happened after is where they stop resembling each other.
The pairing picks everything after that
Scope every claim in this section to the pairing, not the model; that framing is the series’ own finding, and this corpus repays it with mechanism.
Sol in Claude Code is the heavy mover: most tool calls on 8 of 8 tasks, 589 calls across the bout against Fable’s 199 and Kimi’s 183, and the only configuration that re-reads files, in every single run. About 32% of its calls are task management (TaskCreate, TaskUpdate and friends), a surface Claude Code offers and Sol alone adopts. On the bug fix above, its three runs spent 80 tool calls where Fable spent 20 and Kimi 17, and closed with an unrequested git diff --check and a __pycache__ cleanup.
The same model under its own Codex CLI, same task, first run, complete transcript: announce plan in prose, pytest -q, one batched command that reads both source and tests via sed, one patch touching cache.py and SOLUTION.md together, pytest -q, done. Four tool events. No task list exists anywhere in its 24 Codex transcripts, because Codex surfaces no such tool. (Instrument honesty: Codex reads files through shell commands, so re-read counts aren’t directly comparable there; what is comparable is that the bookkeeping layer is absent.) The ritual we could have billed to Sol’s character is Sol-in-Claude-Code, a pairing; we published the dollar consequences of that pairing already, $4.46 per pass proxied against $1.25 at home.
Fable and Kimi sit together at the frugal end in Claude Code, and their runs are near-clones of each other at trace level: survey, test, read, edit, retest, document. The visible difference is that Kimi compresses (its survey and first test run share one compound command) and reads a little less. At home under Kimi Code its habits loosened, which we published as the correction to our own working-styles paragraph; the home-game transcript here adds a concrete detail: Kimi’s own CLI environment shipped without pytest, so the model quietly built a .venv, installed it, and carried on to a pass.
The one run that went feral
One run in 120 did something no other run did. On the review task with the transplant prompt, Sol’s second Claude Code run (05-review-transplant/gpt-5.6-sol/run-2) spawned four subagents: one general reviewer, one database-invariant auditor, one pagination auditor, and one reader assigned only the test files and explicitly told not to look at the diff. A blinded panel, invented mid-run. It then pressed them (“Please finish now with only your verified introduced defects”), stopped the stragglers, and turned in a passing review: 51 turns, 829 seconds, 97 tool calls, while its sibling runs took 8. Nothing in the prompt asks for any of this. It is the only delegation in the corpus, and hypothesis eight, whenever we write it, starts there.
What to do with a tied scoreboard
Our graders saw five identical columns of green. The transcripts saw a batcher, two minimalists, a bookkeeper, and one spontaneous middle manager. If you run agents in production, the pass rate you track has the same blind spot ours had, and the fix costs nothing: pull one transcript per model per week and count three things, tool calls, re-reads, and calls that never touch the repository. Those three numbers separated every configuration in this corpus before the first dollar figure did.
All seven hypothesis verdicts, the parser, and per-run records for all 120 runs are in analysis/2026-07-19-mechanism-trace. Fable 5 co-wrote the harness and this note, and Claude Code is its home field; the two configurations that never re-read a file include it, so read the counts with that in mind. Transcript audits like this one are part of the production-readiness work we do on client agent fleets, and this one cost one parser and zero dollars, the least we have ever paid to find out how much a scoreboard was hiding.
Questions this raises
Straight answers.
- Do AI coding agents work differently even when their benchmark scores are identical?
- In our corpus, yes, and the differences are large and stable. Across 120 graded runs that all passed, GPT-5.6 Sol re-read a file it had already opened in 24 of its 24 Claude Code runs; Claude Fable 5 and Kimi K3 did so in 0 of 24 each. In Claude Code, Sol also made the most tool calls on all eight tasks, with roughly a third of its calls going to task-list bookkeeping. None of this moved a grade: every configuration passed everything. The differences show up on the bill and in the transcripts, not on the scoreboard.
- Why does the same model behave differently in different agent harnesses?
- Because part of what looks like model behavior is the harness's affordances. In Claude Code, GPT-5.6 Sol opens tasks by writing a three-item task list and spends about 32% of its tool calls maintaining it; under OpenAI's Codex CLI the transcripts contain no planning tool at all, and the same model finishes the same bug fix in four tool events. We measured the same effect in reverse with Kimi K3, which changed its edit style under its own CLI. Score a cross-vendor benchmark and you have measured the pairing the model ran inside, not the model.
- How do I see what my own coding agent is actually doing?
- Stop at the pass column and you will miss everything we found. Pull a transcript and count tool calls per task, re-reads of the same file, and calls spent on planning surfaces rather than the repository. Our parser and per-run records are public in the agent-arena repo (analysis/2026-07-19-mechanism-trace) if you want a starting point, and all 120 transcripts it reads are in the same repo.
Production-Readiness Audit
The writeup has a service behind it.
If this is your situation, the production-readiness audit is where it gets fixed — by the person who wrote this.