ZeroClaw targets prompt-cache misses at conversation boundaries

A ZeroClaw operator's cache ledger has turned prompt-cache placement into a concrete product discussion. The September 6 proposal adds a marker at the previous turn's last cacheable message, aiming to keep a new user turn from falling back to only the system-prompt cache. The associated report supplies a long-session cost example and the PR supplies a smaller live two-turn result. Neither is a benchmark for every Claude workload.

The facts

- The reported long-session ledger shows an in-turn request with 218,000 cached tokens and a following turn-boundary request with only 37,011 cached tokens. - The proposal adds a previous-turn marker to native Anthropic and compatible-provider passthrough paths using a shared placement rule. - Placement walks back at most three messages for cacheable content and avoids the system message and merged carrier. - OAuth with tools already occupies all four allowed marker slots, so this proposal leaves that layout unchanged rather than adding a fifth marker. - The author reports a live two-turn test whose second request read 25,341 cached tokens and wrote a 303-token delta. - A separate request for a one-hour cache lifetime addresses pauses between turns, not the same breakpoint-placement failure.

Why it matters

A long-running agent can look efficient during tool use and become expensive when the human returns with a new instruction. Aggregate cache percentages conceal that transition. The useful diagnosis here is at the boundary: which prefix was cached, which marker survived, and whether the next request could reuse conversation history rather than only the stable system prompt. The original issue explicitly framed part of its mechanism as a hypothesis; the later implementation adds a targeted test without turning that one operator's ledger into a general savings guarantee.

Current

Inspected on 2026-09-07. The ZeroClaw stable-release baseline is v0.8.5 published 2026-09-05T07:31:19Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is zeroclaw-labs/zeroclaw PR #10666 (https://github.com/zeroclaw-labs/zeroclaw/pull/10666). Supporting context comes from zeroclaw-labs/zeroclaw issue #10660 (https://github.com/zeroclaw-labs/zeroclaw/issues/10660); zeroclaw-labs/zeroclaw issue #10662 (https://github.com/zeroclaw-labs/zeroclaw/issues/10662); zeroclaw-labs/zeroclaw issue #10663 (https://github.com/zeroclaw-labs/zeroclaw/issues/10663). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Measure both active tool loops and the first request after a new user turn, then separate marker placement from expiration. More markers are not automatically better because the request-wide limit also includes system and tool definitions. The OAuth-prefix follow-up identifies a potentially wasted slot but says its author lacked credentials for the required live probe, so that improvement remains unverified. Longer lifetime is another trade-off, with different write pricing and workload dependence. Operators should compare real cached-read and cache-write counters before changing a production policy rather than extrapolating a monetary return from one unusually long conversation.

Caveat

The primary PR is open and depends on the earlier passthrough work. The live numbers are contributor-reported, not independently reproduced here. OAuth-plus-tools does not gain the new marker in this proposal, and the separate one-hour lifetime option is not claimed to have shipped.