Orchestrate Cheap Models for Grunt Work, Save Expensive Models for Reasoning

Not every line of code needs Claude.

Stubbing out a file? Creating boilerplate? Writing a test that checks if a button exists?

A local model can handle that. A cheap API model can handle that. The expensive frontier model sitting idle while you generate scaffolding is just burning budget.

The misallocation problem

You're three sprints into a new feature. The codebase needs twelve new files: interfaces, test stubs, configuration boilerplate, README sections. You fire up the AI agent and watch it churn through the work.

The model generating your empty test file is the same model you'd use to debug a race condition in your authentication flow.

That's the misallocation. You're paying senior engineer rates for intern-level work.

The pattern emerging from teams using Roo Code: route tasks by complexity, not just by cost. Intern-level tasks go to small models. Senior-level reasoning goes to frontier APIs. An orchestrator handles the assignment.

"Can I pair local models with big models? So it's like a new orchestrator mode. Can I have different levels of engineers that the micromanager figures out: 'All right, intern you do this, junior level you do this.'"

Adam, Office Hours S01E09

The layered approach

The mental model: think of your AI tooling like a team with different experience levels.

Intern tier (local or cheap models):

• Stub out new files
• Generate boilerplate
• Write skeleton tests
• Create configuration files
• Add imports and basic structure

Senior tier (frontier APIs):

• Debug complex failures
• Refactor tangled logic
• Review architectural decisions
• Handle ambiguous requirements
• Reason through edge cases

"You don't need Claude to go create a file for you, to like stub something out. You can use a small model to do that."

Adam, Office Hours S01E09

The orchestrator routes based on task type. A request to "create a new React component with standard props" goes to the cheap tier. A request to "figure out why this auth flow fails intermittently" goes to the frontier tier.

The configuration flexibility

The approach scales in both directions. You can run the intern tier on a local model (zero API cost) or a cheap cloud model (minimal cost). You can run the senior tier on Claude, GPT-4, or whatever frontier model fits your budget.

"You could just put it all as good models, too. You can be like, 'All right, I'm going to have a cheap online model for the low level. I'm going to have an expensive model for the senior level.'"

Adam, Office Hours S01E09

The point isn't to squeeze every token. The point is to match capability to task complexity. A small model that generates correct boilerplate on the first pass is more valuable than a frontier model doing the same work at 10x the cost.

The tradeoff

This adds configuration overhead. You need to decide which task types route where. You need to test that the cheap tier actually handles its assigned work reliably.

The payoff: your budget goes to reasoning, not scaffolding. The frontier model shows up when you need actual judgment, not when you need a file created.

How Roo Code enables model orchestration

Roo Code closes the loop on multi-model workflows through its BYOK (Bring Your Own Key) architecture. You configure which API keys connect to which models, then assign those models to different modes or task types. The orchestrator mode can delegate grunt work to cheap models while reserving expensive frontier models for tasks requiring genuine reasoning.

Roo Code lets you route AI tasks by complexity: use local models for boilerplate, cheap APIs for scaffolding, and frontier models only when you need real judgment.

Because Roo Code runs commands, tests, and iterates based on results, the orchestrator can validate that cheaper models completed their work correctly before escalating to more expensive tiers. You spend tokens intentionally for outcomes, not uniformly across all task types.

Old approach vs. new approach

Why this matters for your team

For a five-person team shipping 10+ PRs a week, the grunt work adds up. Test stubs, config files, boilerplate components. If 40% of your AI usage is on tasks a small model could handle, you're spending 40% of your budget on work that doesn't require frontier reasoning.

The shift: treat model selection like task assignment. Route the intern work to intern-level models. Save the expensive reasoning for problems that actually need it.

If your AI spend feels high relative to output, audit which tasks are going to which models. The misallocation is often obvious once you look.