Inference API Monopolies and Downstream Market Dependency

Introduction

Inference APIs allow downstream businesses to access the outputs of an AI model without owning or operating the underlying model infrastructure. A provider hosts a foundation model and exposes access through an API, charging per token, request, compute unit, or subscription.

A competition concern arises when a provider of a critical inference API becomes indispensable to downstream firms—such as AI applications, search services, enterprise software, autonomous systems, financial tools, or developer platforms—and uses that position to restrict competition in those downstream markets.

The central competition-law question is therefore:

When does control over an indispensable AI inference layer become market power capable of foreclosing or weakening competition in downstream markets?

The problem can be represented as:

Foundation model → Inference API → AI applications/services → End users

If one undertaking controls the inference layer, downstream competitors may become dependent upon its:

• model access;
• API availability;
• token prices;
• rate limits;
• latency;
• technical standards;
• model versions;
• safety policies;
• access to specialised capabilities;
• data interfaces;
• embeddings or tool-calling functionality; and
• interoperability arrangements.

This creates a potentially important vertical competition problem.

1. Meaning of an Inference API Monopoly

An inference API monopoly exists where one provider possesses substantial or durable market power over access to AI-model inference and downstream businesses depend materially upon that access.

The relevant market could potentially be defined narrowly as:

• inference services for particular foundation models;
• general-purpose AI inference APIs;
• enterprise AI inference;
• specialised inference, such as coding, reasoning, vision or speech;
• low-latency inference;
• inference for particular workloads; or
• infrastructure-enabled model-serving services.

Alternatively, competition authorities may define a broader market for:

AI model development and deployment services.

The correct market definition depends upon substitutability, not simply the technical label attached to the API.

2. Why API Control Can Create Downstream Dependency

An inference API may function as a bottleneck input.

A downstream company might have:

• its own application;
• its own customers;
• its own user interface;
• its own distribution;
• its own proprietary data;

but nevertheless lack an economically viable alternative to the dominant inference provider.

For example:

Dominant AI provider

↓ controls

Inference API

↓

AI legal-research applications

↓

Enterprise customers

The downstream application may technically be capable of switching providers, but switching can involve:

• rewriting prompts;
• retraining systems;
• changing output schemas;
• recalibrating evaluations;
• rebuilding safety controls;
• changing agent architecture;
• migrating embeddings;
• renegotiating service-level agreements;
• losing model-specific functionality; and
• undertaking extensive testing.

Consequently, technical substitutability does not necessarily mean effective competitive substitutability.

3. Sources of Market Power

A. Model quality

Superior reasoning, coding, multimodal or specialised capabilities may make a particular model difficult to replace.

B. Switching costs

Applications can become deeply integrated with a particular API.

C. Developer ecosystem

A large developer ecosystem can reinforce the provider's position.

D. Data advantages

API providers may receive enormous volumes of interaction and performance data.

E. Compute advantages

Access to scarce GPUs, specialised accelerators and datacentres can reinforce the inference provider's position.

F. Economies of scale

Inference infrastructure has substantial fixed costs, while marginal costs can decline with scale.

G. Network effects

More developers can create:

more applications → more users → more data → better systems → more developers.

H. Technical dependency

Downstream applications may depend on proprietary:

• APIs;
• SDKs;
• model formats;
• function-calling systems;
• safety layers;
• agent protocols.

4. Forms of Downstream Dependency

4.1 Price dependency

A downstream firm cannot substantially increase its prices because inference costs are determined by the API monopolist.

4.2 Capacity dependency

The provider controls rate limits and access during periods of high demand.

4.3 Quality dependency

A change in the underlying model can materially alter the downstream product.

4.4 Availability dependency

An API outage can simultaneously disable hundreds or thousands of downstream competitors.

4.5 Innovation dependency

Downstream firms may be unable to introduce competing services without access to advanced inference capabilities.

4.6 Information dependency

The API provider may possess information about downstream firms':

• usage;
• demand;
• customers;
• applications;
• queries;
• performance;
• pricing;
• product development.

This can create an especially serious vertical-information advantage.

5. Competition-Law Theories of Harm

A. Refusal to supply

A dominant inference provider may refuse access to a downstream competitor.

Under an essential-facilities-type analysis, the question would include whether:

