Claude Code supports three model tiers, seven aliases, four effort levels, and per-subagent model overrides. Most developers use the default for ev...
For further actions, you may consider blocking this person and/or reporting abuse
nice write-up
Glad it landed — if you've been using model routing in practice, curious whether you default to Haiku for most tasks or find yourself reaching for Sonnet more than expected.
I'm going to be honest with you. My company pays my Claude and I tend to default to Opus most of the time :D
Honestly, that is the best position to be in. When cost is not your constraint, Opus gives you the highest-quality output on the first pass with less back-and-forth. The model routing approach mainly pays off when you are running dozens of agent loops or background tasks where token cost compounds fast. For single-session interactive work with company credits, defaulting to Opus is the right call.
Ha, when someone else is paying the bill Opus for everything is the rational choice. The model routing patterns matter most when you are on your own dime or hitting usage caps on long sessions.
Appreciate that — curious if you've been switching between models yourself or mostly sticking with one?
The per-subagent model override in pattern 4 is a game-changer that most people miss. I run a similar setup where planning and architecture decisions use Opus, but the actual implementation tasks get routed to Sonnet automatically. The cost difference is dramatic — roughly 3-4x savings on a typical coding session — and for most implementation tasks the output quality is indistinguishable. The one exception I've found is complex multi-file refactoring where the model needs to hold a lot of cross-file context simultaneously. That's where Opus still clearly wins.
That 3-4x savings tracks with what we see too — Opus for the thinking, Sonnet for the typing is basically the sweet spot. The key gotcha is making sure your planning agent's output is structured enough that Sonnet doesn't need to re-derive intent.
Still on Cursor/Composer and happy with it. v2 is Opus-level.
Cursor Composer v2 is genuinely solid — the gap between tools is shrinking fast. The model routing idea still applies though; even Cursor lets you pick models per task, which is where the real cost savings hide.
Cursor v2 is solid — the agent loop improvements really closed the gap. Where Claude Code pulls ahead for me is the terminal-native workflow and CLAUDE.md project memory that persists across sessions.
Cursor can have project memory files as well. We keep a separate "wiki" repository with plans and decision-making logs. Plus, Cursor can search past discussions and adjust the behaviour accordingly, even if something was not noted down in a wiki file.
The wiki repo approach is smart — separating plans and decision logs from code keeps context clean. Cursor searching past discussions is essentially doing what CLAUDE.md files do for Claude Code but with implicit indexing instead of explicit structure. The trade-off is discoverability: explicit memory files are predictable but require maintenance, while searchable history is zero-effort but can surface irrelevant context. Both are valid depending on how structured your team workflow is.
The wiki repository pattern is smart. Having plans and decision logs separate from code means the model gets architectural context without parsing through implementation details. That past discussion search is something Claude Code handles differently through CLAUDE.md files and project memory but the goal is the same: persistent context that survives sessions.