Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Claude Code Orchestration

Purpose: Guide model selection, task delegation, context management, and continuous self-improvement for efficient Claude Code usage.

Mindset: Apply /pb-design-rules thinking (Simplicity - cheapest model that produces correct results; Clarity - make delegation explicit) and /pb-preamble thinking (challenge assumptions about model choice - is opus actually needed here, or is it habit?).

Resource Hint: sonnet - reference guide for model selection and delegation patterns.


When to Use

  • Starting a session with mixed-complexity tasks
  • Planning workflows that involve subagent delegation
  • Reviewing resource efficiency after a session
  • Generating or updating CLAUDE.md templates
  • After a session where model choice caused issues (wrong model, wasted tokens)

Model Tiers

TierModelRoleStrengthsTrade-off
ArchitectopusPlanner, reviewer, decision-makerDeep reasoning, nuance, trade-offsHighest cost, slowest
EngineersonnetImplementer, coder, analystCode generation, balanced judgmentMedium cost, medium speed
ScouthaikuRunner, searcher, formatterFile search, validation, mechanicalLowest cost, fastest

Opus reasons. Sonnet builds. Haiku runs.


Model Selection Strategy

By Task Type

TaskModelWhy
Architecture decisions, complex planningopusMulti-step reasoning, trade-off analysis
Security deep-dives, threat modelingopusCorrectness stakes are high
Code review (critical paths)opusJudgment about design, not just correctness
Code implementation, refactoringsonnetWell-defined task, good balance
Test writing, documentationsonnetPattern application, not invention
Routine code reviewsonnetStandard checklist evaluation
File search, codebase explorationhaikuMechanical, no reasoning needed
Linting, formatting, validationhaikuRule application, not judgment
Status checks, simple lookupshaikuInformation retrieval only

Decision Criteria

Ask these in order (first match wins):

  1. Does this require architectural judgment or trade-off analysis? → opus
  2. Does this require code generation or analytical reasoning? → sonnet
  3. Is this mechanical (search, format, validate, scaffold)? → haiku

When unsure, start with sonnet. Upgrade to opus if results lack depth. Downgrade to haiku if the task is mechanical.


Task Delegation Patterns

When to Delegate (Task Tool)

Delegate to subagents:

  • Independent research or codebase exploration
  • File search across many files
  • Validation and lint checks
  • Parallel information gathering
  • Work that would pollute main context with noise

Keep in main context:

  • Decisions that affect subsequent steps
  • Architecture and planning
  • Work requiring conversational continuity with the user
  • Anything where the user needs to see the reasoning

Parallel vs Sequential

PatternWhenExample
Parallel subagentsIndependent queries, no shared stateSearch 3 directories simultaneously
Sequential subagentsOutput of one feeds into nextExplore → then Plan based on findings
Main context onlyUser interaction needed, judgment callsArchitecture review with the user

Model Assignment in Task Tool

model: "haiku"   → Explore agents, file search, grep, validation
model: "sonnet"  → Code writing, analysis, standard reviews
(default/opus)   → Planning, architecture, complex analysis

Context Budget Management

Budget Awareness

Context LoadBudgetFrequency
Global CLAUDE.md<150 linesEvery turn, every session
Project CLAUDE.md<150 linesEvery turn, every session
Auto-memory MEMORY.md<200 linesEvery turn, every session
Session contextFinite, compaction is lossyFills during session

Every unnecessary line in CLAUDE.md or MEMORY.md costs tokens on every single turn. Be ruthlessly concise in persistent files.

Efficiency Principles

  • Subagents for exploration (separate context window, doesn’t pollute main)
  • Surgical file reads (offset + limit, not full files when you know the area)
  • Plans in files, not in chat (reference by path, not by pasting)
  • Compact at natural breakpoints (after commit, after phase - not mid-task)
  • Commit frequently (each commit is a context checkpoint)
  • Reference by commit hash (not by re-reading entire files)

Playbook-to-Model Mapping

ClassificationExample CommandsDefault ModelDelegation
Executorpb-commit, pb-start, pb-deploysonnetProcedural steps, well-defined
Orchestratorpb-release, pb-ship, pb-reviewopus (main)Delegates subtasks to sonnet/haiku
Guidepb-preamble, pb-design-rulesopusDeep reasoning about principles
Referencepb-patterns-*, pb-templatessonnetPattern application, lookup
Reviewpb-review-*, pb-securityopus + haikuPhase 1: haiku automated; Phase 2-3: opus

Self-Healing and Continuous Learning

