Annotate every ranked TOK hotspot with the load-pattern triple (loadPattern/survivesCompaction/derivationConfidence): - hotspotLoadPattern() maps each discovery `type` → a deriveLoadPattern kind. Rules reuse activeConfig.rules for precise `scoped` handling; claude-md maps by scope. Two new deriveLoadPattern kinds back the rest: `command` (on-demand — body loads on /invoke) and `harness-config` (external — settings/keybindings/.mcp.json/hooks.json/plugin.json configure the CLI, not the model context, so they cost no per-turn context tokens). Honest split: the .mcp.json FILE is external; the MCP server's tool schemas are a separate `always` hotspot. Byte-stability — the opposite of B1's manifest. token-hotspots IS a byte-equal SC-6/SC-7 CLI, and its hotspots ride inside scan-orchestrator + posture, so the change touched SIX frozen-v5.0.0 comparisons across five test files. Resolved by preserving the frozen baselines: a shared tests/helpers/strip-hotspot-load-pattern.mjs strips the additive triple before each byte-equal compare (proves the original schema is byte-identical). SC-5 default-output snapshots (scan-orchestrator + token-hotspots) regenerated — diff reviewed as additive-only. Tests 1008→1012. Self-audit A/A, scanner count unchanged at 13 (C bumps to 14). Completes v5.6 B (B1 manifest + B2 token-hotspots). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6.6 KiB
| name | description | argument-hint | allowed-tools | model |
|---|---|---|---|---|
| config-audit:tokens | Show ranked token hotspots and prompt-cache pattern findings — what's costing the most per turn and how to reduce it | [path] [--global] | Read, Bash | sonnet |
Config-Audit: Token Hotspots
Show the configuration sources that contribute the most tokens per turn, ranked by estimated tokens, with prompt-cache-aware recommendations for reducing cache misses, schema bloat, and deep import chains.
Complementary to /config-audit whats-active:
whats-active= inventory view (what loads).tokens= action view (what to trim and why).
UX Rules (MANDATORY — from .claude/rules/ux-rules.md)
- Never show raw JSON or stderr output. Always use
--output-file+2>/dev/null. - Narrate before acting. Tell the user what you're about to do.
- Read, don't dump. Read the JSON file and render formatted tables.
- End with context-sensitive next steps.
Implementation
Step 1: Parse $ARGUMENTS
Split $ARGUMENTS into a path and flags. Path is the first non-flag argument. Default to . (current working directory). Recognized flags:
--global— also include the user-level~/.claude/cascade--json— emit raw JSON instead of rendered tables (power-user mode; bypasses the humanizer for byte-stable v5.0.0 output)--raw— pass-through to the scanner; produces v5.0.0 verbatim JSON (bypasses the humanizer). Use when piping into v5.0.0-baseline diff tooling.--with-telemetry-recipe— includetelemetry_recipe_pathin the JSON output, pointing toknowledge/cache-telemetry-recipe.md. Use this when you want to verify a structural fix actually improved cache hit rate (manual jq recipe, opt-in)
Step 2: Run the CLI silently
Tell the user: "Analysing token hotspots for <path>..."
Default mode (no --json, no --raw) emits a humanized JSON envelope: each finding carries userImpactCategory, userActionLanguage, and relevanceContext in addition to the v5.0.0 fields. Pass --raw through verbatim if the user requested it.
TMPFILE="/tmp/config-audit-tokens-$$.json"
RAW_FLAG=""
if echo "$ARGUMENTS" | grep -q -- "--raw"; then RAW_FLAG="--raw"; fi
node ${CLAUDE_PLUGIN_ROOT}/scanners/token-hotspots-cli.mjs <path> --output-file "$TMPFILE" [--global] $RAW_FLAG 2>/dev/null; echo $?
Exit code handling:
0→ continue3→ tell user: "Couldn't analyse tokens. Check that the path exists and is a directory." Stop.
Step 3: If --json was requested, cat the file and stop
cat "$TMPFILE"
Do NOT render tables in JSON mode.
Step 4: Read JSON and render
Use the Read tool on $TMPFILE. Extract:
total_estimated_tokens— top-line numberhotspots[]— top 10 ranked sources; each carries a load pattern (loadPattern∈ always / on-demand / external, plussurvivesCompaction/derivationConfidence)findings[]— prompt-cache pattern findings (CA-TOK-001..003); each finding in default mode carries humanizer fields (userImpactCategory,userActionLanguage,relevanceContext) alongside the v5.0.0 fieldscounts— severity breakdown
A hotspot's load pattern matters as much as its size: an always-loaded source (CLAUDE.md, MCP tool schemas) is paid on every turn, an on-demand one (skill body, path-scoped rule) only when invoked/matched, and an external one (hooks, harness-config files like settings.json/.mcp.json) costs no per-turn context tokens at all. A big always-loaded hotspot is the most worth trimming.
Render as markdown. Group findings by userImpactCategory (e.g., "Wasted tokens" vs "Configuration mistake") rather than re-deriving severity prose; lead each line with userActionLanguage ("Fix this now", "Fix soon", "Optional cleanup", etc.) so the urgency phrasing stays consistent with the rest of the toolchain. The humanizer already replaced jargon-heavy title/description/recommendation strings with plain-language equivalents — render them verbatim.
**Token hotspots for `<path>`** — ~{total_estimated_tokens} estimated tokens loaded per turn
### Top hotspots (ranked by estimated tokens)
| Rank | Source | Tokens | Load | Recommendations |
|------|--------|--------|------|-----------------|
| {rank} | `{source}` | ~{estimated_tokens} | {loadPattern} | {recommendations joined as `· ` bullets} |
_Load column: **always** (every turn) / **on-demand** (on invoke/match) / **external** (out-of-context). Append `°` when `derivationConfidence` is `inferred`._
### Findings, grouped by impact
{Group findings[] by their userImpactCategory. Within each group, sort by userActionLanguage urgency (Fix this now → Fix soon → Fix when convenient → Optional cleanup → FYI), then render:}
- **{userActionLanguage}** — {title} ({id})
- {description}
- **Fix:** {recommendation}
- _{relevanceContext}_ when not "affects-everyone" (mention the scope so the user knows whether a fix touches shared config or just their machine)
### Severity summary
| Severity | Count |
|----------|-------|
| critical | {counts.critical} |
| high | {counts.high} |
| medium | {counts.medium} |
| low | {counts.low} |
| info | {counts.info} |
_Estimates assume ~4 chars/token (Claude ballpark). Real token count varies ±20%._
Step 5: Cleanup and next steps
rm -f "$TMPFILE"
### What's next
- **`/config-audit whats-active`** — full inventory of what loads (plugins, skills, MCP, hooks)
- **`/config-audit posture`** — overall health scorecard (Token Efficiency is the 8th area)
- **`/config-audit fix`** — auto-fix deterministic issues (where applicable)
- See `knowledge/prompt-cache-patterns.md` for the full pattern catalogue (CA-TOK-001 … 003)
- **Verify cache hit rate after a fix:** rerun with `--with-telemetry-recipe` to surface the path to `knowledge/cache-telemetry-recipe.md` — a copy-paste `jq` recipe that reads cache hit rate from your session transcripts. Opt-in. The TOK scanner is structural; this recipe is the runtime escape hatch.
Scope and limits
- Read-only. Inspects config files; never writes.
- Single repo. Scans one path per invocation.
- Structural only. Hotspots are deterministic byte→token estimates from disk; runtime cache hit-rate is out of scope.
- Heuristic estimates. ~4 chars/token for markdown, ~3.5 for JSON. Real counts vary ±20%.
Error handling
| Condition | Action |
|---|---|
| Exit code 3 | Tell user path is invalid, suggest checking path exists |
| JSON parse fails | Tell user to re-run, mention as a bug to report |
| Empty hotspots | Suggest adding a CLAUDE.md or running /config-audit feature-gap first |