Language Models

Language models, in the jargon Large Language Models (LLM), range from openly available, self-hostable models to closed frontier models behind a foreign API. This page orders the field by the decision every organisation has to make and makes the trade-off visible, instead of crowning a single best model.

Model landscape: a basis for informed decisions

A language model is a model trained on large amounts of text that generates the most probable continuation from an input. This mechanism underlies chat interfaces, code assistants and the generation step in a GenAI and RAG architecture. The practically more important distinction is not which model tops a ranking today, but under what conditions it is run. That is exactly where the dividing line this page orders runs: between models that come in-house, and models reachable only through a provider's interface.

The field is large and moves fast. This page therefore crowns no best model but describes the two camps, the dimensions on which a choice turns, and the intermediary that connects both paths. The individual models are each described on their own catalogue page and linked in place.

Two camps: open weights against closed frontier models

The field splits along a single, consequential property: whether a model's trained weights are freely available or not.

An open-weights model makes its trained weights available for download. That lets it run on in-house hardware without any request ever leaving the organisation's own network. Open availability is not necessarily a fully open licence; both must be checked per model. This camp includes the Llama models from Meta, which are offered for download, and the open models from the European provider Mistral, several of which sit under the Apache 2.0 licence without usage restrictions. Open weights are the precondition for sovereign AI, where the model comes to the data rather than the other way round.

A proprietary model is run exclusively through its provider's API or application; the weights stay locked away. Anyone using it sends every input to the provider's infrastructure. This camp includes the GPT models from OpenAI, Claude from Anthropic and Gemini from Google. These closed frontier models still lead the field on the hardest tasks, such as long reasoning or multilingual code. The line is not perfectly sharp: some providers of closed frontier models also release smaller models with open weights alongside. What matters for the decision is whether the specific chosen model is run open or closed.

flowchart TD
    Q["Use case and data"]
    Q --> OPEN["Open weights<br/>self-hostable"]
    Q --> PROP["Proprietary<br/>provider API only"]
    OPEN --> L["Llama, Meta"]
    OPEN --> MI["Mistral, open models"]
    PROP --> GPT["GPT, OpenAI"]
    PROP --> CL["Claude, Anthropic"]
    PROP --> GE["Gemini, Google"]
    PROP --> GW["Gateway<br/>OpenRouter"]
    GW --> GPT
    GW --> CL
    GW --> GE

The diagram shows the fork: from the use case, one path leads to open models under the organisation's own control, the other to proprietary models behind a foreign API, reachable either directly or bundled through a gateway.

Five dimensions on which the choice turns

The choice between the camps is not made in the abstract but along dimensions that weigh differently depending on the use case.

Data control and residency. A self-run open model keeps every input in-house; nothing leaves the network. An external API sends every request to the provider, whose terms govern how long data is stored and whether it feeds training. For sensitive data this is the decisive difference; the organisational control over it is the work of AI governance.
Cost model. A self-run model incurs fixed costs for hardware and operations, independent of volume. An API charges per token consumed, so variably with usage. At low volume the API is cheaper; at high volume in-house hardware can earn back the fixed cost.
Performance and capability. The strongest closed models lead on the most demanding tasks. Open models have narrowed the gap markedly and are good enough for many structured, tool-driven tasks. The question is not which model is best, but whether the chosen one is sufficient for the specific case.
Openness and licence. Open weights allow adaptation, local fine-tuning and operation without dependence on the provider. The exact latitude is set by the respective licence, which must be checked per model; openly available and fully freely licensed are not the same.
Operational effort. A foreign API is usable immediately, without any in-house operations. A self-run model wants hardware, updating, monitoring and securing, that is an operating discipline of its own. Underestimating it shifts the risk from data protection to availability.

Gateways bundle many providers behind one interface

Between directly connecting a single provider and self-hosting lies a third path: an aggregating gateway. Such a service takes a request and routes it to the chosen model of an upstream provider. OpenRouter is the best-known example and, by its own account, makes several hundred models from dozens of providers reachable through one shared interface compatible with the OpenAI SDK.

The benefit lies in the bundling. A single integration point replaces many direct connections, the routing can steer to the cheapest suitable offer or fall back to another provider when one fails, and billing runs across providers through one shared balance. This reduces dependence on any single provider. The gateway's limit is the same as any external API: the request leaves the organisation's house and passes through the intermediary to the provider. Data residency is not gained this way, but flexibility and a single control point for access to many closed models are.

No best model, but a best fit

The field's honest conclusion is that there is no model that is best across the board. The right choice follows from three quantities: the sensitivity of the data, the budget and the required capability.

If the data is particularly sensitive and nothing should leave the house, the path leads to an open model under the organisation's own control. Open, self-run models maximise control and data residency.
If the highest capability on uncritical data counts and the effort of running in-house operations is not wanted, a closed frontier model over the API is the more pragmatic choice. External frontier models maximise capability.
For organisations wanting to use several closed models flexibly without binding to one provider, they are reachable bundled through a gateway.

In practice the choice is rarely an either-or for the whole organisation. Sensitive use cases run on an open model in house, uncritical ones on the strongest available API, and which data may be processed on which model is governed by AI governance. The page on sovereign AI deepens the self-run path; the individual catalogue pages describe each model in detail.

References

Artificial Analysis Comparison of AI Models across Intelligence, Performance, Price. Independent comparison of many language models from open and closed providers by quality, price and speed. (2026). artificialanalysis.ai/models
OpenRouter OpenRouter Quickstart. Documentation of the aggregating gateway that makes many providers reachable through one interface. (2026). openrouter.ai/docs/quickstart
Meta The Llama 4 herd. Announcement of the downloadable open-weights models Llama 4 Scout and Maverick. (05.04.2025). ai.meta.com/blog/llama-4-multimodal-intelligence/
Mistral AI Mistral 7B. Release of a European open-weights model under the Apache 2.0 licence without usage restrictions. (27.09.2023). mistral.ai/news/announcing-mistral-7b

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.