Model provider dependency: pricing the API risk

Most AI products are built on a model their team does not control. So somewhere in every deal memo there is a paragraph about OpenAI dependency risk, or Anthropic dependency, and it usually says the wrong thing: either that dependency is disqualifying, or that everyone depends on someone so it does not matter.

Here is the position we defend in diligence: dependency on a model provider is not, by itself, a risk. Unexamined dependency is. The job is to establish which one the target has, and to put a number on it.

The four exposures behind provider dependency

When we pull the dependency question apart, it separates into four distinct exposures, and they deserve different treatment.

Pricing. The direction of model prices has mostly been down for equivalent capability, so the naive fear of a sudden price hike is usually the least of the four. The real question is sensitivity: how much does gross margin move if the provider’s line on the cost sheet doubles, and how much room is there to absorb it. A product whose margin swings by double digits on a provider’s pricing decision has an exposure worth modeling, which is why we treat this as part of the margin question every AI deal should start with.

Deprecation. Providers retire models on their own schedule, and every forced migration means re-running evals, re-tuning prompts, and sometimes re-explaining behavior changes to customers. A team with a real eval suite treats a deprecation as a week of controlled work. A team without one finds out about regressions from support tickets.

Terms and limits. Usage policies can exclude use cases, rate limits can cap growth in specific geographies or at specific moments, and the difference between building on a consumer API key and a negotiated enterprise agreement is material. We read the actual contract, not the pricing page.

Capability absorption. The provider ships your feature. This is the exposure founders least like discussing, and it is really a defensibility question: what remains when the underlying capability becomes a commodity. We treat it separately, with the framework in evaluating an AI moat when the models are everyone’s, because the answer rarely lives in the code.

What a healthy abstraction layer looks like

Every pitch deck now claims to be model-agnostic. Most are not, and the claim is easy to test.

A healthy setup is unglamorous: a thin routing layer, prompts and configuration stored per task rather than scattered through the code, and an eval suite that can certify a replacement model in days. The part doing the real work is the evals, not the routing. Switching providers is trivial to code and expensive to trust; the trust comes from being able to measure quality before and after.

The test question we ask is: when did you last actually move a workload to a different model, and what happened. Teams with genuine portability answer with a story, usually about cost optimization, sometimes with a dashboard. Teams with paper portability answer in the conditional tense.

The paper version is common: a wrapper class around a single SDK that has never routed a request anywhere else. That is not an abstraction layer, it is an intention. It has never been exercised, so nobody knows what breaks when it is.

When single-provider dependency is the rational choice

One thing deal teams sometimes do not expect from auditors: for many targets, deep dependency on one provider is the correct engineering decision, and we say so in the report.

An early-stage company shipping fast should not spend a quarter building for a provider switch that may never come. If the product’s edge depends on frontier capability, tying yourself to the provider currently at the frontier is coherent. Multi-provider setups have real costs: two sets of model quirks, two eval baselines, two contracts, and an ops surface that a ten-person team should not carry.

Dependency becomes a finding when it is unpriced. No idea what share of cost of revenue goes to the provider. No evals that would let the team certify an alternative. No contract beyond a credit card on a self-serve tier, at enterprise revenue. Prompt behavior so entangled with one model’s quirks that migration is a rewrite. Any of those turns a reasonable choice into a fragility.

The questions we ask in diligence

The short version of our provider-dependency check:

• What share of cost of revenue goes to a single provider, and what happens to gross margin if that line doubles
• Which model versions are pinned in production, and how was the last forced migration handled
• Show the eval suite you would use to certify a replacement model, and when it last ran
• What do enterprise contracts promise about behavior, uptime, or data handling that actually depends on the provider
• If the provider shipped your core feature next quarter, what would customers stay for

Strong teams answer the first four from artifacts within a day, and have visibly thought about the fifth. The pattern of evasion, when it comes, usually shows up on the eval question first.

Provider dependency almost never kills a deal on its own. It moves price and terms: it changes the margin model you underwrite, and sometimes it justifies an escrow of engineering effort post-close, meaning a funded plan to build the eval and routing muscle that makes the dependency reversible. Sizing that exposure, and separating it from the ambient noise about model markets, is part of what we do in a technical and AI audit.