1. the input is indispensable;
2. effective alternatives exist;
3. refusal eliminates effective competition;
4. access can reasonably be provided; and
5. the refusal lacks objective justification.

AI inference raises an additional question: how indispensable must a particular model be when several technically similar models exist?

6. Case Law

1. Commercial Solvents Corp. v Commission

The Court of Justice established an important principle concerning a dominant undertaking's refusal to supply an input to downstream competitors.

The case involved a vertically integrated undertaking controlling an essential input and subsequently restricting supply to a downstream competitor.

Relevance to inference APIs

The analogy is strong where:

API provider = upstream supplier

and

AI application = downstream competitor.

If an inference provider supplies third-party developers but selectively restricts supply to applications competing with its own downstream products, the conduct can raise a similar vertical foreclosure concern.

The important principle is that dominance at an upstream level cannot automatically justify exclusionary conduct downstream.

2. United Brands v Commission

In United Brands v Commission, the Court examined the conduct of a dominant undertaking controlling an important commercial input and distribution structure.

The case remains significant for understanding:

• dominance;
• commercial dependence;
• discriminatory conduct; and
• the special responsibility of dominant undertakings.

Application to AI inference

An inference API provider with substantial market power could potentially breach competition law if it:

• supplies some downstream developers;
• denies equivalent access to competing developers;
• imposes discriminatory conditions; or
• exploits its control over the upstream API.

The central principle is particularly relevant where downstream businesses have become commercially dependent upon the dominant infrastructure.

7. 3. Bronner v Mediaprint

Oscar Bronner GmbH & Co. KG v Mediaprint is one of the leading EU authorities on refusal to deal and indispensability.

The Court applied a demanding standard before treating refusal to provide access to infrastructure as abusive.

Importance for inference APIs

A downstream AI company could not automatically argue:

"This is the best model, therefore I must receive access."

The company would need to demonstrate something closer to indispensability.

The availability of alternative models is therefore crucial.

However, the analysis could become more complicated where alternatives are:

• substantially inferior;
• capacity constrained;
• prohibitively expensive;
• incompatible with existing systems; or
• unavailable at the required scale.

Thus, the relevant question is not simply:

"Does another model exist?"

but:

"Can the downstream competitor realistically compete using available alternatives?"

8. 4. Microsoft Corp. v Commission

The EU Microsoft decision is highly relevant to technology ecosystems and interoperability.

Microsoft possessed substantial power in one layer of the software ecosystem and was found to have engaged in conduct affecting adjacent markets.

Relevance to inference APIs

An inference provider may similarly control a technical interface that downstream competitors require.

Potentially problematic conduct could include:

• restricting interoperability;
• withholding API functionality;
• degrading compatibility;
• limiting access to important model capabilities;
• tying API access to other services; or
• making downstream products technically dependent upon proprietary interfaces.

The Microsoft precedent demonstrates that technical interoperability can itself have competition significance.

9. 5. Slovak Telekom v Commission

Slovak Telekom v Commission concerned access to infrastructure controlled by a dominant undertaking and the conditions imposed upon competitors seeking access.

The case is important because competition law can scrutinise the terms and conditions of access, not merely outright refusal.

Application to AI APIs

An inference monopolist might technically permit access while imposing:

• excessive minimum commitments;
• restrictive volume requirements;
• discriminatory latency;
• unreasonable rate limits;
• loyalty discounts;
• exclusivity;
• restrictive termination provisions; or
• technical conditions that disadvantage competing applications.

Therefore:

Access that exists formally may nevertheless be competitively ineffective.

This is particularly important for API markets because competition may depend on the quality and reliability of access.

10. 6. Google Shopping

The Google Shopping litigation demonstrates the importance of leveraging power from one digital layer into another.

Google possessed a strong position in general search and used mechanisms that affected the visibility of competing comparison-shopping services.

Relevance to inference APIs

The corresponding AI scenario would be:

Inference dominance

↓

preferential treatment of own downstream AI applications

↓

disadvantage to independent AI applications

For example, an inference provider might:

• give its own applications lower latency;
• provide them with higher model limits;
• provide privileged access to new models;
• reserve advanced features for its own services;
• use API data to improve its competing product; or
• make third-party applications less discoverable within its ecosystem.

The underlying concern is leveraging upstream digital power into an adjacent downstream market.

11. 7. Android / Google

