Here is something that surprises most developers the first time they open Claude Code: the tool does not run on a single AI model. It juggles several, switching between them behind the scenes depending on the task, your subscription plan, and how much work you have already done that week. So when people ask what model does Claude Code use, the honest answer is layered — and understanding those layers can save you money, time, and a lot of frustration.
In this guide, you will learn exactly which Claude models power the command-line tool, how the automatic switching system works, what the difference is between Opus, Sonnet, and Haiku in real coding situations, and how to pick the right model for the job. We will also cover how to check which model you are currently running, how to change it manually, what happens when you hit usage limits, how Claude Code connects to Amazon Bedrock and Google Vertex AI, and where the whole thing appears to be heading. By the end, you will know more about Claude Code’s engine than most people who use it every day.
The AI Models Powering Claude Code
Claude Code runs on Anthropic’s Claude family of large language models — primarily the Opus and Sonnet tiers for reasoning and code generation, with the smaller Haiku model handling lightweight background tasks like file summaries, search, and simple lookups. It is not a separate or custom-built coding model. Claude Code is a terminal application, an agent wrapper, that sends your requests to the same frontier models available through the Claude web app and the Anthropic API.
That distinction matters. Claude Code does not have secret coding intelligence baked into the CLI. What it adds is context: it reads your file system, runs commands, edits files, tracks conversation history, manages a to-do list, and feeds all of that structured information to the model. The model does the thinking. The CLI does the plumbing. When Anthropic ships a smarter model, Claude Code gets smarter almost immediately, because the tool simply points at the new endpoint.
Anthropic organizes its models into three tiers, and each one shows up in Claude Code in a different role:
- Opus — the largest and most capable tier. It handles deep architectural reasoning, complex multi-file refactors, tricky debugging, and long agentic sessions where the model must plan several steps ahead.
- Sonnet — the balanced workhorse. It delivers most of Opus’s coding ability at a fraction of the cost and with faster responses. For the majority of Claude Code sessions, Sonnet is the default.
- Haiku — the small, fast, cheap tier. Claude Code uses it quietly in the background for things like generating conversation titles, scanning file trees, running quick searches, and other tasks that do not need heavyweight reasoning.
Anthropic updates these tiers on a rolling schedule, and version numbers climb steadily — Claude 3 gave way to 3.5, then 3.7, then the Claude 4 line with Opus 4, Sonnet 4, and their point releases. Because Claude Code always pulls the current generation, the specific version string you see today will change. The tier structure, however, has stayed remarkably consistent, which is why learning the Opus-Sonnet-Haiku framework is more useful than memorizing any single model name.
How Claude Code Picks a Model Automatically
Most users never touch the model settings, and that is by design. Claude Code ships with a default mode that makes the choice for you, and it usually chooses well. Understanding the logic helps you predict behavior and avoid surprises mid-project.
The Default Selection Logic
When you launch Claude Code, the CLI checks three things: your subscription tier, your recent usage, and the type of task you are starting. On paid plans, the default setting routes most work to the current Sonnet model because it hits the sweet spot between speed, cost, and capability. If you are on a higher-tier plan and start something the system flags as complex, it may reach for Opus instead.
Here is the part that trips people up. On plans that include Opus access, Claude Code often runs Opus until you consume a set share of your usage window — commonly around the halfway mark — then automatically falls back to Sonnet for the rest of that window. You will see a small notice in the terminal when this happens. It is not a bug or a downgrade in quality so much as a budget guardrail that keeps you from burning through your entire allowance in one long session.
Background Model Assignments
Separately from your main conversation model, Claude Code assigns smaller models to specific internal jobs. These calls happen without you asking:
- Generating short summaries when the conversation gets long and needs compacting.
- Titling sessions so you can find them later in your history.
- Running quick file searches and grep-style scans across a repository.
- Producing simple diffs or formatting suggestions that need no real reasoning.
- Classifying whether a request needs a full plan or a single tool call.
Picture a real session. You ask Claude Code to “find every place we call the old payment API and migrate them to the new one.” Haiku-class calls scan the repo and list candidate files fast and cheap. Sonnet or Opus then reads the relevant code, writes the migration plan, and edits each file. A lighter model summarizes the conversation when it grows too long. Three model tiers, one request, and you never had to think about it.
Opus vs Sonnet vs Haiku for Real Coding Work
Knowing the names is easy. Knowing when each one earns its cost is the skill that separates casual users from people who get real leverage out of the tool. Let’s break down how the tiers actually behave when you throw code at them.
Opus shines when a problem has hidden dependencies. If you ask it to redesign a data layer, it holds more of the system in mind at once, catches edge cases other models miss, and writes plans that survive contact with reality. It also tends to push back when your request contains a flawed assumption, which is genuinely valuable during architecture work. The tradeoff is speed and cost — Opus responses take noticeably longer and consume your usage budget far faster.
Sonnet handles the daily grind beautifully. Writing a new endpoint, adding tests, fixing a failing build, converting a component from one framework to another, explaining unfamiliar code — Sonnet does all of that quickly and accurately. Most experienced Claude Code users report they spend the vast majority of their sessions on Sonnet and only reach for Opus when they hit a wall.
Haiku rarely serves as your main conversation model in Claude Code, but you can select it. It works fine for mechanical tasks: renaming variables across files, formatting, generating boilerplate, or answering one-line questions about syntax. Ask it to reason through a race condition and you will feel the ceiling immediately.
| Factor | Opus | Sonnet | Haiku |
|---|---|---|---|
| Best use | Architecture, hard debugging, long agentic runs | Everyday feature work, tests, refactors | Mechanical edits, search, summaries |
| Relative speed | Slowest | Fast | Fastest |
| Relative cost | Highest (roughly 5x Sonnet) | Moderate | Lowest (a small fraction of Sonnet) |
| Usage burn rate | Consumes limits quickly | Balanced | Barely registers |
| Typical share of sessions | 10 to 20 percent | 70 to 85 percent | Background only |
One practical rule of thumb: if you can describe the task in a single sentence and you already know roughly how the code should look, Sonnet is enough. If you find yourself writing three paragraphs of context because the problem is genuinely tangled, switch to Opus.
Checking and Changing Your Model in Claude Code
You do not have to accept whatever Claude Code picks. The tool gives you several ways to see and control the model, and switching takes seconds.
The Slash Command Method
Inside a Claude Code session, type /model and press enter. The CLI shows your current model and presents a menu of available options. Pick one with the arrow keys, hit enter, and the change applies to the rest of the session. You can also pass a model name directly, like /model opus or /model sonnet, to skip the menu.
The /status command gives you a broader picture — your account, your plan, the active model, and connection details. Run it any time you feel unsure about what is handling your requests.
Environment Variables and Config Files
For persistent control, Claude Code reads several environment variables. Setting ANTHROPIC_MODEL pins your main model across every session. Setting ANTHROPIC_SMALL_FAST_MODEL controls which lightweight model handles background tasks. You can also launch the CLI with a flag, passing the model as an argument when you start it, which is handy inside shell aliases.
Teams often bake these settings into a shared configuration file committed to the repository, so everyone working on a project uses the same model. That consistency matters more than people expect — a plan written by Opus and executed by Haiku can produce mismatched results.
- Use /model for quick, session-level changes.
- Use environment variables when you want the same model every time you open a terminal.
- Use project-level settings files when a whole team needs identical behavior.
- Use the command-line flag inside scripts and CI pipelines where you cannot type interactively.
- Re-check with /status after any change, because a stale environment variable can silently override what you thought you set.
Plans, Limits, and How They Change Your Model Access
Your subscription determines which models you can reach, and this is where most confusion about Claude Code’s engine comes from. Two developers can run identical commands and get different models simply because they pay for different plans.
Free-tier access to Claude Code is essentially nonexistent — the tool expects either a paid subscription or API billing. On the entry-level paid plan, you generally get Sonnet with modest usage limits, enough for light daily work but not for marathon sessions. Mid-tier plans unlock Opus alongside much larger limits. Top-tier plans push those limits higher still and give Opus more room before the automatic fallback kicks in.
If you use API credits instead of a subscription, every model is available all the time. You pay per token, so the only limit is your budget. Many professional teams prefer this because it removes the surprise of hitting a wall mid-refactor. The tradeoff is unpredictable monthly costs — a heavy Opus day on API pricing can cost more than a full month of subscription access.
Usage windows typically reset on a rolling schedule rather than a fixed calendar date, and Anthropic has layered in weekly caps on top of shorter windows to prevent extreme consumption. Practically speaking, that means a developer who runs Opus continuously through Monday and Tuesday may find themselves on Sonnet for the rest of the week. Planning around this is straightforward: use Sonnet for routine work, and save Opus for the sessions where deep reasoning genuinely pays off.
| Access route | Models available | Cost structure | Best for |
|---|---|---|---|
| Entry subscription | Sonnet, Haiku | Flat monthly | Solo devs, light use |
| Mid subscription | Opus, Sonnet, Haiku | Flat monthly | Daily professional use |
| Top subscription | Full access, highest caps | Flat monthly | Heavy agentic workflows |
| API credits | Everything, no caps | Pay per token | Teams, CI, variable load |
| Bedrock or Vertex | Whatever your cloud offers | Cloud billing | Enterprise compliance |
Running Claude Code on Bedrock, Vertex AI, and Custom Endpoints
Claude Code does not have to talk to Anthropic’s servers directly. Enterprises with strict data residency or procurement rules can point the CLI at a cloud provider that hosts Claude models, and the experience stays nearly identical.
Amazon Bedrock hosts Claude models inside AWS. You set an environment variable to enable Bedrock mode, configure your AWS credentials and region, and Claude Code routes every request through your AWS account. Billing flows through AWS, data stays inside your chosen region, and your security team gets the audit trail they want. Google Cloud’s Vertex AI works the same way with its own set of variables and project configuration.
One important catch: model availability differs by provider and region. A brand-new Opus release might land on Anthropic’s own API weeks before it appears in every Bedrock region. Model identifiers also differ — cloud platforms use their own naming format, so you cannot always copy an Anthropic model string into a Bedrock config and expect it to work. Check your provider’s model catalog before assuming a version exists.
Beyond the big two clouds, Claude Code supports gateway setups. Teams route requests through an internal proxy for logging, rate limiting, cost attribution by team, or prompt filtering. Some organizations even use these gateways to fall back to a different provider when Anthropic is at capacity, though that changes the model entirely and usually degrades results.
- Set the appropriate provider variable before launching, not mid-session.
- Confirm the exact model identifier your cloud region supports.
- Expect small differences in latency and occasionally in rate limit behavior.
- Test your usual workflows after switching providers — tool use and long-context handling can feel slightly different.
- Keep a fallback configuration documented so teammates are not stuck if one route fails.
Common Misconceptions About Claude Code’s Engine
Plenty of confident advice floating around the internet gets this topic wrong. Clearing up the most common myths will save you from bad decisions.
Myth: Claude Code Uses a Special Coding Model
It does not. There is no “Claude Coder” model. The same Opus and Sonnet models that answer questions in the web chat power the CLI. What changes is the system prompt, the tool definitions, and the context Claude Code assembles from your project. That scaffolding is genuinely valuable, but it is engineering around the model, not a different model.
Myth: Opus Is Always Better
Opus is more capable at hard reasoning, but it is slower, and in agentic loops that speed difference compounds. A task that requires twenty tool calls can feel painfully sluggish on Opus while Sonnet finishes in a third of the time with an equally correct result. For well-scoped work, Sonnet often produces a better overall experience.
Myth: The Model Never Changes Mid-Session
It absolutely can. Automatic fallback shifts you from Opus to Sonnet when you cross a usage threshold. If your code quality suddenly seems different halfway through a long session, check /status before blaming yourself.
Myth: Extended Thinking Is a Separate Model
When you ask Claude Code to “think harder” or use extended reasoning, you are not switching models. You are giving the same model a larger internal reasoning budget before it answers. It costs more tokens and takes longer, but the underlying weights stay the same.
One more worth naming: people assume the context window belongs to Claude Code. It belongs to the model. Large context windows — hundreds of thousands of tokens on current models — come from the model tier, and Claude Code simply manages what it puts inside that window through compaction and selective file reading.
Best Practices for Getting the Most From Each Model
Choosing a model is only half the game. How you use it determines whether you get a helpful collaborator or an expensive autocomplete. These habits consistently produce better results.
Start with planning on the stronger model, then execute on the faster one. Ask Opus to read the codebase and produce a detailed step-by-step plan. Save that plan to a markdown file. Then switch to Sonnet and have it execute the steps one at a time. You get Opus-quality thinking at close to Sonnet-level cost, and the written plan keeps both models aligned.
Keep your context clean. Every irrelevant file you pull into the conversation dilutes the model’s attention and eats your budget. Use targeted file references instead of asking Claude Code to read entire directories. When a session drifts off topic, clear it and start fresh rather than dragging thousands of stale tokens forward.
Write a project instructions file. A well-maintained configuration file at the root of your repo that explains your stack, conventions, test commands, and gotchas dramatically improves output on every model tier. It often matters more than which model you picked.
- Define the task in concrete terms, including what “done” looks like.
- Point at specific files rather than whole folders.
- Ask for a plan before any edits on anything non-trivial.
- Review diffs before accepting them — never merge blind.
- Run your tests inside the session so the model sees real failures.
- Compact or clear the conversation once the current task finishes.
Consider the numbers for a moment. If a typical feature task consumes roughly the same token count on Opus and Sonnet, and Opus costs around five times more per token, then reserving Opus for the ten to twenty percent of tasks that truly need it can cut your effective spend by more than half while barely affecting quality. That single habit is the highest-leverage change most developers can make.
Where Claude Code’s Model Strategy Is Heading
The pace of change here is fast, and a few trends are already clear enough to plan around.
First, model routing keeps getting smarter. Early versions of Claude Code made you choose. Newer versions ship a default mode that decides for you based on task complexity and remaining budget. Expect that routing to become more granular — different models handling different steps within a single request, chosen automatically and invisibly.
Second, the gap between tiers is narrowing in useful ways. Each Sonnet generation absorbs capabilities that previously required Opus, which pushes Opus toward genuinely hard frontier problems and makes the mid-tier the practical default for nearly everyone. If that continues, the question of which model to pick will matter less over time.
Third, agentic runtime is growing. Claude Code sessions that once handled a single file now run for hours across large repositories, spawning subagents that each get their own model assignment. Managing which model runs which subagent is becoming its own small discipline, and Anthropic keeps adding controls for it.
Finally, deployment options keep expanding. More clouds, more gateway integrations, and tighter enterprise controls mean the answer to which model powers your particular installation will increasingly depend on your organization’s configuration rather than Anthropic’s defaults. Documenting your setup is quickly becoming a real operational task, not an afterthought.
- Watch release notes — model identifiers change more often than the tier names.
- Avoid hardcoding exact version strings in scripts when a tier alias will do.
- Revisit your model choices every few months as capabilities shift.
- Track your own usage patterns so you notice fallback events early.
- Test new model versions on a real task before rolling them out to a team.
Frequently Asked Questions About Claude Code Models
A few questions come up constantly, and short answers help.
Can I use Claude Code with a non-Anthropic model? Officially, no. Claude Code is built and tuned for Claude models, and its tool-use format depends on them. Some community proxies route it to other providers, but results degrade and Anthropic does not support the setup.
Does Claude Code work offline? No. The models run on remote servers, so you need a network connection. The CLI itself lives on your machine, but every reasoning step requires an API call.
Which model reads my whole codebase? None of them read everything at once. Claude Code searches and selectively loads files into context. Larger context windows on newer models let it hold more at a time, but it still curates aggressively.
Why did my answers get worse today? Most often, you hit a usage threshold and fell back to a smaller model, or your conversation grew so long that compaction dropped important details. Check /status, then consider starting a clean session.
Is the model in Claude Code the same one in the web app? Yes, at the tier level. The differences you feel come from the system prompt, the tools available, and the context the CLI assembles from your project files.
How do I know which version I am on? Run /status or /model. Both display the active model identifier, including its version string.
Do subagents use the same model as my main session? Not necessarily. Claude Code can assign different models to subagents, and you can configure that explicitly in agent definitions.
Bringing It All Together
Claude Code runs on Anthropic’s Claude models — Opus for the hardest reasoning, Sonnet for the everyday majority of coding work, and Haiku quietly handling fast background jobs. There is no separate coding-specific model, no hidden engine. What makes the tool feel powerful is the agent layer around the model: the file access, the tool calls, the planning, and the context management that turn a chat model into a genuine coding partner.
Once you understand the tiers, the automatic fallback behavior, the plan-based access limits, and the simple commands that let you switch, you stop guessing and start steering. Plan on the strong model, execute on the fast one, keep your context tidy, and check your status when something feels off. Models will keep improving and version numbers will keep climbing, but that framework will serve you well through every release — and the developers who learn it now will get far more out of every session they run.
