Every measurement re-run on Claude Code 2.1.224: two were identical to the token
Eleven published figures, re-measured against a newer version. Nine unchanged, two moved, and the two that moved are exactly the ones the methodology predicted would.
Re-verified 2026-08-13 against Claude Code 2.1.231. The startup floor moved, slightly, and the mechanism did not.
Re-measured with the published method, five rounds, every cell twice per round: the floor is 22,404 tokens with tool search on against 22,340 on 2.1.229, and 40,209 with it off against 40,144. Both arms rose about 64 tokens, and the tool-search delta held at 17,805 against 17,804. A slightly larger base system prompt, not a changed mechanism. The /cost/ calculator has been updated to the new figures and its version stamp moved with them.
Two things worth recording from the re-run. The minimum is the wrong estimator here. modelUsage on a trivial isolated call is bimodal, 22,404 in nine repetitions out of ten and 21,883 in the tenth, because a 521-token Haiku call fires most times but not every time. Taking the minimum publishes the rare run as the floor, so this corpus reports the mode with its count. Anyone measuring a floor from a single run has roughly a one-in-ten chance of landing 521 tokens low.
And the gate that should have caught the staleness could not. It compared the calculator’s constant against a corpus filename that was hardcoded to 2.1.229, so it proved internal consistency while being structurally blind to the corpus having been measured on a version nobody was running. It printed ok on every deploy as the figures aged. It now derives the corpus path from the calculator’s own version stamp and fails when the installed claude --version differs from it. The runs are in baseline-floor-2-1-231.json.
Re-verified 2026-08-11 against Claude Code 2.1.227. Two load-bearing figures were re-measured.
Batching tool calls, the largest claim on this site, holds. Across two rounds, three 8KB files read in one batch cost 128,762 tokens both times; the same three read one at a time cost 257,486 and 257,489, a 2.0x penalty against the 1.97x published on 2.1.224. Both arms carried an arrival control, a marker placed past the end of each file that the reply had to quote back, and it passed 3 of 3 in every arm of both rounds.
The CLAUDE.md versus skill mechanism holds decisively. Measured with the floor and the configured arm in the same round, four rounds, the same 28,000 bytes cost +7,617 tokens as a CLAUDE.md (three rounds of four; the fourth is explained below) and +7 tokens as a skill body (four of four). The exact byte-rate is not comparable across these two runs, because the filler text differs and token density depends on content, so this re-verifies the mechanism and the order of magnitude rather than the precise number. What that does to the published multiplier is set out here.
The drift did something more instructive than “the baseline wandered”. Partway through the run the whole session baseline stepped down by 289 tokens at once, and both arms moved with it: the CLAUDE.md floor went 59,330 to 59,041 while its configured measurement went 66,947 to 66,658, and the skill arm stepped by the same 289. Three rounds caught both of their calls on the same side of that step and produced +7,617. One round caught the step between the two calls of its pair, taking its floor before and its configured value after, and produced +7,328, short by exactly 289.
That is the sharper version of a rule this site already follows. Same-round pairing does not merely shrink drift error, it eliminates it whenever both calls land on the same side of a step, and fails completely when the step lands inside the pair. Across all eight floor measurements the observed spread was 291 tokens, which is the documented ~290 noise floor showing up as a single discrete step rather than as continuous wander.
Every round is published at reverify-2-1-227.json.
Every finding on this site is pinned to a Claude Code version, which makes version decay the obvious weakness: a measurement is only as good as its expiry date. 2.1.223 became 2.1.224, so the honest thing was to re-run everything rather than let the numbers quietly rot.
Eleven published figures. Nine unchanged, two moved.
What held
| Claim | 2.1.223 | 2.1.224 |
|---|---|---|
| 200 MCP tools, tool search on | +3,054 | +3,054 |
| 200 MCP tools, tool search off | +60,854 | +60,854 |
| 1 skill, 200-byte body | +5 | +5 |
| 1 skill, 28,000-byte body | +5 | +5 |
PostToolUse carries tool_response, not tool_output |
yes | yes |
SessionEnd carries reason, not end_reason |
yes | yes |
InstructionsLoaded carries load_reason, not reason |
yes | yes |
Stop carries stop_hook_active, background_tasks, session_crons |
yes | yes |
MessageDisplay carries delta, no message_text |
yes | yes |
The two MCP figures are the striking ones. Not close, not within noise: identical to the token across a version bump, both the deferred cost and the loaded cost, each reproduced twice.
What moved
| Claim | 2.1.223 | 2.1.224 | Change |
|---|---|---|---|
| 1,000 skills | +1,474 | +1,461 | −13 (0.9%) |
| Turning off tool search, zero MCP servers | +17,214 | +17,795 | +581 (3.4%) |
Neither overturns anything. A thousand skills still costs about 2.5% of a session, and disabling tool search still costs five figures before you connect a single server.
The interesting part is which two moved
The absolute baselines drifted between versions:
| Baseline, empty project | 2.1.223 | 2.1.224 |
|---|---|---|
| tool search on, no MCP | 57,758 | 58,130 |
| tool search off, no MCP | 74,972 | 75,925 |
So the system prompt grew by a few hundred tokens. Fine, and expected.
Now look at what that does to the two kinds of number this site publishes.
A paired delta measures a baseline and a configuration back to back and subtracts. Baseline drift cancels out entirely, which is why 200 MCP tools cost +3,054 in both versions despite the baseline moving 372 tokens underneath it.
A baseline-to-baseline comparison has nothing to cancel. The tool-search-off penalty is the gap between two baselines, so both endpoints moving means the figure moves. It went up 581 tokens because that is what it is made of.
That is not a flaw in the finding, it is what the finding is. But it does mean the two number types age differently, and it is worth knowing which kind you are reading:
- Paired deltas are durable. They survived a version bump unchanged, twice, to the token.
- Baseline-derived figures are perishable. They move whenever the system prompt does.
The skills measurement argued for paired baselines after a drifting anchor produced a nonsense negative result. This is the same argument from the other direction: the methodology predicted which numbers would survive a version change, and it was right about all eleven.
Re-verified 2026-08-12 against 2.1.228
Version moved again, so the load-bearing figures were re-measured on the same method: every arm against its own floor in the same round, no isolation, because these are paired deltas where the user-level CLAUDE.md cancels.
Batching holds exactly. Four rounds, every one at 2.0x, arrival control 3/3 in both arms of all four: 127,430 to 127,988 batched against 254,807 to 255,949 sequential. On 2.1.227 it was 128,762 against 257,486.
The CLAUDE.md versus skill mechanism holds. The same 28,000 bytes cost +8,137 tokens in CLAUDE.md and +5 as a skill body, across three scored rounds. On 2.1.227 it was +7,617 and +7. The filler text differs from the original measurement, so the numerators are not strictly comparable; the mechanism and order of magnitude are what re-verifies.
The ratio moved again, and that is the point. 1,845x on 2.1.224, 1,088x on 2.1.227, about 1,620x here. The gap held steady every time while the ratio swung by 70%, because the denominator is five to seven tokens. This is the third independent measurement confirming that the headline ratio is fragile and the gap is not — which is why the ranked list on the front page leads with the gap.
A fourth round was thrown away rather than reported. Its skill arm came back at -284 tokens, a negative cost for adding a file. That is the drift-straddle case: a ~5-token signal against ~290 tokens of baseline drift only measures cleanly when the drift step does not fall between the pair’s two calls. The harness now marks such a round unscored instead of dividing by it, because the ratio it first produced was -28.1.
The configured subagent figure holds. 92,468 tokens per parallel subagent against the published 92,304, 0.2% apart, with both cells reproducing within 0.3%. The isolated figure from that same post did not re-verify cleanly, and the reason turned out to be worth its own measurement: the fan-out has two execution modes.
Every round is published in reverify-2-1-228.json.
Why bother publishing a re-run
Because a measurement with no expiry check is a claim, not a measurement. Every figure here names the version it was taken against, and that promise is worthless if nobody ever goes back and looks.
Nine of eleven held. Two moved slightly and have been corrected in place on their original posts with a dated note. Nothing needed retracting.
Re-measured against Claude Code 2.1.224, headless mode, usage from --output-format json, every figure paired against a baseline captured in the same batch and reproduced across two runs.
Clarified 2026-08-08. The baseline figures in this post were measured on a machine with a large user-level CLAUDE.md, which loads into every session. That file was separately measured at 26,763 tokens, so Claude Code’s own floor is closer to 31,400 with tool search on. Every delta in this post is unaffected, because each was measured as a paired before-and-after on the same machine and the global config cancels out. Only the absolute baseline numbers are specific to that setup. The calculator now takes user-level config as a separate input.
Corrected again 2026-08-13. The ~31,400 floor quoted just above was itself too high. It was the loaded measurement minus that one file, which left this machine’s user-level skills, MCP servers and plugins sitting inside the supposed floor. Measured directly on 2.1.229, in an empty directory with --setting-sources project so nothing user-level loads at all, Claude Code’s own floor is 22,340 tokens with tool search on and 40,144 with it off, twice per round across four rounds with 0 to 4 tokens of noise. The deltas in this post remain unaffected, and that is now measured rather than asserted: the tool-search gap came back at 17,804 against the 17,795 the old pair implied, 0.06% apart. See the calculator for the full decomposition.
Re-verified 2026-08-09 against Claude Code 2.1.226. Two further releases on, the load-bearing figures were re-measured and every one holds. Per-model startup floors reproduced within run-to-run drift (Sonnet 5 at 70,031 identical to the token across both versions, Opus 5 at 58,747, Haiku 4.5 at 45,955). The image figures hold: a 1568x1568 image measured +3,135 and a 3840x2160 one +2,989, against +3,135 and +2,994 on 2.1.224. The tool round trip holds at +58,900 for a six-byte read against +58,851. The cross-model tokenization ratio holds at 0.75 Haiku-to-Opus against 0.74. Nothing needed correcting.
One line of this superseded 2026-08-14. The 1,000-skill row reproducing at +1,461 was real, but both it and the original were measured without the isolation flag, on a machine whose own configuration was loaded. That condition is worth about 10x on the price of a skill: measured in isolation on 2.1.231, a thousand skills cost 11,711 tokens rather than 1,461. Reproducing a number across two versions establishes that the machine had not changed, not that the number generalises, which is the lesson worth taking from this whole post. The MCP rows are affected differently: deferred still holds, loaded now measures 652 tokens per tool rather than 304. See the same forty skills cost 1,558 tokens, or 152.