The Google Android litigation is also relevant to ecosystem leverage, tying and strategic use of platform power.

The case illustrates how contractual and technical arrangements across interconnected digital markets can reinforce dominance.

Application to inference ecosystems

Suppose an AI provider controls:

1. a dominant inference API;
2. an AI application marketplace;
3. an operating system or cloud platform; and
4. a downstream AI assistant.

It could potentially use contractual or technical arrangements to require downstream firms to purchase multiple services together.

This could transform an inference monopoly into an ecosystem monopoly.

12. 8. IMS Health

IMS Health is another important EU authority concerning indispensable information infrastructure and refusal to provide access.

The case demonstrates that competition law may intervene where control over an infrastructure or information resource becomes sufficiently indispensable to downstream competition.

AI relevance

Inference APIs increasingly combine:

• computational infrastructure;
• model capability;
• proprietary interfaces;
• accumulated technical knowledge; and
• developer ecosystems.

A sufficiently entrenched API can therefore begin to resemble digital infrastructure, rather than merely an ordinary commercial product.

13. Self-Preferencing and Downstream Competition

One of the most important risks is self-preferencing.

Imagine an AI provider operates:

Upstream

inference API

and

Downstream

AI research assistant.

Independent developers also operate AI research assistants.

The provider possesses information about:

• API usage;
• customer demand;
• prompts;
• latency;
• conversion;
• failure rates;
• application categories.

If the provider uses that information to replicate successful downstream products, it can potentially compete with an informational advantage unavailable to independent developers.

This creates a feedback loop:

API control → information collection → downstream entry → improved competing product → stronger API dominance.

14. Margin Squeeze

A particularly important theory is margin squeeze.

Suppose the dominant provider:

• charges downstream competitors a high API price;
• simultaneously offers its own downstream application at a low price.

The downstream competitor may therefore face:

API input cost > economically viable downstream retail price.

Even though the API is technically available, the downstream competitor cannot profitably compete.

This can potentially produce:

Upstream dominance + downstream foreclosure.

15. Predatory or Strategic API Pricing

An inference provider might alternatively:

• temporarily underprice inference;
• subsidise API consumption;
• offer aggressive discounts;
• lock developers into long-term contracts; and
• subsequently increase prices after competitors have become dependent.

This creates a potential dependency-building strategy.

Competition authorities would need to distinguish:

legitimate innovation and introductory pricing

from

strategic exclusionary pricing.

16. Exclusivity and Loyalty Contracts

Inference providers could require downstream developers to:

• use only one model;
• purchase minimum volumes;
• avoid competing models;
• use a particular cloud;
• refrain from migrating workloads;
• maintain minimum API consumption.

Such provisions can increase switching costs and prevent competing inference providers from obtaining scale.

The competition concern becomes stronger where the dominant provider already controls a substantial share of downstream demand.

17. API Degradation as a Competitive Weapon

A particularly novel AI-specific issue is quality degradation.

Instead of refusing access, a dominant provider could give a rival:

• slower inference;
• lower rate limits;
• reduced context windows;
• older model versions;
• weaker tool access;
• reduced reliability.

This is effectively:

constructive refusal through degraded technical access.

Traditional competition-law principles concerning access and discrimination can therefore become relevant to API architecture.

18. Model Version Lock-In

Downstream companies may build their applications around a specific model version.

The provider could then:

1. launch a new model;
2. discontinue the old model;
3. force migration;
4. alter technical requirements;
5. make migration expensive.

This can create technological lock-in.

The competition issue becomes particularly serious if the provider uses forced migration to:

• eliminate compatibility with rival systems;
• impose new contractual conditions; or
• make competing infrastructure more difficult to use.

19. Bundling and Tying

An inference provider could condition API access on purchasing:

• cloud storage;
• advertising;
• data analytics;
• identity services;
• application hosting;
• marketplace placement;
• cybersecurity services.

This can extend market power from the inference market into neighbouring markets.

The more markets controlled by the same AI ecosystem, the greater the possibility of cross-market foreclosure.

20. Data and Information Advantages

Inference APIs generate potentially valuable information concerning downstream businesses.

The provider may observe:

• workload patterns;
• customer requirements;
• application functionality;
• failed prompts;
• product launches;
• industry demand;
• usage volumes.

If that information is used to compete against API customers, the provider obtains an unusual form of upstream informational leverage.

