Who actually serves these models, and does it matter where they are?

The easy mistake is to think model access is a question about model vendors alone: OpenAI, Anthropic, Google, Meta, Mistral. In practice, running models in production is also a question about who serves the inference. OpenRouter presents one catalogue and one API surface, but behind that surface sit 105 providers. They are not all the model creators. They are the companies and services that actually host, route, and bill the requests.

That matters for a simple reason: the model name tells you what weights or endpoint family you are calling, but the provider determines part of the operational and legal reality around the call. If you care about latency, region, documentation, or which company is actually receiving the request, the provider layer is not administrative detail. It is part of the product.

The first fact is concentration. Among providers that declare a headquarters, the US dominates. The published breakdown shows 55 providers headquartered in the US, far ahead of every other jurisdiction. After that come Singapore and China with 6 each, then Israel with 2, and single-provider entries for Spain, the Netherlands, Indonesia, Sweden, and France.

That is not the same thing as saying all providers are American, because some do not publish a headquarters in the catalogue metadata. But it does mean the declared landscape is not geographically balanced. The platform may feel global; the provider base, on what is publicly declared, is much less evenly spread.

Why should anyone care where a provider is headquartered? Not because one country automatically implies good or bad practice. It matters because jurisdiction changes the legal surface behind the same inference call. A provider’s headquarters is not the whole story — data residency, subprocessors, and actual datacenter location matter too — but it is one of the few durable facts a buyer can establish quickly. It tells you which legal system the company primarily sits under, where corporate accountability begins, and which policy documents are supposed to explain the rest.

That is where the second fact becomes useful: publication quality is uneven. In the current provider set, 13 of 105 providers publish neither a privacy policy nor terms in the linked catalogue materials. That should be stated carefully. It is a fact about what is publicly linked and published, not proof that a provider has no internal policy, no contractual terms, or no compliance process. But for a customer trying to assess operational risk, the public documentation is what exists until something else is supplied.

A missing document is not a moral verdict. It is a reduction in assessability. If a provider publishes neither privacy terms nor service terms, a buyer cannot easily answer routine questions: what happens to prompts, which commitments are made about retention, what liabilities are disclaimed, what service boundaries exist, and under which terms the service is actually offered. Those are not edge-case procurement questions. They are basic questions about sending data to someone else’s infrastructure.

The point is sharper in an aggregator setting. When one API makes many providers look interchangeable, the temptation is to compare only price and throughput. Sometimes that is enough; often it is not. If two providers expose the same family of model at similar quality and cost, but one gives a clear legal and policy surface while the other does not, they are not operationally identical.

This is also why “where are the models?” has two different answers. One answer is legal: which company serves the request, and where is that company based? The other is physical: in which datacenter region is the inference actually run? The current catalogue headline count reports 7 declared datacenter regions. That helps, but only partially. Region declarations tell you something about likely latency and possible data locality. Headquarters tell you something about corporate and legal context. Neither substitutes for the other.

A sensible way to read the provider layer is therefore not as a trust ranking, but as a filter:

• First, identify whether the provider publishes the minimum documents needed to evaluate it.
• Second, check which jurisdiction it declares, because that changes the legal frame around the same technical service.
• Third, check declared regions if locality or latency matter to the workload.
• Only then compare price, speed, and model availability.

The main conclusion is less dramatic than the market rhetoric around model access. The important unit is not just “which model,” but “which provider serving which model under which published terms.” On OpenRouter today, that means dealing with a market of 105 providers, a declared headquarters map led heavily by the US, and a non-trivial minority — 13 providers — whose public documentation omits both privacy policy and terms.

For teams putting models into production, that does not imply panic or paralysis. It implies a more exact question. Before asking whether a model is available, ask who is actually serving it and whether they have published enough for you to assess the risk. Inference is infrastructure. Infrastructure is never just the weights.

Both projects are on GitHub and PyPI. Install them.