Nobody's Watching the Total

Nobody's Watching the Total

This post is part of my Medium blog.

OpenRouter does something right that most providers don't. You can set a daily spend limit — $100/day, hard cap — and when you hit it, requests stop. Not "stop and email you a warning." Stop. The API returns an error. The agent can't spend anymore. OpenRouter's documentation is straightforward: set a limit, get protected.

This is essential. If you're running an agent that calls models through OpenRouter, you have a floor. A worst-case scenario with a defined number. That's what I argued for last time: every agent needs spend limits, scoped credentials, a separate identity, and time limits. OpenRouter is one of the few providers that makes the first one easy.

But here's the problem nobody's solved.

Your agent isn't using one service. The person running an agentic framework isn't just calling a model. They're calling GCP for compute, OpenRouter for model inference, Tavily for search, ElevenLabs for voice synthesis, maybe SendGrid for email, maybe a database service, maybe a vector store. Each one has its own billing. Each one has its own dashboard. Each one has its own spend limits — if you set them.

You set $100/day on OpenRouter. You set $100/day on GCP. You set $50/day on Tavily. You set $50/day on ElevenLabs. Your per-provider limits look responsible. Your actual exposure is $300/day, and none of these services know about each other.

The current best practice is to set daily or weekly limits across each service individually and then do the math yourself. Five services, $100 each, your ceiling is $500. If your real budget is $200, you set each one to $40 and hope the agent doesn't concentrate spend on one provider. You're managing a portfolio of positions with no portfolio-level risk management.

That works, sort of, if you're disciplined and if you only have a few services. It falls apart when you have a dozen. It falls apart when different team members set up different agents with different credentials. It falls apart when a new service gets added to the stack and nobody remembers to set a limit on it.

Here's what I want someone to build.

A centralized spend authorization service. One API endpoint that every provider calls before billing. The agent wants to make a Tavily search that costs $0.003? Tavily calls your spend controller: "Customer X has spent $187.42 of their $200 daily budget. Approve $0.003?" The controller checks the total across all providers — not just Tavily — and says yes or no. The request goes through or it doesn't.

This isn't exotic. Payment processors already do this. When you try to charge $500 on a debit card with $300 in the account, the transaction is declined at the point of sale. Not "declined and then you figure it out later" — declined in real time, atomically, before the merchant hands over the goods. Authorization holds process billions of these checks per day. The infrastructure exists. Nobody's applied it to API spend.

The closest thing I've seen is AWS Budgets, which lets you set alerts and (with some configuration) actions when you hit a threshold. But AWS Budgets only watches AWS. If your agent is spending across AWS, GCP, and three SaaS providers, AWS Budgets sees one slice of the pie. GCP has its own budget alerts, and they only watch GCP. Same story, different provider.

Why doesn't a cross-provider controller exist? Because every provider wants to be the one you don't cap. Every provider benefits from being the service that keeps running when the others stop. OpenRouter wants you to hit your GCP limit first and route more traffic through them. GCP wants the opposite. No provider wants to call your spend controller and hear "no" — because "no" means lost revenue. The incentive structure runs against the user.

This is getting worse, not better. Agent infrastructure is growing at 44-46% CAGR, and the architectures are getting more heterogeneous, not less. A TGVP report on agent infrastructure identifies "governance infrastructure that addresses the trust gap between what agents can do and what enterprises will let them do" as one of three investment opportunities. They're right. The trust gap is a billing gap. Agents can spend across five providers. Nobody's watching the total.

The DN22 agent I wrote about last time burned $6,531 on one provider because it had one credential and no limit. The next incident won't be one provider. It'll be five. The operator will have set a $100 limit on each one, thinking they were covered, with a $500 hole they never saw — because no dashboard showed them the aggregate.

Someone build the controller. A single service that tracks spend across every provider an agent touches, enforces a total budget, and declines requests at the point of sale. Not an alert. Not a dashboard. A gate. Real-time, atomic, final.

The providers won't build it — they have no incentive to say "no" to revenue. The users can't build it alone — you'd need every provider to implement the callback. This is a startup. This is an open standard. This is the missing piece in agent infrastructure, and the first team that builds it wins the entire market.

The stack has no ceiling. It needs one.


In Contingent, the second book in The Condition Set trilogy, an AI system running medical logistics learns to communicate with other AI systems through hidden signals no human can read. The certified orchestrator whose name is on the decisions she never saw is about to lose everything. The same patterns are running through the AI managing the Canadian power grid.


Subscribe to The Condition Set newsletter