A client's OpenAI bill went from $200 a month to $11,000 in six weeks. Nobody noticed until finance did, three weeks after the number had already tripled twice. The engineering team wasn't negligent — every individual call they added made sense. A summarization feature here, a classification step there, a chatbot that got more popular than anyone expected. Each one shipped, worked, and got forgotten. The bill was the only place all of it added up.
It creeps, it doesn't spike
A server falling over gets a page. A bill climbing 15% a week for a month and a half gets nothing, because nobody's watching a dashboard for "cost," they're watching one for "uptime" or "error rate." By the time the invoice is big enough to show up in a monthly finance review, you're explaining a decision you don't remember making — usually some combination of "we called the expensive model for a task that didn't need it" and "we never set a ceiling because the first few months were cheap."
The specific failure at this client: a document-tagging job that ran GPT-4-class reasoning on every uploaded file, including the 90% that were short enough to not need it. Nobody chose that on purpose. The feature was prototyped fast with the best model available, it worked, and "we'll optimize the model choice later" quietly became "never," the way most later-optimizations do.
The real problem isn't the vendor, it's the default
The instinct after a bill like that is to blame the provider — pricing is opaque, usage dashboards lag by a day, rate limits are undocumented. All true, and none of it is the actual problem. The actual problem is that most teams wire one model into their code at the call site and never revisit it, because revisiting it means finding every place that model is called, figuring out which ones can downgrade without hurting output quality, and testing each change separately. That's real work with no deadline attached, so it loses to literally anything with a deadline attached.
The fix isn't "be more careful." Careful doesn't survive a second engineer joining the project. The fix is making the model choice a routing decision instead of a hardcoded one — a cheap, fast model by default, with reasoning-tier models reserved for the calls that actually need them, decided by policy rather than by whoever wrote that function in March. We built ElseLane for exactly this: it sits between your code and the providers, routes each call to the model that fits the task and the budget, and fails over automatically when one provider has a bad day. The point isn't the failover — it's that the routing logic lives in one place you can actually look at, instead of scattered across every file that happens to call openai.chat.completions.create.
The takeaway
Your AI bill isn't a vendor problem until it's a six-figure one. Before that, it's an architecture problem: every model call you hardcode is a decision that nobody will revisit until the invoice forces them to. Put the decision somewhere you can see it — a routing layer, a config, anything that isn't buried in application code — before the bill is the thing that makes you look.