Does the coordinator that only assigns work need an expensive model?

No. A coordinator that only assigns work does not need an expensive model, as long as “assign” means picking one name from a roster you already wrote. A cheap model can do that when each specialist has a narrow label and the incoming sentence uses those words. It does need an expensive model the moment assign also means interpreting an outcome, splitting one request into several owners, or deciding whether the specialist’s result was the right job. Paying a frontier model to emit a label from a list of four is a waste. Using a small model to guess what “the staging link is wrong” means is how the work goes to the wrong specialist.

The decision is not “cheap models are fine for orchestration.” The decision is whether your coordinator is a switch or a manager. Switches can be cheap. Managers cannot, and you should stop calling the manager a coordinator.

What “only assigns” has to exclude

I mean a coordinator whose entire output is a specialist name, plus maybe a one-line reason you can reject. It does not open files. It does not browse. It does not send mail. It does not rewrite the user’s request into a plan. The specialists already exist, and each one has a sentence on the roster that says what it is allowed to be given.

A roster I have actually used looks like this. Files: edits and reads inside one repo, no network. Docs: reads a fixed set of pages and quotes them, no login. Calendar: reads today’s events, does not create or invite. Mail draft: writes a draft in a holding folder, cannot send. If the request does not fit one of those sentences, the coordinator’s only honest output is “no specialist,” and a person takes it.

That last line is the product. A cheap model can match a request to a sentence. It cannot be trusted to invent a fifth specialist, or to decide that two of them should share the job, or to “just handle it” because none of the sentences fit. If your coordinator is allowed to do those things, it is not only assigning. It is planning, and planning is where a cheap model quietly changes the request.

Where the cheap model matched the label

I kept a list of requests I had already classified by hand, and I ran a small local model and a frontier model over the same list. The output I scored was only the name. Not the quality of the eventual work. Just: did it pick the specialist I had picked?

When the request used the specialist’s vocabulary, they agreed. “Rename invoice_prefix in the billing service” went to Files. “What does the install page say about the GPU flag?” went to Docs. “What is on my calendar Thursday afternoon?” went to Calendar. “Draft a note to Sam that the doc is in the project folder, do not send it” went to Mail draft. The cheap model was not insightful. It was copying the nouns I had put in the roster. That is enough for assignment.

The frontier model picked the same names and wrote longer reasons. The reasons were pleasant and did not change the route. On this slice I would not pay for them. The expensive model’s advantage showed up later, inside the specialist, when the file edit had to survive a real diff. That is a different bill. Putting the expensive model in the coordinator seat, for these sentences, bought me a nicer explanation of an enum.

Where “assign” stopped meaning assign

The miss was always an outcome with more than one plausible owner. “The staging link is wrong” can be a CSS bug, a deploy that never finished, or a DNS record. My roster had a Files agent and did not have a DNS agent. The cheap model sent it to Files, because Files was the closest tool that could “fix” something, and because the prompt said to pick a specialist rather than refuse. The frontier model also wanted to be helpful. It picked Files and added a plan: check the stylesheet, then the deploy config. That plan was not assignment. It was the coordinator doing the specialist’s thinking, and it was still the wrong first owner if the link was a DNS name.

A second miss was one sentence with two owners. “Move Thursday’s review notes into the project folder and tell Sam the doc is there.” Files and Mail draft both apply, and Calendar might, if “Thursday’s review notes” means an event attachment rather than a file that already has that name. The cheap model picked Files and dropped Sam. It had assigned. It had also deleted half the request by never giving it a name. I do not count that as a successful route. I count it as the coordinator editing the job.

On those items the expensive model was better at saying “this is two tasks” and worse at staying in its seat. It would decompose, then start answering, because a frontier model asked to be useful will not stop at a label. If you put it in the coordinator role without a hard stop after the name, you did not buy a better switch. You bought a second worker that does not have the tools and will still talk as if it does.

The output format is the whole trick

A cheap coordinator survives only if the format cannot hold a plan. I ask for JSON with two fields: specialist, which must be one of the roster names or none, and because, which must be under twenty words and must quote a phrase from the user’s sentence. No steps. No tool calls. No “I would also.” If the parser fails, the request comes to me. If specialist is none, the request comes to me. The model does not get a retry where it can talk its way into a route.

That format is doing the work people hope the expensive model will do. It removes the places a cheap model shows off. A small model is dangerous when it can write a paragraph, because the paragraph can smuggle a second task or a softened request. It is boring when it can only emit a name you already listed. Boring is what you want from a switch.

I also pin the roster in the prompt every turn, including the sentence for each specialist and the sentence for none: “use none when two specialists apply, or when the request is an outcome that does not name the artifact.” The cheap model still violates that on ambiguous lines. The violation is then visible, because the format has a bucket for it. I would rather see none and do the split myself than watch Files “handle” a DNS problem because the prompt punished refusal.

What you should not spend the frontier model on

If the coordinator’s job is the enum, the frontier model belongs in the specialist that can spend money, send a message, or edit the repo. That is the step where a wrong argument hurts. A wrong label hurts too, but you can check a label in a second if the format is a name. You cannot check a quiet file edit that looked plausible unless you read the diff.

Running the expensive model on every incoming chat line, only to have it pick Files, is how agent bills get absurd while the dangerous step is still under-modeled. I have seen people put the frontier model in the coordinator “for safety” and a small model in the specialist “to save money.” That is backwards for this shape. The safety they wanted was a careful edit. They paid for a careful router and got a cheap edit.

The exception is the ambiguous outcome. If most of your real requests look like “the staging link is wrong,” you do not have an assignment problem. You have a diagnosis problem, and the coordinator is the wrong place to cheap out. Either a person triages, or a strong model triages and is required to stop at a name, or you stop pretending the next step is assignment. Do not solve diagnosis by widening the cheap model’s prompt until it writes a plan. You will get a plan. It will be confident. It will name one specialist and drop the rest.

How I decide which model sits in the chair

I read a week of real requests and mark each one. Vocabulary match: the user named the artifact the specialist owns. Outcome: the user named a symptom. Compound: the sentence has two verbs and two owners. If vocabulary match is almost the whole week, a cheap coordinator is the right spend, with none as a first-class answer. If outcome and compound are common, the cheap model will assign something on every line, and “something” is not a route.

I do not promote the coordinator to an expensive model just to feel better about those lines. I take them out of the coordinator. A person, or a strong model used as a triage pass with the same tiny format, labels them. The cheap switch never sees them. Mixing the two in one prompt is how the cheap model learns that guessing is preferred to none, because the examples you wrote for the hard lines reward a guess.

Check the coordinator the way you would check any other enum. A labeled set, scored on the name only, refreshed when you add a specialist. If agreement with your labels drops, the roster sentences have started to overlap, or the requests have drifted into outcomes. Changing the model is the second fix. Tightening the labels, or refusing the line, is the first.

The seat, not the brand

A coordinator that only assigns work needs a cheap model and a format that cannot hold a plan. It needs an expensive model only if you have secretly asked it to understand, split, or judge. Those are real jobs. They are not assignment. Put a strong model on them if you must, make it stop at a name, and keep the switch cheap for the lines that were already obvious.

If you cannot describe the coordinator’s output as one roster name or “none,” you do not have a coordinator that only assigns work. You have a manager with a modest title, and a modest model in that chair will edit the request before any specialist sees it.