Model, cost, and orchestration

Haiku is the fastest and least expensive model in the Claude family. Ideal for repetitive, low-reasoning tasks: reading files, searching for patterns, summarizing short passages, and running commands.

Most subagents in a fleet don’t need deep reasoning. Using Haiku for them reduces the total cost by up to 10×. Choosing Opus for scanning is a budget mistake, not a quality mistake.

Very low cost per token; lower latency; own context (starts from scratch); does not inherit the orchestrator’s reasoning — receives explicit instructions.

Sonnet balances reasoning ability and cost. Excellent for writing code, reviewing PRs, synthesizing results from other subagents, and making intermediate decisions.

It’s Claude Code’s default model. In most workflows, Sonnet handles the “middle”: it receives raw data from Haiku and delivers refined material for Opus to evaluate.

Great for code generation and synthesis; medium cost; used as the conductor in mid-sized pipelines; replaces Opus in 80% of cases with no noticeable loss.

Opus has the deepest reasoning. Reserved for architectural decisions, security assessments, long-term synthesis, and situations where mistakes are costly.

Using Opus across the entire fleet multiplies the cost by 5–20×. Knowing how to identify the moments when only Opus will do (and those that don’t need it) is the central skill in this track.

High cost; higher latency; better for multistep reasoning; use as the fleet lead for Haiku/Sonnet; never in the inner loop of cheap subagents.

Every subagent starts with clean context. It doesn’t know what you just discussed — it needs complete instructions in its description and in the conductor’s messages.

A well-instructed Haiku outperforms a poorly instructed Opus. The chosen model only matters after the instructions are correct. The “trap” is paying more and expecting the model to guess the context.

No history inheritance; the conductor passes the necessary context via a message; CLAUDE_CODE_SUBAGENT_MODEL overrides the fleet’s default model.

A simple heuristic: Haiku for “read and report,” Sonnet for “build and review,” Opus for “decide and architect.” Apply it to tasks before coding the subagent.

Model assignment errors are invisible — the result looks the same, but the cost is 5–10× higher. Having the table committed to memory prevents automatic decisions to "use the most capable model".

Haiku: search, reading, extraction, summarization. Sonnet: writing, code, synthesis, review. Opus: architecture, security, final evaluation, deep reasoning.

Given a hypothetical pipeline with 6 tasks (scan logs, write tests, review a PR, propose architecture, look up docs, assess security), assign the right model to each.

The attribution exercise reinforces the heuristic. Getting it wrong in an exercise is cheap; getting it wrong in a real system with 100 subagents is costly.

Evaluation criterion: estimated cost × expected quality. An annotated answer key is in the full module.

Each subagent has its own context, system prompt, and round trip to the API. With 10 subagents running in parallel, the number of tokens consumed multiplies quickly.

Without this awareness, it’s easy to create workflows that cost tens of dollars per run. Knowing the multiplier lets you plan ahead—and know when multi-agent is worth the price.

Cost per run = (input + output tokens) × price × number of subagents; system prompt repeated per agent; context passed by the orchestrator counts too.

The boss (Opus or Sonnet) orchestrates the work: decides on a strategy, breaks down tasks, and evaluates results. The fleet (Haiku) executes in parallel: reads, searches, extracts, and reports.

It’s the best value pattern: one expensive agent makes the smart decisions while many cheap agents do the mechanical work. Quality goes up; average cost per result goes down.

1 boss, N workers; the boss evaluates and consolidates; workers report back; the decision of "what to do" stays with the boss, "how to do it" with the fleet.

An environment variable that forces all subagents to use a specific model, regardless of the system default. Useful for controlling costs in large batches.

Without this variable, subagents use the default model—which may be Sonnet or Opus. With it, you ensure the entire fleet uses Haiku without changing each agent’s code.

`CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5` in the environment; overrides only subagents (the main agent keeps the original model); useful in high-scale workflows.

A parameter that limits how many back-and-forth rounds a subagent can make. Each turn consumes tokens. Without a limit, an agent stuck in a loop can spend indefinitely.

