Closed models are used purely through a vendor's API, trading control for zero infrastructure burden.
ConceptWhat it is
A closed model is accessed exclusively through a provider's hosted API, with the underlying weights kept private, so users send requests over the network and receive responses without ever running the model themselves. It exists because frontier labs invest enormous compute and research into training the very best models and monetize that investment through API access rather than releasing the weights.
This model gives users instant access to state-of-the-art capability with zero infrastructure to manage, at the cost of depending on the provider's pricing, availability, and data-handling policies.
How it worksThe mechanics
The provider trains and hosts the model on its own infrastructure, exposing an HTTP API where clients send a prompt and receive a completion, typically billed per input and output token; the provider controls versioning, rate limits, safety filtering, and uptime, and the model's weights never leave their servers.
At a glanceSee it
A rented closed model keeps evolving beneath you — pinning a dated snapshot and re-evaluating each release is the only guard against silent version drift.
Closed does not mean opaque — the API deliberately exposes a controlled surface such as text and hosted fine-tuning while sealing the weights, activations, and training data.
When to use itWhere it fits
- Teams that want instant access to frontier capability without managing infrastructure.
- Products needing the absolute best available quality on hard reasoning or multimodal tasks.
- Low to moderate volume workloads where API pricing beats the fixed cost of self-hosting.
- Fast prototyping and iteration before committing to a self-hosted deployment.
When NOT to use itLimits & anti-patterns
- Strict data residency or privacy requirements that forbid sending data to a third-party API.
- Extremely high, sustained volume where self-hosting an open-weight model becomes cheaper.
- Use cases needing deep architectural customization beyond what fine-tuning APIs expose.
Trade-offsAdvantages & costs
Advantages
- Access to frontier-level capability without any infrastructure investment.
- Provider handles scaling, uptime, and continuous model improvements.
- Fast to integrate, often production-ready within a day via a simple API call.
- Includes built-in safety tuning and moderation from the provider.
Trade-offs & costs
- Ongoing dependency on the provider's pricing, rate limits, and API stability.
- Data typically passes through the provider's infrastructure, a concern for sensitive workloads.
- Per-token costs can add up significantly at high volume.
- No access to model internals for deep customization or full fine-tuning.
ExampleIn the real world
Most companies building on OpenAI's GPT-5, Anthropic's Claude, or Google's Gemini access these frontier models purely through their respective APIs without ever seeing the underlying weights.ToolsHow to implement it
- OpenAI APIhosted access to the GPT model family.
- Anthropic APIhosted access to the Claude model family.
- Google Vertex AI / Gemini APIhosted access to Gemini models.
- Amazon Bedrockunified API gateway to multiple closed and open model providers.
Cost & effortWhat it takes
Pay-per-token pricing with no infrastructure cost; latency depends on provider load and model size; minimal engineering effort to integrate versus self-hosting.
What changedWhat changed here
- World's Largest Free AI Model Goes Live With 2.8 Trillion Parameters: Kimi K3
Moonshot's Kimi K3, an open-weight model with 2.8 trillion parameters, is now live, giving builders a frontier-scale model they can self-host and fine-tune rather than rent by the token. That changes the default for anyone who assumed frontier capability only comes through a closed API.
Three kinds of claim, strongest first. Signal runs every morning.