HN Debrief

Show HN: Echo – Fable-level results at 1/3 the cost using open-weight models

  • AI
  • Developer Tools
  • Infrastructure
  • Startups

The post introduces Echo, a hosted system that routes each prompt across a pool of open-weight models and decides how much compute to spend, which models to involve, and how to combine their outputs. The claim is not that one open model suddenly matches a frontier closed model. It is that a routing layer over several weaker models can hit roughly the same aggregate benchmark score as Fable while using much less inference cost. The author points to a public evaluator with 907 stored rows across seven benchmark families and says harder coding evidence like SWE-bench Verified and BigCodeBench is still being added.

If you buy API usage for teams, model routing is worth watching because it could cut spend without giving up much quality. If you mostly use subsidized consumer subscriptions, the cost claim is far less compelling and you should wait for stronger coding and real-world evals before taking it seriously.

Discussion mood

Interested but skeptical. People broadly buy the premise that routing across models can help on cost and quality, but they pushed hard on weak presentation, benchmark quality, missing transparency on the routing policy and model pool, and whether the economics are meaningful outside enterprise API buyers.

Key insights

  1. 01

    Benchmark saturation can fake router gains

    Once benchmark scores bunch up near the top, a router can look smarter than it is because the test no longer separates models cleanly. GPQA Diamond was called out as a case where even frontier systems stall in the low 90s and some questions may be wrong in the ground truth, which means small headline gains can be benchmark noise rather than real routing skill.

    Treat aggregate benchmark wins near saturation as weak evidence. Ask for repeated trials, variance, and harder evaluations like coding or agentic tasks before you price this into your roadmap.

      Attribution:
    • seizethecheese #1 #2
    • yorwba #1
  2. 02

    Cost per task is not price per token

    Router economics break if you assume the cheapest model per token is the cheapest way to finish work. Several commenters pointed out that stronger models can use fewer tokens, and that systems like Fusion pay extra by generating multiple full replies before synthesis. The right unit is completed task cost under latency constraints, not posted input and output rates.

    When comparing routers, build evals around your real prompts and measure latency, total token use, cache hits, and successful task completion. Vendor pricing pages are not enough to predict actual savings.

      Attribution:
    • janalsncm #1
    • seizethecheese #1 #2 #3
    • meander_water #1
    • indiantinker #1
  3. 03

    Conversation routing can destroy cache savings

    Per-request model switching sounds efficient until a long chat or coding session starts reusing context. If consecutive turns land on different models, prompt caching can reset and you pay full input costs again. That makes routers much easier to justify for fresh one-shot tasks than for sustained conversations with large shared context.

    Segment your workload before adopting a router. Stateless tasks are the easy win. Long-lived chats and coding sessions need cache-aware routing or the savings claim may invert.

      Attribution:
    • subygan #1
    • purplecats #1
    • seizethecheese #1
  4. 04

    This is routing, not Mixture of Experts

    Calling every multi-model system 'MoE' muddies the picture. Commenters drew a clear line between Mixture of Experts inside one model, where routing happens per token among trained experts, and products like Echo, where routing happens per prompt or task across separate models from different providers or families. That distinction matters because the engineering, failure modes, and economics are completely different.

    Do not borrow intuition from model architecture papers when evaluating a product router. Judge it like decision infrastructure with orchestration and cost-control problems, not like a new base model architecture.

      Attribution:
    • yonatan8070 #1
    • janalsncm #1 #2
    • Alifatisk #1
    • tintor #1
  5. 05

    The pitch lands differently for subscriptions and enterprises

    For people using heavily subsidized $200 consumer plans, 'one third of API cost' is not a compelling headline because they already get far more model usage than list pricing implies. For enterprise buyers paying per token through APIs, the same claim is immediately relevant. That split explains why some readers saw a real business and others saw a non-problem.

    Position multi-model routing by buyer type. Enterprise API spend is the credible wedge. Prosumer chat subscriptions are a much harder sell until subsidies tighten or vanish.

      Attribution:
    • cheema33 #1
    • killingtime74 #1
    • nickthegreek #1
    • jacobgold #1
    • teruakohatu #1
    • eikenberry #1
    • dberg #1
  6. 06

    Row-level transparency is the real trust test

    The most convincing part of the launch was not the top-line claim but the author exposing prompts, outputs, grades, and costs for stored evaluation rows, then acknowledging a UI bug and the need for repeated matched trials. That is the right direction because routers are otherwise impossible to audit from marketing copy alone. The missing piece is more variance reporting and stronger code-heavy benchmarks.

    If you build in this category, publish row-level evidence early and make reruns easy. Buyers will trust visible failures and variance more than polished aggregate charts.

      Attribution:
    • adam_rida #1 #2

