TL;DR — A coding router's model pool needs three tiers, not one big list: frontier reasoning (Claude Opus, GPT-5.5) for planning and hard debugging, workhorse (Claude Sonnet, GPT-5.4, DeepSeek V4 Pro) for everyday implementation, and bulk (DeepSeek V4 Flash, Gemini 3 Flash) for tests, docs, and boilerplate. The pricing spread between tiers is 10-100× — which is the entire routing opportunity. What matters more than the exact lineup: your router should tell you which model served each request, or you can't audit any of it.
Why the pool matters more than any single model
Coding agents generate wildly mixed workloads — a planning prompt followed by forty implementation calls, then a batch of test generation. No single model is the right answer for all three, and the differences are not subtle:
| Tier | Model | Input /1M | Output /1M | |------|-------|-----------|------------| | Frontier | Claude Opus 4 | $15.00 | $75.00 | | Frontier | GPT-5.5 | $5.00 | $30.00 | | Workhorse | Claude Sonnet 4 | $3.00 | $15.00 | | Workhorse | GPT-5.4 | $2.50 | $15.00 | | Workhorse | DeepSeek V4 Pro | $1.74 | $3.48 | | Workhorse | GLM-5.1 | ~$1.40 | ~$4.40 | | Bulk | Kimi K2.6 | $0.60 | $4.00 | | Bulk | DeepSeek V4 Flash | $0.14 | $0.28 | | Bulk | Gemini 3 Flash | $0.075 | $0.30 |
Output tokens are where coding bills explode — generated code is long. The Opus-to-Flash output spread is 250×. A router that moves even half your implementation traffic down one tier changes the bill more than any prompt optimization ever will.
What each tier should actually handle
Frontier (plan, architect, debug the weird stuff). Multi-file refactor planning, race-condition debugging, architecture trade-offs. These calls are maybe 10-20% of a session but determine whether the other 80% goes in the right direction. Skimping here is false economy — phase-aware routing exists precisely to protect these calls while economizing everywhere else.
Workhorse (write the code). Implementing a planned function, applying a described fix, writing a migration. DeepSeek V4 Pro and GLM-5.1 have made this tier dramatically cheaper without a quality cliff for well-specified tasks — our V4 Pro vs Flash comparison shows where the line sits.
Bulk (tests, docs, boilerplate, commit messages). High-volume, low-ambiguity output. Flash-class models handle these at prices that round to zero, and they're also the fastest — routing bulk work down-tier improves latency, not just cost.
Models that need special handling in a pool
- Reasoning models (DeepSeek thinking mode, o-series): thinking output must round-trip correctly through the router or you get hard 400s — the
reasoning_contenttrap is the canonical example. - Chinese-provider models (DeepSeek, GLM, Kimi): excellent value, but check the router handles their API quirks (thinking-mode traps) rather than just proxying blind.
- Long-context models: context length is a routing dimension too — a 400K-token repo dump shouldn't go to a 128K model no matter how cheap it is.
How to evaluate a router's model list
Bigger isn't better. A "200 models" list usually means a thin proxy with no opinions. Questions that matter:
- Does it cover all three tiers with at least two options each (fallback needs a same-tier alternative)?
- Does it add new models fast — was DeepSeek V4 available the week it launched, or a quarter later?
- Can you see which model served each request? Per-request attribution is non-negotiable — it's how you audit both quality and billing (what a router API should expose).
- Can you pin or exclude models? Compliance sometimes requires it; a good router lets you constrain the pool without abandoning routing.
CodeRouter's pool covers all three tiers with the models in the table above, routes by coding phase automatically, and stamps every response with the serving model. The April 2026 frontier cheat sheet tracks how the lineup evolves as new models land.