Sonnet 4.6: What It Actually Gets Right (and Where It Surprises You)

The Underrated Workhorse

People treat Sonnet 4.6 as the fallback model — the one you use when you do not want to pay for Opus. That framing misses what Sonnet actually does well. It is not just a cheaper Opus. It is a different profile: faster responses, more direct output, less tendency to over-explain or hedge. For a specific class of development tasks, those properties make it better than Opus.

Where Sonnet 4.6 Actually Excels

Sonnet 4.6 shines on well-defined tasks where you know exactly what you want. Writing a function from a spec. Implementing an API endpoint from OpenAPI docs. Adding tests to a module you understand. Refactoring code where the target structure is clear. In these cases, Sonnet is faster, produces cleaner output, and does not pad the response with caveats and hedged suggestions.

It also handles code review well — identifying obvious issues, suggesting improvements, catching patterns that violate team conventions. The responses are snappier. You spend less time reading and more time acting.

The Honest Limits

Sonnet 4.6 will confidently give you wrong answers on hard problems. Not tentative wrong answers — answers that look right until you dig deeper. This is the main failure mode: tasks that require multi-step reasoning or tracking cause-and-effect across many files. Sonnet tends to produce plausible answers that do not quite work when you apply them.

The signal to watch: when you find yourself validating Sonnet's output more than you expected. That usually means the task is above Sonnet's pay grade and you should switch to Opus for that specific task.

When to Default to Sonnet

Use Sonnet as your default model for most development work. The cost-to-capability ratio is favorable for any task where the solution path is clear to you. Only move to Opus when Sonnet repeatedly fails on a task — do not pre-emptively use Opus because you think a task might be hard. Give Sonnet a shot first and escalate when you see the failure pattern.

For teams: if you are running high volumes of development tasks, defaulting to Sonnet for everything except flagged hard tasks is the right cost structure. You get most of the capability at half the price.