在约 1,000 项智能体任务测试中,开源模型 Kimi K3 与闭源模型 Fable 5 整体准确率接近(SWE 基准 92.4% vs 92.6%),但 K3 在 Fireworks
上的推理成本可低至 Fable 的 1/50。 通过任务路由,两者组合可实现 93% 的准确率,其中 K3 承担 72-96% 的任务流量,在保持前沿质量的同时大幅降低总成本。
宣布我们的D轮融资和10亿美元ARR
K3是一个前沿高质量的开源模型,成本仅为一小部分。更重要的是,它可以稳定地补充Fable,使得通过任务路由获得最高质量的智能成为可能。
🧭 简而言之:我们在约1,000个智能代理任务中,将Kimi K3(开源)与Fable 5(闭源)进行了对比,发现:
我们对每个基准进行了平均,每个基准针对不同类型的工作,并使用相同的框架运行K3和Fable 5。总共有约1,030个任务,在真实代理循环中进行。
在进入结果之前,先给出一个快速定义。Oracle路由是一种通过将任务在每个模型上运行后,选择最便宜的正确选项(成本/性能上限)来衡量最佳理论性能的方法。在实际路由中,你不能让任务同时运行在多个模型上。路由器会预测哪个模型在成本和质量上最优,但最终只是一个猜测。
在这项研究中,Oracle路由显示K3被选中的任务占72-96%。这表明,通过学习日常任务与前沿工作的真实长尾之间的差异,可能实现几乎完美的路由器。要得出明确结论,需要多一个数量级的路由数据和实际性能。
从10,000英尺的高度来看,很容易只看两个模型便认为正面对比是平手。例如,如果你看SWE这个主基准,K3得分92.4%,Fable得分92.6%。在我们基准测试的五种类型任务中,这两个模型的得分通常相差几个百分点,Fable在代码语言广度(多语言)上略占优势。
很容易就停止在这里,说“它们大致相当”。新闻是它们在不同任务类型上具有明显更好的性能。
如果你仔细查看单个基准,不只是看到一个顶线准确率就够了。以SWE为例,整体上两者完全相同。如果按问题领域拆分SWE,你可以看到每个模型的擅长领域。K3在符号数学和开发工具方面最为出色;Fable在网页和数据可视化工作上胜出。同样的模式在多语言集合中也存在,Fable在Java、Python和C++上具有广度优势,而K3在JavaScript和Rust上表现平分秋色。
对于在终端进行长周期工作的情况,如驱动 shell 并跨几十个回合操作系统,K3 展现了它的真实实力。它完成了一批 Fable 从未攻破的任务:7z 哈希、FEAL 密码分析、泄露的秘密、实时漏洞、失控的异步作业。
虽然在高水平上质量几乎不分伯仲,但价格却相差悬殊。
那么,这巨大的价格差距是从哪里来的呢?是令牌定价、提示缓存以及每个任务的处理工作量。例如在SWE上,K3 比 Fable 工作更努力:每个任务大约 55 回合和 130 万令牌,而 Fable 是 21 回合和 13 万令牌。在长终端任务上情况正好相反:Fable 才是耗费最多的,会达到 64 回合和 150 万令牌(有时直接导致超时)。
提示缓存大多负责将这些工作量转化为 K3 的价格优势:即使 K3 阅读的令牌数是 Fable 的十倍,但由于缓存命中,SWE 运行成本仍低于 Fable。这是一个权衡。增加回合数的任务通常意味着每次运行的实际时钟时间增加,即运行速度更慢。如果你需要在两秒内得到答案,这很重要;但如果你是在大规模后台运行代理,账单只是小部分,这就更重要了。
如果你将每个任务发送给最能处理它的模型,你并不会落在两种模型之间,而是超越两者。
按任务路由始终优于任何单一模型运行:
Oracle 路由器选择了 K3,占 72-96% 的任务流量。通过这样设计路由器,你最终获得的总体质量高于任何单一模型,成本接近仅使用最优化的模型。
将质量和成本放在同一图表上。K3 用蓝色表示,在所有五个任务类别中都位于 Fable(红色)左侧(更具成本效益的一侧)。准确率则此消彼长:Fable 在多语言上领先,K3 在终端和法律任务上领先,其他任务大致持平。
Kimi K3 + Fable 组合路由可以以最佳价格释放它们的最佳特性。
单一模型供应商、令牌最大化的时代即将结束。任务级数据表明,这些模型在不同价格下是专长不一的专家。最好的 AI 不再来自单一实验室,而是多模型的混合。
Announcing our Series D and $1B ARR
K3 is a frontier quality open model at a fraction of the cost. Even bigger is that it complements Fable predictably, which makes it possible to get the highest quality intelligence by routing tasks.
🧭 tl;dr: We ran Kimi K3 (open) against Fable 5 (closed) on ~1,000 agentic tasks finding:
We averaged benchmarks, each aimed at a different kind of work , and ran K3 and Fable 5 through the same harness. About 1,030 tasks in all, in real agent loops.
One quick definition before we get into the results. Oracle routing is a method for measuring the best theoretical performance by running the task through each model and then picking the cheapest correct option (the cost/performance ceiling). In a practical router, you don’t get to run your task against multiple models. The router makes a prediction of which model has the best cost and quality trade off, but ultimately it’s a guess.
In this study, oracle routing demonstrated K3 is selected for 72-96% of tasks. This suggests a near-perfect router might be achievable, by learning the difference between day-to-day tasks and the true long tail of frontier work. It will require an order of magnitude more routing data, and real world performance to say definitively.
From a 10,000 foot view, it can be easy to look at both models and call the head-to-head a tie. For example, if you look at SWE, the headline benchmark, K3 gets 92.4% , Fable 92.6% . Across the five types of tasks we benchmarked on, the two models tend to stay within a few points of each other, with Fable pulling slightly ahead on its coding-language breadth (Multi-lang).
It’s easy to stop there and say “they’re roughly even”. The news is that they have discretely better performance across different task types.
If you take a peek inside a single benchmark, there’s more to see than just a top-line accuracy number. Take SWE, where the two are dead even overall. If you split SWE by problem domain you can see where each model shines. K3 is sharpest on symbolic math and dev tooling; Fable wins on web & data visualization work. The same pattern runs through the multi-language set, where Fable's breadth carries Java, Python and C++, while K3 draws even on JavaScript and Rust.
For long-horizon work at a terminal, driving a shell and prodding at systems across dozens of turns, K3 showed its true colors. It cleared a batch of tasks Fable never cracked: a 7z hash, FEAL cryptanalysis, leaked secrets, a live vulnerability, runaway async jobs.
While quality is a near-tie at a high level, price isn't close.
So where's this huge price gap coming from? token pricing, prompt caching, and effort-per-task. On SWE for example, K3 works much harder than Fable: roughly 55 turns and 1.3M tokens a task versus 21 turns and 130K. On the long terminal tasks it's the other way around: Fable is the one that spirals, running up 64 turns and 1.5M tokens (sometimes straight into a timeout).
Prompt caching does most of the work of turning that effort into K3's price advantage: even when K3 reads ten times the tokens, with cache hits that means that SWE runs still come in lower cost than Fable. There’s a tradeoff. Tasks with extra turns generally mean more wall-clock time per run i.e. slower runs. If you need an answer in two seconds, that matters; if you're running agents in the background at scale, a bill that's a fraction of the size matters a lot more.
If you send every task to whoever handles it best, you don't land somewhere between the two models, you land above both.
Per-task routing always out performs any single model run:
The oracle router choose K3, 72-96% of task traffic. By architecting a router this way, you end up with overall quality above either model alone at a cost close to just using just the cost-optimized one.
Put both quality and cost on one plot. K3 in blue lands to the left (the more cost-effective side) of Fable in red in all five task-families. Accuracy trades back and forth: Fable pulls ahead on multi-language, K3 on terminal and legal, the rest roughly level.
Kimi K3 + Fable routed together unlocks their best qualities at the best price.
The single model provider, token maxxing days, are coming to an end. The task-level data says these models are specialists at very different prices. The best AI no longer comes out of a single lab, it’s a mixture of models.