The Best Model Routing is Task Specific最佳模型路由因任务而异
Model routing is so hot right now. In the last few 1.5 months, OpenRouter shipped 模型路由现在非常热门。在过去的一个半月里，OpenRouter 发布了, a compound model that fans your prompt out to a panel of frontier models and synthesizes one answer; Cognition shipped ，这是一个复合模型，将你的提示分发到一组前沿模型并综合出一个答案；Cognition 发布了, a harness that runs a frontier model and a cheap "sidekick" in parallel and switches between them with classifiers; Factory shipped a ，这是一个工具，并行运行一个前沿模型和一个廉价的“副手”，并通过分类器在它们之间切换；Factory 发布了一个 that holds ~99% of Claude Opus 4.7's pass rate on Terminal-Bench 2 at 20% lower cost; even Vercel now ships ，它在 Terminal-Bench 2 上保持了 Claude Opus 4.7 约 99% 的通过率，同时成本降低 20%；甚至 Vercel 现在也发布了 in its AI gateway. Recently 在其 AI 网关中。最近 published an article showing how they were able to tune the harness and model mixture to create a spreadsheet agent with much higher accuracy and lower tokens compared to Claude for Excel. 发表了一篇文章，展示了他们如何调整框架和模型组合，创建了一个与 Claude for Excel 相比准确率更高、token 更少的电子表格代理。
The pitch converges on a common pattern: nobody wants to pay frontier prices for every token.这个推广归结为一个常见模式：没有人愿意为每个 token 支付前沿价格。
I think the trend is real. To add on to this, I do think that the best routing is deeply task-specific, and the more narrowly you focus on a single workflow, the more alpha there is to exploit in terms of both accuracy and cost. You don't need frontier intelligence for every task — but figuring out 我认为这个趋势是真实的。在此基础上，我确实认为最佳路由是高度任务特定的，并且你越专注于单一工作流，在准确性和成本方面就越有可挖掘的阿尔法。你不需要为每个任务都使用前沿智能——但弄清楚which哪个 model clears the bar for 模型达到的标准which task, subject to your cost/latency constraints, is a problem only someone obsessed with that task can solve.任务，受限于你的成本/延迟约束，是一个只有痴迷于该任务的人才能解决的问题。
Model intelligence is jagged, and what counts as "good enough" (and what you'd pay for the last few points of accuracy) depends entirely on the task. A router that doesn't know your task is guessing at both.模型智能是不均衡的，什么是“足够好”（以及你愿意为最后几个百分点的准确率支付多少）完全取决于任务。一个不了解你任务的路由器是在两者上猜测。
The cost story, and why a generic router falls short成本故事，以及为什么通用路由器力不从心
Frontier models are too expensive to run on every token at scale — a model like Fable can burn $600 an hour of inference at volume, and most work doesn't need that horsepower. The curve helps: near the top, cost drops sharply while quality barely moves, because the first work to leave the frontier model is the work a cheaper one handles just as well. Factory runs on that flat stretch and pulls out 20-25% of the cost while pass rate holds; Cognition's Devin Fusion, which declares "the age of using one model for all of your work is coming to an end," holds Fable 5-level performance at 35% lower cost, with 88% of its users' merged PRs now coming straight from the router.前沿模型大规模运行时每个 token 都太贵了——像 Fable 这样的模型每小时推理成本可达 600 美元，而大多数工作不需要那么强的算力。曲线有帮助：在顶部附近，成本急剧下降而质量几乎不变，因为最先离开前沿模型的工作是那些更便宜的模型同样能处理好的。Factory 就运行在这个平坦区域，在保持通过率的同时降低了 20-25% 的成本；Cognition 的 Devin Fusion 宣称“对所有工作使用单一模型的时代即将结束”，它以 35% 更低的成本保持了 Fable 5 级别的性能，其 88% 的用户合并的 PR 现在直接来自路由器。
OpenRouter is genuinely great at this, and I said as much when Fusion launched. But Fusion is an ensemble built to maximize quality on hard, open-ended questions where you'll pay for several completions because being wrong is expensive. Task-specific routing answers a different question: given OpenRouter 在这方面确实很出色，我在 Fusion 发布时也是这么说的。但 Fusion 是一个集成模型，旨在最大化解决困难、开放式问题的质量，在这些问题上你会为多个完成支付，因为犯错代价高昂。任务特定路由回答的是不同的问题：给定this specific input这个特定输入, what's the cheapest path that maximizes ，什么是最便宜的路径，能够最大化this task's这个任务的 quality bar? A generic gateway can route across providers and fall back when an endpoint degrades, but it can't know that page 3 of your scanned loan file is a dense table that needs a specialized vision model while pages 1-2 are plain text you should pull with cheap direct extraction. It has no model of your inputs, because it isn't in the business of any one task.质量标准？一个通用网关可以在提供商之间路由并在端点降级时回退，但它无法知道你的扫描贷款文件的第 3 页是一个需要专门视觉模型的密集表格，而第 1-2 页是纯文本，你应该用便宜的直提取来获取。它没有你的输入模型，因为它不从事任何单一任务。
The teams routing well go one workflow deep路由做得很好的团队深耕一个工作流
The coding agents are just the loudest example. Look at the teams shipping serious vertical AI products and you see the same pattern: each routes inside a single workflow, and each has gone deep enough on its task to know which model clears the bar.编码代理只是最引人注目的例子。看看那些发布严肃垂直 AI 产品的团队，你会发现同样的模式：每个团队都在一个工作流内部进行路由，并且每个团队都对其任务足够深入，知道哪个模型符合标准。
Harvey, in legal, is the cleanest case. Their 在法律领域的 Harvey 是最清晰的例子。他们的 breaks a request into sub-tasks, picks a model for each, and synthesizes — "no single model is the best at everything," so they route high-volume Vault work to faster models like Sonnet 4.6 and Gemini 3 Flash where latency matters and quality is good enough, and they're 将请求分解为子任务，为每个子任务选择模型，然后综合——“没有单一模型在所有方面都是最好的”，所以他们将大量 Vault 工作路由到更快的模型，如 Sonnet 4.6 和 Gemini 3 Flash，在这些模型中延迟很重要且质量已经足够好，而且他们正在 to hit near-frontier legal performance for less.以更低的成本达到接近前沿的法律性能。
Decagon does the same in support, and Jesse's framing is the sharpest version of the argument I've read: when a use case is new you want the smartest general model, but "once the use case is fully built out... general intelligence is overhead," and you want "the smallest, fastest model fine-tuned to do your specific thing extremely well." Decagon now runs Decagon 在支持领域也这样做，Jesse 的框架是我读过的最尖锐的论点：当用例是新的时，你想要最聪明的通用模型，但“一旦用例完全构建出来……通用智能就是开销”，而你想要“最小、最快的模型，经过微调以极其擅长你的特定事物。”Decagon 现在运行 on fine-tuned open models.在微调后的开放模型上。
Neither is reaching for a single model and hoping. Each is hillclimbing one task with a mix of models it understands deeply, and that understanding is the thing a generic router can't buy. It's the most concrete version of Sarah Guo's 两者都不是指望一个单一模型。每个团队都在用他们深入了解的模型组合来攀登一个任务，而这种理解是通用路由器无法买到的。这是 Sarah Guo 的“不可训练”最具体的版本: the difficulty model and the eval that grades it are private ground truth, earned from real volume, that a smarter frontier model next quarter doesn't hand you. That's where the alpha is, and it compounds.：难度模型和对其进行评分的评估是私有的事实依据，是从真实数据量中获得的，而下一季度更智能的前沿模型不会给你。这就是阿尔法所在之处，而且它不断积累。
Document AI: the gap is big, and it stays big文档人工智能：差距很大，而且仍然很大
A lot of people assumed that frontier models would eat document parsing entirely. It didn't. On 很多人以为前沿模型会彻底取代文档解析。但事实并非如此。在, the ，一个, frontier VLMs are great at visual understanding and terrible at layout — GPT-5-mini and Haiku score below 10% on visual grounding while specialized parsers land at 55-80%, and no single method tops all five dimensions. Gemini gains ~5 points going from minimal to high thinking at 4x the cost, and you burn vision tokens on text-heavy pages that never needed a VLM.，前沿视觉语言模型在视觉理解方面表现出色，但在布局方面表现糟糕——GPT-5-mini 和 Haiku 在视觉基础方面得分低于 10%，而专门的解析器得分在 55-80% 之间，没有任何单一方法在所有五个维度上领先。Gemini 从最小思考到高度思考，成本增加 4 倍，性能提升约 5 分，而且你会在从未需要视觉语言模型的文本密集型页面上浪费视觉 token。
The right architecture for document OCR involves a complex "router" (or more accurately, a complex engine) with many pieces operating in conjunction that are carefully tuned for the specific data domain and task distribution. 文档 OCR 的正确架构涉及一个复杂的“路由器”（或者更准确地说，一个复杂的引擎），其中有许多部件协同运作，它们针对特定的数据领域和任务分布进行了精心调优。 contains this under the hood: an agentic harness that auto-routes each page between frontier and specialized models with a self-improving document-complexity model, custom document engines that cut vision tokens 50-90% where text is all there is, specialized VLMs post-trained for tables and charts, and an agentic judge that validates the output. On the cost-accuracy plane it sits on the frontier — our agentic mode leads at 84.9% and wins 4 of 5 dimensions, our cost-effective mode lands near the top at roughly a third of a cent per page. 内部包含以下内容：一个自主框架，通过自改进的文档复杂度模型在每个页面在前沿模型和专门模型之间自动路由；自定义文档引擎，在只有文本的地方将视觉 token 减少 50-90%；针对表格和图进行了后训练的专门视觉语言模型；以及一个验证输出的自主评判器。在成本-准确率平面上，它位于前沿——我们的自主模式以 84.9% 领先，赢得 5 个维度中的 4 个；我们的成本效益模式接近顶部，每页大约 0.3 美分。
There will always be a massive gap on the pareto curve for document understanding relative to the visual capabilities of frontier models. We have designed LlamaParse to always be the best at exploiting that gap. 在帕累托曲线上，文档理解相对于前沿模型的视觉能力将始终存在巨大差距。我们设计 LlamaParse 始终最擅长利用这一差距。
Two layers, different jobs两层架构，不同职责
The two layers settle into different roles. Generic gateways like OpenRouter own broad, provider-level routing and ensembling (which models are up, which are cheapest this minute, when to convene a panel for a hard general question). The task-specific layer is where the excess returns live, and they accrue to whoever goes deepest on a workflow: software engineering to Factory and Cognition, legal to Harvey, support to Decagon. For documents, we intend it to be us. If you're routing frontier and open-source VLMs to squeeze every point of document accuracy out of every cent, 这两层承担不同的角色。像 OpenRouter 这样的通用网关拥有广泛的、提供商级别的路由和集成（哪些模型在线，哪些是当前最便宜的，何时召集一组模型处理困难的通用问题）。任务特定层则是超额回报所在，它们归属于那些在工作流上做得最深的人：软件工程归 Factory 和 Cognition，法律归 Harvey，支持归 Decagon。对于文档，我们打算让它属于我们。如果你正在路由前沿和开源视觉语言模型，以从每一分钱中榨取文档准确率的每一个百分点，.
想发布自己的文章？想发布自己的文章？
升级为 Premium升级为 Premium