TL;DR: Common model dispatchers hardcode “which task goes to which model” into their rules. But model capability is the most volatile thing in the entire system. What requires the biggest model today might be handled by a cheaper one next year. My approach: classify task difficulty by error cost, reasoning depth, and judgment space, and keep that classification layer stable. What actually changes is “which model is the most cost-effective choice for this tier right now.” So model names don’t go into the rules. They go into a dated binding table.

A few days ago, I used Claude to help me assign my work across different models. It quickly put together a table: hard tasks to Opus, medium ones to Sonnet, high-volume routine work to Haiku. This split looked reasonable. It treats models as tools at different tiers, allocating resources by task difficulty. Hard problems get the strong model, routine work gets the light one, and both cost and quality are covered.

But then I asked: if models keep improving, what happens to our workflow?

A task that needs Opus to be reliable this year might be handled by Sonnet next year. Work that’s a good fit for Sonnet today might become basic enough for Haiku before long. So what happens to that original dispatch table?

That’s where the problem surfaces. Multi-model dispatch can’t just be a fixed table, because what changes inside it isn’t only the task. It’s also model capability.

Once you write something that changes into a rule that rarely gets updated, the system starts drifting out of calibration. It doesn’t break right away. It depreciates slowly: some tasks are still running on models stronger than they need, some could already be handed down a tier, and some judgments are still stuck at the boundary of what last generation’s models could do.

So the hard part of multi-model dispatch may not be how you draw that first table. Plenty of people have already covered that well.

The real question is: once this plan is set, who’s responsible for checking whether it’s already expired?

Why a Model Dispatcher Starts to Rot the Moment It Goes Live

Because the table’s default assumption is that model capabilities won’t change. And model capability is the one thing in the entire system you can be certain will change.

Writing “hard tasks to Opus, simple ones to Haiku” into your rules means you’ve pinned the most mobile thing in the system to the place that should move the least. Six months later, when new models arrive, tasks that once required Opus are handled reliably by a cheaper tier, but the rules are still living in the old world. You’re either continuing to spend on expensive models for work that has quietly gotten easier, or you’ve simply never noticed there’s a cheaper path. The dispatcher isn’t broken. It’s just silently expired.

What Should a Durable Dispatcher Actually Hardcode?

Let me explain: this kind of dispatch isn’t a new trick. The orchestrator-workers pattern, routing, and the principle of “send easy problems to cheap models, hard ones to strong ones” are all covered in detail by Anthropic’s agent design guide. What I want to add is the layer that guide touches on less: how to make that dispatch survive model generations.

My approach: hardcode difficulty, keep the “which model” column flexibly replaceable.

A task’s difficulty is a property of the task itself, not of the model.

Fixing a punctuation error in an article: worst case, you fix it again. Assessing legal risk in a contract: a mistake might shape a real decision. Models getting stronger genuinely makes many things easier to complete, but it doesn’t automatically lower the cost of being wrong. How many inferential steps a task requires, what’s at stake if it fails, whether there’s a correct answer: these are intrinsic properties of the task. A model’s improvement doesn’t turn a high-stakes decision into a low-stakes one. The only thing that changes is: at this difficulty level, who’s the best value right now?

So I split the system into two layers. One is the difficulty taxonomy: stable, rarely touched, describing work in terms of roles, deep reasoning, standard generation, high throughput, without naming any specific model. The other is a binding table that maps roles to the current models. That table moves. And it’s explicitly dated.

The engineer’s habit is to hardcode that binding table, once called an “internal setting.” But in this design, it should be as visible as possible.

Because it’s the only part of the system explicitly authorized to change. When a model updates, you touch this table and nothing else. Update the date. The classification rules stay untouched.

“Today’s mountain becomes tomorrow’s road.” Models are improving faster than we can stop. What we can do is concentrate all the volatility into a small, dated lookup table.

Same task, two designs, compared: the common approach welds the difficulty judgment and the model name into one rule (hard tasks always go to Opus, easy ones always to Haiku); six months later a new model ships, the rule doesn't notice, and you keep overpaying or miss the cheaper path. This article's approach splits difficulty taxonomy (stable, describing only roles, no model names) from the binding table (volatile, carrying a calibration date) into two layers, so when a model changes, only the date on the binding table moves, and the difficulty taxonomy stays untouched.

One more point to note: swapping model tiers isn’t the only adjustment you have. Within a single model, parameters like extended-thinking or effort level control how much reasoning the model invests. Turn it up and the answers tend to be more reliable, but slower and more expensive. Turn it down and speed and cost improve, with the tradeoff that this suits lower-risk tasks. Anthropic’s model selection guide also notes that adjusting effort is often more cost-effective than changing models. So the binding table actually has two columns to fill: which model, and how much effort. Both belong to the volatile layer.

