Halving the output saved 6.8% of the bill

The token-saving guides are specific: write an output style with “no preamble, no trailing summary”, cap CLAUDE_CODE_MAX_OUTPUT_TOKENS, and “reported savings vary from 40% to 70% on focused tasks”.

So I gave a three-turn session a terseness rule of exactly that kind and measured what it bought.

Three-turn session, median of 30 runs	Default	Terse
Reply length	4,733 chars	1,969 chars
Output tokens	1,821	842
Cost	$0.4489	$0.4184

The instruction worked. It cut the output by 54% and the replies by more than half, and every terse run produced fewer output tokens than every default run.

It saved 6.8%.

Why the ceiling is a tenth, not 70%

Output is 1.45% of the billed tokens here. That alone makes the advice sound absurd, and it would be the wrong reading, because output does not bill like input.

It bills at $25 per million tokens against a blended input-side rate of $3.32, which is 7.5x. The input side is cheap because most of it is cache reads at $0.50, not fresh input at $5, so quoting output as “5x the input rate” understates it against the bill you actually get.

None of those rates is quoted at you from a price page. Applying them to each Opus usage record reproduces the cost Claude Code itself reports, to the cent, across all 60 of them, published as cost_model_reconciliation.

So 1.45% of the tokens is 10.2% of the cost, seven times its token weight:

Default arm	Share of tokens	Share of cost
Output	1.45%	10.2%
Everything else	98.55%	89.8%

A tenth of the bill is roughly the whole budget a verbosity lever has to work with, and collecting all of it would mean emitting no output at all.

Roughly, rather than exactly. Of the saving, 80% is the output tokens themselves and 20% is cache creation: the extra words are written into the conversation and re-cached. So the lever reaches slightly past the output line, which is why halving the output collected 67% of the output budget rather than 54% of it.

That tail is concentrated, and it replicates. Taking the per-turn difference in cache creation as a median in each batch, the third turn carries +525, +638 and +631 tokens across the three batches, the second is near flat at +12, +14 and +5, and the first runs slightly negative every time, -67, -59 and -59. The extra words only cost you once the turn after them re-reads the conversation.

Both of the things people say about verbosity are true at once, which is how the advice survives. It is a rounding error in tokens. It is seven times its token weight in money. Neither of those is 40%.

The arms do not overlap, and it replicated three times

Thirty runs, three independent batches of ten, no exclusions.

	Default	Terse
Output tokens, range	1,528 to 3,126	708 to 1,058
Cost, range	$0.4388 to $0.5964	$0.4138 to $0.4249

The worst terse run beat the best default run on both. The three batches gave cost savings of 6.2%, 6.9% and 8.2%, all on the same median basis as every figure here.

The control that failed in the more dangerous direction

Every turn had to echo a planted marker, so a terse arm that quietly did less work would void rather than look cheap.

The first version of that check matched the marker against reply[:600]. The marker is asked for at the end of each turn, so it routinely sat past the cutoff.

Replayed against the full replies this corpus publishes, that old matcher passes only 9 of 30 turns: 4 of 15 in the default arm and 5 of 15 in the terse arm. It voids most of both, which is what made it catchable rather than silent. The asymmetry is real but confined to the first turn.

The distinction is worth keeping even though the effect was small. A control that fails evenly destroys a measurement, which is loud. A control that fails unevenly manufactures one, which is silent. This one leaned the second way.

Fixed to match the full reply, and control-tested on a synthetic pair before any scored run, published as marker_matcher_control:

                    case  old(600-char)  new(full)  expected
verbose reply, marker late          False       True      True
terse reply, marker early           True       True      True

Batch 3 publishes the full reply text, the marker and its index for every turn, so the 30-of-30 arrival result can be recomputed from the file rather than taken on trust. Batches 1 and 2 shipped only a 600-character excerpt and did not store the marker, so their arrival verdict is recorded but not independently reproducible; their field is named reply_excerpt_600 to say exactly that. Publishing the evidence for a truncation bug truncated at the length that caused it is the reason batch 3 exists.

What this does not settle

One task shape. One ~40KB document, three turns of summary and discussion. The output share of a bill depends on the task, and a session that writes a lot of code produces far more output against similar input. Not measured here, and no direction claimed for it.

Quality is not measured. The marker came back 30 times out of 30, which proves the work happened, not that the terse summaries are as good as the long ones. A cheaper answer that is worse is not a saving, and this corpus cannot tell you which you got.

One mechanism of several. The advice names output styles, system-prompt rules and CLAUDE_CODE_MAX_OUTPUT_TOKENS. This tests a system-prompt terseness rule. The others are untested here.

The treatment changes the cached prefix, necessarily, since it adds to the system prompt. Input-side medians are 123,742 tokens against 123,294, a 0.36% difference.

Controls

Arrival, 30 of 30, on all three turns, matched against the full reply as an exact string, and recomputable from the published text on batch 3.

The treatment is shown working, not assumed: reply characters and output tokens are published per run, so an inert flag would be visible.

No exclusions. Every run is scored.

Three batches, run independently, each reported above.

Isolation on every call, --setting-sources project, asserted onto the command line. Arms alternate order by round. Totals from modelUsage.

All 30 runs, the exact terseness text and the three turn prompts are published in verbosity.json.