Your developer asked which AI provider you want to use. Or a vendor told you their product is “built on OpenAI” as if that settled something. You have read that one company’s model is the smartest, then read the opposite a week later, and you suspect the honest answer is that it does not matter as much as everyone says.
You are mostly right. Choosing an LLM provider matters less than choosing well how your software talks to it. But the account will be in your name, the bill will be yours, and your customer data will pass through it, so the decision deserves twenty minutes of clear thinking rather than a coin flip or a sales pitch.
This article gives you that. What the main providers are, how they differ on the things a business actually feels (quality, cost, data terms, reliability), the setup that stops the choice from becoming a marriage, and when a small cheap model is all you need.
What this actually is
An LLM provider is a company that runs large language models (the systems behind Claude, GPT-class models, and Gemini; explained from zero in What Is an LLM? A Plain Explanation for Business Owners) on its own computers and lets your software send text in and get text back over the internet, billed by usage. You never install anything. Your application makes a request, the provider’s model answers, you pay per token (a unit of text, roughly three quarters of a word).
The analogy is a utility. You do not generate your own electricity; you pick a supplier, plug in, and pay for what you use. The suppliers differ in price, reliability, and terms, and the smart move is to wire your building so that switching suppliers means changing a contract, not rewiring the walls.
There are three kinds of supplier. The big closed providers (OpenAI, Anthropic, Google) run their own models that nobody else can host. The cloud platforms (Amazon Bedrock, Microsoft Azure, Google Vertex) resell those same models and others under the cloud’s own contract and billing. And the open-weight models (families like Llama, Mistral, Qwen, DeepSeek, and OpenAI’s open releases) are published for anyone to run, either on a hosting service or on your own hardware.
How to choose, in eight rules
1. Sort by tier before you sort by brand
Every provider offers a ladder: a small fast cheap model, a mid-tier model, and a large expensive one. The gap between tiers within a provider is usually bigger than the gap between providers at the same tier. So the first decision is not “OpenAI or Anthropic,” it is “what tier does this feature need.”
Classification, extraction, routing, and short summaries are small-model work. Drafting customer-facing text, answering from documents, and anything that needs judgment is mid-tier work. Complex multi-step reasoning, code, and long documents are where the large models earn their price. Start every feature one tier lower than you think it needs and move up only when your measurements say so (AI Evaluation and Evals: Testing an AI Feature Before Launch).
2. Read the data terms before the price list
This is the part that is actually about you. On their business and developer terms, the major providers state that what you send through the API (the programmatic door your software uses, as opposed to a consumer chat app) is not used to train their models, and describe how long they retain it, typically a short window for abuse monitoring with zero-retention options for some customers. Consumer chat products are a different matter and often do use conversations for training unless you opt out. Read the current terms for the exact product your developer will use, not the marketing page, and keep a copy.
The cloud platforms add a wrinkle that some businesses like: if you already have a contract with Amazon, Microsoft, or Google, using the models through that platform means your data stays under a contract your lawyer has already read. The full list of questions to ask is in AI Data Privacy for Business, What Happens to Customer Data.
3. Compare cost on your own traffic, not the price table
Prices are quoted per million tokens, separately for what you send (input) and what comes back (output), with output usually several times more expensive. That table is nearly useless on its own. What you need is the cost per unit of your work: per ticket summarised, per document extracted, per customer conversation.
Have your developer run fifty real examples through the two or three candidate models and multiply. The answer often surprises people: the “expensive” provider’s small model is cheaper than the “cheap” provider’s mid-tier one for the job, or the whole feature costs less than a lunch a month at any provider and the comparison is a waste of time. Check the current pricing page for each; prices change every few months and always downward.
4. Check what happens when you send too much
Every provider limits how many requests and tokens you can send per minute, and the limits start low for new accounts and rise with usage or spend. This bites businesses that launch a feature, get a busy Monday, and find their requests refused. Ask your developer what your limits are and how the software behaves when it hits them (it should queue and retry, not fail). Reliability differs too; every provider has outages, and the practical protection is not choosing the one that “never goes down” but having a second one wired in.
5. Do not marry one: put the provider behind one door
The single most valuable thing you can do is structural, not commercial. Every call to the model goes through one place in your software, one module, with the provider name, model name, and prompt in configuration rather than scattered through the code. The rest of the application asks that module for a summary or a label and never knows which company answered.
With that in place, switching providers is a configuration change and a test run. Without it, switching is a project nobody schedules. It also lets you route by feature: a cheap model from one provider for classification, a stronger one from another for drafting, and a fallback if the first is down (LLM Cost Optimization in Production: A Practical Guide shows how that routing saves money). In the systems we build, this module exists before the first feature does. There are also open-source libraries that present many providers behind one interface, which is a reasonable shortcut as long as you own the configuration.
6. Know when open-weight is the right answer
Open-weight models can be hosted by a third party (Groq, Together, Fireworks, and the cloud platforms all offer them) or run on your own server. Hosted, they are often the cheapest option per token and are good enough for small-model work. Self-hosted, they are the answer when data must not leave your premises (a regulated workload, a contractual promise, a government customer), but self-hosting means buying or renting a machine with a serious graphics card, keeping it patched, and having someone who can fix it, which is a real ongoing cost that most businesses under two hundred people should not take on.
Our view: use open-weight through a hosting service for cheap, high-volume, low-stakes work, and only self-host when a contract or a regulator requires it.
7. Prefer boring, current, and documented
Pick models the provider marks as current and stable, not previews. Pick the ones with the widest documentation and the most examples, because your developer will be faster and your next developer will be able to read the code. Avoid models the provider has already announced it will retire; every provider publishes deprecation dates, and your software should not depend on something with an expiry.
8. Write the decision down and revisit it twice a year
Record why you chose what you chose: the tier, the provider, the terms you read, the cost per unit you measured. Put a date on it. Every six months, rerun the fifty examples on the current models from each provider and look at the numbers. Prices fall, quality rises, and the right answer changes. Because the provider is behind one door, acting on a better answer is an afternoon.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: an industrial parts distributor with forty staff, a custom order portal, and a plan to add three AI features: classifying inbound emails into quotes, orders, and support; extracting line items from emailed purchase orders; and drafting replies to quote requests.
What was wrong: the first developer quote named a single premium model for everything, hard-coded, with the cost estimated from the price table. The owner asked what would happen if that provider raised prices or had an outage, and the answer was a shrug.
What gets built instead:
- A single AI module in the portal with provider, model, and prompt per feature in configuration, plus logging of every call’s cost.
- Email classification on a small fast model from one provider, chosen after running two hundred old emails through three candidates and picking the cheapest that matched the human labels almost every time.
- Purchase-order extraction on a mid-tier model with structured output (a fixed set of fields the software reads directly), from a second provider, because it handled scanned attachments better on the distributor’s own samples.
- Quote drafting on the first provider’s mid-tier model, with a fallback to the second provider’s equivalent if the first returns errors.
- Business terms reviewed and filed for both providers; the API accounts opened in the company’s name with spending caps set.
- A six-month calendar reminder to rerun the samples.
What changes: the three features cost a fraction of the original single-model estimate because two of them run on small models. An outage at one provider during the first quarter goes unnoticed by staff because the fallback took over. When a better mid-tier model appears eight months later, the switch for drafting takes an afternoon.
What it costs to run
The models are billed by usage. For a business of this size with a few thousand requests a month, small-model features cost single-digit dollars monthly, mid-tier features tens of dollars, and only heavy document or reasoning work reaches into the hundreds. Check each provider’s current pricing page rather than trusting any figure printed here.
Provider accounts are free to open; you pay for usage, and every major provider lets you set a monthly spending cap, which you should do on day one. Hosted open-weight models are typically cheaper per token than closed models at the same tier. Self-hosting starts at a few hundred dollars a month for a rented machine with a suitable graphics card, plus the person who looks after it. The one-door module costs nothing to run; it is a few days of developer time once.
The mistakes we see most
- Choosing by headline. Picking whichever provider was in the news this week, for every feature, at the top tier.
- Hard-coding the provider. Model names in forty files. Two years later, still on a deprecated model because switching is “a project.”
- Consumer terms for business data. Staff pasting customer records into a free chat app because nobody set up a proper account with proper terms.
- Estimating cost from the price table. Then being surprised by the bill, in either direction.
- No spending cap, no rate-limit handling. A bug loops overnight and the invoice is the first anyone hears of it.
- Self-hosting for pride. A server nobody maintains, running a model nobody updated, to avoid a bill that would have been forty dollars.
When to bring in help
You can open an account, read the terms, and set a spending cap yourself, and you should, because the account should be yours. If you are using AI through off-the-shelf products, the provider choice is theirs, and your job is only to read their data terms.
Once the choice affects your own software, you need a developer to build the one-door module, run the sample comparison, and wire in the fallback. That is a few days of work on a well-kept code base and it saves months later. If a developer proposes hard-coding a single model, or cannot tell you what happens at the rate limit, that is the moment to get a second opinion. The general plan for adding features once the provider is behind the door is in How to Add AI to Existing Software Without Breaking It.
Levelbrook builds this for businesses: the provider behind one door, the models chosen from your own samples, the accounts in your name with caps set. Fixed price from a written scope, everything runs in accounts you own, and the form below is how a conversation starts.