The AI Efficiency Trap: Why Cheaper Costs More
The AI budget horror stories are everywhere now. A FinOps hire in every job feed. A LinkedIn post every morning about a bill nobody saw coming. The receipts are real and they are large.
In 2025, Uber handed roughly 5,000 engineers access to Claude Code. By April 2026 the company had burned through its entire annual AI budget. One healthcare firm ran a trillion tokens through models over six months and picked up more than six million dollars in costs nobody had planned for. Meta’s own employees consumed nearly 74 trillion tokens in about a month, and Meta started capping internal token spend. By 2026, 73 percent of enterprises said their AI costs had blown past the original projection, and the share of finance teams responsible for managing AI spend went from 31 percent to 98 percent in a single year.
The reflex read is simple: AI is expensive, so wait for it to get cheaper.
Here is the part that should stop you. It already got cheaper. The blended price of a million tokens fell about 67 percent in one year, from $18.40 to $6.07. For a fixed level of quality, some prices dropped by a factor of a thousand. And over the same stretch, enterprise spending on generative AI did not fall. It rose 320 percent, from $11.5 billion to $37 billion.
Cheaper was the trap.
Under all the panic sits a durable economic law, one that predates AI by 160 years. When a resource gets cheaper to use, you do not use the same amount for less money. You use far more of it, until your total bill climbs even as the unit price craters. That is the efficiency trap, and for a founder it quietly inverts the single best thing about software: that once you have built it, serving the next customer costs almost nothing. I run two companies where AI writes most of the code and answers a lot of the customers, and the efficiency trap is the thing I watch more closely than any model release. This is the map for what it is, why it breaks the software playbook you inherited, and the discipline that turns cheaper tokens into margin instead of into a bigger bill.
Table of Contents
- The Problem: Software’s Best Assumption Just Died
- The Efficiency Trap: Cheaper Tokens, Bigger Bills
- The Four Forces That Move Your AI Bill
- Why the SaaS Playbook Breaks on AI
- The Agent Multiplier: How Tokens Per Task Exploded
- The Forecasting Problem: Budgets Built for the Wrong Shape
- The Meter Mindset: Running a Metered-Cost Business
- The Contrarian Take: Is Gross Margin a BS Metric?
- What to Do Monday Morning
- FAQ: The AI Efficiency Trap
The Problem: Software’s Best Assumption Just Died
Every software business you have ever admired was built on one quiet miracle. The cost of serving one more customer rounds to zero.
You write the code once. The tenth customer and the ten-millionth customer cost you almost the same to serve, which is to say almost nothing. That single fact is why software companies carry gross margins in the 80 to 90 percent range while a restaurant fights for 5 percent. It is why a small team can build something that prints money at scale. It is the reason venture capital fell in love with the category. Marginal cost near zero is the engine under the whole machine.
AI products do not have that engine.
When your product calls a model, you pay for that call. Every time. The tenth customer costs you real compute, and the ten-millionth costs you ten million times as much. Your cost of goods sold is no longer a rounding error you can ignore on the way to a beautiful margin. It is a metered utility bill that grows with every active user, every session, every retry. You did not buy a printing press. You rented a taxi meter, and it runs whenever the product works.
This is not a small adjustment to the model. It changes what “winning” does to your bank account. In classic software, more usage is pure upside, because the revenue climbs and the cost barely moves. In an AI product priced carelessly, more usage can mean more loss, faster, because every unit of that usage carries a variable cost you may have priced below. Success stops being an unambiguous good and becomes a thing you have to survive.
The founders who get hurt are not careless. They are applying a mental model that was correct for fifteen years and is now quietly wrong. They budget like the cost is fixed. They price like the margin is 85 percent. They celebrate a usage spike that is actually a cash leak. The efficiency trap punishes exactly the instincts that made software such a good business.
The Efficiency Trap: Cheaper Tokens, Bigger Bills
The trap has a name older than computing. In 1865 the economist William Stanley Jevons noticed that when steam engines got more efficient with coal, England did not burn less coal. It burned far more, because efficiency made coal useful for a thousand new things. Cheaper per unit, larger total. The efficiency created its own demand.
Swap coal for tokens and you have the AI economy. When the price of intelligence falls, you do not do the same work for less. You do far more work, because things that were too expensive to be worth it yesterday are suddenly cheap enough to ship. You run the model on every support ticket instead of the hard ones. You add a reasoning step, then three. You let an agent loop until it is sure instead of answering once. Each of those choices is rational on its own. Together they mean your consumption grows faster than the price falls, and the bill goes up.
This is why the “just wait for it to get cheaper” plan fails. Cheaper is not a discount you pocket. It is an invitation you accept. The moment inference drops in price, your product team, your agents, and your users all find new ways to spend the savings, and they find them faster than you can forecast. One study of consumption put it exactly right: agentic workflows, with their token multipliers, absorb every price reduction before you ever notice it on your bill.
So the founder question is not “when will tokens be cheap enough.” Tokens are already cheap and getting cheaper, and the bills are already scary and getting scarier. The real question is whether you have the discipline to convert falling unit prices into margin, or whether you will let them convert into more consumption. Everything that follows is about winning that specific fight.
The Four Forces That Move Your AI Bill
Founders talk about “the price of tokens” as if that one number decides their costs. It does not. Your monthly AI bill is a product of four separate forces, and the token price is only one of them. Get the other three wrong and the cheapest model on earth will still bankrupt you.
Here is the whole thing in one line. Your bill equals the price per token, times the tokens per task, times the tasks per active user, times the number of active users. Multiply them together and you have your compute cost. Now look at which direction each one moves.
Only the price per token is falling. The other three all climb, and they climb for reasons you actually want. Tokens per task go up because you added reasoning and agents that do more thinking per request. Tasks per user go up because people build the product into their habits and lean on it more. Active users go up because you are growing, which is the entire point. Every one of those is a sign of a healthy product. Stacked together, they overwhelm the one number that is dropping.
Watch what happens with real numbers. Imagine a product where the price per million tokens gets cut in half over a year, from six dollars to three. Good news, right? Now add the other forces. You shipped an agent, so tokens per task jump from 8,000 to 40,000. Users get more hooked, so tasks per active user go from 20 a month to 60. And you grew, from 1,000 active users to 4,000.
| Force | Year 1 | Year 2 | Direction |
|---|---|---|---|
| Price per 1M tokens | $6.00 | $3.00 | down 50% |
| Tokens per task | 8,000 | 40,000 | up 5x (agent) |
| Tasks per active user / month | 20 | 60 | up 3x |
| Active users | 1,000 | 4,000 | up 4x |
| Monthly inference bill | $960 | $28,800 | up 30x |
The price per token dropped by half, and the bill went up thirty times. Nothing in that story is a mistake. You built a better product, more people used it more often, and it cost you thirty times as much to run. If your revenue did not also grow thirty times, and it rarely does, your margin just got worse in the exact quarter you were celebrating. That is the efficiency trap doing its work, and no amount of waiting for cheaper models fixes it, because cheaper models are already priced into the story.
Why the SaaS Playbook Breaks on AI
If you learned to build companies in the cloud era, you inherited a set of assumptions that were not just true, they were load-bearing. They shaped how you budget, how you price, and how investors value you. Almost every one of them cracks under a metered-cost product.
| The SaaS assumption | Why it held for cloud software | Why AI breaks it |
|---|---|---|
| Marginal cost is near zero | Serving one more user was almost free once the code existed | Every request burns metered compute you pay a vendor for, forever |
| Scale expands margin | Fixed build cost spread over more users, so margin improved with size | Usage-linked cost grows with every active user, so scale can compress margin |
| Gross margin lives at 80 to 90% | Hosting was a thin slice of revenue | Inference alone runs near a quarter of revenue and rises with use |
| Costs are predictable | Seats times price made both revenue and cost roughly linear | Tokens per task swing 10 to 100x by workload and model choice |
| Success is pure upside | More usage meant more revenue at nearly full margin | More usage can mean more loss if a feature was priced below its variable cost |
The numbers behind that third row are worth sitting with, because they are what investors are quietly repricing. Bessemer’s State of AI work put gross margins for model-native companies around 65 percent, well under the 80 to 90 percent that defined the last decade of cloud. ICONIQ’s early 2026 snapshot pegged the average AI product gross margin at 52 percent, up from 41 percent two years earlier but still nowhere near classic software. On the ground, that means for every million dollars of AI product revenue a company books, roughly $230,000 walks out the door as inference before a single salary is paid. The 80 percent gross margin that built a generation of software companies is becoming the exception, reserved for the rare team that either uses very little AI or has engineered an unusually careful cost stack.
This ripples straight into how you get valued. The Rule of 40, the shorthand investors use to judge whether growth plus profitability clears a healthy bar, quietly assumed software margins. A business growing 25 percent at 80 percent gross margin is a very different animal from the same business growing 25 percent at 67 percent, even if the top line looks identical. When you raise, you are not just selling growth anymore. You are selling the credibility of your unit economics, and “we will figure out margins later” lands very differently in 2026 than it did in 2019. If you have watched pilots stall on the way to production, the cost structure is often the hidden reason, which I wrote about in The Production Gap.
The Agent Multiplier: How Tokens Per Task Exploded
Of the four forces, one deserves its own section, because it is the one founders most consistently underestimate and the one that is growing fastest. Tokens per task.
A year ago, “using AI” mostly meant a chat call. You sent a prompt, you got an answer, you paid for a few hundred or few thousand tokens. The whole industry has since moved to reasoning models and agents, and both of them spend tokens the way a teenager spends someone else’s money. A reasoning model thinks out loud in tokens you pay for before it answers. A simple query that returns seven tokens on a plain model can consume 603 tokens on a reasoning model. That is 86 times the cost for the same visible output. By 2026, more than half of all output tokens flowing through some large routing services were internal reasoning tokens, meaning the model was talking to itself on your dime.
Agents make it worse, and they make it worse on purpose, because that is how they get better answers. An agent does not answer once. It plans, calls tools, reads results, corrects itself, and loops until it is satisfied. A modest tool-calling agent runs 5,000 to 15,000 tokens for a single task. A complex multi-agent system, the kind everyone is racing to ship, can burn 200,000 to more than a million tokens on one task. Measured against a plain chat call, agentic systems spend 5 to 30 times more tokens per task, and the high end is far higher than that.
Put those two shifts together and you get the quiet reason bills explode. Average prompt sizes roughly quadrupled in under two years as context windows grew and people stuffed them. Completion lengths tripled. The token price per unit fell the whole time, and it did not matter, because the number of units per task was climbing faster. This is exactly why agent-heavy roadmaps need cost thinking baked in from the first design conversation, not bolted on after the invoice arrives. I go deeper on the design side of agents in Loop Engineering, but the economic point is blunt: every loop you add to an agent is a multiplier on your bill, and most teams never count the loops.
The trap tightens here. The better your agent gets, the more steps it is willing to take to be right, and the more it costs per answer. Quality and cost move together. You cannot simply tell the agent to think less, because thinking less is what made the old chatbots useless. So the discipline cannot be “spend fewer tokens.” It has to be “know exactly what each task costs, and decide on purpose whether that task is worth it.” Which brings us to the part almost nobody does.
The Forecasting Problem: Budgets Built for the Wrong Shape
There is a second reason AI spend blindsides founders, and it is not about the average. It is about the shape.
Software costs are smooth. One month’s hosting bill is a near-perfect predictor of the next, so a single annual number, divided by twelve, is a fine way to budget. AI costs are spiky and workload-dependent in a way that breaks that habit. The same feature can cost a few hundred tokens for one user and half a million for another, depending on how hard their problem is and how many times the agent loops to solve it. Tokens per task swing by 10 to 100 times across a normal range of real usage. You are not budgeting a utility with a steady draw. You are budgeting something closer to a call center where any given call might take thirty seconds or three days, and you learn which only after the work is done.
That variance is why the annual budget is the wrong instrument. A number set in January assumes a distribution you have not measured yet, and the field moves fast enough that the distribution shifts under you. A new model launches and your team rewrites a workflow to use it. A big customer onboards and their usage pattern looks nothing like your existing base. An agent you shipped a quarter ago starts getting used the way you hoped, and the hope carries a token cost. None of these are failures. They are just the reasons a static forecast is stale within weeks.
The teams that handle this well stop forecasting a single number and start watching a rate. They track cost per active user and cost per successful task, week over week, and they care more about the direction of those two lines than about hitting an annual figure. A rate you watch beats a budget you set and forget, because the rate tells you the trap is tightening before the invoice does. It also turns cost into a product signal: when cost per successful task starts climbing, that is usually a feature quietly changing behavior, and you want to know which one while it is small.
The Meter Mindset: Running a Metered-Cost Business
Here is the uncomfortable truth about most AI startups in 2026. They have no idea what anything costs. They get one lump invoice from a model vendor at the end of the month, they wince, they pay it, and they have no way to say which feature, which customer, or which workflow ate the money. They are flying a plane with the fuel gauge taped over.
The fix is not a tool you buy. It is a mindset you adopt, the same one utilities and cloud teams adopted decades ago. Treat compute as a metered resource that has to be measured, attributed, budgeted, and priced, on purpose, as a core discipline of the business. I think of it as a maturity ladder, and most teams are sitting on the bottom rung without knowing there are four more above them.
| Rung | What you can see | What you can control | Typical result |
|---|---|---|---|
| 0. Blind | One lump vendor invoice | Nothing until it hurts | Surprise overages, panic cuts |
| 1. Metered | Spend by feature, customer, and model | Where the money actually goes | You stop guessing |
| 2. Budgeted | Spend against a budget, in real time, with alerts | Caps, throttles, and kill switches | No more budget blowouts |
| 3. Priced-In | Margin per feature and per customer | Which usage you charge for, cap, or kill | You charge for what you burn |
| 4. Architected | Cost per successful task | Routing, caching, smaller models, owning the loop | Cheaper tokens become margin, not more spend |
The jump that changes a company is from rung 0 to rung 1. The moment you can attribute spend to a feature and a customer, everything downstream gets possible. You find out that one power user is costing you more than they pay. You find out that a feature nobody talks about in sales calls is eating a third of your compute. You find out which model calls are worth their price and which are vanity. None of that is visible from the lump invoice, and all of it is obvious the moment you meter.
Rungs 2 and 3 are where the business gets safe. Budgets with real alerts mean the Uber story does not happen to you, because a throttle trips before the annual number does. Pricing that reflects cost means a usage spike is good news again, because you charge for the thing you burn. This is the connective tissue between cost and revenue, and it is why I treat pricing as a cost decision as much as a growth one, which I argued in AI Product Pricing: Why Per-Seat Is Dead.
Rung 4 is the tactical layer, the routing and caching and model selection that squeezes cost per successful task. It is real and it matters, and I laid out that playbook in The Cost-First AI Product Launch. But notice it sits at the top of the ladder, not the bottom. Optimization without measurement is guessing. Teams love to jump straight to “let us route to a cheaper model” before they can even see which calls cost the most. They save 30 percent on the wrong 5 percent of spend and feel productive. Meter first. Optimize last. The order is the whole lesson.
The Contrarian Take: Is Gross Margin a BS Metric?
Now the honest counterargument, because there is a serious one and some very smart investors make it.
The case goes like this. Obsessing over gross margin in the early years of an AI company is a category error. Bain Capital Ventures made this argument directly, under the deliberately provocative title that gross margin is a BS metric. The reasoning: in a land-grab market, the winner is whoever delivers the most value fastest, and spending aggressively on inference to deliver that value is not a leak, it is an investment. Amazon ran thin margins for years on purpose. If cheaper models are arriving every quarter, then a cost that looks brutal today will be cut 80 or 90 percent within a year or two for the same task, and margins you cannot yet see will materialize as the technology deflates underneath you. On this view, a founder who starves the product to protect margin in year one loses the market to a competitor who spent, won, and fixed margins later from a position of dominance.
I think this argument is right about the destination and dangerous about the road. It is true that you should not amputate a winning product to hit a spreadsheet number, and it is true that model deflation is real and durable. A team that owns its market with a 55 percent margin and a clear path to 70 beats a team that protected 80 percent and stayed small. The direction is correct.
The trap is in the word “later.” “Margins later” only works if you can prove three things: that your usage curve bends toward profitability as you scale rather than away from it, that the deflation actually reaches your specific workload instead of being eaten by the agent multiplier, and that you have the runway to survive the gap. The founders who get destroyed are not the ones who invested in inference. They are the ones who used “gross margin does not matter yet” as permission to never look at the meter at all. They confused a strategy with an excuse. The discipline I am describing is not margin panic. It is knowing your numbers so precisely that when you choose to spend below margin to win a market, it is a decision you made on purpose, with a date attached, and not a thing you discovered in an invoice. Spending into a trap you cannot see is not a landgrab. It is just the trap.
So both things are true. Do not let a margin obsession make you build a small, timid product. And do not let a growth narrative talk you out of ever measuring what your product costs to run. The winners will be the teams that can hold both ideas at once, and the meter is what lets them.
What to Do Monday Morning
Enough theory. Here is what actually moves you off rung 0, in order, from the thing that takes an hour to the thing that takes a quarter.
1. Find your real number. Before anything else, pull your last three months of model invoices and divide by revenue. That single ratio, inference cost over revenue, is the most important number about your business that you probably cannot recite from memory. If it is over 30 percent and climbing, you have a structural problem, not a temporary one. Write it on the wall.
2. Add usage tracking to every model call. Tag each call with the feature, the customer, and the model, and log the token counts you already get back in the response. This is a day of engineering, not a platform migration. By the end of the week you should be able to answer “which feature costs the most” and “which customer costs more than they pay.” Most founders have never been able to answer either.
3. Set a budget with a real alert. Not a spreadsheet you check monthly. A live threshold that pings you at 50, 80, and 100 percent of the month’s expected spend. The goal is that no invoice ever surprises you again. Uber’s annual budget did not vanish in a day. It vanished slowly, and nobody was watching the gauge.
4. Price at least one thing for what it burns. Find your most expensive feature and make sure the customers who use it heavily pay in a way that tracks their usage, whether that is a usage tier, a credit, or a cap. You do not have to reprice the whole product. You have to stop losing money on your best users, which is the most common and most painful version of the trap.
5. Only then, optimize. Once you can see cost per feature and per task, the tactical wins are obvious and safe: route the easy 80 percent of requests to a smaller model and save the expensive one for the hard 20 percent, cache repeated calls, trim bloated prompts, and cut agent loops that do not change the answer. Done in this order, these move margin. Done first, they are guesswork.
The founders who will be fine in this shift are not the ones with the cheapest tokens. Everyone gets cheaper tokens, on the same schedule, from the same vendors. The ones who win are the ones who built the discipline to turn that cheapness into margin instead of into a bigger bill. If you want the wider frame for building this way, it sits inside The AI-Native Founder Playbook, and the vendor-side risk of having your costs repriced out from under you is its own problem I covered in AI Platform Risk. Where the margins actually pool across the AI stack, I mapped in The AI Opportunity Map.
The cost of intelligence is falling and will keep falling. That is not the good news it sounds like. It is a force, and it points at more consumption unless you point it, on purpose, at margin. Watch the meter, or the meter will watch you.
FAQ: The AI Efficiency Trap
What is the AI efficiency trap?
The AI efficiency trap is the pattern where falling per-token prices lead to a rising total AI bill, because cheaper compute drives you to consume far more of it. It is the Jevons paradox applied to AI: when intelligence gets cheaper per unit, founders and users find so many new uses for it that total spend goes up, not down. Between 2024 and 2025, per-token prices fell more than 90 percent for equivalent quality while enterprise AI spending rose 320 percent. Cheaper unit, bigger bill.
Why do AI costs rise when token prices are falling?
Because the token price is only one of four forces that set your bill. Your cost equals price per token, times tokens per task, times tasks per active user, times number of active users. Only the price per token is falling. Tokens per task rise as you add reasoning and agents, tasks per user rise as engagement grows, and users rise as you scale. Three forces push up, one pushes down, and the three usually win.
What is a good gross margin for an AI startup?
The old software benchmark of 80 to 90 percent no longer applies to most AI-native products. Bessemer’s research placed model-native gross margins around 65 percent, and ICONIQ’s early 2026 data put the average AI product gross margin near 52 percent. A healthy AI business today often lives in the 60s and low 70s, with a credible path to improve as it meters and optimizes. What matters more than the absolute number is whether your margin improves or erodes as you scale.
How much of AI revenue goes to inference costs?
At scaling-stage AI companies in 2026, inference alone runs near 23 percent of revenue. For every million dollars of AI product revenue, roughly $230,000 leaves as inference cost before any salary, sales, or marketing is paid. That is the single biggest reason AI gross margins sit well below classic software.
Why are AI agents so expensive to run?
Agents and reasoning models spend far more tokens per task than a simple chat call. A query that returns 7 tokens on a plain model can consume around 600 on a reasoning model, roughly 86 times the cost. A simple tool-calling agent uses 5,000 to 15,000 tokens per task, and a complex multi-agent system can burn 200,000 to more than a million. Overall, agentic workflows consume 5 to 30 times more tokens per task than standard chat, which is why they absorb every price cut before it shows up as savings.
What is AI FinOps and how do I control AI costs?
AI FinOps is the discipline of measuring, attributing, budgeting, and pricing AI compute the way utilities and cloud teams manage metered resources. It works as a maturity ladder: move from a single lump invoice (blind) to spend attributed by feature and customer (metered), to real-time budgets with alerts (budgeted), to margin visibility per feature (priced-in), to architectural optimization like routing and caching (architected). The single most valuable step is the first one, getting off the lump invoice so you can see where the money goes.
Is a low gross margin a dealbreaker for an AI business?
Not by itself. Some investors argue that in a land-grab market you should invest in inference to win and expand margins later as models get cheaper. That can be correct. The danger is using “margins later” as an excuse to never measure costs at all. A low margin you chose on purpose, with a plan and a date, is a strategy. A low margin you discovered in an invoice is a problem. The deciding factor is whether you can see your numbers clearly enough to make it a choice.
Does the efficiency trap mean I should not build on AI?
No. It means you should build on AI with a meter running. The falling cost of intelligence is a genuine opportunity, and abstaining forfeits it. The trap only catches founders who treat AI compute like near-free software hosting. If you measure spend per feature and customer, set budgets, and price for the usage you burn, cheaper tokens turn into margin instead of a bigger bill. Discipline, not abstinence.