When you wire your product straight into OpenAI — or Anthropic, or Gemini — the cost looks obvious. It’s the number at the bottom of the monthly invoice. You can see it, budget for it, and argue about it in a planning meeting.
That number is the cheapest thing about calling providers directly.
The real costs don’t appear on any invoice. They’re paid in downtime, in the better model you never adopted, in the bill nobody could explain, in the weekend an engineer lost to a migration. They’re invisible right up until the moment they all arrive at once. Here’s what’s actually on the tab.
Your uptime is now their uptime
This is the one most teams never price in, and it stopped being hypothetical a while ago.
On April 20, 2026, OpenAI had a partial outage that lasted around 90 minutes — login, conversations, the API platform, all degraded — with thousands of users reporting failures globally. The detail that should worry anyone building on a single provider: it wasn’t just OpenAI. ChatGPT, Claude, and Gemini all went down inside the same window, and of the major providers, Grok was one of the few that stayed up. That wasn’t a freak event either — the week of May 4–8 logged multiple incidents across Claude, ChatGPT, and Google within a single five-day stretch.
Here’s why the headline uptime number lulls you. OpenAI’s core components held roughly 99.83% availability over a 90-day window — which sounds excellent, and is, until you remember what it means for you. When you call one provider directly, their 0.17% is your 0.17%, and you have no say in when it lands. It lands during your launch, during the customer demo, at 2am. And there’s nothing to do but refresh their status page and wait. You did everything right, and you’re still offline, because your only provider is having a bad hour.
The fix is to stop depending on any single provider staying up. The cost of skipping it isn’t theoretical downtime; it’s every request that failed during a window you couldn’t control and couldn’t route around.
Lock-in you chose by accident
Whatever you integrated first is probably what you’re still running — not because it’s the best option today, but because moving is expensive.
Trying a cheaper model, or a better one for a specific task, means a new SDK, new auth, new response handling, new code paths. So the experiment that would take an afternoon becomes a sprint nobody schedules. You stay on what you wired in, even when a competitor ships something better or cheaper, because switching costs more than the upside seems worth.
That’s lock-in by friction. No provider trapped you — the integration did. And the cost is the quietest kind there is: the better, cheaper, or faster option you never took, paid every month in the difference.
A bill you can’t actually read
Calling providers directly gets you one number a month. It does not get you the only thing that makes that number actionable: attribution.
Which feature drove the spend? Which customer? Was it real usage, or a retry loop quietly hammering the API in the background? Direct integration can’t tell you, because the provider bills you in aggregate and your code wasn’t built to tag every call. So every cost conversation is a guess, and every optimization is a shot in the dark. By the time a bill looks wrong, the money is already gone.
You can’t cut what you can’t see. Direct access makes it easy to miss it unless you build attribution yourself.
The key that can drain the account
A single API key with no ceiling is a standing liability most teams carry without noticing.
It ends up in a client bundle, a public repo, a shared doc — and now someone else is spending your money at the speed of a script. Or there’s no leak at all, just a bug that retries forever, or a traffic spike during an outage as your code hammers a degraded endpoint. Calling providers directly, there’s usually nothing between that failure mode and your balance. You find out from the invoice.
The fix is unglamorous: a hard cap on every key, so even the worst case is bounded to a number you chose in advance. Direct integration rarely gives you the per-key blast-radius controls your product needs by default, because the provider’s dashboard wasn’t built around your blast radius.
The integration tax that never stops
Building a provider integration isn’t a one-time cost. It’s a subscription.
The OpenAI SDK updates. Anthropic changes an auth flow. Gemini deprecates an endpoint. Each change is a ticket, a PR, a deploy — for every provider you wired in, for as long as the product lives. And the worst of it is failover code: the retry-and-reroute logic you write to survive an outage is exercised only during an outage, which is precisely the worst time to discover a bug in it. You maintain it forever and find out if it works at the worst possible moment.
The controls you’ll build under deadline
There’s a question coming that direct integration has no answer for: the next time you chase a serious customer, their security review will ask what sits between your model and your users. PII handling. Spend limits. Audit logs. Data retention. As agents start calling tools and taking actions, that surface only grows — something we get into in What MCP governance actually means in production.
Teams calling providers directly almost always build that answer during the review — retrofitting controls onto five separate integrations, under deadline, with a deal on the line. The cost isn’t just the engineering scramble. It’s the deals that slip, or die, while you build what you should have had in place.
Add it up
None of these line items appear on the bill from OpenAI, Anthropic, Gemini, or any other provider. That’s exactly why they’re dangerous — calling providers directly feels free, like the simplest possible choice, while quietly being one of the most expensive ways to run AI in production. The token cost is visible and bounded. The hidden costs are unbounded and arrive without warning.
The structural fix is to stop scattering these problems across every integration and put them in one place: a single layer between your product and every provider, where reliability, cost visibility, spend limits, and controls live by default instead of being rebuilt five times and discovered too late.
That’s what Metriqual is — one OpenAI-compatible key in front of OpenAI, Anthropic, Gemini, Mistral, and MiniMax, with automatic failover, per-key cost attribution and caps, and the production controls you’d otherwise scramble to build. The direct line to a provider looks like the cheap option. The invoice just isn’t where its real price is printed.
Metriqual is the control layer for AI in production. Start free or book a demo.