What’s the Right Ruler for Measuring Difficulty?

Use error cost, not “is the model smart enough.”

I score difficulty on three dimensions: reasoning depth, judgment space, and error cost. Error cost carries the most weight, deliberately. Reasoning depth and judgment space both shrink relative to a given task as models strengthen. Something that demands hard thinking today might be one-shot for next year’s model. But “how expensive is a mistake here” is a business property. It has nothing to do with model intelligence. It’s the most stable of the three axes. Weight it most heavily, and the taxonomy doesn’t become obsolete every time a model improves.

When a Model Improves, How Do You Know It’s Time to Rebind?

This is the part of the design I’ve thought about most carefully, because what it needs to catch will never throw an error.

I learned this the hard way. A scheduled job I had was running automatically every day. One day an upstream dependency broke, and the job just sat there silently. The whole pipeline went dark. I didn’t notice for a while. The same risk applies here: models improve, the bindings should update, but nothing will tell you. The table doesn’t error. It just stops being the most cost-effective option. That kind of deprecation triggers no alerts.

So I gave the binding table a heartbeat. I keep a set of roughly ten representative tasks drawn from my actual work, each pre-tagged with an ideal role and a clear success criterion. When a new model ships, I run the whole set through it to see which tier it reliably handles. Then I move the corresponding role to a cheaper model, update the date, and log one line explaining why. This is a resilience principle I keep coming back to: any automation you depend on should be able to answer the question “is it still alive?”

This isn’t my first time writing about how to divide work across multiple models. Multi-model cognitive collaboration and the Fable 5 work system both covered that ground. But the focus here isn’t who does what. It’s how to make that division of labor survive model generations. Worth noting: on the day this ruleset went live, I put it to the test on my own design. A task comes in, maybe writing a tool, organizing a batch of documents, or updating a feature on the site, and I’d often be unsure which model to hand it to. I used to have to ask explicitly, “how hard is this?” or “help me dispatch this,” to trigger a judgment. It used to run passive by default. I later switched it to active and shipped a new version of the skill, so I no longer have to ask. Now, whenever I hand off a task in a session window, the first thing I see is one line: difficulty, role, current model, and a one-sentence reason. The flip only touched three lines. The classification logic was untouched, because the operating mode and the classification logic had been cleanly separated from the start.

When it doesn’t kick in on its own, I call it in with a trigger phrase, something like “which model should handle this” or “help me dispatch this task,” or I just type the slash command /model-orchestrator. Getting a judgment is one thing. Actually having it execute across models is another: to make it run the dispatch for real, I need to say something like “run this dispatch for real” or “spin up subagents for this,” and only then does it kick off the plan-execute-verify-integrate flow, routing through subagents using the model parameter to Opus, Sonnet, Haiku, or Fable. Which model runs the main conversation thread is something I chose myself in the app, and Claude can’t switch that. Cross-model routing only happens through subagents, not by swapping out the main thread itself. Right now this setup is fully live in the window where I do my coding (Code), and it also works in the other two windows I keep running (Cowork, Chat) once capabilities have been uploaded there.

The full flow: a task arrives and the stable-layer difficulty taxonomy (error cost weighted highest, then reasoning depth, then decision space) scores it into a role. That role is handed to the volatile-layer binding table (carrying a calibration date), which maps it to the current model. On a new model release or quarterly, the recalibration heartbeat reruns the representative task set, moves roles to cheaper models where possible, and updates the table's date.

Designing for Future Tier Collapse

One more thing to prepare for early: these three tiers will eventually collapse into two.

The capability floor keeps rising. Cheaper models eat away at the middle tier from below. Today you might have three layers: deep reasoning, standard generation, high throughput. Next year, maybe standard generation gets absorbed by cheaper models. The year after, perhaps everything except the most demanding work goes to one model, and any dispatch is just overhead. So from the beginning, I let the binding table allow multiple roles pointing at the same model. When a tier empties out, the system doesn’t break with it.

Looking further out, the decision axis itself will shift. Today’s question is “which model is smart enough for this task.” Eventually it becomes “what’s the cheapest tier that can stay within this error cost threshold.” This is exactly why error cost has to be the primary axis from day one: it’s the only ruler that survives to that point. This connects to something I keep thinking about in the AI thread of this site: when capabilities are changing this fast, what does it even mean to design order that holds?

That question extends beyond model dispatch. It shows up in people’s own workflows too.

Actually, this is bigger than model dispatch. After a reading group a while back, a friend and I compared notes on our shared experience using AI Agents over the past six months. Context-switching has become the norm. Multiple windows, multiple tasks, multiple threads open simultaneously: the number of things a person has to track at once has hit a new ceiling. We’d both gone back to handwritten notebooks to keep our thinking straight. Interestingly, the tools themselves have recently shipped something like a control panel, a dashboard where you can see which windows are running, which are idle, which need a second look. When AI is cheap and fast, the new constraint isn’t AI capability. It’s whether the person can manage that many threads at once. The handwritten notebook preserves exactly this — judgment and direction, held firmly, while the tools accelerate underneath. Same principle as the dispatch table.