This is especially problematic when downstream firms cannot prevent the provider from observing commercially important API interactions.

21. Dependency and Innovation

The greatest long-term concern is not necessarily higher prices.

It may be suppressed innovation.

If developers believe that:

"There is no viable way to compete without this API,"

then potential entrants may avoid investing in:

• new models;
• alternative infrastructure;
• specialised AI architectures;
• open-source systems;
• inference optimisation;
• alternative API standards.

Thus, dependency can reduce dynamic competition even where short-term prices appear competitive.

22. Objective Justifications

An inference provider may legitimately impose restrictions for reasons such as:

• cybersecurity;
• safety;
• abuse prevention;
• privacy;
• regulatory compliance;
• model misuse prevention;
• capacity management;
• intellectual-property protection.

Competition law should therefore distinguish legitimate technical restrictions from exclusionary restrictions.

A provider should ideally be able to demonstrate:

1. the restriction addresses a genuine risk;
2. the restriction is necessary;
3. less restrictive alternatives were considered;
4. the restriction is applied consistently; and
5. competitors are not selectively disadvantaged.

23. Remedies

Competition authorities could potentially consider several remedies.

Structural remedies

In extreme cases:

• separation of inference and downstream businesses;
• divestiture;
• restrictions on vertical integration.

Behavioral remedies

More commonly:

• non-discriminatory API access;
• interoperability;
• portability;
• transparent API terms;
• reasonable switching mechanisms;
• limits on exclusivity;
• non-discrimination obligations.

Data remedies

Possible measures include:

• restrictions on using downstream API data competitively;
• data-access safeguards;
• confidentiality obligations.

Technical remedies

Authorities could require:

• API interoperability;
• standardised interfaces;
• migration tools;
• model portability;
• transparent versioning.

24. Competition-Law Assessment Framework

A regulator examining an inference API monopoly could ask:

Step 1 — Define the market

Is the relevant market:

AI inference generally

or

specialised inference for a particular capability?

Step 2 — Establish dominance

Consider:

• market share;
• compute capacity;
• model quality;
• developer ecosystem;
• switching costs;
• barriers to entry;
• data advantages.

Step 3 — Identify dependency

Determine whether downstream firms can realistically switch.

Step 4 — Identify conduct

Possible conduct includes:

• refusal to supply;
• discrimination;
• self-preferencing;
• tying;
• exclusivity;
• margin squeeze;
• predatory pricing;
• technical degradation.

Step 5 — Establish foreclosure

Ask whether the conduct can:

• exclude rivals;
• raise their costs;
• reduce innovation;
• prevent entry;
• increase switching costs.

Step 6 — Examine justification

Consider:

• security;
• safety;
• capacity;
• privacy;
• legitimate technical requirements.

Step 7 — Select proportionate remedies

Remedies should preserve legitimate AI innovation while preventing infrastructure-level foreclosure.

25. Key Legal Principle

The most important conceptual distinction is:

An inference API does not become competitively problematic merely because many downstream firms depend upon it.

Dependence becomes a competition concern when substantial market power, indispensability or strategic bottleneck control is combined with conduct capable of restricting effective downstream competition.

The combination is therefore:

Market power + bottleneck control + downstream dependency + exclusionary conduct = potential abuse/foreclosure problem.

Conclusion

Inference APIs may become a critical infrastructure layer for the AI economy. Their competitive significance arises because downstream applications can be technologically and economically dependent on access to particular models and inference infrastructure.

Traditional cases such as Commercial Solvents, United Brands, Bronner, Microsoft, Slovak Telekom, Google Shopping, Google Android and IMS Health provide useful legal principles concerning refusal to supply, indispensability, interoperability, discrimination, tying, leveraging and downstream foreclosure.

The distinctive AI challenge is that dependency can arise without a conventional physical bottleneck. Model quality, proprietary APIs, switching costs, developer ecosystems, scarce compute, accumulated data and technical compatibility can collectively create an AI bottleneck.

Accordingly, future competition-law analysis is likely to focus not merely on whether an alternative inference API technically exists, but on whether downstream firms possess genuine, economically viable and technologically effective alternatives.

The central regulatory objective should be to prevent an inference provider from transforming control of an upstream AI capability into durable control over downstream innovation, applications and markets, while preserving legitimate incentives to develop better models and safer AI infrastructure.