security-guidance: layer 3 agentic commit review is default-on, unbudgeted, and its token usage is computed then discarded

Summary

The security-guidance plugin's layer 3 (agentic commit review) is on by default, fires an
agentic LLM call on every commit, and provides no local way to see what it costs. In a
multi-commit batch session it consumed on the order of 200k tokens across roughly 77 reviews
and returned zero findings. It took a dedicated root-cause session to attribute the burn to
the plugin at all, because nothing surfaces per-review token usage locally.

Meanwhile the two cheap layers did the actual work. This is a cost/observability report, not a
correctness report — the plugin's detection works.

Environment

• Claude Code CLI: 2.1.226
• Plugin: security-guidance 2.0.6 (claude-plugins-official)
• Provider: 1P Max subscription via OAuth (ANTHROPIC_API_KEY unset)
• OS: macOS 27.0 (Darwin 27.0.0), Apple Silicon

Evidence

After disabling layer 3 and dropping layer 2 to Sonnet:

"env": {
  "ENABLE_COMMIT_REVIEW": "0",
  "SECURITY_REVIEW_MODEL": "claude-sonnet-5"
}

I planted a file containing a hardcoded secret, a %-formatted SQL query, and
subprocess.check_output(..., shell=True), then let the Stop hook run:

[19:39:25.739] Pattern matches for .../sg_probe.py: ['python_subprocess_shell']
[19:44:04.580] LLM code review found 3 high/critical vulnerabilities
[19:44:04.580] Stop hook: LLM reviews took 8.1s total

• Layer 1 (regex): caught the shell=True instantly, zero tokens.
• Layer 2 (Stop diff review, Sonnet): 3/3 findings, 8.1s.
• Layer 3: was the expensive layer, and was not the one catching things.

Caveat on the ~200k figure: it was reconstructed by summing per-record usage from session
transcripts, a method that in my experience overstates by roughly 2x. Treat the magnitude as
approximate; the ratio of cost to findings is the point.

Three concrete problems

1. Token usage is computed, then discarded

hooks/_base.py:_record_usage() already accumulates input_tokens, output_tokens,
cache_read_input_tokens, cache_creation_input_tokens, and a computed cost_usd. It flows
only to emit_metrics() → telemetry. ~/.claude/security/log.txt logs timing, finding counts,
and diffstate but deliberately omits tokens (the README states this).

A subscription user therefore cannot answer "what did this plugin cost me today?" without
patching the plugin.

Suggested fix (small): emit one line per review into the existing debug log with the values
_record_usage already holds — resolved model id, in/out/cache tokens, cost_usd, duration.
This also resolves the "resolved model is never logged" half of #81057, and would have made
this entire investigation a grep.

2. Layer 3's default-on cost/benefit is poor, and undisclosed

SG_AGENTIC_MAX_TURNS defaults to 18, on claude-opus-4-7
(_DEFAULT_PUBLIC_MODEL), with Read/Grep/Glob, per commit, on top of the same large prompt as
layer 2. #73271 documents one way this loops and burns turns on unresolvable paths.

The README documents ENABLE_COMMIT_REVIEW=0 clearly, but nothing at install time tells a user
that enabling this plugin means an agentic LLM call on every single commit.

Suggestions:

• Default ENABLE_COMMIT_REVIEW=0, opt-in.
• Or gate it: run layer 3 only when layer 1 or 2 already flagged something, or only when the

diff touches auth / crypto / network / subprocess / SQL / deserialization surfaces. Most
commits touch none of these — my zero-finding run was largely shell scripts, CI config, and
docs.

• Disclose the per-commit LLM call in the plugin description and first-run output, not only in

the env-var table.

3. The ~9k-token prompt is identical every call and uncached

The layer-2 review prompt is a single 35,293-character literal in hooks/llm.py (~9k tokens),
sent on every review regardless of diff size. A one-line change costs nearly the same as a
200-line one.

grep -n "cache_control\|ephemeral" hooks/llm.py returns nothing — the raw-HTTP path in
_call_claude() sends no cache breakpoint.

Suggested fix: add a cache_control: {"type": "ephemeral"} breakpoint at the end of the
static prompt block. It is byte-identical across every call in a session, which is close to the
ideal caching case, and at the 0.1x cache-read rate it should cut layer 2's input cost by
roughly an order of magnitude. _record_usage already tracks cache_read_input_tokens, so the
accounting side is in place.

Why this is worth fixing rather than documenting

For an API user this is a line item they can see. For a Max subscriber, an unobservable
background process that quietly consumes a 5-hour window is a materially worse failure mode:
there is no invoice to notice, no local counter to check, and the first symptom is being locked
out mid-task with no way to identify the cause.

Related: #81057 (fail-quiet + model never logged), #73271 (commit reviewer path loop),
#77582 (background work continues consuming quota past the warning), #33978 (claude usage).