The Orchestrator Is Where Your Tokens Go to Die

Run a multi-agent system long enough and you find the bill in a place nobody expects. It is not the sub-agents writing tests or reviewing code or extracting a transcript. It is the orchestrator. The thing that sits at the top, polling, listening, tracking what everyone else is doing, and adding almost no value beyond occasionally saying "go work this item."

I watched a single pipeline run cost real money, and when I traced it, the orchestrator's context window was growing a thousand tokens with every poll. The actual output was 73 tokens. The work was cheap. The babysitting was expensive. You are paying Opus-class prices for a manager that is mostly just waiting.

The instinct is to fix this by downgrading the orchestrator from Opus to Sonnet, then from Sonnet to something cheaper. But that misses the real move. The real move is to stop using an agent for orchestration at all. When you step back, most orchestration is not reasoning. It is sequencing. You fetch some context, you build a prompt, you fire it off, you collect the result. That is string interpolation. That is mad libs. You do not need a frontier model to do mad libs.

The better frame is a DAG. Data in, data out. Some steps are deterministic - run ffmpeg, hit an API, run a SQL query - and those are trivially cheap. Some steps are agentic - judge this output, summarize this video, sharpen these work items - and those are where you spend your reasoning budget. The skill is knowing which is which, and refusing to let an LLM do work that a shell command does for free. This is the same lesson the old Airflow world already learned: a step that can be deterministic should be.

Reserve the expensive models for verification, where high reasoning actually pays off. Use cheap, fast models for the looking-and-checking work. And get the orchestrator out of the hot path entirely. The next thing builders should measure is not which model is smartest, but where every token is actually going.