ModelRefs / Closed Model — AI Glossary

Closed Model — AI Glossary

A model accessed only via API, with weights, training data, and architecture kept proprietary by the provider. A closed model publishes none of it.

Overview

Closed models (GPT-5, Claude, Gemini) typically lead on capability but introduce vendor lock-in, data-residency, and rate-limit constraints. Often paired with open-weights fallbacks for cost optimization or offline use.

Reference details

Topicecosystem
Last reviewed2026-06-24

How it works

  1. Access is mediated entirely by an API. The weights, the training data, the architecture and often the exact parameter count are not disclosed, so the model is a behavioural specification rather than an artefact you hold.
  2. Versioning is the provider's to control. A dated snapshot is the strongest guarantee available, and its lifetime is set by a deprecation policy rather than by you — which is the structural difference from a file on disk that works forever.
  3. Capacity is a quota. Throughput is bounded by rate limits that are negotiated rather than provisioned, so scaling is a commercial conversation rather than a hardware purchase.
  4. Data handling is contractual. Whether prompts are retained, for how long, and whether they may be used for training are terms in an agreement, which is the control that matters for regulated workloads since no technical measure is available to the caller.
  5. Behaviour can change beneath an unpinned identifier. Safety tuning, system-prompt handling and tool-calling formats shift between generations, so prompt-sensitive behaviour is only as stable as your pinning discipline.
  6. The migration surface is prompts and evaluations rather than code. Switching providers is a small integration change and a large re-tuning and re-validation effort, which is where the lock-in actually lives.

Example: The utilisation at which self-hosting becomes cheaper

Compare token cost only. Suppose a closed model bills 3 units per million tokens, and a self-hosted open-weights deployment runs on a GPU costing 2 units per hour and achieving 2,000 tokens per second at a serving batch size you can actually reach. That GPU produces 2,000 x 3,600 = 7,200,000 tokens per hour, or 7.2M, so at full utilisation its cost is 2 / 7.2 = 0.28 units per million — about a tenth of the API price. But a GPU bills whether or not it is busy, so the real figure is 2 / (7.2 x u) for utilisation u. Setting that equal to 3 gives u = 2 / (7.2 x 3) = 0.093, so self-hosting wins on token cost above roughly 9% utilisation and loses below it. That one number reframes the decision: the question is not whether open weights are cheaper per token — at scale they plainly are — but whether your traffic keeps a GPU 9% busy, and what the engineering, on-call and evaluation costs are that this calculation excludes entirely.

Commonly confused with

Closed is not the opposite of open-source, and the middle category is where most of the ecosystem sits. Open-weights models publish downloadable weights under a licence that may restrict use, often without the training data or code, so they are reproducible to run and not to rebuild. Genuinely open-source models publish data and training code as well. A closed model publishes none of it. The distinction matters because 'open' in procurement usually means open-weights, which gives you self-hosting, pinning and offline operation but not auditability of what the model was trained on.

When to use it

Reach for it when:

  • Capability-limited work at the frontier, where the best available model is the deciding factor and it is not downloadable.
  • Low or spiky volume, where per-token billing beats paying for idle accelerators.
  • Small teams without inference expertise, where the operational burden of serving is the dominant cost.
  • Rapid iteration, where swapping a model string beats provisioning hardware.

Reach for something else when:

  • Data residency or processing constraints that a contract cannot satisfy, where the data must not leave your infrastructure at all.
  • Sustained high volume with steady utilisation, where the arithmetic above favours self-hosting by a wide margin.
  • Workloads needing indefinite behavioural stability, since deprecation timelines are the provider's to set.
  • Offline or air-gapped deployment, which an API cannot serve under any terms.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Closed Model — AI Glossary.

Frequently asked questions

What is Closed Model?

A model accessed only via API, with weights, training data, and architecture kept proprietary by the provider.

What concepts are related to Closed Model?

Closely related concepts include open weights.