The AI market is maturing and our understanding of it is improving fast. Most operators now use LLMs on two main fronts: chatbots and AI agents. What is still unclear is which model to reach for depending on the goal.

Four questions come up often from operators:

This edition covers the main Claude models available today, with recommendations on the best model and effort level based on the difficulty of the problem. In future editions we will cover the same ground for the main models behind OpenAI and Gemini.

These recommendations are drawn from Anthropic's own published guidance on model selection.

Before introducing the Claude model family, one assumption is worth clearing first. Operators tend to arrive asking what the best model is for a specific type of work. The best model for writing sales outreach, or for data analysis, or for finance.

Claude's position contradicts this directly. The model classes do not specialise by type of work. There is no recommendation to use one model for finance and another for writing or analysis. Every Claude model is trained to perform across coding, agentic tasks and knowledge work. They are generalists by design.

What separates the models is how difficult a problem each one can reliably carry to completion, and what that capability costs in price and speed.

So there is no map from task to model. There is a map from difficulty to model.

An operator working in Claude has two parameters to decide on when running a specific use case:

Finding the right combination of model and effort level is what determines performance in terms of relevance, cost and speed.

Claude currently offers four selectable models, covering different grades of intelligence, speed and cost.

Mythos is the most capable model class Anthropic has built, with frontier capabilities across knowledge domains. It ships in two packages of the same underlying model. Claude Mythos is restricted to trusted organisations working on dual-use cybersecurity and biology, and is not generally available. Claude Fable carries additional safeguards that make it suitable for public and enterprise use, and is the version an operator can actually select. It is the model to reach for on the toughest problems.

The powerful class for reasoning-intensive enterprise work, and the model to reach for on complex tasks.

The choice between Opus and Fable is not obvious, because both perform well on coding, long-running agents and knowledge work. Benchmark scores land close together. In practice, larger models such as Fable tend to show more judgment, more creativity and stronger writing. The working rule: if testing shows Opus struggling on a particular type of task, Fable is the answer. If Opus already clears the quality bar, its speed and price profile make it the better choice.

The versatile class for everyday work. Sonnet balances performance, cost and speed across the widest range of general purpose use cases, including high-volume sub-agents inside multi-agent setups.  It is the most efficient model to reach for on everyday tasks.

The lowest cost and fastest class, built for high-frequency workloads where latency and cost matters. It is the model to reach for when answers need to arrive quickly.

Since the models are not built for specific tasks but for general purpose, the selection question has to be asked differently: 

From there the guidance runs in two directions:

A larger model is appropriate when the problem is genuinely hard. Subtle bugs, unfamiliar domains, architecture decisions. The clearest signal operators need a larger model is a smaller one that stays wrong no matter how much context it receives. Larger models also handle ambiguity better, which means they work from a general, high-level description of the goal.

A smaller model is the right call when the work is routine, which increases speed and reduces cost without impacting the quality. Step-by-step workflows that can be described exactly. Smaller models need precise instructions that direct execution rather than a description of the outcome. There is no reason to pay for capability the task does not need.

Effort means more than thinking time. It controls how much work Claude does on a request overall. That includes how long the model thinks, but also how many files it reads, tools used, how much it verifies, and how far it pushes through a multi-step task before checking back in.

At a higher effort level, Claude takes more of those actions before returning. It reads more, runs more checks, and confirms its own work. At a lower effort level it would rather ask for more context than spend tokens working something out alone.

Claude´s guidance is to use each model's default effort level for most tasks. Raise it when Claude has got something wrong by skipping a file, not running a check, or not verifying its own output, which is most likely if the level was set below the default in the first place.

Effort is best understood as a manual override on how hard and how long Claude works. It rewards being set deliberately, according to the domain and the type of work an operator does.

Higher-class models at higher effort levels give the best available performance. Higher-class models at lower effort levels can sometimes be more efficient than smaller models at higher effort.

Claude's recommendation is to start with the most intelligent general model available and use the effort level to tune performance and cost from there.

The reasoning is counterintuitive. Cost per task is often lower on more intelligent models, even at lower effort levels, and even though the price per token is higher. More capable models need fewer turns and less reasoning time to get most tasks right the first time. Starting with a smaller model also makes it harder to distinguish between model failure and setup failures.

On routine work at the same effort level, both models generally get it right. The larger one simply consumes more tokens on extra verification, at a higher price per token. Dropping to the smaller model for routine stretches saves real money at no cost to quality.

On harder, multi-step work the equation inverts. The smaller model grinds toward the limit of its ability, burning iterations along the way, while the larger model reaches the same quality bar in fewer steps. The per-token price is higher, but on tasks that genuinely stretch the smaller model, total cost per task can come out lower. More importantly, the larger model can complete tasks the smaller one cannot reach at the highest effort setting.

Two signals tell an operator when to move:

Move up when Claude had all the relevant context, clearly attempted the task, and still got it wrong. Move down when the work on the larger model has been routine for a sustained period. Dropping a class increases speed and usually reduces cost without touching output quality.

It is worth noting that Claude documents the opposite approach as well. Some organisations prefer to start with the most cost-effective model and move up through the classes until the quality bar is met. Both directions are ok. Starting high has the advantage of separating capability problems from configuration problems early, which is the harder diagnosis to make later.

The question is not which model is best for a specific task. Models do not specialise by type of work. They are generalists by design. The more useful questions are these:

Model and effort are a single decision. The model sets the level of intelligence available. Effort decides how much of it gets used on a given request: thinking time, files read, tools used, checks run, and how far Claude pushes through a multi-step task before coming back. Starting with the most capable model available and tuning the effort level down from there is what allows operators to optimise speed and cost, with evaluations verifying that quality holds.

In future editions we will cover the model families behind OpenAI and Gemini, with recommendations on how to choose the best one.

The goal of this deep-dive edition was to give you more visibility into a key element of agent system design: which AI model to choose.

That's it for today 🙂. See you in two weeks.

Claude models explained: choosing the best model for your use case

Choosing a Claude model and effort level in Claude Code