// blog/claude-sonnet-4-6-migration-guide
Claude Sonnet 4.6 Migration Guide
Claude Sonnet 4.6 changes the default model-selection calculation for many coding, document, and computer-use workflows. Anthropic has kept pricing at Sonnet 4.5 levels, starting at $3 input and $15 output per million tokens, while adding a beta 1M-token context window and substantial reported improvements in instruction following, long-horizon work, computer use, and code changes across large repositories. The practical question is how to migrate without treating an upgraded model as a drop-in replacement for an existing agent loop.
What is Claude Sonnet 4.6?
Claude Sonnet 4.6 is Anthropic's February 2026 Sonnet release. It is available through Claude plans, Claude Cowork, Claude Code, the API, and major cloud platforms. It is the default model for Free and Pro users in claude.ai and Claude Cowork.
The release spans several workloads that often end up coupled together in production:
| Workload | What Anthropic reports |
|---|---|
| Coding | Better context reading before code changes, more consolidation of shared logic, fewer false success claims, and stronger follow-through on multi-step tasks |
| Computer use | A major improvement over previous Sonnet models, including multi-step browser and spreadsheet tasks |
| Long context | A 1M-token context window in beta, with reported effective reasoning across large inputs |
| Knowledge work | Opus 4.6-level performance on OfficeQA, which evaluates reading and reasoning over enterprise documents |
| Agent planning | Stronger long-horizon planning, with a reported strategy change in Vending-Bench Arena |
| Platform use | Support for adaptive thinking, extended thinking, and beta context compaction |
Anthropic's internal Claude Code testing found users preferred Sonnet 4.6 over Sonnet 4.5 roughly 70% of the time. They preferred it over the November 2025 Claude Opus 4.5 model 59% of the time. Those are useful signals, though they are not a substitute for an evaluation built around a team's own repository, tools, task mix, and acceptance criteria.
A model that reads more context before editing, follows instructions more reliably, and makes fewer unsupported success claims changes the economics of an agent loop. The output token price matters, but so do failed runs, unnecessary review cycles, duplicated code, and work that must be reopened after an apparently successful completion.
When should teams move from Sonnet 4.5 to Sonnet 4.6?
Move first when a workflow depends on repository-wide context, multi-step execution, or an agent correctly respecting detailed instructions. These are the areas where the release describes concrete behavioral differences rather than a generic benchmark increase.
A sensible initial migration set includes:
- Bug fixes that require searching across a large codebase before making a targeted change.
- Code-review and remediation loops where the agent must trace shared logic across files.
- Tasks with a written specification, test requirements, or repository conventions that must be followed closely.
- Document workflows involving charts, PDFs, tables, and fact retrieval.
- Browser, form, and spreadsheet workflows that require moving across multiple steps or tabs.
- Long-running agents that accumulate enough history for old context to become a constraint.
Keep a control path for the existing model during the initial rollout. Sonnet 4.6 may produce a different plan, choose a different edit boundary, or spend a different amount of effort on the same task. A migration that records only whether the final test passed will miss the operational differences that prompted the upgrade.
For coding agents, compare at least these outcomes:
| Measure | Why it matters |
|---|---|
| Task completion | Establishes whether the requested result was reached |
| Test and lint results | Separates a plausible patch from a working patch |
| Files and lines changed | Detects oversized changes and unneeded rewrites |
| Repeated or duplicated logic | Tests the reported improvement in shared-logic consolidation |
| Instruction violations | Captures changes that disregard repository or task constraints |
| Unsupported completion claims | Measures whether the agent says work is done without evidence |
| Human correction time | Captures the cost that token pricing does not show |
The release says Sonnet 4.6 was rated less prone to overengineering and "laziness" than prior models in early Claude Code testing. Both failure modes deserve explicit measurement. Overengineering expands the review surface and creates maintenance work. Premature shortcuts can make an agent look fast until a reviewer has to reconstruct the missed requirements.
How should Claude Sonnet 4.6 be evaluated?
Start with a fixed task set taken from work that has already been reviewed. Each task should have a clear request, a known acceptable result, and evidence that can be checked without relying on the model's own account of what happened.
A useful evaluation set has variation. Include one narrow bug fix, one change involving shared code, one task with strict instructions, one task with a large amount of relevant context, and one task that requires multiple tool or browser steps. That variation puts the model under the conditions where its behavior is expected to matter.
For each task, hold the surrounding system steady:
- Use the same prompt, repository state, tools, permissions, and time limit for Sonnet 4.5 and Sonnet 4.6.
- Preserve the full transcript, tool calls, changed files, command output, and final response.
- Run automated checks independently of the agent.
- Have a reviewer assess the result without knowing which model produced it where practical.
- Record both the final outcome and the path taken to get there.
Do not collapse these results into one score too early. A model can pass at the same rate while producing cleaner, smaller patches. It can also complete a task more often while calling tools more frequently or requiring more context. Those are different tradeoffs.
Anthropic recommends exploring the spectrum of thinking effort when migrating from Sonnet 4.5. That recommendation matters because Sonnet 4.6 is described as performing strongly at any thinking effort, including with extended thinking off. A fixed "maximum reasoning" configuration may be unnecessary for a well-bounded change. Conversely, turning reasoning off for a difficult codebase task can erase much of the benefit of the upgrade.
Use a small matrix rather than one setting:
| Task type | Starting configuration to test |
|---|---|
| Bounded extraction or classification | Lower thinking effort, with an explicit output schema |
| Small code fix with strong tests | Lower and medium thinking effort |
| Cross-repository change or difficult bug | Medium and higher thinking effort |
| Long-horizon tool workflow | Medium and higher thinking effort, with checkpointed verification |
| High-consequence decision | Higher thinking effort plus independent validation |
The configuration is part of the system being evaluated. "Sonnet 4.6 performance" without its prompt, tools, context, and thinking setting is too vague to guide a migration.
What does the 1M-token context window change?
Sonnet 4.6 offers a 1M-token context window in beta. Anthropic describes that as enough to hold an entire codebase, lengthy contracts, or dozens of research papers in one request. The release also claims that the model can reason effectively across that context, which matters more than raw capacity for planning and retrieval.
A large context window can reduce the need to manually choose a small set of files before asking an agent to investigate a problem. It can also support workflows where requirements, prior decisions, source documents, and tool outputs need to remain available over a longer run. None of that removes the need for context design.
More material in the prompt can include conflicting instructions, outdated specifications, generated artifacts, irrelevant logs, and malicious text from external sources. A model with room to read more has more material to distinguish. The right approach is to retain useful evidence while keeping its origin and authority clear.
For a long-context coding task, organize material into explicit groups:
Task:
- Requested behavior
- Acceptance tests
- Constraints and non-goals
Repository context:
- Relevant modules
- Dependency boundaries
- Existing tests
- Coding conventions
Evidence:
- Failing test output
- Reproduction steps
- Logs or traces
Instructions:
- Files that may be changed
- Files that must not be changed
- Required verification commands
This structure makes later review easier and gives the agent a basis for resolving conflicts. If a log suggests one fix while the acceptance test requires another behavior, the acceptance test should have a clearly higher authority.
The platform also supports context compaction in beta. Anthropic describes it as automatically summarizing older context as a conversation approaches its limits, increasing effective context length. Treat compaction as a state transition and test it. A summary can preserve the important decisions from an earlier phase, but it can also omit a narrow constraint that becomes important later. Long-running agents should retain durable artifacts outside the conversational summary: task state, accepted decisions, test results, and links or references to source material.
How does Sonnet 4.6 affect computer-use agents?
Computer use is one of the clearest reasons to distinguish a model upgrade from a chat-quality upgrade. Anthropic describes OSWorld as a benchmark of hundreds of tasks in real software, including Chrome, LibreOffice, and VS Code, on a simulated computer. The model interacts through virtual mouse and keyboard actions rather than special-purpose APIs or bespoke connectors.
Anthropic says its Sonnet models have made steady gains across sixteen months, while noting an evaluation change: scores before Sonnet 4.5 used the original OSWorld, while Sonnet 4.5 onward use OSWorld-Verified. OSWorld-Verified was released in July 2025 with updates to task quality, evaluation grading, and infrastructure. Do not compare scores across those versions as though every aspect of the measurement stayed fixed.
The product release reports that early users are seeing human-level capability on tasks such as navigating a complex spreadsheet, filling out a multi-step web form, and working across browser tabs. It also says the model remains behind the most skilled humans at using computers. That is a useful operating boundary. A computer-use system should be designed around verifiable milestones rather than an assumption that a visually plausible sequence of clicks is correct.
For browser and desktop workflows, use controls at the action boundary:
- Scope the accounts, websites, applications, and directories the agent may access.
- Require confirmation before irreversible submissions, payments, deletions, or external messages.
- Capture screenshots, tool traces, and final-state evidence for consequential tasks.
- Validate extracted values against expected formats and business rules.
- Stop and escalate when the page content conflicts with the task or requests credentials, secrets, or policy changes.
Prompt injection remains a central risk. Anthropic describes the attack as malicious instructions hidden on websites that attempt to hijack the model. Its safety evaluations show Sonnet 4.6 as a major improvement over Sonnet 4.5 on resistance to prompt injection, with performance similar to Opus 4.6. Even with that improvement, untrusted page text still needs to be treated as data, and a browser agent still needs limits on which instructions can authorize actions.
When is Opus 4.6 still the better choice?
Anthropic says Opus 4.6 remains its strongest option for tasks requiring the deepest reasoning, including codebase refactoring, coordinating multiple agents in a workflow, and problems where correctness is paramount. Sonnet 4.6 narrows the gap and changes where the cost-performance boundary falls, but it does not make model selection disappear.
A practical routing policy can reserve Opus 4.6 for work that is both difficult and expensive to get wrong, while using Sonnet 4.6 for the broader class of coding, document, and tool tasks where it meets the required reliability.
The handoff should be triggered by evidence rather than intuition. Escalate when a Sonnet run reaches an ambiguity in requirements, cannot reconcile conflicting repository evidence, fails repeated verification, or must coordinate a complex multi-agent plan. Otherwise, a lower-cost model that completes the work cleanly is the useful default.
Sonnet 4.6 is available under the API model name claude-sonnet-4-6. Set the task boundaries, test thinking effort, retain evidence from long runs, and evaluate the completed work independently of the model's final message.