One hour for the parent, five minutes for the child

The quiet part of a multi-agent workflow

An agent finishes a patch, starts a test run, and waits. Another sends work to a reviewer. A third asks you a question while you are reading a diff. Nothing unusual is happening. But the next model request may have to write a prompt prefix that was already cached a few minutes ago.

We wanted to know whether the way you launch an agent changes that behavior. On October 10, 2026, we measured Claude Code 2.1.286 with claude-sonnet-5-5. The main session explicitly requested a one-hour prompt cache. Its native Agent subagent omitted the TTL, and the response assigned its writes to the five-minute tier.

That is relevant to TUICommander: every agent it launches runs as a top-level CLI session in its own PTY. A worker can be a child in our coordination graph while remaining a main session from Claude Code’s point of view. Under the measured behavior, that puts each Claude worker on the one-hour path.

A post by Haz prompted the experiment. We could not retrieve it independently, so we are crediting the prompt for the investigation, without quoting or treating its claims as evidence. The numbers below come from our captures.

Watch the request, then check the response

We used a loopback-only mitmdump 12.2.3 proxy on macOS arm64, with a certificate authority trusted by the CLI process alone. The CLI handled its existing login. Our scripts did not read credential stores, copy credentials, or install a system trust entry.

The capture addon saved an allowlist of fields: timestamps, host, request byte count, model, cache directives, numeric usage, tool schema property names, and tool-call names and hashes. It did not save headers, cookies, prompt or response text, account metadata, or raw flows. Native runtime state stays out of the published evidence.

A filesystem sandbox constrained experiment writes. Requests over 45,000 serialized bytes were stopped before forwarding; that is a byte guard, not a token measurement. Prompts asked for short fixed replies. We counted usage from individual wire responses, merging repeated streaming usage updates instead of summing them.

The first useful distinction was visible directly in the request:

Main session:   {"type": "ephemeral", "ttl": "1h"}
Native child:   {"type": "ephemeral"}

A requested TTL alone would be weak evidence. The initial native child also returned 4,251 cache-write tokens, all in ephemeral_5m_input_tokens, with 2 fresh input tokens and zero cache-read tokens. Parent requests on either side requested and wrote into the one-hour tier.

The main session stayed warm after half an hour

We kept the main process alive and inserted separate 4-, 6-, and 30-minute waits. Each gap is measured from the preceding response to the next request by the same role. These are sequential gaps; a cache read refreshes retention, so the final row is not a clock running from the first write.

All three turns reused cached input. The extra writes are new conversation suffixes: a cache hit does not mean that the whole growing request came from cache. A smaller initial probe had only 287 input tokens and neither read nor wrote cache, despite requesting one hour. Tiny prompts cannot prove retention.

The child crossed the five-minute boundary

The first timing attempt asked the parent to resume its child. The later requests were actually main-session requests. Inspecting the captured Agent schema showed no resume property, so those turns cannot establish anything about child retention.

The separate child run keeps one native child alive through synchronous shell sleeps. Its available responses show a hit after 244.135 seconds: 5,686 cache-read tokens and 611 new five-minute write tokens. After 360.296 seconds, it returned zero cache-read tokens and 6,436 five-minute write tokens. Both turns had 2 fresh input tokens.

The native-child 30-minute check is still pending at this writing. We are not filling that cell from the requested TTL. The six-minute miss is a measured event in this run; one run does not locate an exact eviction boundary.

Why a terminal per worker matters

TUICommander coordinates independent agent processes. Each gets its own terminal, working context, and session. The parent assigns work and receives results through agent messaging; Claude Code does not have to create that worker through its native Agent tool.

That separation has an interesting consequence. The worker inherits the main-session cache policy observed here: one hour. A review, a build, or a human answer can take longer than five minutes without crossing that requested retention window. The measured main-session hits after six and thirty minutes support why this can help a workflow with long pauses.

This is an architectural advantage supported by the CLI experiment. We did not run a controlled, end-to-end comparison of the same workload inside TUICommander and through native delegation. Launching more top-level sessions also creates separate contexts; it does not make their prompts identical or guarantee a shared cache between workers.

It suggests a useful scheduling principle: keep a worker’s session alive when you expect to return to it, and send it the next bounded assignment. A short task that finishes before any long pause may see little benefit from the longer tier. The pause pattern matters as much as the agent count.

What 25× means, and what it does not

At Anthropic’s API list prices, checked October 10, 2026, Sonnet 5.5 costs $2 per million fresh input tokens, $2.50 per million five-minute cache-write tokens, $4 per million one-hour cache-write tokens, and $0.10 per million cache-read tokens. The five-minute write/read ratio is 25×.

Here is an API list-price counterfactual: if an unchanged 100,000-token prefix must be written again into the five-minute tier after a six-minute pause, that write costs $0.25. Reading those same tokens from a surviving cache costs $0.01. This isolates one input operation; it excludes initial writes, new suffixes, output tokens, and any other work.

The longer tier has an upfront premium: $4 rather than $2.50 per million write tokens. A longer lifetime is therefore not automatically cheaper for every workload. Nor does 25× describe a whole request: the observed initial child’s input-only counterfactual ratio was about 24.78× once its 2 fresh tokens were included.

We have not measured subscription savings, subscription quota accounting, or a TUICommander bill reduction. The experiment used an existing personal login. API list-price arithmetic explains the magnitude of the token-category difference; it cannot tell us how a subscription meters those categories.

How to reproduce the useful part

The sanitized evidence extract contains the request directives, per-turn usage, measured gaps, and price inputs used here. It includes no prompt bodies or native login state. To repeat the measurement in your own environment:

1. Record the exact CLI version, model, date, and login tier. Start with an already authenticated CLI; let it handle authentication.
2. Run a loopback interception proxy with per-process CA trust. Save only an explicit allowlist of cache directives and numeric usage. Apply a request-size guard before forwarding.
3. Send a short task with enough stable input to produce a real cache write. Confirm the response’s five-minute and one-hour write counters before testing retention.
4. Keep the same main process alive. Insert separate 240-, 360-, and 1800-second waits, recording the actual response-to-request gaps and the usage after each.
5. Repeat with one native child kept alive through synchronous waits. Verify that the later requests really belong to that child; do not infer it from the parent’s reply or assume a resume parameter exists.
6. Merge streaming usage updates by field rather than adding repeated counters. Compare cached reads and tier-specific writes, then calculate costs separately.

The timed sequences take roughly forty minutes each and make real inference requests. An independent rerun should preserve the same model and login tier, and report any sandbox or startup failure before drawing conclusions about caching.

The boundary of the result

This is one CLI version, one model, and one environment. We did not test all account tiers, regions, context sizes, or eviction conditions. We did not observe a 500,000-token rewrite. Changing a prompt prefix, restarting a session, or using another CLI release can change the outcome.

Codex and Grok were not measured. The experiment’s isolation broke their probes; reruns are in progress. We make no claim about their cache policies or comparative costs.

What we can say is concrete: this Claude main session requested one hour and reused cached input after a half-hour pause. Its native child wrote into the five-minute tier and missed after six minutes. TUICommander’s independent-terminal architecture keeps Claude workers on the main-session side of that distinction. That is a useful property for agents whose work includes waiting.