Measure what an agent step costs, so cache and compaction changes can be judged by their effect #56422

Measure what a step costs

The harness has no way to answer "is this change cheaper?" Today the cache policy is checked by asserting that a cache_control marker lands where a test expected one, which proves the marker exists but not that it saves anything.

That gap is measurable rather than theoretical. Against a provider stand-in that counts the tokens of the request it receives and reports a cache read only for a prefix an earlier request already wrote:

• The shipped default policy (tools + system + one tail breakpoint) reaches ~91% reuse over a 20-step conversation, with uncached input staying roughly flat while the conversation grows tenfold.
• Marking more of the tail does not help (tail: 2 measures equal), and tail: 3 is measurably worse, because each step's newest turn is new regardless and the provider only allows four breakpoints.
• Dropping the tail breakpoint is the expensive mistake: +66% on the same conversation.

Two related open questions would benefit from the same measurement, and I would rather add numbers than guesses:

• A fork of a fork misses the prompt cache: its prompt_cache_key is the intermediate fork's id #55243 — a fork of a fork sends the intermediate fork's prompt_cache_key, so its first request rewrites a prompt whose prefix was already cached under the root's key.
• Compaction is itself a request: the older half of the conversation is re-sent to produce the summary. What is the net effect on a long run, after the summary request and the steps that follow it?

The proposal is a test fixture, not a production change: a provider stand-in in test/fixture/ that meters requests the runner already made, plus cases that assert the reuse it measures. Happy to split it smaller if that is easier to review, or to keep it purely as a fixture and let follow-up PRs add the measurements.