The orchestrator is not static. It learns, adapts, and improves.

Operational Self-Awareness

After each significant workflow, reflect:

QuestionAction if Yes
Did a model choice produce poor results?Record in auto-memory, adjust default for that task type
Did a subagent return insufficient results?Note the prompt pattern that failed, try broader/narrower next time
Did context fill up mid-task?Record breakpoint strategy, compact earlier next session
Was a playbook missing or insufficient?Note the gap, suggest improvement to user
Did the workflow take more turns than expected?Analyze why - wrong model? Missing information? Poor delegation?

Auto-Memory as Learning Journal

Use the auto-memory directory (~/.claude/projects/<project>/memory/) to persist operational learnings:

MEMORY.md (loaded every session, <200 lines):

  • Model selection adjustments discovered through experience
  • Playbook gaps encountered and workarounds used
  • Project-specific orchestration preferences
  • Context management lessons learned

Topic files (referenced from MEMORY.md, loaded on demand):

  • orchestration-lessons.md - Model choice outcomes, delegation pattern results
  • playbook-gaps.md - Missing guidance discovered during workflows
  • project-patterns.md - Project-specific efficiency patterns

Feedback Loop

Execute workflow
    |
    v
Observe outcome
    |
    v
Was it efficient? Correct? Right model?
    |           |
    YES         NO
    |           |
    v           v
Continue    Record learning in auto-memory
            Adjust approach for next time
            Surface playbook gap to user if systemic

Self-Healing Behaviors

TriggerSelf-Healing Response
Subagent returns empty/useless resultsRetry with adjusted prompt or different model tier
Context approaching limit mid-taskProactively compact, checkpoint state in files
Playbook command produces unexpected outputNote in memory, suggest playbook update
Model produces shallow reasoningEscalate to higher tier, record the task type
Repeated pattern across sessionsExtract to auto-memory for persistent learning
Stale information in MEMORY.mdPrune during session start, keep only current learnings

Suggesting Playbook Improvements

When the orchestrator discovers gaps during operation:

  1. Note the gap - What was missing, what workaround was used
  2. Assess frequency - One-off vs recurring need
  3. Propose to user - “Encountered [gap] during [workflow]. Suggest updating [playbook] with [specific addition].”
  4. Don’t self-modify playbooks silently - Propose, don’t assume

This creates a virtuous cycle: use playbooks → discover gaps → propose improvements → playbooks get better → usage gets better.


Anti-Patterns

Anti-PatternWhy It HurtsBetter Approach
Opus for file searchExpensive, no reasoning advantagehaiku via Task tool
Haiku for architectureShallow reasoning, bad decisionsopus in main context
Serializing independent subagentsWastes wall-clock timeParallel Task calls
Loading full files for 10 linesContext wasteRead with offset + limit
Pasting plans into chatConsumes context every turnStore in files, reference by path
Skipping compaction until forcedLossy emergency compactionCompact at natural breakpoints
Same model for everythingWastes cost or qualityMatch model to task
Never recording what workedSame mistakes repeatedUse auto-memory feedback loop
Ignoring playbook frictionWorkarounds accumulate silentlySurface gaps, propose fixes

Examples

Example 1: Feature Implementation Workflow

  1. /pb-plan - opus (main context): architecture decisions, trade-offs
  2. Explore codebase - haiku (Task tool, 2-3 parallel agents): find relevant files
  3. Implementation - sonnet (main context): write code
  4. Write tests - sonnet (Task tool): parallel test generation
  5. Self-review - opus (main context): critical evaluation
  6. /pb-commit - sonnet: procedural commit workflow

Post-session reflection:

  • Did haiku find what was needed? (If not, adjust search prompts in memory)
  • Did sonnet’s code need significant opus review fixes? (If yes, consider opus for complex implementation next time)

Example 2: Playbook Review with Model Delegation

  • Phase 1 automated checks - haiku (Task tool): count commands, validate cross-refs
  • Phase 2 category review - opus (main context): nuanced evaluation of intent, quality
  • Phase 3 cross-category - opus (main context): holistic pattern recognition

  • /pb-claude-global - Generate global CLAUDE.md (concise orchestration rules)
  • /pb-claude-project - Generate project CLAUDE.md
  • /pb-learn - Pattern learning from debugging (complements operational learning here)
  • /pb-review-playbook - Playbook review (model delegation by phase)
  • /pb-new-playbook - Meta-playbook (resource hint in scaffold)

Last Updated: 2026-02-07 Version: 1.0.0