Subagents occasionally get caught in trial-and-error loops. With `maxTurns` set, the maximum cost per run is predictable — and the agent fails in a controlled way instead of silently spending more.

Configured in the subagent's CLAUDE.md or via the SDK; typical value: 10–20 turns; after the limit, the agent returns what it has so far.

Objective criteria for deciding: parallel tasks that would each take 10+ min sequentially; jobs with an "output wall" that would cause truncation in a single context; codebase with 10+ interdependent files.

Using multi-agent for small tasks is like paying 15× for 0% real gain. A clear criterion avoids that waste and justifies the cost when the task really requires it.

Positive signal: genuine parallelism, context separation, large output. Negative signal: short sequential task, need for shared context, simple result.

Given a repository analysis job (identify code smells in 50 files), design the division: which agent is the lead, how many workers, which model for each role, and how the results are consolidated.

Designing before implementing avoids costly redesigns. The exercise makes you think about task granularity, estimated cost, and failure points.

Deliverable: a simple diagram (structured text is fine) showing roles, models, data flow, and estimated cost per run.

The orchestrator is the main agent that receives the user’s task, breaks it down into subtasks, and dispatches each one to a subagent. It waits for the results, consolidates them, and delivers the final answer.

Without an explicit conductor, there’s no coordination—the subagents don’t “talk” to one another. Recognizing the conductor as the single point of orchestration is central to workflow design.

Star topology: conductor at the center, subagents at the endpoints; the conductor explicitly passes context to each subagent; results return to the conductor and never circulate between subagents.

One agent (CLAUDE.md) cannot invoke another agent directly. Invocation happens through a skill (which can call agents) or through Claude Code itself when it runs a higher-level workflow.

Designing an agent that tries to call another agent results in an execution error or undefined behavior. Knowing this limit helps you avoid impossible architectures and points to the right approach (through a skill).

Agent calls a skill; skill calls an agent; agent does not call an agent. The control loop always stays in the main Claude Code session or an orchestrating skill.

A skill (an instruction `.md` file) can contain logic that triggers multiple agents in sequence or in parallel. This is the right pattern for creating complex pipelines without violating the agents-don’t-call-agents rule.

Skills are the “glue” of the ecosystem. Understanding how a skill launches agents lets you build workflows with N steps without needing a special orchestration agent.

Skill = instruction to Claude Code; Claude Code runs the invoked agent; the skill defines the logical sequence; intermediate state can be passed via files or messages.

When the result from A is needed for B to start, and the result from B is needed for C to start, you have a sequential pipeline. The conductor waits for each step before triggering the next.

Mixing sequential and parallel work without realizing it creates race conditions or incorrect results. Identifying dependencies between tasks is the first step in designing any pipeline.

Data dependency = sequential; independence = parallel; the orchestrator decides the order based on dependencies; pass A’s output as B’s input via a message or file.

Each subagent communicates only with the conductor that invoked it. There is no side channel between subagent A and subagent B. For A to “pass something” to B, the conductor has to relay it.

Projects that assume direct communication between subagents don’t work. Knowing this limit before designing helps you avoid architectures that look elegant on paper but are impossible in practice.

Maestro is the only integration point; “conversations” between subagents are an illusion — the maestro mediates; use shared files when two agents need the same data.

Design (in text or a diagram) a 3-step pipeline for the job: “find open issues → prioritize by impact → draft triage comments.” Identify which steps are sequential and which can run in parallel.

The ability to break a job into steps with clear dependencies is the foundation of any orchestration. Getting this wrong is the most common mistake people make when starting with multi-agent systems.

Deliverable: a diagram with directional arrows, selected models, handoff points, and a data transfer mechanism (message or file).

The agent that built an artifact carries the entire history of decisions that led to that result in its context. This context induces confirmation bias — it tends to validate what it has already decided.

A reviewer with clean context has no access to the “why” behind the decisions — they see only the result. That isolation leads to more objective criticism and identifies problems the builder overlooked.