Against the grain

  1. 01

    OpenRouter comparisons may miss the point

    Dismissing Echo as a clone of OpenRouter skips an important distinction. OpenRouter's coding router was described as relatively simple infrastructure abstraction, while Echo is trying to make a smarter routing decision about quality and cost at request time. If that works, it is a different product category from basic failover and provider switching.

    When evaluating this space, separate infrastructure routers from performance routers. The feature lists can look similar while the technical moat and customer value are very different.

      Attribution:
    • codekansas #1
    • seizethecheese #1
  2. 02

    The claim is about orchestration, not a single model

    Some criticism treated the title as if Echo were claiming one open model beats Fable at one third the price. That is not the proposal. The whole point is to spend premium inference only when necessary and use cheaper models the rest of the time. Arguing against a nonexistent single-model claim obscures the actual testable question.

    Read router products as scheduling systems, not model launches. The right challenge is whether the controller chooses well enough to beat a static default, not whether any one model tops the chart.

      Attribution:
    • maxdo #1
    • seizethecheese #1

In plain english

API ↩
Application Programming Interface, a way for software to access a service or model over the network under the provider's control.
BigCodeBench ↩
A coding benchmark designed to measure how well AI systems solve programming tasks.
ensemble methods ↩
Machine learning techniques that combine multiple models so their joint output is better than any one model alone.
Fable ↩
A named closed model referenced in comments as the source of alleged distillation by Chinese labs.
GPQA Diamond ↩
A hard question-answering benchmark used to evaluate advanced AI systems, with 'Diamond' referring to its toughest split.
inference cost ↩
The computing cost of running an AI model to answer prompts, often billed through an API by tokens or usage.
latency ↩
The time it takes for a system to return a response after a request is sent.
Mixture of Experts ↩
A model architecture where a gating system activates only some specialized sub-models, called experts, for each token or input.
MoE ↩
Mixture of Experts, a model design that routes work to a subset of specialized internal components instead of using the whole model every time.
open-weight models ↩
AI models whose trained parameters, called weights, are available for others to download and run, even if the full training process is not open.
OpenRouter Fusion ↩
A product mode from OpenRouter that uses multiple model outputs together and synthesizes a final answer.
prompt caching ↩
A system that avoids recomputing repeated prompt context so repeated calls cost less and return faster.
Sakana Fugu ↩
A multi-model orchestration project from Sakana AI that combines several language models rather than relying on one.
SWE-bench Verified ↩
A benchmark that tests whether AI systems can fix real software issues in code repositories, using validated tasks.

Reference links

Project and evaluation links

Related routing and orchestration systems

  • OpenRouter Fusion Router docs
    Frequently cited comparison point for multi-model routing and synthesis.
  • Sakana AI Fugu
    Open repository for a multi-LLM orchestrator used as a close conceptual comparison.
  • Pellmell
    Another commenter’s multi-model system that streams one answer immediately and reconciles with background models.
  • Magnitude
    Referenced by a commenter as a possibly similar product in the same category.

Benchmarks and analysis

Background references