A Show HN post titled "Echo, Fable-level results at 1/3 the cost using open-weight models" spent July 24 climbing the Hacker News front page and collecting a few hundred comments that mostly argue about whether anyone should be impressed. The claim on its face is simple: a system that routes queries across a pool of open weights, decides how much compute each request deserves, and combines intermediate work, matches Claude Fable 5 on a set of evaluation sets while spending about a third as much on inference.
I have read the eval page. The headline numbers are real. Whether they mean what the title implies is a different question, and the HN thread, unusually, is asking it properly.
What Echo actually is
The author, who posts as adam_rida, describes Echo as a single AI system assembled out of a pool of open-weight models rather than one model picked for every task. The pool he names explicitly includes GLM-5.2 and Kimi K2.7. For each request, Echo decides how much inference to spend, which models should participate, and how their outputs should be combined.
The motivating observation is an old one in machine learning. He took the models in the pool, ran them on the same evaluation, and measured what would happen if for each problem you somehow knew in advance which models would be useful and how to combine their answers. That hypothetical system scored substantially better than any single model in the pool. It is also not deployable, because it depends on knowing which decisions were good after seeing the result. Echo is the attempt to recover some of that gain without the cheat.
There is nothing new about combining models. Random forests did it. Kaggle winners did it. The HN comments had fun naming the ancestors. Dogpile and Metacrawler for search. Mixture-of-experts for neural nets. Sakana's Fugu and OpenRouter's Fusion for LLMs specifically. One commenter called it an "intelligence router," which is the description I like best because it names the actual engineering problem: deciding where a request goes and how much you spend on it.
The numbers on the eval page
The evaluation page at echo.tracerml.ai/eval is more transparent than most. It shows failures, not just wins. The latest run, dated July 15, puts Echo at 247 of 249 on a MATH-500 subset and Fable at 246 of 249. Estimated cost: $1.977 for Echo, $5.803 for Fable, which is where the "66 percent lower" and roughly "one third" framings come from.
On the older per-question evaluations the story is more honest and more useful. On these same benchmarks Echo ties Fable exactly on MATH-500, MedMCQA, and HumanEval+, matches on GPQA Diamond, and loses on MMLU-Pro, Belebele, and Global-MMLU.
Global-MMLU is the one to stare at. Six disagreements, Fable right on all six, Echo right on none. That is a real gap and it is in the multilingual set, which is the kind of coverage that tends to favor a frontier lab with a big training budget over a pool of open weights. The eval page does not hide it. The losses are published with the wins.
What is missing is harder to ignore. There is no SWE-bench Verified result, no ARC-AGI, no BigCodeBench. The card says "No result yet" and until that changes the coding claims rest on LiveCodeBench, where Fable has not been run on the same set. Echo solved 251 of 276 there. That sounds high. It is not a comparison.
The disagreement in the thread
The HN discussion splits into two camps and they are not really arguing about the same thing.
One side says this is ensemble methods, which everyone has known about since statistics class, and the surprise is disingenuous. That is true and also not the point. The interesting part of Echo is not that combining models can outperform a single model. It is the cost-minimization objective underneath: deciding not only which model, but how much computation a request deserves and how intermediate work gets combined, without paying the full ensemble cost on every call. Ensembling by itself is cheap to claim and expensive to run. Doing it under a budget is the actual research question.
The other camp, which I find more useful, asks who this is for. The cost comparison is against Fable priced at API rates. Several commenters pointed out that the $200 per month Anthropic plan hands subscribers something on the order of $2,500 per month in Fable credits, which makes "a third of the API price" irrelevant to anyone on that plan. One person described burning $120 in Fable usage credits in about an hour running subagents, and realizing they had accidentally left multiple Fable instances running at once. That is the experience that makes the cost framing feel off: on the subsidized plan you are not paying per token, you are paying a flat fee, and the marginal cost of a request is zero until you hit the cap.
But the subsidized plan is not the whole market. Enterprise accounts pay API rates. Students, developers outside the US, and anyone whose company is too small or too risk-averse to put a $200 personal subscription on a corporate card also pay API rates, or do without. For those users the cost number is the number that matters. One commenter put it bluntly: the subsidized plans are a flexible marketing cost the labs can change without touching their primary customers, and assuming they last is a bet, not a fact.
Why the routing problems get harder, not easier
Echo works on math, multiple-choice, and short coding questions. Those are the easy inputs for a router because correctness is checkable. Math answers are right or wrong. Code passes tests or it does not. Multiple choice has a key. When the answer is verifiable, you can run several models and keep the one that produced a working result, and the cost of being wrong is bounded.
Agentic coding is not like that. "Write me a CRUD app" has no single checkable answer. "Refactor this service for readability" does not either. Quality is a judgment call, the task runs for a long time, the cost of a wrong allocation is not a failed test but a few hours of wasted inference. The author says he is currently spending a lot of time on the failure cases in coding and agentic tasks, and that is the right place to be spending it. Until something like SWE-bench Verified or a real agentic benchmark shows the same pattern as MATH-500, the cost claim is a claim about the easy half of the workload.
There is also a caching problem a router inherits that a single-model API does not. Prompt caching discounts the input tokens you reuse across calls. If a router sends your prompt to three different models, you pay the full input cost three times. Whether the ensemble still wins depends on how much of your bill is first-message versus repeat-message, and on which providers cache what. One HN commenter flagged this. It is not a fatal objection but it is one the eval page does not account for in its cost estimates.
What the subsidized pricing argument is really about
The thread keeps returning to the $200 plan because it is the clearest illustration of a wider confusion. The API price and the plan price are two different products aimed at two different buyers. The API price is what an enterprise or a router like Echo pays. The plan price is what an individual developer pays, and it is subsidized precisely because that developer's advocacy is worth more to the lab than the difference.
This matters for reading the Echo cost number. "A third of Fable's cost" is true against the API. It is not the comparison most people on HN are running in their heads, which is "a third of what I actually pay on my plan," and that comparison comes out closer to "more expensive," because Echo has no subsidized pool to draw from. Enterprises, students, and non-US developers are the buyers for whom the API price is the real price. They are also the buyers most likely to value a router over open weights, for the reason the Hugging Face incident made obvious: when a guardrail on a hosted model locks you out of your own logs, a model you can run yourself is the one that can read them.
Where this points
I do not think Echo is a Fable replacement today. The missing benchmarks are the ones that matter for the use cases where routers actually earn their keep: long agentic coding tasks, multi-step tool use, the messy stuff. Tying a frontier model on MATH-500 is an achievement, but MATH-500 is a contest math set. It is exactly the kind of well-formed, checkable task where an ensemble should shine. Showing the same cost-quality tradeoff on SWE-bench Verified would change my read of this entirely.
What I do think is happening is that the part of the market that pays API rates is going to start asking why it is paying frontier prices for work a pool of open weights can do at a third of the cost, and the answer "because the subsidized plan makes it free for you personally" is going to stop applying the moment the buyer is a business and not an individual. The policy and supply-constraint story I wrote about earlier this week is the macro version of this. Echo is the micro version, and it is the more concrete one because it has actual eval numbers attached.
My guess is that routers like this stop being interesting exactly when the frontier labs stop pricing into scarcity. If compute ever catches up with demand and Fable tokens drop to the cost the labs can actually serve them at, the price advantage of an open-weight pool shrinks toward the cost of running the pool itself, and the router has to justify itself on quality rather than cost. The author is honest that there are cases where Echo makes the wrong allocation. I would want to see those cases on a real coding benchmark before paying for a router, and I would want the subsidized-plan comparison done honestly before announcing the death of the single-model API.
The useful claim from the Show HN is narrower and more defensible than the title. A pool of open weights, routed sensibly, can match a frontier model on the benchmarks where the answer is checkable, for a fraction of the API cost. The benchmarks where the answer is not checkable are still missing. That is where the work is. It is also where the money is.