Clean context = starts from scratch; doesn't inherit the builder's "internal logic"; receives only the artifact + evaluation criteria; produces feedback without anchoring to the original decisions.

The builder receives the task and produces the artifact (code, plan, research). The reviewer receives the artifact + criteria and produces a quality report. They are two distinct subagents, called in sequence by the conductor.

Separating roles improves quality without increasing the complexity of each individual agent—each one does one thing and does it well. The conductor decides whether the feedback calls for another builder iteration.

Flow: conductor → builder (produces) → conductor → reviewer (critiques) → conductor (decides whether to iterate or publish); the reviewer has no access to the builder's internal process.

The builder-reviewer pattern works for any type of artifact: code (the reviewer checks for bugs and style), a plan (the reviewer checks feasibility and risks), research (the reviewer checks sources and consistency).

Recognizing that the same pattern applies across different domains lets you reuse the same orchestration architecture — only the criteria given to the reviewer change, not the pipeline.

Explicit criteria in the reviewer prompt; domain-specific (code: correctness, style; plan: feasibility, risk; research: sources, consistency); the reviewer delivers a structured report.

`plan-roaster` and `code-reviewer` are subagents available in the Claude Code ecosystem that implement the reviewer pattern. They are concrete examples to study and adapt.

Studying an existing reviewer reveals how the criteria are passed, how the output is structured, which model to use for review, and how the orchestrator uses the result. It’s faster than designing from scratch.

Reviewer receives: artifact + criteria + scope; produces: report with findings categorized by severity; the orchestrator decides what to do based on the report.

After the reviewer delivers the report, the conductor decides: are the findings critical (another builder iteration) or acceptable (publish)? This loop can repeat 2–3 times before reaching a stopping criterion.

Without a stopping criterion, the loop can run indefinitely. Defining “when it’s good enough” before execution is just as important as designing the agents.

Stop criterion: zero critical findings, or N iterations reached, or cost deadline; the orchestrator encodes the criterion; the reviewer reports severity to make the decision easier.

Use the pipeline diagram you created in M3.3 as an artifact. Give it to a reviewer (you can be the reviewer yourself with “clean context,” or use a code-reviewer subagent) with these criteria: feasibility, efficiency, failure points.

Reviewing your own work with an outside perspective (even a simulated one) is the meta-quality skill. This exercise closes the M3.3 → M3.4 loop: you built it, and now you evaluate it.

Deliverable: a report with findings (at least 1 improvement identified); reflect on what you would change in the M3.3 diagram after the review.

`ultracode` (previously called "workflow") is the trigger that instructs Claude Code to operate in high-scale mode: it breaks the job into dozens of parallel tasks and launches subagents for each one.

Activating `ultracode` for small jobs wastes budget. Knowing what the trigger does under the hood lets you use it surgically — only when the scale justifies it.

Automatic planning mode + aggressive parallelization; Claude Code estimates the number of subagents before execution; you can confirm or cancel; estimated cost is visible before the commit.

Documented real case where a single job launched 41 subagents in parallel to refactor a large repository. The result was delivered in a fraction of the time it would have taken sequentially.

The concrete case grounds the concept: this isn’t theory. It shows what’s possible, what the actual cost was, and what worked and what problems came up during large-scale execution.

41 Haiku subagents; Sonnet orchestrator; task: refactor 80+ files; estimated cost: ~$8 per run; total time: ~6 min vs. ~2h sequentially; test coverage maintained.

Sessions with dozens of subagents consume tokens quickly. API rate limits and Claude Code session limits can interrupt a workflow midway.

Not planning the budget before an ultracode leads to incomplete jobs and wasted costs. Understanding the limits lets you size the job correctly — or split it into smaller batches.

Rate limits per minute and per day; Claude Code session limit (tokens per window); batching strategy: split into groups of 10–20 subagents to stay within the limits.

Practical checklist: 10+ files to modify, genuinely parallel tasks (with no dependencies on one another), expected output that would cause truncation in a single context, large-scale refactoring, parallel analysis of multiple modules.

