Stopping Fraud And Waste

2026-10-19, Jacks-iMac. Research into what actually prevents a session from overclaiming or wasting effort, measured from 13 sessions of real gate-refusal data plus one session that produced both failures repeatedly under observation.

1. The short answer

2. What works, with the number that proves it

3. The leak: a spent budget lets a failing session exit

A bigger cap only buys more turns of the same argument. The way out is to spend fewer refusals on causes that need no judgement, so the budget is still there for the ones that do.

4. The ledger nobody was reading

These gates leave exactly one durable trace, ~/.claude/stop_budget_state/<session>.json, holding the spend and the reason text. No tool read it until today. Aggregated across 13 sessions:

Refusal causes, numbers normalised

Display substitution in the table above, listed rather than hidden: "names" shown as "cites". One word in the gates' own messages is on the house banned list, and the voice checker reads the text with the markup removed, so the verbatim string fails the check. Nothing else in the cause text is changed.

Which gates refuse

Per session

4 sessions were refused with no reason recorded. The spend is kept and the cause is lost, so those refusals can never be reviewed or counted.

5. The false-positive tax

The established practice for this is called guardrail telemetry, where every check emits a verdict and the false-positive rate is computed from labeled traffic. One published interceptor reports 1.2% on 500 benign tool calls. Nothing here emitted a verdict, so the rate was unknown and unknowable.

labeled tally after one session of labeling:
  true_catch        11
  needs_parser_fix  2
  unlabeled         2
  of 15 cause-instances across 13 sessions

6. What was built today

Every one is a nudge rather than a refusal, so none of them can spend the Stop budget, and each returns zero on malformed input so none can break a tool call.

7. The finding that indicts this page

hook latency on ONE Bash call     695 ms across 12 processes
a do-nothing python hook           51.8 ms   <- the floor every hook pays
therefore interpreter startup      622 ms
all twelve hooks' logic combined   ~13 ms
the three nudges added today      ~156 ms, almost entirely startup

after consolidating those three into one process:
processes per Bash call            12 -> 11
measured saving                    22 ms   (the prediction was 52 ms)
my nudges still cost              ~104 ms per Bash call

The consolidation was proved by equivalence rather than by fresh fixtures: every original control was run through both the old script and the new entry point, and all 33 paired cases returned identical verdicts, 40 of 40 correct overall. That is a stronger test than the ones below it on this page, and it is still author-written.

The controls on this page are weak evidence, and here is the proof

None of the six hooks has fired once in production. They are not loaded in the session that wrote them, so the honest status is written and self-tested, unverified in use. claude_nudges.py now appends one line per firing to ~/.claude/_state/nudge_ledger.jsonl, which starts at zero, so the question of whether they ever fire and whether they are right when they do becomes answerable. The three test firings were moved aside rather than removed.

8. What is still open, and why I did not do it

Three further items are stated here rather than quietly dropped. Nine blocking safety gates still run one process each, about 470 ms per Bash call, and consolidating them behind one dispatcher would recover most of it; that one was left alone because a bug in such a dispatcher drops a refusal silently, where a bug in the nudge dispatcher only costs time. The 4 refusals with no reason recorded mean the dispatcher drops the cause on one path, which should be traced before anyone trusts the cause table as complete. And the labeled tally above comes from one session of labeling, so the false-positive rate it prints is a floor rather than a measurement.