One_Model_Does_Not_Fit_All

The first three articles in this series - Building an Agentic Workflow, Scaling, and Designing Rules for AI Agents - put every agent on Claude Opus. That was the right call for proof of concept: eliminate model capability as a variable. The proof-of-concept phase ended months ago. The system now manages 10 active projects with 12 specialised agents running multiple sessions per day. Not all of that was waste - Opus earned its cost on orchestration and code generation. But a meaningful portion of it was spent on tasks that did not require Opus-level reasoning: writing social captions, generating meta descriptions, auditing content calendars, producing design system documentation. Running every agent on your most powerful model is like staffing a senior architect on meeting notes. The architect can take excellent notes. But the hourly rate does not match the task, and while they are documenting action items, they are not available for the work that actually needs their capabilities. The question that matters is not "which model is best?" - every benchmark will tell you that. The question is "which model is best for this specific role, given what the role actually does?" Answering that question requires understanding what each model tier can and cannot do in practice, not on a leaderboard.

The_Capability_Spectrum

Three model tiers are relevant for agentic workflows within the Claude family: Haiku 4.5, Sonnet 4.6, and Opus 4.7. Each has a distinct capability profile that maps to different categories of agent work. Haiku 4.5 is the fastest and cheapest tier - 5x cheaper than Opus on both input and output tokens. It is the first Haiku to support extended thinking, which means it can reason through multi-step problems rather than just pattern-matching. Tool calling works on the same API surface as the larger models with no capability restrictions. Where Haiku falls short is complex architectural reasoning. It struggles with novel problem-solving that requires deep inference, loses coherence on plans with more than ten interdependent steps, and can drop constraints from highly detailed system prompts. For structured text generation guided by clear instructions, it is reliable. For work that requires weighing subtle tradeoffs or maintaining long chains of logic, it is not. Sonnet 4.6 is the workhorse. It handles complex multi-step reasoning with tool use, follows detailed system prompts reliably, and understands architectural patterns well enough to review code, not just write it. It costs 1.67x less than Opus on both input and output. For the majority of agent roles, Sonnet is the correct tier. Opus 4.7 is the ceiling. Its unique value is not raw intelligence on isolated tasks - Sonnet is close enough on most benchmarks. The value is in orchestration: managing competing constraints across multiple agents, maintaining coherence over sessions that accumulate large context, and following complex persona instructions with the highest fidelity. The 1M context window matters here because an orchestrator's context grows with every delegation and every result. Opus errors are the most expensive kind because they propagate. When the orchestrator misunderstands a task and delegates incorrectly, every downstream agent does the wrong work.

| Dimension | Haiku 4.5 | Sonnet 4.6 | Opus 4.7 | |---|---|---|---| | Input / Output cost | $1 / $5 per MTok | $3 / $15 per MTok | $5 / $25 per MTok | | SWE-bench Verified | 73.3% | 79.6% | 87.6% | | Context window | 200K | 1M | 1M | | Agentic strength | Execution with clear instructions | Strong across all task types | Complex multi-step orchestration | | Cost vs Opus | 5x cheaper | 1.67x cheaper | Baseline |

Matching_Models_to_Roles

Three questions determine which tier an agent needs. First: does this role generate or modify code? Code generation requires strong reasoning, and SWE-bench performance is the closest proxy for real-world code quality. If the agent writes, refactors, or reviews code, Sonnet is the minimum. Haiku's 73.3% on SWE-bench is not close enough to risk on production codebases. Second: does this role make decisions that propagate to other agents? If an agent's output becomes another agent's input - especially if it becomes instructions or constraints - errors compound. The orchestrator is the obvious case, but any role that sets direction for downstream work needs the highest-fidelity model available. Third: is the work primarily structured text generation guided by detailed instructions? If the agent's system prompt is specific enough to constrain the output format, vocabulary, and scope, then Haiku's instruction-following is sufficient. The system prompt does the heavy lifting; the model executes within those rails. Applying these three questions to the 12 agents in my system produces the following assignments. Opus goes to one agent: Sheena, the orchestrator. She delegates tasks, routes decisions, manages cross-project state, and her mistakes propagate to every downstream agent. There is no case for running the orchestrator on anything less than the best available model. Sonnet goes to seven agents. Nix (frontend) and Sable (backend) write and modify code - Sonnet minimum by the first question. Quinn (QA) writes tests, which is code generation, and identifies bugs, which requires understanding architectural context. Tom (research) synthesises evidence and structures arguments where nuance matters. Oren (knowledge systems) designs schemas and writes PostgreSQL queries. Reid (brand strategy) was initially a Haiku candidate - brand work is primarily structured text analysis, which fits the third question. But Reid is the brand guardian. His positioning decisions propagate to Vera's copy, Lena's social content, and Maya's design direction. By the second question, that propagation means Sonnet. The brand judgment call is high-stakes enough that saving on model cost is not worth the risk of off-brand output reaching four other agents. Jo (operations) audits workflows, tracks agent performance, and runs manifest staleness checks. Her findings propagate to action across agents - the same propagation pattern that justifies Sonnet for Reid. Haiku goes to four agents. Vera (copywriting) generates short-form copy - hero lines, meta descriptions, blurbs - constrained by a detailed voice system document. Lena (social media) writes platform-specific captions and manages a content calendar. Cleo (content strategy) audits existing content and structures editorial plans. Maya (UI/UX design) works primarily through design tool calls and specification reading. All four roles fit the third question cleanly: structured output, detailed instructions, clear constraints. Maya carries a trial protocol. If design rationale quality degrades - if the reasoning behind layout decisions becomes shallow or the accessibility considerations drop off - she upgrades to Sonnet. The trial runs three to five real tasks against the last three Opus-generated deliverables for the same role, comparing output quality directly. This is not a permanent assignment; it is a hypothesis with a defined evaluation period.