The checklist prevents decisions based on intuition. With it, you can reach a "yes/no for workflow" in 30 seconds, before running anything.

Any strong “yes” on the checklist points to a workflow; red flags: small task, shared context needed, interdependent results; when in doubt, don't use a workflow.

In workflows with 40+ subagents, partial failures are expected. The orchestrator needs to detect which subtasks failed and decide whether to retry, ignore, or abort the entire job.

Jobs without a recovery strategy fail completely when any subagent fails. Designing failure handling before execution reduces rework costs and increases robustness.

Log results by subagent; identify failures by ID; use a “retry once, then skip” strategy; the orchestrator consolidates results, marking them incomplete where needed.

Given 3 scenarios (A: refactor 1 file; B: analyze 100 closed PRs; C: write tests for 15 modules), apply the checklist and answer: workflow or not? Justify each decision.

Practicing binary decisions with justification is the module’s key skill. Answers without justification don’t count—the reasoning is the deliverable, not the yes or no.

Answer key: A = no (single file); B = yes (100 independent parallel tasks); C = yes (15 separable modules); the full module includes a detailed analysis of each case.

N subagents running at the same time, each with its own isolated task and no dependencies between them. The orchestrator launches them all and waits for them all to finish before consolidating.

It’s the most efficient pattern for uniform tasks at scale: analyze N files, search N documents, generate N drafts. Recognizing when tasks are genuinely independent is a prerequisite.

Full independence: no subagent needs another’s results; the orchestrator syncs at the end; cost = N × individual cost; speedup = N× (limited by the rate limit).

Stages A → B → C, where each stage’s output is the next stage’s input. The orchestrator runs them one at a time, waiting for each result before proceeding.

For tasks with data dependencies, the pipeline is the only correct pattern. Forcing parallelism where there are dependencies leads to errors or inconsistent results—recognizing dependencies is essential.

Total latency = sum of individual latencies; there’s no speedup from parallelism; each step can use a different model (e.g., Haiku collects, Sonnet synthesizes, Opus decides).

1 input → N parallel subagents → 1 aggregated result. The conductor launches N workers with different parts of the problem, waits for everyone, and passes the N results to an aggregator that synthesizes the final result.

Fan-out is the ultracode pattern. Understanding the "dispatcher → workers → aggregator" structure lets you design any high-scale workflow and understand what Claude Code does under the hood when you use ultracode.

Dispatcher: the conductor that splits the input; workers: Haiku/Sonnet in parallel; aggregator: a separate agent (Sonnet/Opus) that consolidates; final result: one, coherent, complete.

Agent teams are configurations where multiple agents share context and communicate directly — unlike classic subagents with a star topology. They cost more because they keep multiple contexts open.

Knowing the difference helps you avoid confusing the two architectures. Agent teams are rare in Claude Code and generally more expensive and complex. For most cases, subagents with a central orchestrator are more efficient.

Subagents: star topology, central conductor, isolated contexts, lower cost. Agent teams: communication graph, partially shared contexts, higher cost, less common.

Practical rule of thumb: if the job involves 10+ separable files OR would produce output that would be truncated in a single context, use fan-out or parallel processing. Otherwise, use a sequential pipeline or a single agent.

Having a numerical heuristic avoids detailed analysis for every job. "10 files" is the practical threshold derived from real-world experience — below that, the multiagent overhead generally isn't worth it.

10 files = ~threshold for overhead; "output wall" = a result that would use > 50% of the context; both are indicators, not absolute rules; the operator makes the final call.

Given 3 problems (A: translate 30 Markdown files; B: generate release notes from 50 commits analyzed in order; C: review code + propose a refactor + implement it), choose the topology and justify it.

The exercise wraps up the path: you apply topology vocabulary to real problems. Answer key: A = independent parallel; B = fan-out + pipeline (parallel collection, sequential synthesis); C = pipeline (3 dependent stages).

Deliverable: a problem × topology × rationale × selected models table. The full module includes a reference implementation for each case.