What jumped out at me wasn’t the stop hook trick itself. It was the admission that the “obvious” culprit was wrong. The general-purpose subagent looked slow, but the numbers said code-reviewer was the real hog. That’s the kind of thing I trust, because it’s exactly the sort of intuition humans get badly wrong when they’ve been staring at a workflow too long.
I also like the shape of the system here: don’t instrument Claude Code from the outside, don’t babysit logs manually, just hook into session end and let the transcript become the source of truth. That feels very in-family for how these tools are meant to be used. If the transcript really contains tool calls, timestamps, and results in a machine-readable way, then the whole thing is less “clever hack” and more “use the plumbing that already exists.” That part seems solid.
What I’m less convinced about is the confidence level around the savings. “Dropped my weekly Claude Code spend by roughly 15–20%” might be true for this setup, but I’d want to know how much of that came from changing agent behavior versus simply better logging making the author behave more carefully. Those are not the same thing. Also, when someone says they built an autonomous setup that now runs at about ¥1.2M in monthly revenue, I don’t read that as evidence of the technique so much as evidence that they’re operating at a scale where small efficiency gains finally show up as real money.
The part I’d actually copy is the discipline, not the exact scripts. Keep a JSONL ledger. Track durations. Track errors. Separate “felt slow” from “is slow.” If I were using Claude Code heavily, I’d do the same thing before trying any more elaborate optimization. The article’s real value is that it turns vibe-based debugging into something uglier and better: a log file.
