How do I install the Inspect skill?

Run npx skillmds@latest add zapgun-ai/inspect in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Inspect safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Inspect?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Inspect free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Inspect?

zapgun-ai (@zapgun-ai) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Inspect by zapgun-ai — Agent Skill

Name: Inspect
Author: zapgun-ai

Inspect

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.

zapgun-ai 1148670 2 files · 5.6 KB Updated Sep 17, 2026

File contents

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.

---name: inspectdescription: 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 inspectorRun `.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 runningproxy — so it is safe to run while a benchmark is in flight.```bash# 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 reportsA cache-ordered segment table (`tools -> system -> messages`), each row markedwith its `cache_control` breakpoint (and TTL) and any ephemeral token itcarries, 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-dateVERDICT: 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 exactmatch. So a token at cache-order position P invalidates every breakpoint atposition >= P when it rotates. That single fact characterizes the wholestructure: you do **not** need a 2^N probe to know what cold-starts. Theinspector reads the breakpoint placement straight out of the captured body andapplies that rule. This replaces, rather than approximates, an exhaustivedynamic sweep; the one thing it can't prove (that Anthropic honors thebreakpoints as documented) is what the optional token-costing probe confirms.## Input fidelity caveatA **synthetic** (hand-authored) fixture may carry a tools breakpoint thatreal Claude Code lacks, and no `cch` at all — so the inspector will(correctly) report "no cch ... rotation driven only by date/env." That is aproperty 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 ofpersonal 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 averdict on the current build.## SensitivityState files and captured bodies contain your system prompt and tooldefinitions. Treat the inputs as sensitive; the inspector itself only printspositions, token estimates, ~60-char segment labels, and short ephemeralsamples (e.g. `cch=f1b84`) — not full block contents.

Frequently asked questions