In March 2026, Google told Meta it could not supply the Gemini model capacity Meta had asked to buy. The shortfall disrupted internal AI projects across Meta, forced staff to be more efficient with tokens, and made headlines as a clash between two of the largest technology companies in the world.
The instinctive reading was that this was a compute supply problem, and in a narrow sense it was: Google Cloud’s backlog had nearly doubled quarter on quarter, and CEO Sundar Pichai said computing power constraints were preventing even higher growth. But if you step back, the Google-Meta restriction belongs to a category of behaviour that is becoming a feature of the AI industry rather than a bug. Call it AI model access denial: any action by a vertically integrated provider that constrains a competitor-customer’s ability to use the provider’s infrastructure or models, whether through outright termination, capacity deprioritisation, or contractual restriction.
The Google-Meta incident was a signal of a broader market dynamic.
What pattern of competitive AI access denials has emerged across the industry?
The Google-Meta case is the most visible, but it is not alone. Anthropic cut off Windsurf’s Claude API access after reports emerged that OpenAI was in talks to acquire Windsurf. At the same time, Anthropic was scaling its own coding agent, Claude Code, which targets the same enterprise customers. Windsurf was a paying API customer, and it was removed the moment its acquisition threatened Anthropic’s own ambitions in the coding-tool market.
Anthropic also blocked OpenAI’s access to Claude models in August 2025, saying OpenAI had routed prompts through Claude’s API and compared the outputs against GPT-5’s performance in coding, writing, and safety tasks. Then in January 2026, Anthropic blocked xAI’s access via the coding tool Cursor, on grounds that xAI was using the models to train or test its own systems. Anthropic’s chief science officer stated it plainly: “I think it would be odd for us to be selling Claude to OpenAI.”
What unifies these cases is not bad luck. In each, the provider was actively building or ramping up a competing product in the same application category, and the denial occurred at a moment of heightened competitive sensitivity. These clauses are enforced, and the enforcement follows a predictable logic.
The enforcement pattern points to a deeper structural dynamic.
What is the inherent conflict of interest when an AI model provider also competes with its own enterprise customers?
The dynamic has a name: platform conflict of interest. A company that both provides a platform (model API, cloud infrastructure) and competes in the application layer built on that platform occupies an inherently conflicted dual role. The provider controls a critical input its own commercial rivals require: model access, latency, pricing, and API behaviour. When the provider’s own application ambitions overlap with a customer’s business, the incentive to degrade or deny that customer’s access is structural.
This is the Amazon-AWS pattern applied to AI. Amazon both hosts independent retailers on AWS and competes with them through Amazon Basics. AI model providers both sell API access and build competing applications. But the AI version is worse because the supplier pool is smaller: with only three providers controlling the enterprise market, there are far fewer places to route around a denial. Switching costs compound the problem: prompt engineering, model-specific integration, and data gravity all make migration harder the longer you stay.
The AI application layer is where the overlap happens. Coding assistants: Cursor and Windsurf versus Claude Code, Codex, and Gemini Code Assist. Legal and financial tools: threatened by Anthropic’s Claude Cowork plugins, announced in February 2026. Enterprise workflow platforms: contested by OpenAI’s Frontier and Google’s Gemini Enterprise. When Anthropic’s application-layer announcement caused RELX and Thomson Reuters stock to drop, markets were pricing in this structural threat.
The conflict is the equilibrium state of a market where model provision alone cannot sustain the business model.
How concentrated is the enterprise AI model market, and who controls it?
The structural conflict would be a manageable commercial risk if the market were diffuse. It is not. Anthropic (~40%), OpenAI (~27%), and Google (~21%) collectively control approximately 88-90% of enterprise LLM API spend, per Menlo Ventures analysis. No fourth provider exceeds single-digit share, and open-weight alternatives (Llama, Mistral, DeepSeek) hold just 11% of enterprise market share, down from 19% in 2024.
Concentration is what transforms the conflict of interest from an inconvenience into a crisis. In a diffuse market with 10 viable providers, an access denial is a problem you route around. In a three-provider market where each has unique model behaviour and prompt-engineering investment, a denial can threaten a product’s viability.
The concentration is self-reinforcing. Enterprise procurement favours established vendors with compliance certifications, SLA guarantees, and legal indemnification, barriers that entrench the incumbents. Compounding this, the investment arrangements between providers reduce competitive pressure further. The FTC’s 6(b) investigation documented exclusivity rights and circular cloud spending commitments embedded in the Microsoft-OpenAI and Amazon-Anthropic partnerships. These function as de facto tying of investment capital with cloud spend, foreclosing smaller providers without giant balance sheets.
Nvidia’s position adds a hardware-layer parallel: ~92% GPU market share plus equity investments in OpenAI, xAI, and Coreweave means the same structural conflict operates at the infrastructure level. Concentration is the condition that makes exclusion potent, and it is not easing.
What do the major AI providers’ terms of service actually say about competitor access?
The structural conflict has legal force. Anthropic’s commercial terms state that a customer may not “access the Services to build a competing product or service, including to train competing AI models or resell the Services except as expressly approved by Anthropic.” The language covers any application that overlaps with Anthropic’s own roadmap, not just model training. Anthropic could decide that any coding app, or any legal or financial services app using its models, is a prohibited competing product.
Google’s terms prohibit using Gemini to “develop models that compete with the Services,” a narrower formulation focused on model development. OpenAI’s terms similarly forbid using output to “develop models that compete with OpenAI.” But the scope question is the same across all three: who decides what counts as competing? The provider does, unilaterally, with no independent review before access is terminated.
These are not boilerplate provisions. The Windsurf case, described in Section 1, is the clearest illustration of how these clauses are applied in practice: Anthropic’s chief science officer treated the clause as self-evidently justified. The same enforcement logic was applied against OpenAI and xAI. These clauses are the mechanism through which structural conflict becomes operational denial, and the publicly available terms establish a negotiating baseline that most API customers never move beyond.
But why are providers so motivated to enforce these clauses in the first place? The answer sits one layer deeper, in the economics of model provision.
Why are AI foundation models becoming commodities?
The conflict described so far would be less urgent if model provision were a high-margin business with room for everyone. It is not. Mary Meeker’s 2025 internet trends report documented that general-purpose LLM economics look like commodity businesses: capabilities are converging, innovations are quickly copied by any adequately resourced competitor, and the quality gap between frontier and open-weight models has narrowed to roughly six months.
Commoditisation does not mean proprietary models are worthless. It means the performance premium that justifies premium pricing is shrinking. The pricing landscape spans a 600x range, from $0.10 per million tokens to $60 for frontier reasoning models, and open-weight alternatives from China (DeepSeek V4 at $0.14/M input tokens) and France exert price pressure. Intuit’s CEO put it directly: “large language models are commodities.”
The platform play is the infrastructure layer’s response: AWS Bedrock and GCP Vertex AI commoditise model access while capturing value at the orchestration layer. When models are fungible, the platform that routes between them captures the margin. As Paul Kedrosky observed, “applications become the margin layer.”
Commoditisation drives the platform-competition conflict by forcing providers to seek application-layer revenue. If model APIs alone cannot sustain premium pricing, providers must capture value in the application layer, which is where their enterprise customers are building.
How much are hyperscalers spending on AI infrastructure versus what they earn from it?
The root cause sits in the numbers. Bloomberg estimates Microsoft, Meta, Alphabet, and Amazon will spend $610 billion in capital expenditures in 2026, roughly triple what they spent two years ago. Paul Kedrosky estimated AI capex alone amounts to 1.2% of US GDP. J.P. Morgan calculates $650 billion in annual AI product revenue is needed on top of $5 trillion in global AI investment just for investors to earn a 10% return. OpenAI is on track to spend $1.4 trillion over the next decade while generating roughly $20 billion in annual revenue.
The causal chain is direct: enormous infrastructure investment requires returns, commoditisation erodes model-layer margins, so providers must capture application-layer revenue, which puts them into competition with their own API customers. This is not temporary. Frontier model training costs continue to rise, and agentic AI workloads (which consume orders of magnitude more tokens per task) will compound the capex burden.
Google’s compute-capacity justification for restricting Meta was real: Google Cloud hit $20 billion in Q1 2026 revenue but compute constraints prevented higher growth. The bottleneck that forced Meta out is the same one that makes model provision alone unprofitable at scale. The economics make the conflict predictable from the market’s structure, not a question of corporate behaviour.
If the economics make the conflict inevitable, the practical question is whether you can see it coming.
What warning signs suggest your AI provider might restrict your access?
Access denials are not random. They follow observable patterns, and the signals are visible in public information if you know what to watch for.
The provider launches a product in your application category. Anthropic’s Claude Code launch preceded the Windsurf denial; its legal and financial tools announcement preceded the RELX and Thomson Reuters stock drops. This is the clearest single signal.
The provider’s public language shifts from “platform” and “infrastructure” to “applications” and “end-user products.” A competitor in your space is acquired by, or enters partnership with, your model provider: the Windsurf case was triggered when OpenAI entered acquisition talks. The provider’s terms of service contain competing-product language broader than what you understood during procurement. Your API latency, capacity, or support responsiveness begins to degrade, a soft form of access restriction that can precede formal termination.
These signals are not a checklist. They are observations drawn from what happened before the restriction letters went out, what you would have seen if you were watching. The same market forces that explain past denials predict future ones.
Can regulation fix the platform-competition problem in AI?
The natural question is whether government will step in. The answer, for practical purposes, is: not in time.
US antitrust law provides limited remedies. The Supreme Court’s Verizon v. Trinko decision substantially narrowed the essential-facilities doctrine, expressing scepticism that monopolists have a duty to deal equally with all parties. The Vanderbilt Policy Accelerator has proposed “AI neutrality” rules analogous to net neutrality, with model legislation that would prohibit unjust discrimination among similarly situated customers. The Windsurf case anchors the proposal.
The EU Digital Markets Act could designate major AI model providers as gatekeepers, imposing non-discrimination obligations, but no formal designation process has begun. The Brookings Institution concludes Congress is unlikely to adopt protective measures in the current political climate.
The gap between the problem’s urgency and the regulatory timeline is measured in years. Enterprises building on proprietary APIs today cannot plan around a regulatory solution.
The Google-Meta restriction was not an isolated incident. It was the visible surface of a market structure where the same companies control model access and compete in the application layer, where three providers command roughly 90% of enterprise spend, where contractual clauses give them unilateral authority to cut off competitors, and where the economics of commoditisation and trillion-dollar infrastructure investment make vertical integration a predictable consequence.
The two false comforts are that this is temporary (the capex numbers disprove it) and that regulation will arrive in time (the legal analysis disproves it). The practical imperative is architectural: enterprises that depend on proprietary model APIs need multi-model design, open-weight fallback paths, and supply-chain audits that treat model providers as potential competitors rather than neutral utilities.
Building on a provider’s API without recognising the structural conflict exposes your product to a risk you cannot control. The question is not “will my provider compete with me?” It is “when they do, will my architecture survive it?”
Frequently Asked Questions
Is it safe to build my product on OpenAI’s API?
It is not unsafe in the sense that OpenAI is likely to cut off access tomorrow, but it is structurally exposed. The risk is not that OpenAI wants to harm its customers; it is that when OpenAI’s own application ambitions overlap with yours, its incentive to treat you as a neutral customer degrades. The economics of commoditisation and the capex-revenue gap mean that pressure will only increase. Safety is not a binary property of the provider; it is a property of your architecture’s ability to survive a change in the provider’s incentives. If your product cannot run without OpenAI’s API, you are not safe regardless of OpenAI’s current posture.
Can Anthropic just shut down my API access overnight?
In practice, yes. Anthropic’s commercial terms reserve the right to terminate access at its discretion, and the competing-product clause gives it broad pre-authorisation to do so. The Windsurf case demonstrated that termination can happen without a protracted negotiation period: access was cut after reports emerged that OpenAI was in talks to acquire Windsurf, at the same moment Anthropic was scaling Claude Code. Enterprise agreements may include notice periods that self-serve API customers do not receive, but the underlying right to terminate is the same. The question is not whether the provider has the legal authority; it is whether your architecture can absorb the timeline they give you.
Won’t using multiple model providers solve the dependency problem?
It reduces the problem but does not solve it. Multi-provider architecture is the right direction, but the three-provider concentration means your fallback options are limited. If you are blocked by Anthropic, you can route to OpenAI or Google, but if your product competes with applications in a category all three are entering, you may find yourself unwelcome on all three platforms. Worse, each provider’s models behave differently enough that a prompt-engineering investment tuned for one does not transfer cleanly. Multi-provider routing is a mitigation, not a cure, and it needs to be paired with open-weight fallback paths that no provider can revoke.
Should I switch to open-weight models like Llama instead of using proprietary APIs?
Not necessarily, but they should be part of your architecture. Open-weight models eliminate the access-denial risk entirely because no provider controls the weights, but they come with their own trade-offs: weaker enterprise support, fewer compliance certifications, and harder integration paths. Meta’s Llama strategy is instructive: Meta released Llama as open-weight in part because it lost Gemini API access and needed an insurance policy. The right approach is not to abandon proprietary APIs but to ensure your architecture can fall back to open-weight alternatives without a rewrite. Treat proprietary APIs as a performance optimisation, not a structural dependency.
What does architectural sovereignty actually look like in practice?
Architectural sovereignty means your product’s core function does not depend on any single model provider’s continued goodwill. In practice, that means three things. First, your prompt-engineering and evaluation pipeline is provider-agnostic, capable of routing the same task to multiple models and comparing outputs. Second, you maintain an open-weight fallback path that can serve production traffic, even if at reduced quality, if your primary provider withdraws access. Third, your supply-chain audit treats model providers as potential competitors and tracks the warning signs described in the article. It is not about avoiding proprietary APIs; it is about making them replaceable.
Are smaller AI model providers any safer than the big three?
Not in any structurally meaningful way. A smaller provider may not currently compete in your application category, but that is a function of its limited resources rather than a principled separation. If the provider grows, its incentives will track the same economic forces that drive Anthropic, OpenAI, and Google toward vertical integration. In fact, smaller providers may be more volatile: they can be acquired (bringing your API access under a larger competitor’s terms), they can change their commercial terms with less public scrutiny, and they can shut down entirely. The structural conflict of interest is not a function of scale; it is a function of the business model.
Will my model provider use my prompt data to compete with me?
The public commercial terms from the major providers generally prohibit using customer API inputs for model training, but the question is narrower and more practical than training-data policies. Your prompt data reveals what problems your product solves, how your users interact with it, and what edge cases you handle. That intelligence, even in aggregate, tells the provider exactly where application-layer demand exists. The provider does not need to train on your data to compete with you; it only needs to observe that your product category is generating significant API volume. The competitive signal is in the usage, not the content.
How long does it take for an AI provider to restrict your access once they decide to?
In the documented cases, the timeline from decision to effect has been short. The Google-Meta Gemini restriction was announced in March 2026 with immediate operational impact. The Windsurf-Anthropic termination followed quickly after the OpenAI acquisition reports surfaced. If you are on self-serve API terms without a negotiated enterprise agreement, the effective timeline may be zero: your API keys stop working and you learn about it after the fact. Enterprise agreements may provide notice periods of 30 to 90 days, but even that is not enough time to re-architect a deeply integrated product. The timeline is set by your architecture’s flexibility, not the provider’s notice period.
What clauses should I negotiate in my enterprise AI API agreement?
The single most important clause to negotiate is a carve-out from the competing-product language that explicitly names your product category and confirms it does not constitute a competing product or service. Without this, the provider retains unilateral authority to determine that your application competes. Second, negotiate a minimum notice period for any access restriction of at least 180 days, which gives you time to migrate. Third, seek a most-favoured-customer provision on latency and capacity that prevents the provider from deprioritising your traffic relative to its own applications. These are not standard terms, and smaller customers will struggle to secure them, but they are the negotiation targets that directly address the structural risk.
Is this only a problem for large enterprises, or should startups worry too?
Startups are more exposed, not less. Large enterprises have procurement leverage, legal teams, and the ability to negotiate custom enterprise agreements with carve-outs. A startup building on a proprietary API is exactly the profile Windsurf represented: dependent on a single provider, operating in a category the provider is entering, and too small to negotiate meaningful protections. The Windsurf case is the canonical warning: Anthropic cut off a startup’s API access at the moment its acquisition by a competitor threatened Anthropic’s own ambitions. Startups cannot rely on being too small to matter. In this market, being small means being easier to remove.
Doesn’t Microsoft’s investment in OpenAI protect API customers from access denial?
It complicates the dynamic but does not protect API customers. Microsoft’s stake in OpenAI creates a different kind of structural entanglement: OpenAI’s API customers are also, in some sense, Microsoft’s Azure customers, and Microsoft has its own application-layer ambitions through Copilot. The FTC’s 6(b) investigation into cloud-provider investment arrangements documented how these stakes function as de facto tying of investment capital with cloud-spend commitments. The protection, if it exists, runs in the opposite direction: Microsoft’s interest is in capturing enterprise AI spend, not in ensuring OpenAI treats its API customers as neutral counterparties. If anything, the partnership adds a layer of competing incentives rather than resolving them.
