inspect

name

inspect

description

Statically inspect prompt-cache breakpoints in a captured /v1/messages body or a clawback --state file, with ZERO token spend and no API calls. Answers "where are the cache_control breakpoints, and which ephemeral tokens (cch / date / <env>) sit inside which cached prefixes?" — i.e. what a single mutation cold-starts. Use it to SEE why strip-ephemeral matters (cch precedes the earliest breakpoint, so it cold-starts every cached prefix every request) before spending tokens on a dynamic probe. Read-only and safe to run against a live benchmark.

clawback cache-breakpoint inspector

Run .skills/inspect/scripts/inspect_breakpoints.sh [PATH] [--json] from the project root.

With no PATH, it inspects the most recently modified runs/*/state*.json. This is read-only — it touches only files already on disk, never the running proxy — so it is safe to run while a benchmark is in flight.

# inspect the newest run's captured state
.skills/inspect/scripts/inspect_breakpoints.sh

# inspect a specific captured body or fixture
.skills/inspect/scripts/inspect_breakpoints.sh benchmark/fixtures/ccode.json

# machine-readable model for tooling
.skills/inspect/scripts/inspect_breakpoints.sh runs/l2-haiku/state.A0.json --json

What it reports

A cache-ordered segment table (tools -> system -> messages), each row marked with its cache_control breakpoint (and TTL) and any ephemeral token it carries, followed by a verdict centered on cch (the per-request rotator).

Worked example, from a real Claude Code v2.1.145 body:

  33    20               system[0] "x-anthropic-billing-header: cch=..."   <-- cch
  34    14  BREAK 1h    system[1] "You are Claude Code, ..."
  35  7304  BREAK 1h    system[2] " You are an interactive agent ..."   <-- iso-date

VERDICT:
  cch sits BEFORE the earliest breakpoint (pos 34). Every cached prefix
  includes it, so a new cch per request cold-starts 2/2 prefixes ... No
  breakpoint isolates tools or anything ahead of cch, so nothing survives.

Why static is enough (and the limit of "static")

Anthropic caches the cumulative prefix up to each breakpoint by exact match. So a token at cache-order position P invalidates every breakpoint at position >= P when it rotates. That single fact characterizes the whole structure: you do not need a 2^N probe to know what cold-starts. The inspector reads the breakpoint placement straight out of the captured body and applies that rule. This replaces, rather than approximates, an exhaustive dynamic sweep; the one thing it can't prove (that Anthropic honors the breakpoints as documented) is what the optional token-costing probe confirms.

Input fidelity caveat

A synthetic (hand-authored) fixture may carry a tools breakpoint that real Claude Code lacks, and no cch at all — so the inspector will (correctly) report "no cch ... rotation driven only by date/env." That is a property of the input, not a bug: only a body captured from a real session (see .skills/capture) reproduces the genuine cch + breakpoint structure. The shipped benchmark/fixtures/ccode.json is such a capture (sanitized of personal data, structure intact), but it ages as Claude Code releases move — inspect a fresh --capture-body dump or a live run's state*.json for a verdict on the current build.

Sensitivity

State files and captured bodies contain your system prompt and tool definitions. Treat the inputs as sensitive; the inspector itself only prints positions, token estimates, ~60-char segment labels, and short ephemeral samples (e.g. cch=f1b84) — not full block contents.