Echo Claims Fable-Level Results at One-Third the Cost Using Open-Weight Models

A Show HN post this week introduced Echo, a system that claims to match Claude Fable-level performance while costing roughly one-third as much. The approach: dynamically route requests across a pool of open-weight models, allocating compute based on task difficulty.

The post hit 403 points and 193 comments, sparking debate about what "Fable-level" actually means, whether the benchmarks hold up, and whether this approach can scale to production.

How Echo Works#

Echo is not a single model. It is an orchestration layer that decides, for each request, which models should participate and how their outputs should be combined.

From the creator's description:

"It started with a simple experiment. I took a group of models, including GLM-5.2, Kimi K2.7 and others, and ran them on the same evaluations. Then I measured what would happen if, for each problem, you somehow knew in advance which models would be useful and how their outputs should be combined."

That hypothetical system - the "oracle" that knows the right model for each task - performed substantially better than any individual model in the pool. Echo is an attempt to recover some of that advantage without having oracle knowledge.

The system exposes an OpenAI-compatible API endpoint. Users send prompts; Echo decides how much computation to allocate, which models participate, and how to combine their work. Some prompts may only need lightweight inference. Others get multiple models working on different parts of the problem.

The Evaluation Claims#

Echo publishes an evaluation observatory with 907 questions across 8 benchmarks and 9 test sets. The methodology page notes that results represent performance "on the questions listed here" rather than universal guarantees.

Current status according to the observatory:

• Echo matches Claude Fable on several evaluations
• Fable leads on Belebele, Global-MMLU, and MMLU-Pro
• SWE-bench Verified, ARC-AGI, and BigCodeBench are upcoming

The creators acknowledge that public benchmarks can appear in model training data, which complicates interpretation.

What HN Is Saying#

The discussion was polarized between skepticism about the claims and genuine interest in the architecture.

On benchmarks: Several commenters noted that "Fable-level" is a loaded term when benchmarks are saturated. One developer working on a similar project shared: "I wasted a huge amount of time trying to improve GPQA Diamond results above the 93% range. I realized my mistake when Fable dropped and made no improvement on this benchmark vs. Opus."

Another commenter pointed to research suggesting roughly 7% of GPQA Diamond questions may have incorrect ground truth labels. (link to thread)

On transparency: A recurring critique was that Echo does not disclose per-request routing decisions. The creator responded: "Echo does not disclose its per-request routing decision because that policy is the product."

A Canva engineer pushed back hard on this: "Observability and full transparency is a critical requirement; we can't accept not knowing which model serves a request. Both for legal/contract reasons, coordinated capacity planning with API providers, or even just evaluating our prompts and harnesses."

On the comparison to existing approaches: Multiple commenters noted similarities to OpenRouter (which offers model routing), NotDiamond (which does task-based model selection), and Sakana AI's Fugu (which orchestrates multiple models). The debate was whether Echo adds meaningful innovation or is simply "vibe-coded OpenRouter."

On practical value: Supporters argued that even if the claims are aggressive, the approach has value. One commenter noted: "A model that is clearly weaker overall can still be extremely useful on particular problems or as part of a combination." The insight that models are complementary - rather than strictly rankable - is the core of why multi-model systems can outperform single-model approaches.

The Pricing Uncertainty#

Echo is currently in public alpha with no charges. The estimated pricing includes "every internal model attempt and guardrail at provider rate-card prices," but actual billing may differ based on caching, tools, and other factors.

The "one-third the cost" claim appears to assume that routing to smaller open-weight models for easier tasks reduces average cost versus always using a frontier model. This is plausible but depends heavily on the task distribution and routing accuracy.

Why This Matters#

The broader trend here is important: as open-weight models close the gap with closed models, orchestration becomes a viable strategy. If GLM-5.2 or Kimi K2.7 can handle 60% of requests at 10% the cost of Fable, routing saves money even if the routing itself adds overhead.

This aligns with patterns we have covered in AI Model Routing Orchestration Layer and Agent Fleet Economics. The question is no longer "which model is best" but "which model is best for this specific task at this cost."

The HN discussion also surfaced a real tension in the space: developers want observability, but providers want to protect their routing logic. This is the same tension that exists in any managed service, but it is sharper when the "service" is making model selection decisions that affect output quality, latency, and cost.

The Honest Assessment#

Echo makes aggressive claims that are not fully substantiated by the published benchmarks. The evaluation methodology is more transparent than most, but the benchmark selection and the "Fable-level" framing invite skepticism.

That said, the underlying approach - multi-model orchestration with dynamic allocation - is sound. The best production AI systems already do some version of this, whether through explicit routing (OpenRouter), implicit caching (Anthropic's prompt caching), or task-specific model selection (GitHub Copilot's "auto" mode).

If Echo's routing layer actually works - if it can reliably match task to model - then the cost savings are real. The question is whether the accuracy holds up on the long tail of real prompts, not just curated benchmarks.

For developers evaluating Echo, the advice is standard: test on your actual workload, compare costs end-to-end, and demand the observability you need for production. The claims are interesting. The proof is in the deployment.

Continue Reading#

• AI Model Routing Orchestration Layer
• Agent Fleet Economics: Fable 5 vs Sonnet 5
• Best Local Coding LLMs 2026
• Kimi K3: Moonshot's 28T Frontier Model
• GLM-5.2 Local Deployment Guide

Sources#

• Echo on Tracer ML - Official product page
• Echo Evaluation Observatory - Published benchmarks
• Hacker News Discussion - 403 points, 193 comments
• Sakana AI Fugu - Similar multi-model orchestrator
• NotDiamond - Model routing service