BlockRun
Back to Signal
Aug 2026

When LLM Routing Saves Money — and When It Doesn't

Illustration of a routing valve splitting one stream of tokens between a large expensive pipe and several smaller efficient pipes

LLM routers are sold with big savings numbers, and the numbers are usually real. What the marketing skips is that the savings come from exactly three places — and if your workload doesn't match any of them, a router saves you nothing.

This article walks through the three, shows what we measured on our own router (including the part that didn't go our way), and ends with a five-minute test you can run on last month's bill.

Picture one day of an agent

Say your agent makes 1,000 model calls a day. Look at what those calls actually are:

  • ~700 are grunt work — extract a field, format an output, fill tool arguments, summarize a page.
  • ~250 need moderate reasoning — plan a small task, review a diff, answer with some judgment.
  • ~50 are genuinely hard — the calls where you truly want the best model available.

If everything is pinned to a flagship model, all 1,000 calls pay flagship rates. But the 700 grunt calls would come out the same from a model that costs roughly a tenth as much per token — and a small model doing easy work is not "good enough," it is simply the right size. That gap between what you pay and what the call needed is the entire routing opportunity.

Keep this picture in mind; all three levers below are just ways of closing that gap.

Lever 1: Send easy calls to cheap models

A router prices each request individually instead of pinning one model for everything. ClawRouter's decision layer classifies every prompt across 15 dimensions — locally, in under a millisecond, before any tokens are spent — and sends the grunt majority down-tier while the hard tail still gets the flagship.

In the 1,000-call picture: 700 calls drop to ~10% of their cost, 250 drop somewhat, 50 stay full price. The blended bill lands at a fraction of the pinned-flagship bill — not because any price changed, but because most calls stopped over-paying.

One thing routing is not: a discount. Per-token prices are public, and on BlockRun paid chat rates match OpenRouter with no platform margin (a flat $0.001 transaction fee is the only add-on). Any gateway telling you its price sheet saves you money on the same model is describing a rounding error. Savings come from which model handles which call — policy, not prices.

Lever 2: Send fewer tokens

The second lever ignores model choice entirely: shrink the requests. ClawRouter runs seven layers of token compression — context deduplication, history pruning, tool-schema minification, and friends — before a request leaves your machine.

Compression multiplies with routing: a cheaper model × a smaller prompt is where the dramatic numbers in router marketing come from. When you see a "500×" or "10×" claim — including ours — decompose it: part routing, part compression, part workload-specific. The multiplier is real for the workload it was measured on. Yours will differ.

Lever 3: Pay per call, not per seat

The third lever is billing structure. Subscriptions bill your peak; pay-per-call bills your actual. Agents are bursty — idle for hours, then a million tokens in a loop — so the gap between peak and actual is unusually wide. On BlockRun each call settles individually in USDC via x402 (minimum $0.002 per request), with no seat and no idle spend.

This lever doesn't make any single call cheaper. It makes the months cheaper.

What we measured — including the part that didn't flatter us

Enough theory. Our Router v3.4 checkpoint ran real agent tasks three ways — new router, previous router, and everything pinned to Opus 5 — and only counted a task as a success if the result verified.

Routed vs. pinned flagship: the router spent 91.1% less normalized token cost than pinning Opus 5 for everything — but verified success came out 10 points lower. That is the honest shape of the trade: on this workload, routing was not "flagship quality at a tenth the cost." It was slightly worse quality for dramatically lower cost. For a high-volume background fleet, that trade is obviously right; for one high-stakes query, it's obviously wrong.

New router vs. old router: verified success rose to 57% — up 8 percentage points — while cost per success decreased by 6.4%. Better and cheaper at once is the result you want from a router upgrade. One honest caveat: the sample is small enough that the improvement's margin of error still technically includes zero. We publish that instead of hiding it, because a router vendor that only shows you point estimates is selling, not measuring. (Full intervals and methodology are in the research writeup.)

When a router saves you nothing

Run your workload against these four cases before you integrate anything:

Every call is hard. Deep research, competition math, high-stakes review — if all 1,000 calls belong in the top 50, the router sends them all to the flagship and you pay flagship prices plus fees. A router monetizes variance in difficulty. No variance, no savings.

One wrong answer costs more than a month of API spend. Pin the best model and don't look back. The v3.4 numbers are explicit about what routing traded away against a pinned flagship.

Your spend is tiny. Saving 40% of $20/month is $8. Any integration effort takes months to pay back. Routing is a volume game.

You're already pinned to a cheap model and it works. A router can only move your calls up-tier from there. That's a quality upgrade, not a cost cut — a fine lever, but know which one you're pulling.

The five-minute test

Open last month's usage and ask:

  1. Is the workload mixed? Sample 50 requests. If half or more could plausibly run a tier down, routing has room to work.
  2. Can you verify quality? Routing without outcome checks silently converts cost savings into quality regressions. Our checkpoint counts only verified success for exactly this reason.
  3. Is the volume real? Multiply monthly spend by 0.3–0.6. If that number doesn't justify an afternoon of integration, wait until it does.

Two or three yeses: try ClawRouter — open source, sub-millisecond local decisions, per-request pricing on public rates. Zero or one: pin a model and move on. A router you don't need is just a dependency.

FAQ

Do routers add latency? The decision itself shouldn't. ClawRouter classifies locally in sub-millisecond time (benchmark methodology); the dominant latency remains whichever model the call routes to.

Is a cheaper gateway a substitute for routing? No. Per-token rates on serious gateways are within noise of each other — ours match OpenRouter exactly. The savings live in which model runs the call and how many tokens you send it. Policy, not price sheets.

What's the catch on the 91% number? It's normalized token cost versus pinning Opus 5 for everything, on our checkpoint workload, and it came with a measured quality trade of 10 points of verified success. If someone quotes you a savings multiplier without its quality delta and its workload, ask for both.