The Frontier LLM Field Guide I Actually Use

Every model comparison on the internet is stale within a quarter, including — eventually — this one. Labs ship major updates on a cadence measured in weeks, and a benchmark table from March is a historical document by September. So instead of scores, this is the thing that stays useful: how the leading models differ in character, and a method for choosing between them that survives the next release cycle.

Treat the names below as "the current version of each lab's flagship as you read this," because that is the only stable way to talk about them.

The four characters at the frontier

The reasoner. One flagship is built like a solver — it thinks in long internal chains before answering, and it shows on the hardest material: competition math, novel algorithm design, multi-hour agentic tasks. The cost of that depth is patience and money: answers take longer, tokens add up, and for easy questions the machinery is overkill. Use it like a specialist consultant, not a chat partner.

The craftsman. Another flagship's signature is taste in text and code. It writes prose that sounds like a person, follows subtle stylistic direction ("more Hemingway, fewer adjectives"), and produces code that reads like your codebase rather than like a tutorial. Teams that live in their editors tend to gravitate here. It is also the model most likely to say "that premise is wrong" — which people either love or find insufferable, depending on the day.

The researcher. The third flagship is the wide one: enormous context, strong multimodality, deep ties into search and its own ecosystem of tools. Its superpower is breadth — ingest a 300-page PDF plus a spreadsheet plus a video and answer across all of them. It is the default for "read everything and tell me what matters" work, and the price of breadth is that its answers can feel less surgical than the other two on narrow, high-difficulty problems.

The challenger. Then there is the open-weight frontier — models you can download and run yourself that now sit within shouting distance of the closed flagships on most benchmarks, and past them on some. The capability per dollar is extraordinary, and they are the only option where you hold the weights. The trade: you run the infrastructure, you handle the safety tuning gaps, and the very top of the hardest reasoning tasks still belongs to the closed labs.

What benchmarks tell you (and what they don't)

Public benchmarks measure the top of a model's ability on clean problems with checkable answers. That is genuinely useful information — it establishes a floor of competence below which nobody ships a frontier model anymore. What benchmarks systematically fail to capture is where the daily differences live:

• Instruction-following fidelity. Does the model do the specific thing you asked, or an adjacent, more impressive thing? This varies wildly between models and dominates real-world satisfaction.
• Refusal and calibration behavior. Some models refuse readily; others attempt everything with confidence. Neither is "smarter" — but one of them will annoy you more given your use case.
• Formatting discipline. Whether output arrives as requested — JSON that parses, the exact section structure, no chatty preamble — is a make-or-break for anyone building on top of an API, and benchmarks barely touch it.
• Drift. The same model ID in June and August can behave differently. This is why personal evals beat articles, including this one.

The method that survives model releases

Here is the evaluation I run on every new flagship, and it takes an afternoon:

Build a personal eval set — twenty tasks, frozen. Ten from your actual work: one gnarly bug, one document to summarize, one piece of writing to draft in your voice, one data extraction to JSON, one long-context question, one translation, one thing where the correct answer is "no, that won't work." Plus five known-hard reasoning problems and five from public benchmarks for sanity. Freeze this set. New model? Run the same twenty.

Score three axes, not one. Correctness (did it get the right answer), compliance (did it do what was asked, in the format asked), and rework (how much editing did you do to make the output usable). The third axis is where rankings and reality diverge most.

Test at the temperature of real use. If you will use the model through an API at temperature 0 with structured output, test exactly that — not the chat playground, where sampling settings and hidden system prompts flatter results.

Check the economics of your actual workload. Frontier models differ by an order of magnitude in price, and the expensive one is not always the expensive one: a reasoner that solves a task in one shot can be cheaper than a cheaper model that needs five guided retries. Price per token is a bad metric; price per completed task is the real one.

A decision table for common situations

And one universal rule: for anything consequential, whatever model you use, verify the output against ground truth. The models differ in how often they are wrong, not in whether they ever are.

The honest meta-take

Two years of watching this race has taught me that the ranking changes almost monthly and the shape of the field barely changes at all: there is always a reasoner, a craftsman, a researcher, and a challenger, because those are the four strategies you can have. Labs swap roles occasionally — the craftsman ships a reasoner, the researcher catches up on taste — but the categories persist.

So the practical answer to "which frontier LLM is best" is the unsatisfying one: best for which of the four jobs, at this week's version prices, on your twenty frozen tasks? Run the eval. It takes an afternoon, it never goes stale, and it will tell you more than every comparison article published this year — including, with full self-awareness, this one.