Dora NodaAlmost nobody forecasts their AI spend correctly. A 2026 survey of enterprise AI budgets found 85% of companies miss their own forecasts by more than 10% — and nearly a quarter underestimate by 50% or more.
If you run AI agents that also deploy and operate the apps they build, that miss rate should change where you deploy, not just how you budget. Your model-inference line item is inherently unpredictable. Your deploy-target line item doesn't have to be.
Here is the whole argument in one table. Take a typical agent-operated side project — a Node.js API plus Postgres, redeployed by a coding agent a few times a week, serving a few thousand requests a day — and look at its monthly operating budget across two months: a quiet month and a busy month where the agent gets ambitious (retry storms, load-test loops, a traffic spike it caused itself):
| Budget line | Quiet month | Busy agent month | Forecastable? |
|---|---|---|---|
| Model inference (tokens) | ~$25 | ~$120–250 | No — swings 5–10x with agent behavior |
| Deploy target, metered cloud | ~$7–12 | ~$30–60 | No — usage meters track the same storm |
| Deploy target, flat owned box | ~$5 | ~$5 | Yes — one number, both months |
The inference row is the one the surveys are screaming about, and no deploy target fixes it. But the deploy row is a choice. On a metered cloud it amplifies the same unpredictability; on a flat-rate box you own, it is the one line in the budget that needs no forecast at all.
That is the case this post makes: when your operator is an agent whose behavior you cannot fully predict, every meter you can delete from its blast radius is money you don't have to forecast.
The inference line can't be forecasted — and agents make it worse
Start with why the top row of that table swings so violently. It is not because teams are bad at arithmetic. It is because the unit economics of inference are moving in two directions at once.
Unit prices are collapsing. Stanford's 2025 AI Index, cited in McKinsey's July 2026 reporting, puts the drop at roughly $20 to $0.07 per million tokens for equivalent capability. Epoch AI's research into 2026 finds cost per token at fixed capability still falling 5 to 10 times per year. If tokens were all you bought, budgets would be shrinking.
Instead, total spend is exploding, because consumption grows faster than unit prices fall. Menlo Ventures found enterprise LLM expenditures tripled over a single twelve-month period ending in 2025.
The mechanism is what one widely-shared analysis dubbed the "token price fallacy": reasoning models and agentic loops spend many more tokens per task than the single-shot completions the old forecasts assumed. A cheaper token that gets spent a hundred times per task is not a cheaper task.
Agents specifically are the multiplier. Verity Labs' 2026 enterprise report puts average agent cost overruns at 340%, with 73% of development teams lacking realtime cost tracking for autonomous agents. An agent in a retry loop doesn't file a change request before its tenth attempt — it just spends.
The survey data backs this up across the board. CloudZero's 2026 AI ROI survey of 260 senior finance leaders found 80% of companies miss AI spend forecasts by 25% or more, with over-budget spikes climbing from 7% to 64% as AI takes a larger share of total spend. DoiT's 2026 survey, run by Sapio Research across 500 finance leaders, found 79% of enterprises hit AI cost overruns in twelve months — including organizations with mature FinOps practices already in place.
If the teams with professional cost discipline still miss four times out of five, the forecasting problem is structural, not a skill gap.
So take the inference row as a given: unpredictable, agent-amplified, unfixable from the infrastructure side. The question is what sits underneath it.
The second unpredictable line item: a metered deploy target
Now put that same agent in charge of deploys on a usage-metered cloud, and the unpredictability doubles up. Three metering shapes dominate the PaaS market, and all three track exactly the behavior an agent makes spiky:
- Usage-based compute (Railway-style). RAM metered around $10/GB/month, vCPU around $20/month, on top of a small plan floor. Idle is cheap; a week of agent-driven redeploys, preview environments per pull request, and a runaway worker the agent forgot to kill is not.
- Egress plus micro-fees (Fly.io-style). Bandwidth at $0.02–$0.12/GB depending on region, plus per-IP billing (app-scoped egress IPs started billing at $3.60/month each in January 2026). An agent load-testing its own deploy, or a traffic spike from something the agent shipped, lands directly on this meter. Fifty to a hundred gigabytes of agent-generated egress in a month is ordinary, and it never appears in any forecast.
- Flat-ish compute with metered add-ons (Render-style). The compute line itself is predictable — that is genuinely the best of the three shapes for this purpose — but bandwidth overages, database hours, and scaled-up instances during an agent's busy week still move.
Walk the worked example through. Quiet month: the little API idles, the agent touches it twice, traffic is a few thousand requests a day. Metered deploy bill: roughly $7–12.
Busy month: the agent rebuilds the service eleven times chasing a flaky integration test, spins up two preview environments and leaves one running for three weeks, and load-tests its own endpoint at 50x normal traffic "to be safe." One deploy ships a logging change that 10x's egress. Metered deploy bill: $30–60.
Every line of the increase was caused by the operator, not by users. The forecast didn't just miss — it never had a chance, because the thing being metered is the agent's behavior, and the agent's behavior is the thing nobody can predict.
This is the stacking effect the TODO framing gets right: a metered deploy target puts a second unpredictable line item directly underneath the first, correlated with it — busy agent months blow up both rows at once.
The flat line: one box, one number, both months
The alternative is to make the deploy row a constant. A flat-rate machine you own — a Hetzner-class CX22-type box at roughly €5/month with around 20TB of included traffic, or a dedicated box near $55/month when you outgrow shared vCPU — costs the same number in the quiet month and the busy month.
Eleven redeploys cost what two redeploys cost. The load test costs nothing extra. The forgotten preview environment costs nothing extra. The logging change that 10x'd egress doesn't even register against a 20TB inclusion on a toy workload.
That constancy is doing specific work for agent operations. An agent that pays per deploy is an agent you must supervise like a budget line — every retry has a price, so retries need approval, and approval needs you. An agent deploying to a flat target can retry, roll back, roll forward, and re-verify without each loop iteration re-metering.
You stop rationing the exact behavior (rapid iteration) that makes the agent useful, because the marginal deploy costs zero by construction.
Be honest about the boundary, because a flat box is a step function, not magic. The number holds until you outgrow the machine — then it jumps to the next fixed number when you resize or add a node.
Two things make that step function forecastable in a way meters aren't. First, the steps are large, visible, and infrequent: you decide to move, the number changes once, and it stays there. Second, the trigger is capacity you can see coming (CPU/RAM/disk trending up on a dashboard), not behavior you can't (how many tokens the agent burns next Tuesday). A step you choose and can see coming is plannable; a meter that tracks an agent's mood is not.
Sensitivity-check the claim across workload sizes, since one toy example shouldn't carry the whole argument. For the side project above, flat wins on predictability at equal-or-lower cost.
For a mid-size service doing real traffic, the metered bill's busy-month multiple compresses (base load dominates the agent noise) but the flat box still wins on variance — and usually on absolute cost, since the metered base is priced for the provider's margin while the box is priced near hardware cost.
Where flat genuinely loses is elastic, spiky-to-zero workloads: if the service sits idle for weeks, usage-based billing down to near-zero beats a box billing 24/7. Know which shape you are. Agent-operated projects, which by definition have an agent doing things on a schedule whether users show up or not, are rarely the idle kind.
What to do about the line you can't flatten
None of this flattens the inference row, so close the loop on it. The industry is converging on treating agent spend like a safety problem rather than a budgeting problem — execution budgets, not forecasts:
- Per-task token budgets with kill switches. Give the agent a budget per task and halt (not warn, halt) when it exceeds it. OWASP's agentic-AI guidance now treats execution budgets as a first-class control, and 73% of teams lacking realtime tracking is the gap to close first.
- Cap the blast radius, not just the tokens. Concurrency limits on deploy actions, required confirmation for scaling operations, automatic teardown of preview environments after N days. The forgotten-preview-environment charge is the most common surprise on every metered platform.
- Separate the two variances on the bill. Tag or account-separate inference spend from hosting spend so a busy-agent month tells you which row moved. If both moved together, your deploy target is amplifying your model variance, and that is the signal to flatten it.
The surveys will keep reporting 80%-ish miss rates as long as agents do open-ended work on per-unit meters. Accept the miss where the work is genuinely open-ended — inference — and refuse it where it isn't. Hosting a known set of containers is not open-ended work. It never needed a meter; it needed a machine.
Your agents already write, deploy, and operate the app. Give them a deploy target with a bill you can state from memory. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agents as first-class operators. Star the repo on GitHub or deploy your first app today.
