This page is an overview for anyone who wants to build on a foundation model rather than only chat with one. It covers the routes from your code to a model, what you pay for, and how the main providers’ model families differ. The companies themselves, and their consumer products, are the subject of Frontier AI companies.
What a model provider sells
A foundation model provider trains a general model and sells access to it. Most providers offer two things:
- Applications for people: chat assistants, coding tools, and office integrations, usually paid by monthly subscription.
- An API for software: your program sends text, images, or files over HTTPS and receives the model’s answer. You pay for the amount of text processed.
This page is about the second. An API lets you put a model inside your own product, workflow, or agent, under your own interface and rules.
Ways to access a model
The same model can often be reached through several routes.
flowchart LR app["Your application"] --> lab["Provider API: OpenAI, Anthropic, Google, Mistral, and others"] app --> cloud["Cloud platforms: Amazon Bedrock, Google Vertex AI, Microsoft Azure"] app --> router["Routers and gateways: one API for many providers"] app --> host["Inference providers for open-weight models"] app --> self["Your own servers with open-weight models"]
- Directly from the provider. The fastest way to get new models and features, with one contract per provider.
- Through a cloud platform. Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Azure host models from several providers. Billing, access control, and data residency follow the cloud account a company already has.
- Through a router or gateway. Services such as OpenRouter offer one API and one bill for models from many providers, which makes switching between models easy.
- Through an inference provider. Companies such as Together AI, Fireworks AI, and Groq run open-weight models on their own hardware and sell access per token, often at low prices or high speed.
- On your own hardware. Open-weight models can run on your own servers or laptop. You pay for hardware and operations instead of tokens, and no data leaves your control.
Calling a model through an API
An API call sends a list of messages and receives the model’s reply. Many providers accept the request format that OpenAI’s Chat Completions API made common, so a request looks much the same everywhere:
curl https://api.openai.com/v1/chat/completions \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "MODEL_ID", "messages": [ { "role": "system", "content": "You answer in one short sentence." }, { "role": "user", "content": "What is a context window?" } ] }'The system message holds standing instructions. The user message is the input. Earlier replies come back as assistant messages, because the API itself keeps no memory between calls; your application sends the conversation each time. The response contains the generated text and a count of input and output tokens, which is what you are billed for.
Every provider also ships official SDKs for languages such as Python and TypeScript, plus features beyond plain text: tool calling for agents, structured JSON output, image and file input, streaming of partial answers, and batch processing.
Providers and their model families
| Provider | Model families | Open weights | Also available on |
|---|---|---|---|
| OpenAI | GPT, reasoning models, gpt-oss, Whisper | gpt-oss and Whisper | Microsoft Azure |
| Anthropic | Claude (Haiku, Sonnet, Opus) | No | Amazon Bedrock, Google Vertex AI, Microsoft Azure |
| Gemini, Gemma | Gemma | Google Vertex AI | |
| Meta | Llama, Muse | Llama | Most clouds and inference providers |
| Mistral AI | Mistral, Codestral, Devstral, and others | Many | Major clouds |
| DeepSeek | DeepSeek V and R series | Yes | Inference providers |
| Alibaba | Qwen | Many | Alibaba Cloud, inference providers |
| xAI | Grok | Some older models | Microsoft Azure |
| Cohere | Command, Embed, Rerank | Some, for research | Major clouds |
Model versions change every few months, so the table lists families. Each provider’s documentation has a model overview page with the current versions, prices, and context window sizes.
A few patterns hold across providers:
- Families come in sizes. A large flagship model is the most capable and the most expensive. Medium and small models are faster and much cheaper, and good enough for many tasks. Anthropic names the sizes Opus, Sonnet, and Haiku; others use labels such as Pro, Flash, or Mini.
- Reasoning is often a setting. Many current models can think step by step before answering. Applications choose how much reasoning effort to spend, trading speed and cost for accuracy.
- Specialized models sit next to the chat models. Providers offer embedding models for search, speech-to-text and text-to-speech models, image and video models, and models tuned for code.
- Chinese labs publish many strong open-weight models. DeepSeek, Qwen, Kimi from Moonshot AI, GLM from Zhipu AI, and MiniMax release weights under permissive licenses, which made them popular for self-hosting.
Pricing models
API usage is billed per token, usually quoted as a price per million tokens. Output tokens cost several times more than input tokens, because generating text takes more computation than reading it. Reasoning models are billed for their hidden thinking tokens as output, so a short answer can still be expensive.
Providers add several ways to lower the bill:
- Cached input. When many requests start with the same long text, such as a system prompt or a document, the repeated part is billed at a fraction of the normal price.
- Batch processing. Requests that can wait for hours are often processed at about half price.
- Smaller models. Moving a simple task from a flagship model to a small one can cut the cost by more than ten times.
- Provisioned throughput. Large customers can reserve capacity for a fixed fee instead of paying per token.
Consumer and team subscriptions are priced per user per month and are separate from API billing. The cost of AI works through an example calculation.
Matching a model to a use case
| Use case | What matters most | Typical choice |
|---|---|---|
| Chat assistant or customer support | Quality of answers, tone, cost per conversation | Medium model with retrieval over your documents |
| Coding and software agents | Reasoning, tool use, long context | Flagship or strong coding model |
| Classification, extraction, routing | Low cost, speed, structured output | Small model |
| Document analysis and summaries | Long context window, accuracy | Medium or large model with a large context window |
| Search over your own content | Good embeddings, retrieval quality | Embedding model plus retrieval-augmented generation |
| Sensitive or regulated data | Data control, location | Open-weight model on your own servers, or a cloud region with suitable contracts |
| Images, audio, video | The right modality | Specialized generation or speech models |
Choosing a provider
The best model on a public leaderboard is not automatically the best choice for a product. A short checklist:
- Quality on your task. Test candidate models on a set of your own examples. Evaluating AI models explains how.
- Cost and speed. Estimate tokens per request and requests per day, and measure response time.
- Data handling. Check whether inputs are stored, for how long, whether they are used for training, and in which region they are processed. AI and data privacy covers the questions to ask.
- License and lock-in. Open weights and widely copied API formats make it easier to switch later.
- Features. Tool calling, structured output, file input, and the context window size your application needs.
- Reliability. Rate limits, uptime history, and support. Many teams keep a second provider configured as a fallback.
Check your understanding
Question 1 of 7
0 of 7 checked