Your AI Uses a Sledgehammer for Every Job — This Smart Router Picks the Right Tool and Gets 8.8x More for the Same Budget

Ask your AI assistant to draft a two-line email and it fires up the same giant, expensive model you use for hard reasoning and tricky code. It is like hiring a master carpenter to hang a picture frame — every time, for every job — and paying master-carpenter prices for picture-frame work.

A new paper from researchers at the National University of Singapore, InfRec, UC Berkeley and HKUST offers a different answer: build a dispatcher. A small router looks at each task and sends it to the cheapest specialised model that can actually do it well. Their system is called Route Anything ("Route Anything: A Study of Model and Policy Routing for General-Purpose AI Systems", Pengfei Zhou et al., arXiv:2611.05275, 3 November 2026), and across 25 benchmarks and more than 374,000 test runs, routing delivered 8.82 times more efficiency than always using the big reference model — while matching or beating it on quality.

What the researchers did

Start with the problem. AGI, the paper argues, probably will not arrive as one model that masters everything. The realistic path is an ecosystem of specialised models — language, image, video and speech generation, coding agents, workplace agents, robot policies — hundreds of candidates, each good at some things and wasteful at others. The open question is orchestration: for each task, how do you pick the right candidate while balancing quality against cost?

To answer it, the team first built the measurement infrastructure most routing research skips: an "omni-modal trajectory matrix" of 25 benchmarks across language understanding, image, video and speech generation, coding and workplace agents, and robotic manipulation — 374,401 scored runs from 452 candidate configurations. That is the map of who is actually good at what.

On top of that map they built a unified theory of routing, characterising the optimal router under quality-versus-cost trade-offs. Its key lesson: a router can only be as good as the information it gets about the task. Give it only the broad category ("this is a coding task") and its choices stay crude; give it the specifics of the input and its picks sharpen.

Then they trained and tested actual routers, and the results show how much efficiency is hiding in plain sight. Perfect "oracle" routing — always picking the best candidate per input — beats the best fixed model by 5.4 points. Learned routers beat it too: by 0.3 points across 16 benchmarks, 2.1 points on video generation, and 1.1 points on robot manipulation, while using 24% less policy time on the robot tasks. Routing raised efficiency 8.82x on average versus always calling the large reference model. In one test, a router fitted for zero quality loss never even needed to call the most expensive model at all.

The most concrete demonstration comes from robotics. Two robot control policies were tested: one worked well in clean, simple scenes, another in cluttered, randomised ones. A router, given a glimpse of the scene from a camera, chose which policy to run — reaching 71.6% success against the best single policy's 70.5%, while using 24% less computation time.

One more finding matters for anyone building routers: the winning approach predicts the outcome, not the winner. The best routers did not guess which tool "wins" each task. For every candidate they predicted its expected score, then picked the highest — often factoring in cost.

Why it matters

The obvious reason is money — and speed. Frontier models are expensive, and most of what real products ask them to do is not frontier-hard. Every routine summary, short email or easy question sent to the biggest model is compute and cash spent for nothing, and smaller specialised models answer faster too. Routing is the difference between paying for capability you use and paying for capability you merely own.

The deeper reason is direction. This paper is part of a shift in AI research: away from "build a bigger model" and toward "build a smarter system around the models you already have." Orchestration — routers, verifiers, harnesses — is becoming the layer where the practical gains live. If you only follow model releases, you are watching the wrong scoreboard.

How YOU can use it

You cannot download Route Anything as a finished product — it is a research framework, with code on GitHub (InfRec-Cardinal/route-anything). But the pattern ports directly to any agent you run, and you can build a first version this week. The code sketch below is illustrative, not code from the paper.

Step 1: Build your own mini trajectory matrix. Collect 100–200 real tasks your product actually sees. Run each through the 2–4 models you already pay for and record who did best and what it cost. This is your map of who is good at what. Without it, any router is guessing.

Step 2: Define tiers, not a single model. Split your models into fast-and-cheap for routine work and strong-and-pricey for hard work. The expensive model becomes the exception, not the default.

Step 3: Start with rules, then learn. Your first router can be rules: short and simple goes cheap; long, ambiguous or high-stakes goes strong. Log every decision and its outcome. Once you have a few thousand logged decisions, graduate to the paper's approach — a small classifier that predicts each candidate's expected score and picks the best, cost included.

Step 4: Measure cost per solved task, not cost per call. A cheap model that fails half the time and forces a retry is not cheap. Track the full price of getting a task done right — including retries and escalations — and let that number drive your routing.

Step 5: Always keep an escalation path. If the cheap model fails, its confidence is low, or the output fails your checks, escalate to the strong model automatically. Routing is not about trusting the cheap model — it is about only paying for the strong one when the evidence says you need it.

ILLUSTRATIVE sketch — not code from the paper:

# Route Anything, pocket edition: predict each model's score, pick the best value
# (Illustrative pattern inspired by the paper — not the paper's code.)

def route(task, candidates):
    # candidates: list of (model, cost_per_call)
    scored = []
    for model, cost in candidates:
        # predict expected quality for THIS task (from your logged evals)
        predicted_score = router.predict(task, model)
        value = predicted_score / cost
        scored.append((value, predicted_score, model))
    scored.sort(reverse=True)
    best_value, best_score, best_model = scored[0]
    # escalate if even the best prediction is weak
    if best_score < QUALITY_FLOOR:
        return STRONG_MODEL
    return best_model

# The discipline that makes it work: log every outcome,
# retrain the router on real results, and watch cost per SOLVED task fall.

One guardrail: route on evidence, not on vibes. The paper's theory is blunt — a router fed only the task category makes crude choices. Feed yours the task itself: its length, type, difficulty signals and history. The more your router knows about the input, the more money it saves you.

Key takeaways

• One giant model for every task is the most expensive way to run AI — a dispatcher that picks the right specialist per task is cheaper and often better.
• The evidence base is unusually large: 25 benchmarks, 374,401 scored runs, 452 candidate configurations across language, image, video, speech, coding agents and robots.
• Perfect per-input routing beats the best single model by 5.4 points; learned routers beat it by 0.3 points overall, 2.1 on video generation and 1.1 on robot manipulation — using 24% less policy time on robots.
• Routing raised efficiency 8.82x on average versus always using the large reference model — in one test the expensive model was never needed at all.
• The winning router predicts each candidate's expected score and picks the best value — it does not guess the winner.
• The portable lesson: measure which model is best at your real tasks, tier them, route by predicted score per cost, escalate on weak predictions, and judge by cost per solved task.

Read the original paper: Route Anything: A Study of Model and Policy Routing for General-Purpose AI Systems (arXiv:2611.05275) by Pengfei Zhou, Yixing Ma, Hexin Wang, Weidong Tang, Zhenglin Wan, Wangbo Zhao and Yang You. Link: https://arxiv.org/abs/2611.05275 — Code: https://github.com/InfRec-Cardinal/route-anything