Call a model maker's API directly when you know which models you want and need new releases first; use a host or a gateway when you'd rather have many models behind one key. Going direct gives you the maker's own docs, limits and release timing. Either way, keep your code behind a thin wrapper, because model names and lists go stale quickly.
There are three ways to reach a large language model: straight from the company that trains it, through a host that runs other people's models, or through a gateway that routes your calls between providers. This list covers the first route, plus the cloud platforms and fast inference providers developers often weigh against it. All ten are in no particular order.
Direct, host or gateway
Going direct means one account per model maker. You get new models as soon as they're released, the maker's own documentation and its own rate limits, and nobody sits between you and the API. The downside is that every provider you add means another key, another SDK quirk and another bill to watch.
A host runs models for you, often a mix of open-weight ones, and a gateway sits in front of several providers so you can switch or fall back without touching your app. If that's the shape you need, my lists of LLM gateways and routers and LLM hosting platforms are the better starting points, and Together AI alternatives covers the open-model hosts.
Why model lists go stale
Vendor pages change faster than reviews do. On the vendor pages as of Nov 2026, x.ai/api serves a page titled SpaceXSI API for Grok models, Google's developer page still lists Gemini 2.0 Flash and 2.5 Pro, and Groq now calls itself a neocloud for fast inference. A tutorial written a few months ago may name a model that's been renamed, replaced or scheduled for retirement.
So read each vendor's current model page and its retirement or deprecation page before you build, and again before you ship. Pin the exact model name in your configuration rather than relying on an alias that might quietly point somewhere new.
Ten providers side by side
| Tool | Group | Good for |
|---|---|---|
| Amazon Bedrock | Cloud platform | Teams already building on AWS |
| Claude Platform (Anthropic) | Frontier model maker | Building and running AI agents on frontier models |
| Cohere | Enterprise model maker | Private, secure, customisable enterprise deployments |
| DeepSeek API | Open-weight maker | Switching over with minimal code change |
| Gemini API (Google) | Frontier model maker | Hosted Gemini and open Gemma models in one place |
| Groq | Fast inference | Apps where response speed matters most |
| Mistral | Open-weight maker | Running open-weight models on-prem, in a VPC or cloud |
| OpenAI API | Frontier model maker | The most widely supported API format |
| Perplexity API | Search-grounded API | Live web answers inside your own product |
| xAI API | Frontier model maker | Grok models plus image, video and voice APIs |
Labs that train their own models
Most of this list is companies that train their own frontier models and sell access directly. Their pitches differ: one pairs its models with a managed harness for building agents, one covers hosted models and open models on the same developer page, one offers a free Playground for its models as of Nov 2026, and one aims squarely at private, customisable enterprise deployments. There's also a search-grounded API built for live web answers inside your own product, which is a different job from general text generation.
Open-weight makers
Two makers here sell models with published weights alongside an API. That gives you a way out: if the hosted API stops working for you, you can run the same model elsewhere, on-prem or in your own VPC. For teams with data-location rules, that option can matter more than any benchmark.
Cloud platforms and fast inference
A cloud platform puts many models inside the account you already use for everything else, with your existing access controls and contracts. That's appealing if you're already deep in one cloud. Fast inference providers focus on serving models quickly, which matters for chat, voice and anything a user waits on. For more of that side, see my guide to AI inference platforms.
Every provider, A to Z
Alphabetical, one line each on who it's built for.
Amazon Bedrock
Best for: AWS customers building generative AI applications and agents inside the platform they use.
Claude Platform (Anthropic)
Best for: Teams building agents who want frontier models paired with a managed harness, context management and infrastructure.
Cohere
Best for: Enterprises with privacy needs using models to automate processes and surface insight from their own data.
DeepSeek API
Best for: Developers wanting to switch with minimal code change, since the docs say a configuration change lets you use the OpenAI or Anthropic SDK.
Gemini API (Google)
Best for: Developers already in Google's ecosystem who want Gemini models and Gemma open models through one API and Google AI Studio.
Groq
Best for: Products where response speed matters, on infrastructure built for fast inference and model serving.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Mistral
Best for: Organisations with data-location needs that want open-weight models they can customise and deploy on-prem, in their own VPC or on the maker's cloud.
OpenAI API
Best for: Teams wanting OpenAI's latest models and safety guides on an API whose format other vendors document compatibility with.
Perplexity API
Best for: Products that need real-time, web-wide research and answers, with Agent, Search and Embeddings APIs on one platform.
xAI API
Best for: Anyone wanting Grok models alongside image, video and voice APIs, with a Playground to try them first.
Switching between providers
Switching is easier than it used to be. DeepSeek's docs say its API format is compatible with the OpenAI and Anthropic SDKs, so the vendor's claim is that you change configuration rather than rewrite code. Check that claim against the features you rely on, such as tool calling or streaming, before you count on it.
The safer habit is a thin wrapper of your own: one function your app calls, with the provider and model name set in configuration. Keep your prompts versioned outside the code, using one of the prompt management tools, and log every call so you can compare providers on real traffic with LLM observability tools.
My advice on calling a model maker directly
Here's what I'd do. Start with one direct provider whose models fit your main task, wrap it in a single function from day one, and add a second provider only when you've got a real reason, such as speed, data location or a model that does one job better. If you're on one cloud already, look at its platform before you open another account. Check model and retirement pages every month or so, because that's where projects quietly break. And don't move to a gateway until juggling keys is the problem you're solving, not the one you're expecting.
Do you make an LLM API? Tool makers can ask to be considered for a featured place on this list.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
What's the difference between an LLM API provider and a gateway?
A provider gives you access to its own models, or models it hosts, through its API. A gateway sits in front of several providers and routes your calls, so you can switch or fall back with one key.
Can I switch LLM providers without rewriting my code?
Sometimes. Some vendors document compatibility with widely used SDKs, so a configuration change may be enough. Keeping calls behind your own wrapper makes any switch smaller.
What does open-weight mean?
An open-weight model has its trained weights published, so you can run it on your own servers or a host of your choice instead of only through the maker's API.
How do I know if a model is being retired?
Check the provider's model and deprecation pages, and sign up for their developer updates. Pin exact model names in your configuration so a change doesn't happen silently.
Do I need a fast inference provider?
Only if users wait on the response, as in chat or voice. For background jobs such as summarising documents overnight, speed matters far less than quality and reliability.
