The first: a Norwegian startup called Vegalabs had about $25,000 of Microsoft for Startups credits. In August it switched on Claude through Microsoft Foundry, expecting the credits to cover it. They didn't. Anthropic models bought through Azure Marketplace are excluded from those credits, so the usage went on the company card instead. The invoice reached $17,600 before tax, and $21,168 of unused credits then expired. When it asked for help, Microsoft pointed it at Anthropic and Anthropic pointed it back at Microsoft. At the time of writing, it still has the bill.

To their credit, Vegalabs say plainly that they didn't read the exclusions or set a budget alert. Their complaint is that the screens didn't make the separate billing obvious. Both things can be true.

The second: an AI security firm called Geordie tested OpenAI's new always-on assistant, dot, with read-only access and nothing connected to email or Slack. In a day, without anyone asking it to do anything, it ran 155 bits of activity, spun up its own short-lived sub-agents and got through about 307,000 tokens. The Register reckons that's a few dollars. The money isn't the point. The point is that nobody asked for any of it.

How AI bills actually run away

With normal hosting you pay for a server and it sits there. AI is metered by the token, every time the software asks the model something. So the bill is decided by how your code behaves, not by how many people use it. The usual culprits are dull:

  • Loops. An agent that keeps calling the model until it's "happy" can go round hundreds of times on a bad day.
  • Retries. A request times out, the code tries again, and again, and each attempt is billed.
  • Big contexts. Sending the whole conversation history or a full document with every request means paying for the same words over and over.
  • Background agents. As the dot test shows, agents can go off and do work nobody can see.
  • Credits that don't cover what you think. Free credits, startup credits and marketplace bundles all come with small print. The Vegalabs bill is that small print.

The boring controls that stop it

None of this is clever. It's the AI version of putting a lock on the stationery cupboard. But we'd want every one of these in place before an AI feature goes anywhere near real customers.

Know which bill the AI is on. Before you switch anything on, find out exactly which account pays for it and whether your credits apply. If it's through a marketplace, assume it's billed separately until someone shows you in writing that it isn't.

Set a hard limit, not just an alert. This is where the providers differ, and it matters. OpenAI lets you set a spend alert, which just sends a notification, and a hard spend limit, which makes requests fail once you hit it. OpenAI's own docs warn that a hard limit can interrupt production traffic, and that spend can go slightly over before it kicks in. Anthropic's Claude Console lets you cap monthly spend per workspace and set alerts at thresholds (though not on the Default Workspace, so create your own). Azure budgets are different again: Microsoft says plainly that resources aren't affected and spending isn't stopped. They send emails, and cost data can take 8 to 24 hours to show up. So on Azure, an alert is all you get unless you build something to act on it.

Separate keys for separate things. One key (and on Claude, one workspace) per feature and per environment. Testing goes on a different key from live. That way a runaway test can't eat the budget for the live system, and when the bill jumps you can see which feature did it.

Put limits in the code as well. Cap how many steps an agent can take. Cap how many times a request can be retried. Set a maximum response length. Trim what you send so you're not paying for the same history on every call. These are a few lines each, and they're the ones that save you at 3am when nobody is reading alert emails.

Log the tokens. Record how many tokens each request used, against which feature and which customer. If one customer or one screen is costing ten times the rest, you want to find out from your own logs, not from your card statement.

Use the smallest model that does the job. Plenty of jobs (sorting, tagging, pulling fields out of an email) don't need the biggest model. The cheaper ones are often a fraction of the price and plenty good enough. Test both and pick on results, not on the name.

Keep agents on a short lead. Geordie's advice was to expect agents you didn't plan for and to scope them narrowly. We'd agree. Give an agent access to the one thing it needs, not everything it could possibly use.

Decide who owns the account and the card. The AI account should belong to the business, not sit on a developer's personal login. The card should be one where a surprise charge gets noticed. And alerts should go to at least two people, one of whom isn't the person who wrote the code.

Sized for a small business

If you're a small firm adding a chatbot or an AI feature to your system, you don't need a finance team for this. You need about half a day: a hard cap set comfortably above what you expect to spend, an alert at half that, separate keys for test and live, limits in the code, and a simple log. That's it. Then look at the numbers once a month for the first few months, because your real usage will tell you far more than any estimate.

We cover what AI features tend to cost to run in what AI-built software really costs. If you're building with AI and want someone to check it over before it goes live, spending limits included, that's part of our AI code audit. And if you'd rather we built the AI feature properly in the first place, have a look at how we approach AI software development.

Either way, set the cap today. It's a lot less painful than the email from your bank.

Cheers, Rob