The harness is a budget line

In Guidelines vs guardrails, I wrote that if the harness is the product, a share of what you pay should fund it, without knowing how to pin the number down. I still don’t know it exactly. But I now have the numbers that piece was missing, and a practical rule to stop treating the question as a footnote.

At cumulative global scope, RTK, a local CLI proxy that filters and compresses what goes out to the agent, shows 4.4M “saved” tokens across 9,892 commands, 45.3%, one of the data points feeding what I call AI ROI elsewhere. That’s the kind of number you read as a lower bill, full stop. That’s wrong, or at least incomplete.

Why isn’t 45% a net gain?

Those saved tokens don’t exist in a vacuum. They come out of tooling that has to be built, then kept alive: the hook that intercepts the command, the filtering logic, the rules that decide what to compress without breaking the result. Counting saved tokens without counting the cost of what saves them is reporting revenue without the cost line.

The proof sits in the terminal, taken on August 12, 2026:

$ rtk gain
RTK Token Savings (Global Scope)
════════════════════════════════════════════════════
Total commands:    9892
Tokens saved:      4.4M (45.3%)

The proxy works, the saving is real: this reading is a snapshot, not a promise. A harness that saves tokens today doesn’t keep saving them on its own tomorrow: someone has to reopen it, re-init it, check it hasn’t started filtering too much or too little since the last pass.

Capex or opex, for a hook?

Building fifteen hooks over a weekend, setting up routing by task type, wiring in RTK: that’s capex, a one-time cost, paid once. The routing by cost I document elsewhere starts from the same calculation: price it before you decide.

The problem is elsewhere. Every CLI update, every new model output format, every false positive a hook fires by mistake, that’s opex, a recurring charge. I treated it for months as if it were paid off once, together with the build. An AI budget that only counts the price of generation tokens underestimates its own real cost, because it forgets the recurring half of the bill.

My rule: not a percentage, a time budget

I don’t have a clean percentage to defend; I’d distrust anyone who displays one without measurement behind it. What I actually do: I log the time spent fixing or tuning each gate that produces a meaningful saving. If a hook’s upkeep costs more, over a month, than what it earns back in tokens or review time, it gets simplified or killed, the same logic behind disarming a false positive on reflex, measured this time in hours rather than trust.

That time budget gets reviewed on the same cadence as my model costs. Treating one without the other means optimizing half the bill and congratulating yourself on the result.

Who doesn’t need this calculation?

If your setup is three hooks and a throwaway script, skip all of this: measuring would cost more than what there is to save. This calculation only earns its keep once the harness has enough moving parts for its upkeep to be a real line item, not background noise: fifteen-odd hooks, multi-model routing, a proxy already close to 10,000 cumulative commands on the odometer. Below that threshold, this is accounting over-engineering: measuring for the sake of measuring.

What this changes in practice

Next time a token-saving number lands, 45%, 4.4M, whatever it is, the question isn’t “how much did I keep,” it’s “what did keeping it cost, and did I count it.” A harness that saves tokens without a budgeted upkeep line doesn’t sleep for free: it’s just waiting for the next hook outdated to hand you the bill.