Why Waiting For Cheaper AI Models Is a Trap: A Founder's Story (2026)

So the thing that broke my head a bit, and honestly the reason I ended up writing this at all, is that the price of a token kept falling the entire time my bill was going up. Everyone kept telling me the models were getting cheaper, and they were, the per-token price genuinely came down, and yet I'm sat in a finance meeting staring at this OpenAI number that had gone from about a grand a month to nearly four thousand and then just kept climbing into five figures, and my first honest reaction was basically, how, right? If the thing I'm buying keeps getting cheaper, how is the bill I'm paying for it getting bigger. And I'll be honest, the plan I'd quietly been running up to that point, the plan of just waiting for the next cheaper model to land and fix the bill on its own, wasn't really a plan at all, it was more of a hope with a roadmap attached, and it took me an embarrassingly long time to realise the falling price and the rising bill were never in tension, they were actually the same thing pointing the same direction, because the second something gets cheaper you just quietly go and use a load more of it.

So let me answer the title plainly before I ramble, because I do ramble. Waiting for the next cheaper model won't fix your margin, and it won't fix it for a pretty simple reason, which is that your usage tends to explode at least as fast as the price falls, so the saving gets eaten before it ever reaches the bottom line. The actual fix isn't a cheaper model at all, it's proving, per prompt, on your own real traffic, that a cheaper model you can already reach is better, or at least as good, as the one you're running, and then only switching the prompts where that's actually true. That's the whole argument, and everything under here is just me showing my working.

Why did cheaper tokens not lower my bill?

Because I didn't hold my usage still, obviously, nobody does. When I first wired the latest OpenAI model into Sentrama across ninety-odd prompts, and into the sister company Real Recruitment, it was a handful of calls a day and it was basically nothing to run. Then it worked, so we onboarded more and more customers, more and more SDRs, more and more clients, and every single one of them was making more calls, and every call was firing off the data qualifying itself and the reason for the call writing itself off everything we'd scraped and the summaries and the reports, all of it running on its own in the background. So the per-call cost was dropping over time, genuinely, and it did not matter even slightly, because I'd gone from a few hundred calls to a mountain of them, and a smaller number multiplied by a much bigger number is still a bigger number. Cheaper tokens didn't lower my bill, they just made it cheap enough that I felt fine building even more on top of them, which is exactly how the bill got big in the first place.

So why is "just wait for the next model" the trap?

Because it's a treadmill, and it's a treadmill by design. There's actually a name for this pattern from way back in the coal days, Jevons paradox, where making a resource cheaper to use just makes people use so much more of it that total consumption rises, and tokens are basically the cleanest example of it I've ever seen. Every time a cheaper model lands you get this little hit of relief, right, you swap it in, the unit cost drops, and for about a fortnight you feel clever. But nothing about the shape of the problem changed. The cheaper model makes it economical to do more, so you do more, you add another feature, you point another workflow at it, you turn the reasoning up, your customers use it harder, and the bill walks straight back up to where it was and keeps going. Waiting for the next model treats your spend like it's a pricing problem, and it basically never is, it's a usage problem that just happens to look like a pricing one from a distance.

What actually fixes it then?

Proving it, per prompt, on your own traffic. And the honest blocker here was never cost, right, there's always a cheaper model, there's a dozen of them a click away through something like OpenRouter, so "is there a cheaper option" was never the question I was stuck on. The blocker was proof. My customers were used to a certain quality across those ninety-odd prompts, and I wasn't about to quietly go and make their results worse just to make my own margins a bit better, and they had no idea what model ran underneath and honestly it wasn't their job to care. The uncomfortable truth I landed on after a very long rabbit hole is that most of those prompts never needed the expensive model in the first place, I just had no way of knowing which ones until I could actually prove it. So instead of waiting for a cheaper model and hoping, you capture your real production prompts and you test a cheaper model you can already reach against them, and you only move the prompts where cheaper genuinely holds up. That's not waiting for the market to save you, it's going and taking the saving that's already sat there in your own traffic, on the models that already exist today.

How do you prove a cheaper model is good enough?

You judge it on three things at once, on your own prompts, not on a leaderboard, because a leaderboard isn't your traffic and never will be, and the leaderboards get contaminated and gamed anyway. The first is format, the boring one that breaks everything, so we hold it to a full match, because if your app wants strict JSON with certain fields and the cheaper model comes back with prose or drops a key, it doesn't matter how clever the answer was, the pipeline downstream is just broken. The second is categorical, meaning did the two models make the same call, and when they disagree we re-judge that case blind so a coin-flip disagreement doesn't get counted as a real one. And the third is semantic, are they actually saying the same thing in substance, obviously allowing for the fact that two good answers are basically never word-for-word identical. And then the bit that ties it together, which most people skip, is that you can't honestly call a swap worse or better until you know how much your own baseline model already disagrees with itself, so we measure that spread first and judge everything against it, using your own baseline model as the judge. A swap only passes if it stays inside your own model's normal deviation. It's now patent pending, but the concept is dead simple, you can't measure better until you've measured your own wobble.

Is waiting ever the right call?

Honestly, sometimes, and I'd rather say so than pretend the answer is always me. If your AI spend is genuinely tiny, if it's a rounding error next to payroll, then don't overthink it, wait for the next model, take the free price drop, get on with your day. And this isn't for coding agents, it's genuinely worse there and the failure modes get nasty, it's really built for the high-volume production prompts a business runs over and over, the classification and extraction and summarisation and qualification and generation-from-structured-data workhorse stuff that runs all day. So if you're routing a coding agent, or your bill is small enough that you don't feel it, waiting is completely fine. It stops being fine the moment the bill is big enough to show up in a finance meeting, because at that point the price falling isn't rescuing you, your own usage is racing it and winning.