Do AI Model Routers Actually Cut Your LLM Bill by Two-Thirds?

Key takeaways

• A new project called Echo claims to match frontier-model quality by routing each request across a pool of open-weight models (GLM-5.2, Kimi K2.7, and others), at around one-third the inference cost of a top-tier model like Fable.
• The savings figure is an average across a benchmark mix, not a guarantee: commenters point out that if most of your traffic is already 'easy,' a cheap model would have handled it anyway.
• Switching models mid-conversation to save money can break prompt caching, which on some providers already discounts repeated context heavily, so a router's savings can be partially offset by lost cache hits.
• Multi-model routing is not new: it echoes OpenRouter's Fusion router, Sakana AI's Fugu ensemble project, and even OpenAI's internal model-selection layer.
• Before adopting a router, model your blended cost across your real task distribution, not the marketed headline ratio.

What is Echo, and how does the '1/3 the cost' claim work?

Echo is a routing layer, launched on Show HN, that decides per request how many open-weight models to invoke and how to combine their outputs. On the builder's own evaluation set (907 rows across seven benchmark families, published publicly), the combined system reportedly reached roughly the same aggregate score as Fable, a frontier model, at about a third of the inference cost. The mechanic is plausible: cheaper models can handle a large share of 'easy' requests, and only the hard tail needs to route to something expensive.

Why do commenters call the savings number misleading?

The top critical comment makes an important point: your savings depend heavily on how hard your tasks are in the first place. If 99% of your traffic is simple, you could already be routing most of it to a cheap model manually, so a router adds little marginal value. Per-request routing can also silently break prompt caching, since switching providers or models resets the cached context, forcing you to re-pay for tokens a sticky, single-model setup would have gotten at a caching discount.

How should a SaaS founder model this before adopting a router?

Before you swap in any router, run a simple model: blended cost equals (cheap-task share times cheap-model $/1M tokens) plus (expensive-task share times expensive-model $/1M tokens), then compare that to your current single-model bill including cache discounts. If your task mix already skews toward 'hard' queries, a router buys you less than the headline ratio suggests, and the cache-loss penalty can eat a meaningful chunk of the saving.

Is this actually a new idea?

Not really, and Echo doesn't claim otherwise. It sits in the same family as OpenRouter's Fusion router, Sakana AI's open Fugu project, and classic ensemble learning. What's changed in 2026 is that token bills have gotten large enough for founders to justify building, or buying, this layer at all.

Routing across models can meaningfully cut your LLM bill, but only if you model it against your actual task mix and cache behavior rather than the marketed average, and that's exactly the kind of scenario you can stress-test in Calcaas before committing engineering time to a router.