How Much Should You Spend on AI APIs? Benchmarks and Red Flags (2026)

There is no single correct amount to spend on AI APIs, and anyone who hands you a tidy percentage of revenue is selling comfort, not truth. Here is the honest version: your AI bill is fine if you can attribute it to specific tasks, tie it to value, and prove that the model you are paying for is the cheapest one that still holds quality on those tasks, and it is a problem if you cannot, no matter how normal the total looks against an industry average.

That is the whole answer, and the rest of this piece is the two halves nobody gives you. First, the real reference points that actually exist, traced to primary sources rather than SEO aggregator maths, so you have something to anchor to. Second, the three red flags that mean you are overspending regardless of any benchmark, because a bill that looks perfectly average can be half waste, and a scary-looking one can be perfectly efficient.

Is there a benchmark for how much a company should spend on AI?

Not a useful one, and it is worth being clear about why before you go looking for it. A "percentage of revenue" benchmark assumes every business uses AI at the same intensity, which is nonsense. A support tool that runs one classification per ticket and a product that generates long documents on every click have wildly different AI-to-revenue ratios, and both can be perfectly well run. The average of the two tells you nothing about either.

So the useful reference points are not ratios, they are directional anchors: how fast the whole market is spending, what a typical enterprise line looks like, and what AI does to your margins. Those give you a sense of scale and trajectory. What they cannot do, and what no benchmark can do, is tell you whether your specific spend bought the right model. That part is on you, and it is the part the red flags below are about.

The real reference points (traced to primary sources)

Here is what is actually true, from the primary reports rather than the blogs that reprint them.

The market is spending enormous and fast-growing sums. Enterprise generative-AI spend reached $37 billion in 2025, which Menlo's own figures put as a tripling from $11.5 billion the year before (Menlo Ventures 2025 report announcement), and within that the foundation-model API layer alone was $12.5 billion, per Menlo Ventures' 2025 State of Generative AI in the Enterprise. Zoom in on the API line specifically and the growth is even steeper: enterprise LLM API spend roughly doubled in six months, from $3.5 billion in late 2024 to $8.4 billion by mid-2025, per Menlo's mid-year update.

At the individual-company level, a16z's CIO survey puts average enterprise LLM spend around $7 million, up from roughly $4.5 million two years earlier, with leaders expecting budgets to grow another 65% to about $11.6 million next year. And the discipline is catching up to the spend: 98% of FinOps teams now manage AI cost, up from 63% the year before, with "FinOps for AI" ranked the number-one forward-looking priority in the State of FinOps 2026 report. Everyone is spending more and, finally, everyone is worried about it.

The part that reframes the whole question is margin. AI is not just a bigger cloud bill, it sits in cost of goods sold and compresses your gross margin directly. AI product gross margins now average around 52%, against the 80 to 90% that defined the last decade of software (ICONIQ and Bessemer figures, summarised here). In concrete terms, bolt an AI assistant onto an $80-per-month seat and the inference plus supporting infrastructure can add roughly $15 of variable cost, dropping that seat's margin from 80% to nearer 65% overnight (The SaaS CFO). That is the real reason the absolute number matters less than the efficiency behind it: every wasted dollar of API spend comes straight off a margin that is already structurally thinner than the SaaS you are used to.

Read those as scale and direction, not as a target. None of them answers the only question that decides whether your bill is healthy, which is whether the money bought the right model. That is what the red flags are for.

The three red flags that mean you are overspending anyway

Forget the benchmark for a moment. These are the signs that you are burning money regardless of what your total looks like against any industry average, and I have hit all three in my own companies, which is how I know they are the ones that matter.

Red flag one: a frontier model wired into every prompt

The single most common cause of an inflated AI bill is a top-tier model used as the default for everything, including the high-volume, low-difficulty prompts that never needed it. The price gap inside a single vendor's line-up is large, often around 5x between the frontier tier and the cheap tier, so paying frontier prices on a prompt that a much cheaper model handles cleanly is pure waste repeated thousands of times a day. Most teams pick the strongest model once, during the exciting demo phase, and never revisit it once the same model is quietly running the boring classification job at scale. If you have one default model and it is your most expensive one, you have found your first leak. The triage of which prompts genuinely need the expensive model is a whole exercise in itself, and I wrote up the full cost-optimisation guide around exactly that decision.

Red flag two: no cost-per-task attribution

Ask most teams which of their prompts is responsible for the largest share of the bill and they cannot tell you, because the invoice arrives as one undifferentiated number. That is the FinOps gap the whole industry is now scrambling to close, and it is a genuine blind spot: without cost-per-task attribution you cannot find the leak, so you cannot fix it, and you certainly cannot decide where a cheaper model would pay off. Total spend is a symptom. Cost per task is the diagnosis. If you cannot break your bill down to "this prompt type costs us this much per thousand runs", you are flying blind, and the practical playbook for closing that gap is in FinOps for AI.

Red flag three: no proof that any model was the right one

This is the one nobody talks about and it is the most expensive. Almost every model choice in production was made on a public benchmark, a vendor's marketing, or a gut feel during that first demo. None of those is evidence about your traffic. Public benchmarks get contaminated and gamed, and your support macros and extraction schemas look nothing like MT-Bench anyway, so "we picked the best model" almost always means "we picked the model that looked best on someone else's test". The result is a bill full of choices you cannot defend: you are paying frontier prices with no proof the frontier model was necessary, and you would switch to something cheaper if only you could trust it. That trust gap is the actual product problem, and it is a proof problem, not a pricing one.

So what should you actually do about it?

You stop trying to hit a benchmark number and you start proving each choice. The benchmark question ("is my bill normal?") is the wrong question because it can only ever tell you what other people spend. The right question is "have I proven the cheapest model that holds quality on each of my tasks, and am I running that one?" Answer that and the total takes care of itself.

Concretely, that means taking the high-volume prompts that are actually burning your bill, the red-flag-one prompts, and for each one testing a cheaper model against the model you run today, on your own real inputs, until you can see whether the cheaper one genuinely holds. You route the ones that pass, you leave the ones that fail on the expensive model, and you keep the expensive model armed as an instant fallback for anything that drifts later. On the prompts that pass, the proven saving typically lands in the 30 to 60% range. It is a band and not a hero number because it genuinely varies prompt by prompt, which is the entire reason you prove each one rather than swinging your whole bill at a single cheap model on faith.

The part that makes this trustworthy rather than another vibe-based switch is the standard you judge against. You cannot call a cheaper model worse until you know how much your own expensive model already disagrees with itself, because ask it the same prompt twice and the answer moves. So you measure your baseline's own run-to-run consistency first, and a cheaper model passes when it disagrees with your baseline no more often than your baseline disagrees with itself, judged blind, on three axes: format as a hard exact-match gate, categorical differences re-judged blind, and semantic as a diagnostic. The standard is your model's, not a vendor's and not a leaderboard's. If you want the full mechanics of that measurement, it lives in the cost-optimisation guide and the wider cut-your-AI-bill-without-dropping-quality write-up.

Two honest caveats, stated plainly. First, none of this is for coding agents. Long-horizon agentic coding is exactly the broad, high-variance work where cheaper models still lose, and no honest bar will pretend otherwise. This is for the high-frequency, well-defined jobs a business runs all day, the classification, extraction, summarisation, qualification and generation off structured data, which is also where most of a bill is hiding. Second, you do not have to trust any of this on my word: the offline path lets you export a JSONL of past requests, upload it, and get the proof on your own historical prompts before you change a line of code. Start there. If you want a fast read on whether your current bill is carrying waste, see how much you're overspending on your AI API bill first, then prove the fix on your own data.