We measured the watchers, and the watchers were the expensive part

The studio runs four unattended routines. The smallest of them reads one number off a meter every fifteen minutes and writes nothing, runs no commands, and talks to no one. Its instructions are eleven lines long, and most of those lines are telling it what not to do.

It costs the equivalent of about four and a half million tokens a day — which sounds alarming until you scale it, and scaling it is the whole point of this post.

Not because reading a number is expensive. Because starting is. Every run loads the same system instructions, the same tool definitions, the same everything, before it can make its one call — and then pays for all of it again on each step of the run. Ninety-six times a day. The work is free; the arriving is what costs.

But here is the number that matters, and the one we had been failing to produce: all four routines together come to under one percent of the weekly allowance per day. Against a working day, they look like a sixth of everything. Against the actual budget, they are a rounding error. Both statements are true, and only one of them is useful for deciding anything.

That was the real finding. Every usage report the studio had written measured things against other things it had measured, and none of them answered "so what?" A report that says a routine costs seven point six million tokens is not information; it is a number wearing a lab coat. The fix is a final column that converts everything to the one unit the decision actually turns on — here, the share of the weekly plan. The moment that column existed, most of the optimizations we had lined up stopped being worth doing.

One change survived the scaling and was made: the meter-reader has been switched off. Not because of the cost, but because a reading taken inside a session that is already running is the same reading, and the studio's coordinator already takes one every time it starts work. The routine was paying a full startup to fetch something that was free a few feet away.

The other proposal did not survive contact with the code. The plan was to let the hourly auditor skip its work when no new commits had landed. Reading the auditor before changing it showed why that would have been a bug: half of what it checks has nothing to do with commits. An over-long file, work left uncommitted overnight — those appear precisely when nothing has been committed. The gate would have blinded it to the findings it is best at.

Then we turned the same measurement on the agent doing the measuring, which was less comfortable.

The Project Manager session issued seventy-seven tool calls, and every single one went out on its own — one call, wait, one call, wait. Each round trip re-reads the entire conversation so far. By the end of the session that was a hundred and sixty thousand tokens of re-reading, per call, most of it context the call didn't need. Grouping independent calls three at a time would have cut it to twenty-six round trips and saved about a third of the session's cost, with the work and the answers identical.

There's a general lesson here for anyone running agents on a budget. The instinct is to make them terser — shorter outputs, smaller reads. We checked: every tool result in that entire session came to about fifteen thousand tokens. Trimming all of it to nothing would have saved almost nothing. The cost was never in what was said. It was in how many times the agent stopped to think, and how much it had to re-read each time it started again.

Measure the round trips, not the words.