Reddit Community: Tiered Model Routing with Opus Planning and Sonnet 5 Batch Execution

One-sentence takeaway

Establish a tiered division-of-labor workflow for complex projects—"flagship model ( Opus/Fable ) top-level planning + Sonnet 5 low/medium effort batch parallel execution + flagship model verification and synthesis"—to prevent Sonnet 5 from spinning its wheels across multiple turns and consuming excessive tokens on high-difficulty, open-ended tasks.

Use cases

• Suitable tasks: Massive unstructured document extraction and cleaning, parallel multi-subagent codebase retrieval, large-scale modular unit test generation, and multi-step deterministic business implementations.

• Unsuitable tasks: Single-turn ultra-complex system architecture design ( should be handled directly by Opus ) and simple single-file minor edits.

• Applicable model versions: Claude Sonnet 5 ( as the execution layer ) paired with Claude Opus 4.8 / Opus 5 ( as the planning and validation layer ).

• Applicable clients, agents, or APIs: Custom multi-agent orchestration systems, Cursor Composer, Claude Code.

• Recommended reasoning levels and parameters: Use effort: "low" or effort: "medium" for Sonnet 5 executing subtasks; use effort: "high" for Opus planning.

Ready-to-use content

Tiered model routing and division-of-labor workflow definition

workflow_name: tiered_model_routing
architecture:
  layer_1_orchestrator:
    model: claude-opus-4.8
    effort: high
    role: "System Architect & Task Decomposer"
    responsibilities:
      - Analyze the full project requirement and repository context
      - Decompose the goal into bounded, deterministic, single-step tasks
      - Specify input files, constraints, and verifiable acceptance criteria for each subtask
  layer_2_workers:
    model: claude-sonnet-5
    effort: medium  # or low
    role: "Parallel Execution Worker"
    responsibilities:
      - Execute isolated subtasks (e.g. read files, extract schemas, write unit tests, generate feature code)
      - Strictly follow acceptance criteria without redefining overall architecture
      - Output diffs, test logs, and structured reports
  layer_3_synthesizer:
    model: claude-opus-4.8
    effort: medium
    role: "Quality Gate & Integration Reviewer"
    responsibilities:
      - Review integrated diffs from Sonnet 5 workers
      - Validate edge cases, security guardrails, and cross-module consistency
      - Approve final merge or issue targeted remediation requests

Test/workflow steps

1. Stage 1 ( Architecture Planning ): Opus analyzes the complete requirements and outputs modular decomposition specifications alongside a task backlog.

2. Stage 2 ( Task Dispatch ): Dispatches the decomposed independent subtasks as structured inputs to Sonnet 5 instances ( can run multiple instances in parallel ).

3. Stage 3 ( Execution and Self-Testing ): Sonnet 5 writes code and runs local unit tests within restricted directories and context, outputting standardized diffs upon completion.

4. Stage 4 ( Quality Gate ): Opus or human reviewers conduct regression checks and acceptance testing on the merged changes.

Original evidence and data

• Empirical validation by multiple heavy community users: If Sonnet 5 is left to independently handle high-difficulty, long-horizon architectural tasks, it tends to repeatedly explore and self-correct across multiple turns, causing total tokens and latency per task to surge dramatically. However, once tasks are decomposed into single-step tasks with well-defined boundaries, Sonnet 5's low pricing ( $2/$10 ) and ultra-fast execution speed advantages are fully unlocked, reducing overall workflow costs by over 50% compared to a pure Opus approach.

• Document processing benchmark: When extracting large batches of unstructured documents and aggregating them into spreadsheets/tables, Sonnet 5's per-call cost is substantially lower than Opus while its accuracy completely meets requirements.

Scope and limitations

• Clear Done Conditions must be established for each subtask; if dispatched subtask objectives are ambiguous, Sonnet 5 may still produce unnecessary refactoring code.

• The orchestration layer must monitor step limits for each subagent to prevent abnormal infinite loops.

Source excerpts or observations ( short compliant quotations only )

• Community user takeaway: "The real trick... you should decompose tasks to the level where they are suitable for smaller models on low/medium reasoning... bigger models orchestrate and smaller models drive primary output."

• Source practice: "I use Sonnet 5 for research in workflows with mild fan out that an Opus agent collates and synthesizes... Token usage is actually cheaper than just Opus."