Nobody Budgeted for the Agent That Never Sleeps

Your seat-based software budget assumes a person who goes home. Closes the laptop, stops consuming, resets to zero until morning. Every SaaS contract you have ever signed priced that assumption in. The agent you just deployed does not go home. It runs the loop at 2 a.m. because the loop does not care what time it is, and the meter runs with it.

That is the whole shift, and almost nobody has repriced for it. The budget line that governs an agent fleet is not a seat count. It is a token economics, metered per call, per token, per cache hit, and it behaves nothing like the flat monthly subscription your procurement team knows how to approve. The meter was running the whole time. The invoice just had not caught up.

The seat was a fiction that finance liked

Per-seat pricing was never really about seats. It was a proxy that let a vendor charge a predictable amount and let a buyer forecast a predictable cost. A seat is a human, a human sleeps, so consumption self-caps somewhere around eight billable hours of one person clicking. Everyone agreed to pretend the seat was the unit because the seat was legible to a budget process built for legible units.

An agent breaks the proxy. There is no seat, there is a workload, and the workload runs continuously across nights, weekends, and the quarter-end freeze when nobody is watching. You can spin up ten agents against one repository and the only thing capping consumption is the token budget you did or did not set. The cost driver moved from headcount to compute, and compute does not sleep. I made the runtime-visibility version of this argument in We Inspect the Traffic, where cost is one of three lenses you have to watch at the boundary. This post is the cost lens on its own, because it is the one that gets expensed silently.

Token metering is the real unit, and it has moving parts

Start with what you are actually paying for, because “tokens” is doing a lot of hidden work in that sentence. Every model call bills input tokens and output tokens at different rates, and for a reasoning model the invisible middle, the thinking tokens the model spends before it answers, bill as output whether or not you ever see them. A background agent that “waffles,” to borrow the factory-floor term, is not just slow. It is expensive in a line item you cannot see in the diff.

Three drivers dominate the bill, and none of them are the thing people watch:

• Context window is a recurring tax, not a fixed cost. Every turn of an agent loop resends the accumulated context: the system prompt, the tool definitions, the file contents it pulled, the prior turns. A long-running agent does not pay for its context once. It pays for it on every single call, and the cost grows with the conversation. A fleet of agents each dragging a bloated window is a fleet each paying that tax on every step.
• Caching is the largest lever most teams never pull. Prompt caching lets the stable prefix of a request, the parts that do not change between calls, bill at a steep discount on cache reads instead of full input price. Structure your context so the invariant block sits first and stays byte-identical, and the recurring context tax drops hard. Reorder it carelessly, invalidate the prefix, and you pay full freight on every turn. The difference between a cached and an uncached fleet is not a rounding error. It is the difference between a workload you can afford to leave running and one you cannot.
• Output is the priciest token you emit. Output bills at a multiple of input on every frontier model. An agent that generates a 2,000-line rewrite when a 40-line patch would do is not just riskier to review. It burned the expensive tokens to get there.

Watch those three and you are metering the workload. Watch seat count and you are metering a fiction.

Per-route budgets, because not every job deserves the dream team

The naive fix is a single spend cap on the whole fleet, which fails the same way a single speed limit for every road fails. The discipline that works is routing, and it is the same discipline IndyDevDan calls tokenomics: use tokens, generate value, arbitrage the value for more than the tokens cost. You cannot do that arithmetic with one global budget. You do it per route.

A route is a class of work with its own economics. Bulk summarization and background classification are high-volume, low-stakes, and belong on a cheap workhorse or a local model where each call costs a fraction of a cent. Architectural reasoning, security-sensitive changes, and anything a human will sign off on belong on a frontier model where the metered cost is worth it because the judgment is. The failure mode has a name on the factory floor: sending the dream team to fix a typo. A per-route budget encodes the tiering so the router, not the vibe of the moment, decides which model handles which step and how much that step is allowed to spend before it stops.