The_Override_Escape_Valve

Static model assignment is too rigid on its own. An agent assigned to Haiku will occasionally receive a task that exceeds Haiku's capabilities - a particularly complex content audit, a design task requiring novel architectural reasoning, a brand analysis that demands weighing subtle tradeoffs. The system handles this through dynamic model override at delegation time. When Sheena delegates a task to any agent, she can pass a model parameter that overrides the agent's default tier. If Vera is assigned to Haiku but receives a copy task that requires synthesising positioning across three product lines, Sheena can delegate with model set to Sonnet for that specific invocation. The override applies to that task only. Vera's default remains Haiku for the next delegation. The model resolution order in Claude Code follows a clear priority chain. First, the environment variable CLAUDE_CODE_SUBAGENT_MODEL - this is a global override that forces all subagents to a single tier, useful for testing but not for production. Second, the per-invocation model parameter that Sheena passes at delegation time. Third, the model specified in the agent's definition file. Fourth, the main conversation's model as a fallback. This priority chain means the orchestrator always has the final say on which model runs a given task. The default tier in the agent definition is exactly that - a default. It represents the right model for the typical task that role handles. The override exists for the atypical case. The orchestrator is the right place for this judgment because she has the full context of the task at delegation time. She knows whether the content audit is a routine monthly check or a comprehensive cross-project analysis. She knows whether the design task is a component variant or a new page layout requiring original thinking. The agent definition cannot encode that context. The orchestrator can. This design turns model assignment from a configuration decision into a routing decision. Configuration is static. Routing is dynamic. Tiering sets intelligent defaults; the override handles reality.

Research_Tool_Routing

Model tiering addresses compute cost. But when Sheena delegates a task, she is making two routing decisions at once - which model runs the work, and which information sources the agent can draw on. Optimising one without the other leaves half the inefficiency untouched. Research tool routing addresses this second inefficiency that most multi-agent setups overlook: redundant information retrieval. When agents have access to multiple research tools - built-in web search, Perplexity's suite of models, and their own training knowledge - the default behaviour is to use all of them for every question. An agent asked about a CSS grid pattern will search the web, query Perplexity, and then answer from its own knowledge - burning tokens on three sources when one would have sufficed. The fix is a three-step research priority injected into every agent's system prompt. Step one: answer from your own knowledge if the topic is well-established. Claude's training data covers pre-2025 technology thoroughly. Asking Perplexity about flexbox or PostgreSQL indexing strategies is redundant. Step two: use Perplexity if you need information from after the knowledge cutoff or require verifiable citations. Current pricing, recent releases, competitor analysis - these need live web data. Step three: use WebSearch only to verify Perplexity results or fetch specific URLs for content extraction. The rule is explicit: never run both Perplexity and WebSearch for the same question. Beyond the priority chain, Perplexity access is tailored per agent role. Tom, the research agent, gets full access to all four Perplexity tools - search, ask, research, and reason. His entire role is information synthesis, and he is the primary consumer of research tokens. Code agents (Nix, Sable, Oren) get perplexity_search only, for checking whether a specific API or feature exists in a current version. Their default for implementation questions is Claude's own knowledge, which is stronger than Perplexity for code patterns and architectural reasoning. Content agents (Vera, Lena) get perplexity_search for fact-checking specific claims. Rare use. Reid (brand) gets search and ask for current competitor information and market positioning data. This is not about restricting agents. Every agent still has access to its own knowledge and web search as a baseline. The routing prevents the specific failure mode where an agent performs the same lookup through three different tools and produces three sets of overlapping results, each consuming tokens. Multiply that by 12 agents across multiple sessions per day, and the redundant research cost adds up independently of model tier.

Measuring_What_You_Tier

Tiering decisions made without data are guesses. The observability layer is the prerequisite for model assignment, not the follow-up. Before I could tier agents by role, I needed to know what the baseline looked like - how much each session cost, where the tokens went, and whether the 97% cache read rate I was seeing actually compressed effective cost the way the math suggested. The primary tool is ccusage, an open-source utility that parses the local JSONL conversation logs that Claude Code writes to disk. No API instrumentation required. No third-party service to configure. It reads the log files that already exist on the machine and produces token consumption breakdowns by session. Historical data goes back to March 8 - the earliest conversation logs on disk - which gave me five weeks of baseline data before making any tiering changes. For forward-looking metrics, OpenTelemetry is enabled via the CLAUDE_CODE_ENABLE_TELEMETRY environment variable. This feeds into standard observability pipelines for trend analysis over time. The gap is Helicone. Helicone provides per-request cost attribution and model-level analytics, but it requires API billing to instrument requests. Claude Max - the subscription tier I run on - does not route through a billable API endpoint, so Helicone cannot intercept and measure the traffic. This is a real limitation for subscription users who want detailed cost analytics. The workaround is ccusage for historical data and OpenTelemetry for trends, but neither provides the per-request granularity that Helicone offers API users. The larger gap is per-subagent token breakdown. When Sheena delegates to four agents in a session, current tooling reports the total session consumption. It does not break out how many tokens Nix consumed versus Vera versus Tom. The feature request at anthropics/claude-code#22625 was closed as not planned, without implementation. Per-subagent token attribution remains unavailable in current tooling. That said, the data that does exist supports the tiering decision. The $1,542 baseline over five weeks, the 97% cache read rate, and the model-tier pricing differentials produce an estimated 52% cost reduction per session after tiering. The exact number will shift as usage patterns change, but the direction is clear: running content and design agents on Haiku at 5x cheaper than Opus, with no observable quality degradation on their typical tasks, is not a marginal optimisation. It is a structural correction. The system was overprovisioned for four out of twelve roles. Tiering fixes that.