Build the Exit Door While You’re Building the House

I never assumed this dispatch system would last forever. The day a model vendor handles routing internally, with one endpoint and routing done for you, this manual layer should retire. The day tiers collapse to one and sending everything to the same model is simpler than any dispatch, it should retire too.

There’s math behind this. Anthropic’s own data: an agent consumes roughly 4× the tokens of a single conversation; multi-agent systems, around 15×. That only makes sense when the task value justifies the cost. They also note directly that most coding tasks have limited parallelism and aren’t well suited to multi-agent setups. More dispatch isn’t better. If you can solve it simply, don’t overcomplicate it.

I had an auto-optimization system once that I maintained until the signal got too sparse and the value no longer justified the upkeep. I shut it down. That experience taught me: designing a clean exit for a tool is part of the design, not an afterthought. This table will be thrown away. This role taxonomy will be revised. What remains is one habit: put the volatile things in a small, dated box, then give that box a heartbeat. The tools will be made obsolete by the next generation of models. The habit won’t.

Build the escape route while you’re building the house. Not to escape. Just to know you still have a choice.

If there’s one thing to take away, it’s this: don’t put model names in your decision rules. Keep the decision rules. Put the model names in a table that can be rebound, updated, and eventually retired.

Appendix: Take This and Make It Your Own

This design isn’t tied to my workflow. You can lift it directly. Two things: a skeleton that makes the structure visible, and a prompt to generate your own version.

First, here’s the skeleton. Fill it in and you have a working draft:

# Task Dispatch Rules (Skeleton)

## Difficulty Taxonomy (Stable layer, rarely changes)
Score on three dimensions, with error cost weighted most heavily:
- Error cost: how expensive is a mistake? Affects overall conclusion or brand = high; affects only a local piece = low.
- Reasoning depth: requires multi-step inference or creative synthesis = high; applies established rules = low.
- Judgment space: requires subjective tradeoffs = high; has a correct answer = low.
Mostly high scores → deep reasoning tier. Mostly low → high throughput tier. In between → standard generation tier.

## Binding Table (Volatile layer: will change, explicitly dated)
Calibration date: ______ (when a model updates, only this table and this date change)
- Deep reasoning tier → your current strongest model
- Standard generation tier → the middle-tier model
- High throughput tier → the cheapest, fastest model

## Recalibration Heartbeat
On new model release or quarterly: run roughly ten representative tasks from your real work (each pre-tagged with an ideal tier and success criteria) through the new model. See which tier it handles reliably. Move the corresponding tier to a cheaper model, update the date above, and log one line of reasoning.

## Exit Clause
Retire this system when any of these occur: vendor handles routing internally within a single endpoint; tiers collapse to one; the overhead of making dispatch decisions exceeds the cost savings.

If you’d rather not fill it in yourself, paste the following into your preferred AI and let it interview you to generate a version that fits your workflow:

You are my model dispatch design assistant. Help me build a task dispatch ruleset that can survive model generations. The principle: treat task difficulty as a constant, model capability as a variable, and keep the two layers separate.

1. Difficulty taxonomy (stable layer): Help me score my tasks on three dimensions, with error cost weighted most heavily, then reasoning depth, then judgment space. Ask me about three to five types of work I do most often, and rate each high, medium, or low.
2. Binding table (volatile layer): Describe tiers by role (e.g., deep reasoning, standard generation, high throughput). Don't hardcode model names yet. Ask me which models I currently use and their costs and strengths, then map roles to current models and produce a dated table.
3. Recalibration heartbeat: Help me list roughly ten evaluation tasks drawn from my real work, each tagged with an ideal role and success criterion, to serve as the benchmark I rerun when a new model ships.
4. Exit clause: Write three signals that should trigger retirement of this dispatch system.

Output a single file I can save as a skill or system prompt: difficulty taxonomy in the stable layer, binding table as a separate dated section, with recalibration steps and exit clause attached.

Sources

The mechanisms and figures referenced in this piece come from Anthropic’s official documentation:

  • Anthropic, Building Effective Agents: orchestrator-workers, routing, and other workflow patterns, along with the principle of starting from the simplest solution and avoiding over-engineering.
  • Anthropic, How we built our multi-agent research system: multi-agent token costs (roughly 4× and 15×), empirical results from Opus-led with Sonnet subagents, and the boundaries of when multi-agent approaches are and aren’t appropriate.
  • Anthropic, Choosing the right model: selection principles across the capability/speed/cost dimensions, and the effort parameter for adjusting reasoning intensity within a single model.