Orchestration

One expensive model plans and synthesizes; specialized subagents do the work, each in its own context window. The orchestrator never reads the whole codebase or writes bulk code — it decomposes the task, routes each part to the right agent, and stitches the results back together.

This isn't a bespoke framework. It's how Claude Code already works: the Agent tool spawns subagents, and each agent's model: frontmatter picks its tier. This skill is the doctrine for using that well in this repo.

Why it saves — the real mechanism

Two effects, and neither is "a cheaper model runs the show":

1. Context isolation. A subagent reads files and burns tool-output tokens in its own context, then returns a compact summary. The orchestrator's context never fills up with raw file contents, so it stays cheap per turn and coherent across a long task.
2. Tier arbitrage. The expensive orchestrator generates few tokens (a plan, a synthesis). The high-volume generation — code, tests, boilerplate — happens on whatever tier that work actually needs, and mechanical work drops to the cheapest tier.

The savings come from where the tokens are spent, not from downgrading the thinking. Don't expect a fixed multiplier — the gain scales with how much reading and mechanical volume the task involves.

The tiers