This is where the harness stops being an engineering nicety and becomes a financial control. The same layer that scopes an agent’s tools, the one I broke down in The Six Primitives of a Code Factory, is where you attach the budget. A per-route cap is code that runs every time, not a prose reminder to be frugal. It fires, it records, and it stops the run when the route exhausts its allowance. That is a control you can show, which matters more in some buildings than others.

The TCO of an agent that never clocks out

Here is the number that reframes the whole conversation. When you run a background agent well, the throughput is not incremental. Ramp has publicly described a workflow where a large share of its pull requests, on the order of a third, originate from a background agent rather than a human typing them. Treat that specific figure as reported and worth verifying against the primary source before you quote it, but the shape of the claim is the point: the unit of output stopped being an engineer-hour and became an agent run, and agent runs do not stop at six.

Total cost of ownership for that fleet is not the token bill alone. It is tokens plus the compute the runtime sits on plus the one resource the practitioners running these factories say is now the actual constraint: human attention to supervise the sessions. Vincent Koc, who runs a parallel-agent factory on the OpenClaw project, put the flip plainly. Tokens stopped being the bottleneck. Raw compute and the brain space to keep an eye on all the sessions became it. Your TCO model has to price all three, and the third one, the reviewer’s time, is the one that scales worst and shows up on no invoice.

The founder move the Claude Code team described is to shift budget from humans to tokens deliberately: underfund a project on headcount, overfund it on tokens, and let the compounding work like precompilation, high upfront cost for low ongoing cost. That is a real strategy. It is also a budgeting earthquake for any organization whose planning cycle allocates seats and salaries, because it asks finance to move money from a cost center they understand into a metered utility they do not yet have a meter for.

Chargeback in a cost-center model that was never built for this

Now put it inside a regulated shop, where every dollar of shared infrastructure has to land against a cost center and someone has to be able to reconstruct why. A metered, continuously running, multi-model agent fleet is the hardest possible input to that machinery, because the spend is real-time, variable, and attributable to a workload rather than a person.

The good news is that the capture mechanism already exists. The agent run is the natural unit of chargeback the way the seat used to be. Tag every run with the route it took, the model it hit, the input, output, and cached token counts it burned, and the team or product that requested it, and you have a cost record that rolls up to a cost center cleanly. This is the same instinct behind Agent as a Service: if the agent is an internal service, its consumption is a billable event, and a billable event needs a meter, a tag, and a rate card. Engineering traces already capture the model calls and their cost. Product analytics on top tells you whether the run that cost thirty cents was worth thirty cents. Chargeback is the third layer, and it is mostly a matter of pointing the tagging you already do at the ledger instead of only at the debugger.

What you cannot do is bolt a per-seat mental model onto a per-token reality and hope the variance stays small. It will not. A single misconfigured loop, an agent that resends a bloated context on every turn because nobody structured the cache, a route that sends frontier compute at a typo, and the monthly number moves in a way no seat-based forecast predicted. The overrun is not a vendor betraying you. It is a meter you left running and never read.

Read the meter

The agent fleet is the first piece of software you have bought that consumes like a utility and gets budgeted like a subscription. The gap between those two facts is where the surprise invoice lives. Close it by metering the real unit, tokens with their cache and context drivers, capping spend per route instead of per fleet, pricing the reviewer’s attention into TCO honestly, and running the whole thing through a chargeback model that treats an agent run as the billable event it is.

The seat let you not think about consumption because the human self-capped. The agent removes the human, and with it the cap. Nobody budgeted for the thing that never sleeps because the old budget assumed sleep. Repricing for a workload that does not stop is not a finance chore you can defer. It is the control that decides whether the fleet is an asset or a leak.

---

The meter was always running. The only question is whether you were reading it. Watch the cost lens at the boundary in We Inspect the Traffic, and treat the fleet as the internal service it is in Agent as a Service.

I write about AI-assisted development, enterprise architecture, and the economics that quietly govern both. Find me on X @orestesgarcia or LinkedIn /in/setsero.