AI Coding Agent Sub-Agents: When to Use Cheap Models for Routing and Validation

The Multi-Agent Cost Problem

Modern AI coding systems — Claude Code with sub-agents, Cursor Composer, custom agent workflows — run dozens of model calls per session. The default approach sends every request to a frontier model like Claude Opus 4.8 ($5/$25 per million tokens) or GPT-5.5 ($5/$30). But most agent interactions don't need frontier intelligence.

The insight: not every sub-task requires the same capability. Routing a request to the right file is simpler than writing a complex algorithm. Checking syntax is simpler than designing an architecture. By matching model capability to task complexity, teams cut 60-70% of their AI coding spend.

Four Tasks Where Cheap Models Excel

Routing (~$0.001/decision): Classifying whether a task needs Opus ($5/$25) or can be handled by Haiku ($0.8/$4). A routing model reads the user's request and outputs a single classification — "complex" or "simple." This requires pattern matching, not reasoning. Cost per decision with a nano-class model: fractions of a cent.

Validation (~$0.002/check): Syntax checking, linting, format verification, and type checking. After a frontier model generates code, a cheap model verifies it compiles and matches the expected output format. No creativity required — just pattern matching against rules.

Context preparation (~$0.005/task): Summarizing files, extracting relevant code sections, identifying which files are relevant to a task. This pre-processing step feeds the frontier model only what it needs, reducing both context window cost and latency.

Planning (~$0.01/plan): Breaking tasks into subtasks before handing them to expensive models. A mid-tier model can decompose "refactor the authentication module" into specific file-level changes, then the frontier model executes each step with minimal context.

The Cost Math: With and Without Routing

Consider a typical coding session with 50 agent interactions:

Over a team of 5 developers running 10 sessions daily, that's $84/day saved — roughly $1,800/month. The routing model itself costs pennies, making the overhead negligible.

Model Recommendations by Sub-Task

The key principle: use the cheapest model that reliably succeeds at each sub-task. Routing and validation are near-deterministic tasks — even the smallest models handle them with 95%+ accuracy. Reserve frontier models for tasks requiring genuine reasoning.

Implementing a Routing Layer

A basic routing layer classifies incoming requests by complexity. The router receives the user's prompt and outputs a tier: tier-1 (simple lookup, formatting), tier-2 (standard code generation), or tier-3 (complex reasoning, architecture). Each tier maps to a model.

Signals that indicate a task needs a frontier model: multi-file changes, architectural decisions, security-sensitive code, novel algorithms, ambiguous requirements. Signals for cheap models: single-file edits, boilerplate generation, format conversions, test scaffolding.

Start with conservative routing — send anything uncertain to the expensive model. Track success rates by tier over time and gradually expand what the cheap tier handles as you build confidence in the router's accuracy.

Validation Chains: Cheap Checks Before Expensive Retries

Another high-ROI pattern: use cheap models as validators in the loop. After a coding model generates output, run it through a validation chain before presenting to the user. If validation fails, retry with the same model — don't escalate to a more expensive one.

A validation chain using DeepSeek V4 Flash ($0.098/$0.197) catches syntax errors, missing imports, and type mismatches at near-zero cost. This prevents expensive frontier model retries for mechanical errors that cheaper models can detect and often fix themselves.

The economics: one validation check costs ~$0.002. One unnecessary Opus retry costs ~$0.05-0.10. If validation prevents even 5% of retries, it pays for itself 10x over.

When Not to Use Cheap Sub-Agents

Cheap routing fails when tasks are genuinely ambiguous. If the router misclassifies a complex task as simple, the cheap model produces bad output, the user retries, and total cost exceeds what the frontier model would have cost on the first attempt. Monitor your "escalation rate" — if more than 20% of cheap-tier responses get retried with a better model, your router needs tuning.

Also avoid cheap models for security-critical validation. Format checking is fine with a nano model, but security review, authentication logic, and data sanitization validation should always use a frontier model where reasoning quality matters.