OpenAI lost an estimated $5 billion last year. Google's AI infrastructure spend runs into the tens of billions. Yet both continue to offer frontier model access at prices that, by most credible analyses, do not cover the cost of inference. This is not an accident, and it is not philanthropy. It is a deliberate market strategy — and UK businesses building products and services on top of these APIs are, knowingly or not, the intended beneficiaries of a subsidy designed to create dependency. The question that deserves serious boardroom attention is not whether the losses are real. They are. The question is what happens when they stop.
For senior decision-makers and technical leads, this is not a theoretical concern about Silicon Valley economics. It is a concrete strategic risk sitting inside your product roadmap, your cost model, and your customer commitments. The time to think clearly about it is now, before the price corrections arrive — and before your architecture makes migration prohibitively expensive.
Below-Cost Pricing Has a Name, and It Is Not Generosity
Predatory pricing — or more precisely in this context, penetration pricing at scale — is a well-understood commercial tactic. You price below cost to capture market share, manufacture switching costs, and establish infrastructure dependency. Once the ecosystem is sufficiently entrenched, you reprice. The classic examples come from ride-hailing and food delivery platforms, where years of subsidised fares and fees built consumer habits and supplier reliance that proved remarkably durable even as prices normalised upward.
AI API pricing follows the same logic, with one important difference: the switching costs are architectural, not merely habitual. When your application is built around a specific model's context window behaviour, its function-calling conventions, its fine-tuning formats, or its particular output style, migrating to an alternative is not a configuration change — it is an engineering project. OpenAI and Google understand this perfectly. Every developer who deeply integrates their APIs is a customer whose price elasticity drops substantially over time. The subsidy buys lock-in. The lock-in justifies the subsidy.
The Political and Financial Clock Is Ticking
The losses that underpin current AI pricing are not indefinitely sustainable. OpenAI is burning through capital at a rate that requires continuous fundraising at ever-larger valuations — a dynamic that eventually meets a ceiling, whether from investor fatigue, a broader risk-off environment in tech, or the straightforward arithmetic of unit economics. Google's position is more stable given its advertising revenues, but it faces increasing scrutiny from shareholders about AI return on investment. Microsoft, which has embedded OpenAI's models across its product stack, has its own margin pressures as enterprise customers begin asking harder questions about AI spend.
There is also a regulatory dimension. Pricing below cost to establish market dominance is precisely the kind of behaviour that competition authorities scrutinise. The UK's Competition and Markets Authority has already signalled serious interest in AI market dynamics, and the European Commission is further along still. If regulatory pressure accelerates alongside financial pressure, the timeline for repricing could compress significantly. UK businesses should not assume they will receive eighteen months' notice and an orderly migration window. Historically, platform pricing shifts have arrived with far less warning than product teams would like.
What Lock-In Actually Looks Like in Practice
It is worth being precise about where the lock-in accumulates, because it is rarely as obvious as a contractual commitment. The most significant dependency risks tend to cluster in three areas. First, proprietary model capabilities: if your product relies on a specific model's performance characteristics — particularly around reasoning, code generation, or multimodal tasks — switching to an open-source or alternative commercial model may require substantial prompt re-engineering and acceptance testing, with no guarantee of equivalent output quality. Second, tooling and orchestration: many teams build their agent frameworks, retrieval pipelines, and evaluation infrastructure around provider-specific SDKs and conventions, creating a second layer of migration cost beneath the model itself. Third, fine-tuned models: organisations that have invested in fine-tuning on a proprietary platform have created assets that are, by definition, non-portable.
Collectively, these dependencies mean that a 40% price increase — which would represent a meaningful but not implausible repricing event — could hit margins in a way that is very difficult to respond to quickly. For businesses that have passed AI-powered product costs through to customers at fixed prices, or that have embedded AI into internal workflows with measurable productivity assumptions, the exposure is material.
Open-Source Models and the Architecture of Optionality
The most effective hedge against this risk is not switching providers — it is building for portability from the outset. This means making deliberate architectural choices that treat the underlying model as a replaceable component rather than a fixed dependency. Abstraction layers, provider-agnostic prompt formats, and evaluation frameworks that test outputs rather than assume a particular model's behaviour all contribute to an architecture that can adapt when pricing shifts.
Open-source models have matured considerably and now represent a credible alternative for a growing range of use cases. Llama, Mistral, and their derivatives can be self-hosted or run through independent inference providers, removing the single-provider exposure that makes repricing so dangerous. They are not always the right choice — for cutting-edge reasoning tasks, frontier proprietary models still hold a meaningful advantage — but for many production workloads, the capability gap has narrowed to the point where the portability benefit outweighs the performance premium of a closed model.
The practical advice here is straightforward, even if acting on it requires discipline. Audit your current AI dependencies and map where lock-in has already accumulated. Assess which workloads are genuinely frontier-model-dependent and which could be served adequately by open or alternative models. Build abstraction into new development from day one, not as an afterthought. And model the financial impact of a significant price increase on your cost structure — not because it is certain to happen in a specific timeframe, but because understanding your exposure is the precondition for managing it.
The AI incumbents are not offering cheap access out of goodwill. They are making a calculated investment in your dependency. The businesses that will navigate the repricing moment best are those that accepted this reality early, built accordingly, and retained the optionality to move. That work starts with an honest conversation about where you actually stand today.
Which AI providers are currently pricing their models below cost?
OpenAI and Google are the most prominent examples, with both companies reporting substantial losses on their AI operations while maintaining competitive API pricing. Microsoft, through its Azure OpenAI Service, effectively passes through similar economics. The pattern extends to other frontier model providers competing for developer adoption, making below-cost pricing something of an industry norm at the current stage of market development.
How significant would a price correction realistically be?
Estimates vary, but some infrastructure analysts suggest current inference pricing for frontier models may be 30–60% below fully loaded cost at current scales. A correction to breakeven pricing alone could therefore represent a substantial increase, potentially 40–80% above current rates. The actual magnitude would depend on how quickly compute costs continue to fall and how aggressively providers choose to recapture margin.
Are open-source models genuinely good enough to replace GPT-4 class models for production workloads?
For many production use cases — document summarisation, classification, structured data extraction, customer-facing chat — open-source models from providers such as Meta and Mistral now perform comparably to earlier frontier models at a fraction of the cost. For tasks requiring advanced multi-step reasoning, complex coding, or cutting-edge multimodal capabilities, proprietary frontier models still hold a meaningful advantage. The appropriate answer depends heavily on your specific workload requirements.
What is the CMA's current position on AI market concentration?
The UK's Competition and Markets Authority published its AI foundation models review findings noting concerns about market concentration and the potential for incumbent platforms to leverage existing dominance into AI markets. The CMA has ongoing monitoring responsibilities and has indicated it will scrutinise partnerships, pricing practices, and access conditions in the AI sector. Businesses should expect this regulatory environment to evolve, potentially affecting how providers structure and price their offerings.
What does a provider-agnostic architecture actually look like in practice?
In practice, it means introducing an abstraction layer between your application logic and the model provider — typically a lightweight interface or middleware that standardises how prompts are sent and responses are received. Frameworks such as LangChain or LiteLLM provide this kind of abstraction. It also means writing prompts in a way that does not rely on provider-specific formatting conventions, and building evaluation suites that test output quality independent of which model produced them.
How quickly could a UK business realistically migrate away from a specific provider if pricing changed significantly?
For a product with minimal fine-tuning and clean abstraction layers, migration to an alternative provider could take weeks. For a deeply integrated product with provider-specific fine-tuned models, proprietary tooling dependencies, and embedded output assumptions across the codebase, a realistic migration timeline could be six to twelve months — during which the repriced costs must still be absorbed. This timeline asymmetry is precisely why proactive architectural planning matters.
Does self-hosting open-source models eliminate the cost risk entirely?
Self-hosting removes per-token API pricing risk but introduces infrastructure costs — GPU compute, model serving overhead, and engineering maintenance — that must be weighed carefully. For organisations with sufficient scale and technical capability, self-hosting can be cost-effective and provides full control. For smaller organisations or those without MLOps expertise, independent inference providers such as Together AI or Replicate offer open-model access without the operational burden, at pricing structures not tied to a single incumbent's economics.
Should procurement and legal teams be involved in AI vendor decisions?
Yes, and earlier than is typically the case. Procurement teams should scrutinise API terms of service for clauses relating to pricing changes, notice periods, and data handling. Legal teams should assess whether current AI vendor agreements create any contractual commitments that would complicate migration. Given that most AI API agreements are standard, non-negotiated terms, understanding what you have agreed to — including what protections you do not have — is a reasonable baseline for governance.
Is this risk specific to generative AI, or does it apply to other AI services such as computer vision APIs?
The same dynamic applies to any AI service where a provider is subsidising access to build market share, though the severity varies. Generative language models represent the highest-profile current example due to the scale of losses and the depth of integration they enable. Computer vision, speech recognition, and translation APIs from the same large providers carry similar dependency risks, though the open-source alternatives in those domains are often more mature and the switching costs somewhat lower.
What internal conversation should technical leads be having with their boards about this?
Technical leads should present AI vendor dependency as a category of commercial and operational risk equivalent to other single-supplier dependencies, not purely as a technical architecture question. The board-level framing should cover: what proportion of product margin is sensitive to AI API pricing, what the migration cost would be under an adverse repricing scenario, and what investment in architectural optionality is warranted given that exposure. Framing it in financial risk terms — rather than engineering preference — tends to produce more productive strategic decisions.
Get in touch today
Book a call at a time to suit you, or fill out our enquiry form or get in touch using the contact details below