The big AI model families

A handful of labs build the models that nearly every AI product in a business runs on, including the ones with somebody else’s logo on them: ChatGPT is a product wrapped around OpenAI’s models, and the layer underneath is usually somebody else’s.

Each lab has a model at the top of its range: the newest, the largest, the most expensive to run, the one the lab’s reputation gets measured on and the one the announcements are about. The shorthand for that group, across all the labs, is the frontier. Most work never touches it.

Who makes the models

The useful split is how the model reaches a business. One group keeps the model on its own machines and sells access to it, through an API for whoever is building something, or through a product anyone can open.

GPT, from OpenAI. The name most people outside the industry know, because ChatGPT is what put a model in front of everyone. Reasoning used to be a separate line of models here. It is now a setting on the main one, turned up when a question is worth the extra time and money and left alone when it isn’t.

Claude, from Anthropic. Several sizes ship side by side rather than one flagship, from a small fast model up to the top of the range. Strong on long documents and on code, and common inside large companies.

Gemini, from Google. The strongest of this group on images, audio and video, and wired through Gmail, Docs and the rest of Workspace, which is how most businesses meet it first.

Grok, from Elon Musk’s lab, now part of SpaceX. It sat outside the serious conversation for a while and now sits at or near the top of the general capability rankings, with a business product to match.

The second group publishes the model file itself, so it can be downloaded and run on machines the company controls. DeepSeek and Qwen, from Alibaba, are the two a business is likeliest to meet by name. Kimi, from Moonshot, and GLM, from Z.ai, sit alongside them, and the top of that group has been Chinese for a while now. Mistral, the French lab, publishes files and sells hosted access to both, and turns up wherever rules about which country the data sits in are doing the deciding. Llama, from Meta, is the reason published weights went mainstream at all. It is no longer the top of this group, and Meta has started keeping some of its strongest models closed.

Open vs. closed models is where that second column actually gets weighed up: what the licence permits, where the data goes, which cost shape fits.

None of these names are fixed. Labs that were footnotes 2 years ago are in the top 5 now, most of the second group barely registered in a business conversation then, and at least one name above will have moved again within a year. The grouping survives the reordering. The list doesn’t.

Tiers within each family

Each lab ships at roughly 3 sizes. The names change every 6 to 12 months. The pattern doesn’t.

Top tier. The smartest, slowest, most expensive. The models that work through a problem before answering live here. Used for hard reasoning, long-form work, anything where quality matters more than speed or cost per call.

Workhorse tier. Meaningfully cheaper, almost as good for most everyday tasks. This is what most live systems actually run on.

Small and fast tier. Fast, cheap, less capable. Used for high volume and low difficulty: classification, routing, simple extractions, anything that has to run millions of times a month.

Across the big families, the small tier costs somewhere between a tenth and a twenty-fifth as much per page of text as the top tier, and answers in about a second where the top tier can take tens of them. Put a page in and take a short answer out and the top tier costs around a US cent, the small tier a small fraction of one. 100 of those a day and the difference is invisible. 100,000 a month and it is tens of dollars against about $1,000. Which of those two a given workflow lands on is arithmetic that can be done before anything is built.

That is why the tier question is usually settled by the job rather than by preference. Cheap model on the volume, expensive model on the exceptions, is the shape most of this work settles into.

Example

Say every supplier invoice that arrives gets read, matched against a purchase order and flagged where the two disagree: 40,000 a month, the same short job every time. The small tier reads and matches them for a few tens of dollars, fast enough that nothing queues, and wrong rarely enough that the errors land in the flagged pile a person is reading anyway. The top tier would hold the queue up for a difference in accuracy nobody downstream would see; at this volume the money is small either way, the waiting is not. The few hundred flagged invoices, where the disagreement is genuinely ambiguous, are worth the top tier’s time.

The whole curve also shifts down over time. The frontier model of the previous generation is roughly the small, fast tier of the next one, at a fraction of the price. Any cost or capability assumption locked in today goes stale fast.

What “best at” actually means

Marketing pages and benchmark tables say things like “best at coding”, “most creative”, “top of the leaderboard”.

• The numbers change every few months as new models ship. Today’s leader is often next quarter’s middle of the pack.
• Benchmarks are necessarily generic. They measure standardised tasks that may or may not resemble the job the model would actually be put on.
• They don’t account for prompt quality, context, or how the model is wired into the work around it. The same model in a thoughtful workflow beats a smarter model wired badly.
• They don’t capture taste: how a model phrases things, handles ambiguity, hedges or commits, lays out an answer meant to be pasted into a document. For real work, taste is most of the experience.

Example

Say a lab announces its new model is state of the art on a coding benchmark, 2 points ahead of the nearest rival. What that claim licenses: on that benchmark, on that day, run by the lab, the model is at the top. What it does not license: that 2 points is visible on the code any particular team writes, that it survives the next release from a rival, or that the benchmark resembles the team’s work. 2 points on a leaderboard and a decision to change the model wired into everyone’s editor are not facts of the same size.

For most everyday business tasks, drafting, summarising, extracting, classifying, answering questions over documents, the top few models are interchangeable in any way a user would notice. The differences bite at the edges: extremely long documents, hard reasoning, specialised code work, images and audio, less-resourced languages, very strict instruction-following.

Where the differences come from

The labs train on heavily overlapping material and read each other’s research, which is most of why the models land so close together. What separates them is mostly house style, and it comes from two places: what went into the training mix, and what the lab rewarded once the raw model existed. One lab pushes hard on following an instruction to the letter, another on refusing to guess, another on code. Those are choices, made by people, and they are what a team is reacting to when it says a model feels better on this work.

How “which is best” actually settles

Rarely by benchmark. It settles by use: somebody running real work on a model for a few weeks, noticing where it shines and where it frustrates, and forming a taste. Two teams in the same company often land in different places, and both can be right. Done on purpose, on a team’s own past cases rather than over months of live work, that is testing before trusting.

Example

Say the sales team drafts outreach on the model that holds the house tone, and stops arguing about it. Support moves its ticket summaries to a cheaper model because the bill falls by two-thirds and nobody can tell the output apart. Neither team read a leaderboard, and either default may move again when a new model ships.

Which is also why the choice of model is rarely what decides whether an AI project works. Between the top few, the model is the part of the system least likely to be the problem.