Your Vendor's Balance Sheet Is Your Risk

Single-vendor exposure on a critical path is the risk that ends up unowned. Reliability carries the pager for uptime, not for the vendor’s solvency; the teams shipping conversion keep deepening the dependency, because that is where the roadmap pays. So the warm fallback that would carry you through a vendor’s bad quarter sits in no one’s budget, and loses to conversion work until someone forces the question. Force it with diligence you can actually run.

Price the same million output tokens three ways before you wire a workload to a model vendor: their API, a competitor’s API, and the same job self-hosted on an open-weight model of comparable quality, billed by the GPU-hour. You will never see the vendor’s balance sheet. You do not need it. You need a floor.

Scale buys real efficiency, so a price below your own self-host cost proves nothing; a large operator running batched, high-utilization fleets genuinely serves tokens cheaper than you can. Set the floor lower, then: the cost a well-run fleet at full utilization would carry, and compare against that. When the offered price sits below even that number, no efficiency story closes the gap. The discount is being financed by someone, and financing gets withdrawn. That spread between their price and the floor is the subsidy you will repay later, on their schedule.

This is the diligence that works, because the diligence usually prescribed does not. “Ask what funds the price, durable margin or capital that must be raised again” is a question a private vendor will never answer honestly and you cannot audit. The price-versus-floor spread you can compute yourself, repeat each quarter, and act on.

Repricing arrives as a deprecation notice

It rarely shows up as “we raised prices.” It shows up as a sunset date. The cheap model you built on is scheduled for retirement, and the supported replacement is a reasoning model that emits three to five times the tokens to answer the same prompt. The headline per-token price holds or even falls, and your cost per call still triples, because the only model you are now allowed to call thinks out loud before it answers. Token prices fell; bills did not is the same mechanism viewed from the invoice. The hit lands on your unit economics and your roadmap in the same week, when you have the least slack to absorb it.

Two clauses, written at signing

Two terms cost nothing at signing and cannot be retrofitted during an outage: a price lock paired with a minimum notice window on any model deprecation, and an explicit right to export your fine-tunes, prompt logic, and request logs in a portable form. You are not negotiating to be reassured. You are negotiating for terms that hold through the vendor’s bad quarter.

The control is a warm fallback with an owner

Comparisons and clauses narrow the risk; neither removes single-vendor exposure on a critical path. One thing does: a warm fallback, a second provider or that self-hosted model, kept able to carry the workload at degraded quality on short notice. Treat it as a build-versus-buy portfolio rather than a binary , optionality you fund on purpose, not a hedge you improvise mid-incident.

Warm means it runs. Route a thin slice of real production traffic through the alternate on a fixed cadence, weekly rather than when someone remembers, so the path stays exercised and you know its true error rate before the day you need it. The question it answers is blunt: the morning your largest model vendor posts a shutdown notice, how many days until your product runs on something else? That redundancy costs real money and competes for budget, which is the point: redundancy you can measure is a line a board can fund.

So give the line an owner. On-call carries the failover; conversion carries the dependency that makes it necessary, and will keep deepening it until someone with budget authority puts the fallback above the next feature. Until that owner exists, the vendor sets the answer to the shutdown-notice question, on the quarter that suits them.