13 — Model Configuration — Picking the Right Brain for the Job

"Just pick the biggest" was my model-selection strategy, and it was wrong in three ways at once: slowest, priciest, and often unnecessary. The curve that replaced it: the three Claude models sit on a single reasoning-versus-speed curve, and the job is to match the brain to the task — deep reasoning for hard architecture, balance for daily building, speed for mechanical work. [1] "Biggest" is wrong because the biggest is also the slowest and the most expensive; it's the right choice for one kind of task and a costly waste for another.

The framing that clicked is to think of Opus, Sonnet, and Haiku as three points on the same tradeoff curve, not three unrelated products. As I move along the curve toward more reasoning, I give up speed and pay more. As I move toward speed, I give up depth and pay less. The configuration tools — /model, the --model flag, the model key in settings, the effort dial, and opusplan — are all mechanisms for picking the right point on that curve for the task at hand [1].

The three models on the curve

The roadmap describes each model with a one-line role, and once I read them as positions on the curve they snapped into place [1]:

• Opus — the deep thinker. The most capable, used for complex reasoning, high-level system design, and surgical bug fixes in large codebases. Slowest and most expensive. The right pick when a wrong answer is expensive and the problem is genuinely hard.
• Sonnet — the balanced builder. Strikes a balance between reasoning and speed; handles multi-file refactoring and autonomous debugging while running faster and cheaper than Opus. The default for daily coding, and for good reason — most tasks are neither trivial nor research-grade.
• Haiku — the fast-response specialist. Fastest and cheapest, for near-instant execution of lightweight tasks: rapid UI prototypes, commit messages, or parallel subagents scanning logs and running quick checks [2]. The right pick when the answer is easy and I'm paying for throughput.

The configuration hierarchy

The roadmap describes a layered configuration system, and reading it as "most specific wins" made it click [1]:

• /model — switch the model instantly during a session. The override for "this task needs a different brain."
• --model flag — specify the model at launch. The override for "this whole session is one kind of work."
• model key in ~/.claude/settings.json — the permanent default. The right place for the model I want on every session unless I say otherwise.

Semantic aliases (sonnet, haiku, opus) make these readable. Sonnet is the documented default for daily coding, which matches what I reach for — most work is in the balanced middle of the curve.

Effort: tuning within a model

A separate axis from _which_ model is _how hard_ the model tries. The roadmap calls it effort — a parameter (low, medium, high) available through /model that controls how much thinking time the model allocates to solving a problem versus generating a rapid response [3].

Effort composes with the model choice, and the combination is the real lever. A low-effort Haiku for "draft a commit message" is cheap and fast. A high-effort Opus for "design the auth architecture" is slow and expensive but right. The mistake is leaving effort pinned high always — the thinking tokens cost money on API billing, so dialing effort down for mechanical work is a real saving, not a nicety.

opusplan: plan deep, build balanced

The cleverest configuration in the roadmap is opusplan, and it deserves its own moment. When I start a session with claude opusplan, the tool uses Opus to analyze the request, explore the codebase, and draft a comprehensive technical strategy — getting the hard architectural decisions right — and then automatically switches to Sonnet for the actual code implementation [4]. The point is that planning and execution sit at different points on the curve, and most tasks benefit from deep reasoning on the _plan_ and balanced speed on the _build_.

The way of thinking: opusplan automates the habit I described in the workflow post (don't collapse explore+plan into implement) and assigns the best brain to each phase. It's the right default for non-trivial features where the architecture matters more than the typing speed — Opus nails the strategy, Sonnet efficiently executes it, and I get depth where it counts without paying Opus prices for every edit.

How I use this

The habit these notes left me with is a two-axis match before any non-trivial session. First, _which model_: Haiku for throwaway drafts and parallel log-scanning subagents, Sonnet for daily building, Opus reserved for genuinely hard reasoning. Second, _what effort_: low for mechanical work, high for architectural puzzles, and I dial it down whenever I notice I'm paying for thinking on a task that doesn't need it. For features where the plan matters more than the typing, opusplan is the default — deep strategy, balanced execution. The throughline: the biggest model is a tool, not a setting; matching the brain (and the effort) to the task is the whole craft.

References

[1] Anthropic, "Model configuration," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/model-config#model-configuration

[2] Anthropic, "Models," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/how-claude-code-works#models

[3] Anthropic, "Adjust effort level," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/model-config#adjust-ef

[4] Anthropic, "opusplan model setting," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/model-config#opusplan-model-setting