{"slug": "why-i-route-each-phase-of-my-coding-agent-to-a-different-model", "title": "Why I route each phase of my coding agent to a different model", "summary": "A developer built pi-tiered-router, a coding agent that routes each phase of a coding turn—classify, plan, validate, execute—to a different model optimized for that phase. The tool uses a cheap model for classification and tool-output compression, a frontier model for planning and validation, and a mid-tier model for execution, improving efficiency without sacrificing quality. The approach is packaged as an extension for the pi.dev platform.", "body_md": "Most agentic coding setups run one model for the whole job: it decomposes the task, writes the code, and then wades through thousand-line test logs looking for the one line that matters. That wastes a good model twice over — you're paying frontier-model rates for work a much cheaper model would do just as well, and you're diluting the model's context with noise while you're at it.\n\nMy method is simple to state: **treat a coding turn as a sequence of phases, and give each phase the model best suited to it.** I've packaged it as [ pi-tiered-router](https://pi.dev/packages/pi-tiered-router?name=pi-tiered-router), an extension for the\n\nA coding turn breaks into phases:\n\n```\nclassify → plan → validate → execute\n                              (tool output compressed as it streams in)\n```\n\nEach phase binds to a role, and each role binds to a model plus a thinking level — all configurable:\n\n| Role | Default (model, thinking) | Job |\n|---|---|---|\nPlanner |\nOpus, high | Decompose the goal into a numbered plan |\nValidator |\nFable, medium | Independently critique the plan before any code is written |\nExecutor |\nSonnet, medium | Do the actual work |\nTool parser |\nHaiku, off | Classify the task up front, and compress noisy tool output before it hits the executor's context |\n\nNote that the cheapest role does double duty: it runs the up-front complexity classification *and* the tool-output compression. Both are high-volume, low-difficulty jobs — exactly what you don't want a frontier model spending context on.\n\nPlanning and validation happen **out of band** — they never touch the executor's conversation. Only the final, validated plan gets injected as context. The model doing the actual coding sees a clean, distilled plan instead of the whole reasoning trace that produced it.\n\nA minimal config is just the roles you want to change; everything else falls back to defaults:\n\n```\n{\n  \"roles\": {\n    \"planner\":   { \"model\": \"anthropic/claude-opus-*\",   \"thinking\": \"high\" },\n    \"validator\": { \"model\": \"anthropic/claude-fable-*\",  \"thinking\": \"medium\" },\n    \"executor\":  { \"model\": \"anthropic/claude-sonnet-*\", \"thinking\": \"medium\" },\n    \"toolParser\":{ \"model\": \"anthropic/claude-haiku-*\",  \"thinking\": \"off\" }\n  }\n}\n```\n\nModel specs use wildcards (`claude-opus-*`\n\n) so the config survives point releases, and any role can point at any provider — OpenAI, Google, a local Ollama model, whatever your setup has.\n\nThe name comes from what the classification is *for*. Before anything runs, the cheapest role rates the request into a tier — trivial, simple, standard, or complex — and the tier scales the whole chain:\n\nThis is the part I want to be clear about, because it's an easy thing to get wrong. There are no spend caps and no silent downgrades. Every phase always gets the model and effort level that produces the best result *for that phase*.\n\nThe efficiency is a **side effect of routing well**, not the goal:\n\nIf you want it cheaper, you configure cheaper models per role (or lighter tier chains) — the router will never make that tradeoff for you behind your back.\n\nIf you've read Anthropic's writing on multi-agent systems, the obvious question is: how is this different from the **orchestrator/subagent** pattern — a lead agent that dynamically decomposes a task, spawns worker agents, and synthesizes their results?\n\nThe honest answer is that they optimize different things, and being clear about the tradeoffs is more useful than pretending my method wins on every axis.\n\n**The load-bearing difference: I decompose by phase, decided by code; the orchestrator decomposes by subtask, decided by a reasoning model.** My pipeline is fixed, and its cleverness is binding each phase to a model — deterministic, given a cheap up-front classification. The orchestrator instead has a reasoning model look at *this specific task*, decide how to split it, spawn workers in parallel, read what comes back, and re-plan.\n\nThe way I'd put it: I built a well-engineered assembly line; the orchestrator is a research team. An assembly line is faster and more reliable when the product is known — and the wrong tool when the job is \"go figure out what we should even build.\"\n\nIt isn't strictly either/or: the package includes an opt-in `dispatch_step`\n\ntool that farms parallel steps out to isolated subprocesses, so the executor can borrow a page from the orchestrator playbook when a step genuinely benefits from it.\n\n```\npi install npm:pi-tiered-router\n```\n\nOr browse it on the pi package gallery: [pi.dev/packages/pi-tiered-router](https://pi.dev/packages/pi-tiered-router?name=pi-tiered-router)\n\nIt ships with four modes (plan / agent / ask / debug) and a first-run setup wizard. It's v0.1.0 — I'd genuinely like to hear how it holds up on real work, especially where the phase-based method breaks down and you'd want something more orchestrator-shaped.", "url": "https://wpnews.pro/news/why-i-route-each-phase-of-my-coding-agent-to-a-different-model", "canonical_source": "https://dev.to/rohit_gampa_99770d4d9542c/why-i-route-each-phase-of-my-coding-agent-to-a-different-model-1680", "published_at": "2026-07-13 13:30:00+00:00", "updated_at": "2026-07-13 13:46:52.914882+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models", "ai-infrastructure"], "entities": ["pi-tiered-router", "Anthropic", "Claude Opus", "Claude Fable", "Claude Sonnet", "Claude Haiku", "OpenAI", "Google"], "alternates": {"html": "https://wpnews.pro/news/why-i-route-each-phase-of-my-coding-agent-to-a-different-model", "markdown": "https://wpnews.pro/news/why-i-route-each-phase-of-my-coding-agent-to-a-different-model.md", "text": "https://wpnews.pro/news/why-i-route-each-phase-of-my-coding-agent-to-a-different-model.txt", "jsonld": "https://wpnews.pro/news/why-i-route-each-phase-of-my-coding-agent-to-a-different-model.jsonld"}}