Picture the Horizon dashboard on a Monday at 07:42. One job shows 15,000 attempts since Friday night, and it never failed in a way anyone noticed. Somebody gets paged before the coffee is ready, a timeout goes into the job class, and the postmortem is a single line in the team channel. So why do so many of us shrug when an AI coding agent does exactly that on our subscription?

That number is real, by the way. Back at the end of August, OpenAI reset Codex quotas for paying users after the team followed a pile of complaints back to client-side bugs that were quietly burning tokens. The reset is ancient history now, and whether your allowance got topped up that weekend matters to nobody anymore. The bug list still matters, because it reads like a tour of our own incident tracker. In one thread a background memory task checked more than 15,000 times whether it was allowed to stop. Some /goal runs failed to shut down after finishing, or kept retrying broken tool calls, and that cost the unluckiest users somewhere between 15 and 70 percent of their weekly quota. A history feature kept re-summarizing activity it had already summarized and ate a fifth of the week for some people. Some MCP tool results were being encoded twice. According to the team, fixing all of it gave users roughly 10 to 50 percent more usable quota, depending on how they worked.

Take away the AI branding and you have four bugs every PHP developer has shipped at least once: the retry loop with no ceiling, the worker that never exits, the job that redoes work it already did, and json_encode run on a string that was already JSON. We catch these in our own systems because we've learned, usually at 3 a.m., to put a timeout, a max-tries value and a log line on anything that runs without a human watching. An agent running a long task is exactly that kind of thing. It's a background process spending money for you.

To be fair to the vendor, they understood this. The Codex team said it added automatic alerts for this class of waste and promised users a breakdown of where their tokens go. By the time you read this, that view may well be live, and the vendor can see things you never will, like what the client and model are actually saying to each other. If a dashboard already exists, building your own looks redundant, and I take that seriously.

I still want my own ledger. A vendor breakdown tells you which feature inside the tool used the tokens. It can't tell you that the refactor on ticket 4127 cost three times what the change was worth, or that one developer's automation fires every ten minutes when it was meant to run hourly. And the meter belongs to the company that also sends the invoice. That isn't an accusation. It's the same reason nobody treats the payment provider's export as their only accounting record, however much they trust it.

In practice this means less than it sounds. Treat every agent session like a cron entry: it needs a named owner and a hard wall-clock limit. Log token counts against the branch or ticket, in the same place your other job metrics already go. Then take a quick look at the totals once a week, the way you'd scan slow query logs. Our Go-writing neighbours will point out that context.WithTimeout fixes half of this in one line, and annoyingly they're right about that half. The other half is just paying attention. Paying attention is free.

So I'm curious how your team actually handles it. When an agent spends half your weekly budget on a task nobody asked for, who finds out first: you, from your own logs, or the vendor's dashboard after the damage is done?