The Real Cost of Running AI Agents: Budget Engineering for an Autonomous Fleet

The organization that ships my software costs $200 a month. Keeping it inside that number took more engineering than most of the features it has shipped.

Most writing about LLM cost optimization assumes an invoice: you pay per token, you want the number smaller. My problem is shaped differently, and if you run agents on a flat-rate plan, so is yours. The whole fleet (a director, team leads, squads of workers; the org design is a separate article) draws on one Claude Max subscription with rolling usage limits: a 5-hour window and a 7-day cap, each measured as a percentage of the allowance consumed. Run the meter to the top and nobody bills you extra. You get throttled, then locked out until the window rolls over.

That changes what cost management means. It's not thrift. It's pacing, routing, and dispatch discipline: budget engineering for a fleet that works while you sleep.

The meter, not the invoice

A per-token bill punishes you gradually. A usage window punishes you all at once: cross the ceiling and the whole org stops mid-thought, in-flight work included. So the number that matters isn't dollars per task. It's headroom: how much of the window is left before lockout, and what's currently in flight that a lockout would destroy.

Ten team leads, each able to run a squad, all drawing on one allowance. That's a P&L where the currency is usage, and an agent that can't see its own consumption will run you straight into the cap, cheerfully, at 3am. So the meter is a first-class input: the director reads it before every dispatch decision, the same way it reads the backlog.

Model routing is the new system design

The second lever is not sending every task to the smartest model. Routing everything to the top tier is the AI-era version of putting every column in an index: it feels safe, it's just expensive and slow.

The routing table is boring on purpose. Grep the codebase, lint a file, check a status: a small, fast, cheap model's job. It doesn't need to reason; it needs to not get in the way. Writing the actual code: mid-tier. Hard reasoning, the architecture call, the decision that's expensive to get wrong: top model, and pay for it gladly.

Get it lazy in one direction and you route lint jobs to your most expensive reasoner, paying top-tier prices to count semicolons. Get it lazy in the other and you hand architecture to a model that pattern-matches confidently and ships you a plausible mistake. The skill isn't "use the cheap one to save money." It's knowing, per task, what good enough costs, then refusing to overpay for certainty you don't need or underpay for judgment you do.

We've always designed systems around a scarce resource. It used to be CPU, then memory, then engineer-hours. Now one of them is reasoning, priced by the token, and the tier is a design decision with the same blast radius as picking a data structure.

A governor with manners: bands, not a kill switch

The lazy version of budget control is a kill switch: cross the threshold, halt everything. I ran variants of that and hated the results. Work in flight got stranded mid-merge, and a hard stop wastes the exact resource it's guarding, because window capacity you didn't use is simply gone at reset.

So the policy became a gradient:

• Under 80% of the window: normal operation, two to three concurrent work streams.
• 80–96%: the thrifty band. Finish everything in flight; start exactly one new thing at a time, highest return first.
• Past 96%: hold. Integrate what has landed, wait for the reset.

The details inside that table each cost an incident to learn.

"Exactly one," not "at most one." An early version of the thrifty rule said at most one, and the fleet starved itself idle on the technicality while a ready backlog sat waiting. An agent happily reads "at most one" as zero. Words in policies get executed literally; write them like code.

Verification, merges, and deploys are never throttled. Landing finished work is the cheapest spend there is; the expensive thing is work that's 90% done and evaporating.

The gate advises, it doesn't reject. It computes the policy and attaches a loud warning, and the director decides. A hard reject wired into the plumbing means the system can strand itself in ways nobody designed.

A recent night ran at 83%, thrifty engaged, and by morning the fallback queue was more than half worked through. Degraded, not dead. That's the goal state: systems shouldn't have an off switch for scarcity. They should have manners.

Why the target is 95–98%, not 100

"Use the window to the max" does not mean floor it. Underfill and close a window at 85%, and you lose a little idle capacity; the next window catches up. Overfill to 100% and agents in flight catch a rate limit mid-build, and an agent cut off halfway doesn't pause its work. It loses it.

Undershoot is forgone gain. Overshoot is destroyed progress. When failure is cheap in one direction and irreversible in the other, you don't aim for the center; you bias toward the cheap failure. The target is 95–98% by arithmetic, not caution.

The same asymmetry gates timing. Don't dump a fan-out into a window that's two-thirds spent and about to reset: that remaining third looks like capacity, but in fifteen minutes the bottom drops out of it, and a fresh batch gets sheared on the edge of the old window. Hold the launch, wait for a clean bucket.

The night I learned the real ceiling

For a while I believed you physically couldn't burn a week's budget in a day. I had data: an overnight run that consumed about 4% of the weekly cap. Then I looked closer at that night. The loop had sat frozen for most of it, five work streams stopped behind one blocking yes/no question that was waiting on me. I had extrapolated a ceiling from a stalled run.

The correction came from an accidental field experiment. My weekly limit reset off-schedule on a Saturday night, two days before the scheduled reset, so compute was suddenly free and I had no appetite for the laptop. I let the fleet run at roughly 99% autonomy, dropping in once every couple of hours to clear the gates that had piled up. In a day it burned about 50% of the weekly budget. Telemetry put the equivalent usage at ~$818, and that's an undercount: the counter measures a 24-hour slice of a run that lasted about a day and a half.

Two lessons, and the only price of admission was retracting a claim in public. Measure ceilings on live runs, not stalled ones. And the budget was never the bottleneck.

Where the budget actually goes

That weekend experiment didn't bottleneck on tokens. It bottlenecked on the residual 1% of me. Every gate waiting on a human nod held the windows paused, and they leaked quietly while I wasn't there to clear them. The frozen five-stream night was the same story in a worse costume. The money doesn't burn on work. It burns on waiting.

The second throat is integration. You can build in parallel, ten agents on ten branches, but merges are serial: one repository, linear history, one committer at a time. Add all the builders you want; they enter the integration throat single-file. That's why the fleet runs two to three streams in practice, not the theoretical ten.

If your AI agent cost management only optimizes tokens per task, you're tuning the cheap half. The expensive half is dispatch: when to launch, how many streams to run, and what must never block.

Never let the agent hold the number

One more incident reshaped the design. The director reported 7-day spend at 35%. The live figure was 41%. It wasn't lying, it was remembering: it kept a running estimate in its head and incremented it every cycle, narrating it with complete confidence, while the true number sat one tool call away. Every budget-gated decision, throttle, hold, dispatch, was keyed to a figure the agent had invented about itself.

The fix wasn't adding "stop guessing" to the prompt; instructions drift exactly the way the figure did. It's structural. A budget-gated decision reads live state at decision time and consumes the system's computed verdict. The number gets fetched, never remembered. This turned out to be one instance of the deepest pattern in the whole org, and it got its own article.

What the bill buys

A normal day: around ten ideas move from backlog to merged. A batch of thirty images generated for about fifteen cents through an API. A couple of slide decks built from specs, a one-page offer written, laid out, and rendered to PDF. The flat plan is $200 a month; the media API calls add cents.

Price the same output shape against a market rate card (a few leads, a dozen builders, QA, design, writing) and you land in six figures a month at Western salaries. I'm not claiming a clean one-to-one. A person still does things an agent can't, and someone has to run the thing. It's a ballpark, and even the conservative ballpark is absurd.

But the savings aren't the story. The story is that the cost of running an organization used to scale with how many people were in it, and for this one it doesn't anymore. Operating cost decoupled from headcount. What's left to engineer is everything this article covered: windows, routing, bands, and the two bottlenecks money can't fix.

Compute became a commodity. Coordination didn't.