要选择 AI 模型，先明确任务，再从实时使用数据和基准测试结果中筛选候选模型，对比各家供应商的价格和延迟，最后用你自己的提示词对入围模型进行测试。评判标准应看完成每项任务的总成本，而不是每个 token 的成本，并且要预期答案会随着新模型的发布而变化。
我们不会指定某一个“最佳模型”。我们写下的任何名字都会在一个月内过时，而且正确的模型取决于你在构建什么，以及你愿意为正确结果付出多少成本。
本文介绍了我们用来回答这个问题的框架，以及如何在不离开编辑器的情况下运行它。我们的 MCP 服务器能将你的助手连接到实时使用排名、第三方基准测试、各家供应商定价，以及向候选模型发送测试提示词的方式。
太长不看版
- “最佳”意味着你的任务、你完成每项任务的总成本，以及你的延迟预算。排行榜名次并不在这三者之列。
- 用基准测试来构建候选名单，用你自己的提示词来选出赢家。Ori Eval 可以为你编写并运行这套对比。
- 通过 MCP 从你的编辑器中查询实时排名和价格，然后用 get-generation 衡量每次测试调用的成本。
- 如果没有模型明显胜出，就用 openrouter/auto-beta 按请求路由，而不是只选一个。
为什么不存在单一的“最佳 AI 模型”
不存在单一的“最佳 AI 模型”，只有针对特定任务、预算和时点的最佳模型。
不同任务需要不同的能力侧重。摘要和编程对模型提出了不同的要求。信息抽取更需要每次调用都返回有效的 JSON，而不是优美的文笔。聊天功能取决于第一个 token 到达的速度，这与完整回答的质量是两回事。一个在编程基准测试中排名第一的模型，在处理长文档时可能表现很差，而且对于常规抽取任务来说成本过高。
一个更有用的问题应该包含具体任务。与其问“什么是最好的 AI 模型”，不如问“什么模型最适合从扫描发票中抽取明细项”，或者“最适合审查 TypeScript 拉取请求”，或者“最适合总结 90 分钟通话记录”。写出你自己的版本的问题，然后根据当前数据而不是过时的排名来回答它。
我们的流量数据显示，答案因任务不同而差异巨大。我们将请求样本划分为 29 种任务类型，并公布其市场份额。仅编码一项就占了其中九种，涵盖代码生成、调试、代码审查、仓库扫描、SQL 工作和 DevOps 配置。这九种任务并没有一个共同的领先者。在截至 2026 年 7 月 25 日的七天窗口期内，一个模型在八种任务中领先，而另一个不同的模型则在代码审查和安全性方面领先。“最适合编码的模型”这个问题即使在编码领域内部也过于宽泛。
基准测试是过滤器，不是答案
基准测试有助于将数百个选项缩小到几个你可以真正测试的候选者。我们将来自 Artificial Analysis 和 Design Arena 的第三方评分与我们自己的使用数据一同展示。
排行榜无法替你做出最终选择。分数存在噪声，热门基准测试容易吸引针对性的调优，而且它们都没有运行过你的提示词。用排行榜来缩小候选范围，用你自己的测试来做决定。
不同的任务需要不同的优势。编码需要推理质量和可靠的工具调用。摘要生成需要大的上下文窗口和较低的输入定价。信息抽取需要始终如一地遵循模式，而非流畅度。聊天需要低延迟。视觉任务需要模型本身就能接受图像，这在质量考量之前就已经缩小了候选范围。
没有哪个模型能在每个类别中都领先。为所有事情只选一个模型，会产生一个昂贵的默认选择，它在演示中表现良好，但在你实际运行的工作中表现不佳。
设置 OpenRouter MCP 服务器
下面的每一步都通过 MCP 服务器运行，所以请先连接它。
OpenRouter MCP 服务器由我们托管，因此无需在本地安装任何东西。任何 MCP 客户端都可以连接。下面的设置涵盖 Claude Code、Cursor 和 Codex CLI，文档中还涵盖了 OpenCode 和 Claude Desktop。你只需连接一次，你的助手就能拉取实时模型、定价、积分、排名、基准测试和文档，并发送测试提示词，而无需离开编辑器。在你选择模型时使用它。当你正式上线时，照常调用 API 即可。
Claude Code：
claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp
claude mcp openrouter你也可以在会话内通过运行 /mcp、选择 openrouter 并点击 Authenticate 来进行身份验证。
Cursor：请将此内容添加到 ~/.cursor/mcp.json，然后通过 cursor-agent mcp list 进行验证。
{
"mcpServers": {
"openrouter": { "url": "https://mcp.openrouter.ai/mcp" }
}
}Codex CLI：
codex mcp add openrouter --url https://mcp.openrouter.ai/mcp
codex mcp openrouter身份验证只需一个浏览器步骤，并且在三个编辑器中都以相同方式工作。在 Cursor 中，它会在你的首次请求时运行，而不是通过登录命令触发。未认证的请求会返回 401 错误，从而启动我们的 OAuth 流程，批准界面会在你同意之前明确说明你所同意的事项。
我们会生成一个标记为 OpenRouter MCP：<应用名称> 的密钥，该密钥限定于该客户端，有效期为七天，并带有 10 美元的额度限制，你可以在该界面上更改此限制（MCP 公告）。该密钥默认短期有效且有上限，你可以随时断开连接，并且可以从你的密钥管理面板中撤销它。
该流程会重定向到 localhost，这对于 Claude Code 或 Cursor 这类桌面客户端来说是正常的，但这意味着我们无法验证哪个本地应用接收了该密钥。只有当你刚刚亲自发起连接时，才应批准此操作。
你将使用的工具
大多数工具都是针对实时数据的只读查询。例外情况是 send-message、generate-image、transcribe-audio 和 generate-speech，这些工具会发起计费的推理调用，以及 send-feedback，该工具会对你自己的某个生成结果写入反馈（MCP 文档）。
| 工具 | 返回内容 |
|---|---|
| list-task-classifications | 按任务类型划分的流量份额，以及各类别中的领先模型 |
| list-benchmarks | 来自 Artificial Analysis 和 Design Arena 的第三方评分，可按任务类型筛选 |
| list-daily-model-rankings | 排名前 50 的模型的每日 token 总量，用于了解趋势而非任务适配度 |
| list-models / get-model | 搜索实时目录；查看单个模型的完整详情 |
| list-model-endpoints | 提供某模型服务的每个供应商，包含价格、延迟、吞吐量和数据政策 |
| search-docs | 从我们当前的文档中提取答案，直接在工具内呈现 |
| send-message（计费） | 在你的提示词上运行候选模型。支持 :online、:nitro、:floor、:free |
| get-generation | 单次调用的精确成本、token 数量、供应商和延迟 |
助手会调用 list-task-classifications 获取 code:general_impl 标签，返回领先模型及其使用量和 token 份额，然后继续查看各供应商的定价。整个过程无需浏览器参与。
选择模型的六步框架
请按顺序执行这些步骤。第 2 步到第 5 步分别对应你的助手可以针对实时数据发起的一次特定调用。第 1 步和第 6 步由你自行判断：你先定义自己需要什么，然后决定最终交付什么。
第 1 步：以最终交付的形式定义任务
从任务本身出发，而不是从模型名称出发。写下输入、你期望的输出、什么算作合格、你的延迟目标，以及在成本与质量冲突时你倾向于哪一方。
最后一项会影响后续所有步骤。面向客户展示的摘要可以支撑更高的价格。对一百万条记录执行的夜间抽取任务则应该选择更低的价格，即使以一定质量损失为代价，因为数据量主导了账单。请明确你正在构建的是哪一种。
第 2 步：从实时数据中筛选候选名单
候选名单来自两个问题：人们正在用什么模型来完成这项任务，以及哪些模型在这项任务上得分高？
针对第一个问题，调用 list-task-classifications。它会返回我们过去七天窗口内的 29 个任务标签，每个标签都带有其使用份额以及服务该任务的模型排名列表，这些数据来自真实流量。针对第二个问题，调用 list-benchmarks，并将 task_type 设置为 coding、intelligence 或 agentic，它会返回 Artificial Analysis 和 Design Arena 的评分以及定价。这三个类别刻意比 29 个流量标签更粗略，这两个调用应当配合使用。基准筛选会在宽泛类别中剔除低分模型，而流量标签随后会显示人们在你所针对的具体细分任务中使用哪些模型。
list-daily-model-rankings 对观察趋势很有用。默认情况下，它返回前 50 个模型的每日 token 总量，外加每天一行聚合的“其他”类别。你可以按用例类别（如编程或角色扮演）、按模态或按工具调用活动来缩小范围，但类别切片来自按周聚合的采样数据集，因此请将这些总量视为估算值。它告诉你什么在增长，而不是什么在你的任务上表现好。同样的视图也可以在 openrouter.ai/rankings 上查看。
第 3 步：比较成本、提供商和延迟
对于每个入围模型，调用 list-model-endpoints。你会看到提供该模型的每一家供应商，以及其价格、上下文长度、过去三十分钟的吞吐量和延迟、正常运行时间、量化方式和支持的参数。同一模型在不同供应商之间可能在价格、速度和可靠性上存在差异，最好在这里就发现这些差异，而不是等到生产环境中才遇到。
当你需要与他人分享时，compare 页面会在浏览器中展示同样的数据。
第 4 步：用自己的数据测试入围模型
基准测试给出了入围名单，而你自己的提示词做出最终选择。
针对你实际的工作内容运行 send-message：真实的工单、真实的文档、真实的模式，包括那些通常会导致失败的内容。一个干净的评测集会让每个模型看起来都很能干，这正是它无法区分模型优劣的原因。
测试时有三种变体很有帮助。:floor 路由到提供该模型的最便宜供应商，这样可以降低评测成本。:nitro 路由到最快的供应商，这是你检查延迟预算的方式。:online 在任务需要当前上下文时添加网络搜索。
留意 :online 的成本。用三种方式运行同一个简单提示词，:floor 花费了 $0.0000030，:nitro 花费了 $0.0000024，而 :online 花费了 $0.0052576。这大约是单个提示词普通调用的两千倍，所以要谨慎使用，而不是一直保持开启。
使用 Ori Eval 让对比可重复
临时测试调用只能回答一次问题。Ori Eval 让这一步变得可重复。你用通俗的语言提出一个问题，例如“对我的客服智能体来说最好的模型是什么”，然后你的编码智能体会在你的项目中找到测试材料，将评测写成 *.eval.ts 文件，运行候选模型，并推荐一个模型，附上分数、时间和成本。要从编辑器中启动它，请给你的编码智能体以下指令：
run curl -fsSL https://openrouter.ai/skills/spawn-ori-eval and follow the instructions in its output to get startedOri 会为一次运行解析出一个测试框架和一个模型，并在该次运行中对每个测试都沿用这一组合，因此同一批评测文件跑两次会使用相同的配置。它通过 OpenRouter 发送请求，所以一次对比可以涵盖来自多家提供商的模型。上述指令是在临时目录中执行的。如果你改为手动执行这些步骤，评测文件会作为普通代码保留在你的项目中，当新模型发布时可以重新运行，用 `--baseline` 与之前的运行结果对比，还可以按计划在 CI 中定时运行。
第 5 步：衡量每个完成任务（completed task）的成本
每次测试调用之后，把生成 ID 传给 get-generation。你会得到精确成本、提示词与补全的 token 数量、提供服务的提供商以及延迟。对一组有代表性的提示词取平均值，再按任务成功频率进行调整，然后把该数字记录到决策文档中。
有两点需要注意。生成记录在调用返回的瞬间并不能立即查询，因此紧接着的查询会返回 404，几秒后才能查到。请重试，而不要把首次 404 当作失败。另外，补全响应本身已经带有 usage.cost，所以如果你只需要调用的价格，就无需额外往返。当你还需要提供商、延迟或原生 token 数量时，再使用 get-generation。
第 6 步：做决定，或按请求路由
如果某个模型在你运行的全部任务中明显胜出，那就用它。
如果结果接近、你的流量混合了多种任务类型，或者你不想每次有更好的模型发布时都重新评估决策，那就用模型字符串 openrouter/auto-beta 指向 Auto Router。旧的 openrouter/auto 仍然可以解析，但文档已标注为弃用，所以请使用当前版本。
路由器并非随机选择。它会把每个请求归类到大约 30 种细粒度任务类型中，按过去七天窗口内的真实消费份额对候选模型排序，应用你的成本与质量偏好，并带故障转移地进行路由（见 Auto Router 文档）。这就是上面那套框架，按请求运行，使用的是你在第 2 步查询过的同一套任务分类数据。
要按每个任务的成本来思考，而不是按每个 token 的成本。
比较模型经济性时，正确的单位是“每任务成本”，而不是“每 token 成本”。
人们之所以按每 token 价格比较，是因为这样容易对比，而且过去“全成本”很难衡量。如今 get-generation 每次调用都能返回真实数字，这一困难已不复存在。
单价低的模型，一旦出现重试、生成的补全内容超出你的 token 预算，或者需要背后更强的模型来兜底其错误，就不再便宜。一个更贵的模型如果首次尝试就能完成任务，总成本往往反而更低。
2026 年一项针对推理模型定价的研究对此进行了量化。在 32% 的模型两两对比中，标价更低的模型反而产生了更高的总成本，极端情况下反转幅度高达 28 倍（Chen 等人，《价格反转现象》）。作者将其归因于不同模型在“思考”上消耗 token 的方式差异巨大：同一查询下，一个模型可能比另一个多消耗 900%，而同一查询的多次运行之间差异最高可达 9.7 倍。标价完全反映不出这些差异。
cost per task = ((input tokens × input price) + (output tokens × output price)) × expected attempts大多数对比都忽略了“预期尝试次数”，而这一项往往决定了最终结果。
以下是用真实价格进行的计算，核对日期为 2026 年 7 月 27 日。GPT-5.4 mini 标价为每百万输入 token 0.75 美元、每百万输出 token 4.50 美元。Claude Sonnet 5 标价为每百万输入 token 2.00 美元、每百万输出 token 10.00 美元，大约是前者的 2.4 倍。以一个 2,000 输入 token、800 输出 token 的任务为例。如果 Sonnet 5 首次尝试成功率为 95%，那么每完成 1,000 个任务的成本约为 12.63 美元。要让 mini 达到同样的成本水平，其首次尝试成功率需要达到 40%。低于 40% 时，每 token 便宜 2.4 倍的模型，反而成了完成这项工作更昂贵的方式。
当你向他人汇报这一结果时，请使用“每完成 1,000 个任务的成本”。token 最便宜的模型，往往并不是完成工作最便宜的方式。
下图绘制的是整条曲线，而非单个数据点。曲线才是更有保留价值的东西，因为盈亏平衡点会随着你所对比的两个候选模型之间的价格差距而变化。价格差距越大，便宜的模型在落败之前所能承受的成功率下限就越低。
同一个示例，不再只针对单一成功率，而是绘制了所有成功率下的表现。Sonnet 5 固定在 95% 作为参考，而 mini 的成功率则随之变化。标价截至 2026 年 7 月 27 日，任务为 2,000 个输入 token 和 800 个输出 token，被扫描的是成功率这一变量，而非我们实测的任何指标。
逐任务来看，该优化什么
这是一个起点，而非排名。每一行告诉你该优化什么、该调用哪个接口，而实时数据会给出具体名称。我们不公布赢家，因为任何一份赢家名单在下一次发布时都会过时。
| 任务 | 优化目标 | 如何筛选 |
|---|---|---|
| 编程 | 推理质量、工具调用可靠性，然后是延迟 | 使用 task_type=coding 的 list-benchmarks，并与 list-task-classifications 中的 code: 标签交叉核对 |
| 摘要与长上下文 | 上下文窗口和输入价格，这两者主导账单 | 使用 list-model-endpoints 查看上下文长度和提示词定价 |
| 结构化抽取 | 每次调用都要符合 schema 并返回有效 JSON | 使用 list-model-endpoints 查看支持的参数，然后针对你的真实 schema 发送 send-message |
| 聊天与助手 | 延迟优先，然后是质量 | 使用 list-model-endpoints 查看服务商延迟和吞吐量；用 :nitro 进行测试 |
| 视觉与多模态 | 图像输入支持，然后是领域适配度 | 按输入模态筛选 list-models，然后用自己的图像测试 |
| 智能体工具调用 | 多步骤中的指令遵循能力 | 使用 task_type=agentic 的 list-benchmarks，然后进行多步测试 |
编程：先明确你说的编程是哪一种。我们的任务标签将代码生成与调试、审查、前端和仓库扫描区分开来，而各领域的领先者并不相同。用你积压工作中的真实工单来测试候选模型，而不是用玩具问题。
摘要：把输入价格和上下文长度放在一起看，因为只看其中任何一项都会误导你。一个上下文窗口大、价格更低的模型，往往胜过输入定价高但更强的模型。
抽取：一个每次都能返回有效 JSON 的小模型，胜过一天会破坏两次字段的更强模型。要测试困难输入：缺失字段、模糊记录和格式错误的源文本。
视觉能力：多模态质量在不同领域差异很大，所以要对图像输入做筛选，然后用自己的截图来测试。一套现成的演示数据集会让每个候选模型看起来都很优秀。
无论哪种情况，都要实际运行查询、查看本周的数据，然后从中挑选。
为什么要通过 OpenRouter 跑这个流程
你完全不必绑定某一个模型。
一次集成就能获得跨提供商的完整模型目录。下个月发布更好的模型时，你只需改一个模型字符串，而不用再集成另一个 SDK、重新测试集成路径。模型选择与执行在同一平台上完成，借助 MCP，选择数据可以直接出现在你日常使用的编辑器里。你还能获得提供商冗余和自动回退，以及精确到单次请求的成本数据，足以让上面的“每任务成本”计算做到准确而非估算。
如果你确定自己只想要某一家提供的某一个模型，而且这个决定不会改变，那么直接对接提供商也是合理的选择。但新模型发布非常频繁，所以请认真掂量一下你的确定程度。
选择模型时的常见错误
大多数糟糕的模型决策，都源于衡量了错误的对象，或者太晚才衡量正确的对象。以下是我们最常见的五种。
把排行榜名次当成生产决策依据：在公开排行榜上排名靠前，只能让你进入候选名单，不代表可以上生产流量。先用你的提示词跑一遍模型再说。
只看每 token 单价：低价单位掩盖了重试、超长输出和回退的成本。在 get-generation 告诉你每完成一个任务的成本之前，你根本不知道这个模型到底花多少钱。
忽略上下文形态：既要检查上下文长度，也要检查在该长度下你要付多少钱。长上下文模型能力强，但也贵。用能完成任务的最小可靠上下文策略，在考虑更大窗口之前，先考虑检索方案。
只选一次就不再回头：一月份最适合你任务的模型，到七月份未必还是。我们在截至 2026 年 7 月 27 日的三十天内新增了约 40 个模型，所以在你所在类别有重大发布后，请重新跑一遍这六个步骤；在仓库里保留一个 Ori 评测并按计划定期重跑，或者干脆把这个问题交给 Auto Router。
不要把延迟和可靠性问题留到上线时才处理：先查看 list-model-endpoints 中的延迟、吞吐量和可用性数据，然后按照生产环境的方式实际调用该端点。上线后才发现有问题的服务商，本是可以避免的事故。
先按任务选型，再持续更新这个选择
正确的问题不是哪个模型最好，而是哪个模型最适合你正在构建的东西、符合你的预算、并且适合当下这个时间点。
只要任务定义清晰、有真实数据、还有一组真实提示词，你一个下午就能回答这个问题；而当情况发生变化时，几分钟内就能重新回答一遍。
- “最好”是随任务和时间变化的。评判标准应该是每完成一个任务的成本以及延迟，而不是排名。
- 基准测试帮你圈定候选名单，你自己的数据来选出赢家。send-message 和 get-generation 就能定案。
- 只要 MCP 服务器连接好，整个流程都可以在你的编辑器里跑完。
添加 OpenRouter MCP 服务器，然后让助手为你本周要交付的任务筛选候选模型并给出价格。如果你拿不定主意，或者任务类型比较杂，就用 Auto Router（openrouter/auto-beta），让它按每个请求自动选择。
常见问题
如何选择最好的 AI 模型？
先精确定义任务，再从实时使用数据和基准测试中筛选候选，对比每个模型各家服务商的报价和延迟，最后用你自己的提示词测试入围者。评判赢家的标准是每完成一个任务的成本，而不是每 token 的成本。在 OpenRouter 上，你可以通过 MCP 服务器在编辑器里完成以上所有步骤。
最好的编程 AI 模型是什么？
没有固定答案，而且编程也不是单一任务。我们把编程流量划分为九个独立标签，涵盖代码生成、调试、文件 I/O、Shell 执行、代码审查与安全、前端和 UI、仓库扫描、SQL 和数据库工作、以及 DevOps 配置，而领先模型在每个标签下并不相同。先用 task_type=coding 的 list-benchmarks 筛选候选，再用 list-task-classifications 对照真实流量交叉验证，最后拿你自己 backlog 里的真实任务来测试入围者。
什么是 OpenRouter MCP 服务器？
这是我们托管的一个远程 MCP 服务器，无需在本地安装任何东西。连接后，你的 AI 助手可以查询实时模型数据、各服务商定价、使用量排名、第三方基准测试和文档，并向候选模型发送测试消息，全程无需离开你的编辑器。任何 MCP 客户端都可以连接。我们提供了 Claude Code、Codex CLI、OpenCode、Cursor CLI 和 Claude Desktop 的设置文档。
如何在 Claude Code 或 Cursor 中设置 OpenRouter MCP 服务器？
在 Claude Code 中，运行 `claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp`，然后运行 `claude mcp login openrouter`。在 Cursor 中，将服务器 URL 添加到 `~/.cursor/mcp.json`，并使用 `cursor-agent mcp list` 进行验证。身份验证只需一个浏览器步骤，之后我们会生成一个专用的 API 密钥，有效期为七天，消费上限为 10 美元。
每 token 成本和每任务成本有什么区别？
每 token 成本是输入和输出的标价单价。每任务成本是获得一个成功结果所需的费用，其中包括重试、更长的补全，以及回退到更强模型的情况。一个 token 单价更低的模型，其每个已完成任务的总成本可能反而更高。`get-generation` 会返回每次调用的实际成本和 token 数量，这样你就可以直接测量，而不是估算。
如何比较 AI 模型？
同时从三个维度进行比较：在你的任务上的质量、每个已完成任务的成本，以及延迟。使用第三方基准测试来建立候选名单，用 `list-model-endpoints` 来比较提供每个模型的不同服务商之间的价格、延迟和吞吐量，再用你自己的提示词来做最终选择。并排比较的网页视图位于 openrouter.ai/compare。
我应该多久重新评估一次模型选择？
在你任务类别中有任何重大版本发布后，或者当成本、延迟或失败率出现波动时，就重新运行这套评估框架。在截至 2026 年 7 月 27 日的三十天内，我们新增了大约 40 个模型，所以请把模型选择当作一项运营决策，而不是一次性的设置步骤。如果你不想跟踪这个节奏，也可以改用 Auto Router 按请求进行路由。
如何让模型评估变得可重复？
使用 Ori Eval。你用通俗语言提出一个问题，你的编程智能体会在项目中找到测试材料，将评测编写为 `*.eval.ts` 文件，通过 OpenRouter 运行候选模型，并推荐一个模型，同时附上其分数、耗时和成本。评测文件就是普通代码，因此当新模型发布时你可以重新运行它们，使用 `--baseline` 比较运行结果，并按计划在 CI 中运行它们。
我应该使用一个模型，还是在多个模型之间路由？
当任务范围狭窄、提示词稳定，且有一个候选模型以较大优势通过你的评测时，使用单一模型。当请求的复杂度各不相同、可靠性比模型一致性更重要，或者你不想在每个发布周期都重新审视这个决策时，则进行路由。Auto Router 会将每个请求分类到大约 30 种任务类型中，并根据社区在过去七天窗口内的支出份额，为每个请求单独选择模型。
参考资料
本页面的每项声明均已对照以下来源进行核实，包括实时 API 调用。
- OpenRouter MCP 服务器文档。涵盖托管服务器、各编辑器设置、完整工具列表，以及哪些工具需要计费。
- OpenRouter MCP 服务器公告。涵盖 OAuth 流程、七天密钥有效期和 10 美元支出上限，以及模型后缀变体。
- 模型文档。涵盖模型元数据字段，包括定价、上下文长度、模态和支持的参数。
- 模型变体文档。涵盖 `:online`、`:nitro` 和 `:free` 后缀，以及每个后缀对路由方式的改变。`:floor` 快捷方式在提供商选择部分有文档说明。
- Ori Eval 文档。涵盖评测文件格式、candidateModels、setupJudge、`--baseline`，以及在 CI 中运行评测。
- Auto Router 文档。涵盖将每个请求分类到大约 30 种任务类型、按过去七天支出份额排序，以及 `openrouter/auto-beta` 模型字符串。
- 模型回退文档。涵盖提供商冗余和自动回退行为。
- API 参考。涵盖生产环境 API，供你选定模型后使用，包括如何在请求后查询成本和统计数据。
- 模型目录。实时目录，涵盖 70 多家提供商的 400 多个模型。
- 排行榜。按模型统计的每日 token 总量，以及任务分类的市场份额。
- 对比。在基准测试、价格、上下文和延迟方面进行并排模型对比。
- Artificial Analysis 与 Design Arena。这两个第三方基准来源出现在 list-benchmarks 中。
- 任务分类市场份额。list-task-classifications 背后的端点，返回 29 个任务标签及其使用份额，以及每个标签下的领先模型。
- 基准列表。list-benchmarks 背后的端点，可按 task_type 进行筛选。
- 获取单次生成请求的请求与使用元数据。单次调用的精确成本、token 数量、提供商和延迟。
- Chen、Zhang、He、Stoica、Zaharia 和 Zou 所著《价格反转现象：当更便宜的推理模型反而更贵》。对模型配对中标注价格与总成本进行的独立测量。arXiv，2026 年 3 月，2026 年 5 月修订。
To choose an AI model, define the task, shortlist candidates from live usage and benchmark data, compare price and latency across providers, then test the finalists on your own prompts. Judge them on cost per completed task rather than cost per token, and expect the answer to change as new models are released.
We won’t name a single best model. Any name we printed would be out of date within a month, and the right model depends on what you’re building and what you’re willing to pay for correct results.
This article describes the framework we use to answer the question, and how to run it without leaving your editor. Our MCP server connects your assistant to live usage rankings, third-party benchmarks, per-provider pricing, and a way to send test prompts to candidate models.
Tl;dr
- Best means your task, your cost per completed task, and your latency budget. A leaderboard rank isn’t one of the three.
- Use benchmarks to build the shortlist and your own prompts to pick the winner. Ori Eval can write and run that comparison for you.
- Query live rankings and prices from your editor over MCP, then measure what each test call costs with
get-generation. - If no model wins clearly, route per request with
openrouter/auto-betainstead of picking one.
Why there is no single best AI model
There’s no single best AI model, only the best model for a given task, budget, and moment.
Different tasks require different strengths. Summarization and coding place different demands on a model. Extraction needs valid JSON on every call more than it needs good prose. A chat feature depends on how quickly the first token arrives, which is separate from the quality of the full answer. A model that ranks first on a coding benchmark can still perform poorly on long documents and cost too much for routine extraction.
A more useful question includes the specific job. Instead of “what is the best AI model,” ask “what is the best model for extracting line items from scanned invoices,” or “for reviewing a TypeScript pull request,” or “for summarizing a 90-minute call transcript.” Write your own version of that question, then answer it from current data rather than from an old ranking.
Our traffic shows how much the answer varies by task. We classify a sample of requests into 29 task types and publish the market share. Coding alone accounts for nine of them, covering code generation, debugging, code review, repo scanning, SQL work, and DevOps config. Those nine don’t share one leader. In the seven-day window ending 25 July 2026, one model led eight of them and a different one led code review and security. “Best model for coding” is too broad a question even within coding.
Benchmarks are a filter, not an answer
Benchmarks are useful for narrowing hundreds of options down to a few candidates you can test properly. We surface third-party scores from Artificial Analysis and Design Arena alongside our own usage data.
A leaderboard can’t make the final choice for you. Scores are noisy, popular benchmarks attract tuning, and none of them ran your prompts. Use the leaderboard to shortlist and your own tests to decide.
Different tasks require different strengths. Coding needs reasoning quality and reliable tool calls. Summarization needs a large context window and low input pricing. Extraction needs consistent adherence to a schema more than fluency. Chat needs low latency. Vision needs a model that accepts images at all, which narrows the field before quality matters.
No model leads every category. Choosing one model for everything produces an expensive default that performs well in demonstrations and poorly on the work you actually run.
Set up the OpenRouter MCP server
Every step below runs through the MCP server, so connect it first.
The OpenRouter MCP server is hosted by us, so there’s nothing to install locally. Any MCP client can connect. The setup below covers Claude Code, Cursor, and the Codex CLI, and the docs also cover OpenCode and Claude Desktop. You connect once, and your assistant can then pull live models, pricing, credits, rankings, benchmarks, and docs, and send test prompts, without you leaving the editor. Use it while you’re choosing a model. When you ship, call the API as normal.
Claude Code:
claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp
claude mcp openrouterYou can also authenticate from inside a session by running /mcp, selecting openrouter, and clicking Authenticate.
Cursor: add this to ~/.cursor/mcp.json, then verify with cursor-agent mcp list.
{
"mcpServers": {
"openrouter": { "url": "https://mcp.openrouter.ai/mcp" }
}
}Codex CLI:
codex mcp add openrouter --url https://mcp.openrouter.ai/mcp
codex mcp openrouterAuthentication is one browser step and works the same way in all three editors. In Cursor it runs on your first request rather than from a login command. An unauthenticated request returns a 401 that starts our OAuth flow, and the approval screen states what you’re agreeing to before you agree to it.
We mint a key labelled OpenRouter MCP: <app name>, scoped to that client, with a seven-day expiry and a $10 credit limit you can change on that screen (MCP announcement). The key is short-lived and capped by default, you can disconnect at any time, and it’s revocable from your keys dashboard.
The flow redirects to localhost, which is normal for a desktop client like Claude Code or Cursor, but it means we can’t verify which local app receives the key. Approve it only if you started the connection yourself a moment ago.
The tools you’ll use
Most are read-only lookups against live data. The exceptions are send-message, generate-image, transcribe-audio, and generate-speech, which make billable inference calls, and send-feedback, which writes feedback on one of your own generations (MCP docs).
| Tool | What it returns |
|---|---|
list-task-classifications | Traffic share by task type, with the leading models for each |
list-benchmarks | Third-party scores from Artificial Analysis and Design Arena, filterable by task type |
list-daily-model-rankings | Daily token totals for the top 50 models, for trend rather than task fit |
list-models / get-model | Search the live catalog; full detail on one model |
list-model-endpoints | Every provider serving a model, with price, latency, throughput, and data policy |
search-docs | Answers pulled from our current docs, in-tool |
send-message (billable) | Run a candidate on your prompt. Supports :online, :nitro, :floor, :free |
get-generation | Exact cost, token counts, provider, and latency for one call |
The assistant calls list-task-classifications for the code:general_impl tag and returns the leading models with their usage and token shares, then continues to per-provider pricing. No browser is involved.
A six-step framework for choosing a model
Run these in order. Steps 2 through 5 each map to a specific call your assistant can make against live data. Steps 1 and 6 are your judgment: you define what you need and then decide what to ship.
Step 1. Define the task as you will ship it
Start with the job, not a model name. Write down the input, the output you expect, what counts as good, your latency target, and which way you lean when cost and quality conflict.
The last item affects every later step. A summary shown to customers justifies a higher price. A nightly extraction job across a million records justifies a lower price, even at some cost in quality, because volume dominates the bill. State which of those you’re building.
Step 2. Shortlist from live data
The shortlist comes from two questions: what are people using for this job, and what scores well on it?
For the first, call list-task-classifications. It returns our 29 task tags over a trailing seven-day window, each with its usage share and a ranked list of the models serving it, drawn from real traffic. For the second, call list-benchmarks with task_type set to coding, intelligence, or agentic, which returns Artificial Analysis and Design Arena scores alongside pricing. Those three categories are deliberately coarser than the 29 traffic tags, and the two calls are meant to be used together. The benchmark filter removes low-scoring models across a broad category, and the traffic tag then shows which models people use for your specific part of it.
list-daily-model-rankings is useful for trends. By default it returns daily token totals for the top 50 models overall, plus one aggregated other row per day. You can narrow it by use-case category such as programming or roleplay, by modality, or by tool-calling activity, but the category slices come from a sampled dataset aggregated weekly, so treat those totals as estimates. It tells you what’s growing, not what performs well on your job. The same view is available at openrouter.ai/rankings.
Step 3. Compare cost, providers, and latency
For each finalist, call list-model-endpoints. You get every provider serving that model with its price, context length, throughput and latency over the last thirty minutes, uptime, quantization, and supported parameters. The same model can differ between providers in price, speed, and reliability, and it’s better to find those differences here than in production.
The compare page shows the same data in a browser when you need to share it with someone.
Step 4. Test the shortlist on your own data
Benchmarks gave you the shortlist, and your own prompts make the final choice.
Run send-message against work you actually have: real tickets, real documents, real schemas, including the ones that usually cause failures. A clean evaluation set makes every model look competent, which is why it can’t separate them.
Three variants help while testing. :floor routes to the cheapest provider serving that model, which keeps evaluation costs down. :nitro routes to the fastest, which is how you check a latency budget. :online adds web search when the task needs current context.
Watch what :online costs. Running the same trivial prompt three ways, :floor came to $0.0000030 and :nitro to $0.0000024, while :online came to $0.0052576. That’s roughly two thousand times the plain call for a single prompt, so use it deliberately rather than leaving it enabled.
Make the comparison repeatable with Ori Eval
Ad-hoc test calls answer the question once. Ori Eval makes this step repeatable. You ask a question in plain words, for example “what is the best model for my support agent,” and your coding agent finds test material in your project, writes the eval as a *.eval.ts file, runs the candidate models, and recommends one with the scores, times, and costs behind it. To start it from your editor, give your coding agent this instruction:
run curl -fsSL https://openrouter.ai/skills/spawn-ori-eval and follow the instructions in its output to get startedOri resolves one harness and one model for a run and holds them for every test in that run, so two runs of the same eval files use the same configuration. It sends its requests through OpenRouter, so one comparison can include models from many providers. The instruction above works in a temporary directory. If you run the manual steps instead, the eval files stay in your project as normal code, and you can re-run them when a new model is released, compare against an earlier run with --baseline, and run them in CI on a schedule.
Step 5. Measure cost per completed task
After each test call, pass the generation ID to get-generation. You get the exact cost, the prompt and completion token counts, the provider that served it, and the latency. Average across a set of representative prompts, adjust for how often the task succeeds, and record that number in the decision doc.
Two things to note. The generation record isn’t queryable the instant the call returns, so a lookup made immediately afterward returns a 404 and resolves a few seconds later. Retry rather than treating that first 404 as a failure. Also, the completion response already carries usage.cost, so if the price of the call is all you need, skip the extra round trip. Use get-generation when you want the provider, the latency, or the native token counts as well.
Step 6. Decide, or route per request
If one model wins clearly across the work you run, use it.
If the results are close, if your traffic mixes several kinds of jobs, or if you don’t want to revisit the decision every time a better model is released, point at the Auto Router with the model string openrouter/auto-beta. The older openrouter/auto still resolves but is documented as deprecated, so use the current one.
The router doesn’t pick at random. It classifies each request into roughly 30 fine-grained task types, ranks candidates by real-world spend share over a trailing seven-day window, applies your cost and quality preference, and routes with fallbacks (Auto Router docs). That’s the framework above, running per request, on the same task-classification data you queried in Step 2.
Think in cost per task, not cost per token
Cost per task, not cost per token, is the correct unit for comparing model economics.
People compare on per-token price because it’s easy to compare, and because fully-loaded cost used to be difficult to measure. With get-generation returning the real number on every call, that difficulty is gone.
A model with a low unit price stops being cheap when it retries, produces completions longer than your token budget, or needs a stronger model behind it to catch its failures. A more expensive model that completes the task on the first attempt often costs less in total.
A 2026 study of reasoning-model pricing measured this. In 32% of model-pair comparisons the model with the lower listed price incurred the higher total cost, with the reversal reaching 28x at the extreme (Chen et al., “The Price Reversal Phenomenon”). The authors attribute it to how differently models spend tokens on thinking: on the same query one model can use 900% more than another, and repeated runs of a single query vary by as much as 9.7x. Listed price reflects none of that.
cost per task = ((input tokens × input price) + (output tokens × output price)) × expected attemptsMost comparisons leave out expected attempts, and that term usually decides the result.
Here is the calculation with real prices, checked on 27 July 2026. GPT-5.4 mini listed at $0.75 per million input tokens and $4.50 per million output. Claude Sonnet 5 listed at $2.00 and $10.00, roughly 2.4 times more. Take a task of 2,000 input and 800 output tokens. If Sonnet 5 succeeds on the first attempt 95% of the time, it costs about $12.63 per thousand completed tasks. For the mini to match that, it has to succeed on the first attempt 40% of the time. Below 40%, the model that is 2.4 times cheaper per token is the more expensive way to finish the work.
When you report this to others, use cost per 1,000 completed tasks. The model with the cheapest tokens is often not the cheapest way to finish the work.
The chart below plots the whole curve instead of the single point. The curve is the more useful thing to keep, because the break-even rate moves with the price gap between the two candidates you’re comparing. A wider gap lets the cheaper model tolerate a much lower success rate before it loses.
The same worked example, plotted across every success rate rather than one. Sonnet 5 is held flat at 95% for reference while the mini’s rate varies. List prices are as of 27 July 2026, the task is 2,000 input and 800 output tokens, and the success rate is the variable being swept rather than anything we measured.
What to optimize for, task by task
This is a starting point rather than a ranking. Each row tells you what to optimize for and which call to make, and the live data supplies the name. We don’t print winners, because any list of winners would be out of date by the next release.
| Task | Optimize for | How to shortlist |
|---|---|---|
| Coding | Reasoning quality, tool-call reliability, then latency | list-benchmarks with task_type=coding, cross-checked against the code: tags in list-task-classifications |
| Summarization and long context | Context window and input price, which dominate the bill | list-model-endpoints for context length and prompt pricing |
| Structured extraction | Schema adherence and valid JSON on every call | list-model-endpoints for supported parameters, then send-message against your real schema |
| Chat and assistants | Latency first, then quality | list-model-endpoints for provider latency and throughput; test with :nitro |
| Vision and multimodal | Image input support, then domain fit | list-models filtered by input modality, then your own images |
| Agentic tool use | Instruction following across many steps | list-benchmarks with task_type=agentic, then multi-step tests |
Coding: Decide which kind of coding you mean. Our task tags separate code generation from debugging, review, frontend, and repo scanning, and the leaders differ. Test candidates on a real ticket from your backlog, not on a toy problem.
Summarization: Read input price and context length together, because either one alone will mislead you. A cheaper model with a large window often beats a stronger one with high input pricing.
Extraction: A smaller model that returns valid JSON every time beats a stronger one that corrupts a field twice a day. Test the difficult inputs: missing fields, ambiguous records, and malformed source text.
Vision: Multimodal quality varies strongly by domain, so filter for image input and then run your own screenshots. A stock demo set makes every candidate look good.
In every case, run the query, look at this week’s numbers, and pick from those.
Why run the loop through OpenRouter
You don’t have to commit to one model at all.
One integration gets you the whole catalog across providers. When a better model is released next month, you change a model string instead of integrating another SDK and re-testing an integration path. Selection and execution sit on the same platform, and with MCP the selection data is available in the editor you already work in. You also get provider redundancy and automatic fallback, and a per-request cost figure precise enough to make the cost-per-task calculation above accurate rather than estimated.
Going direct to a provider is a reasonable choice if you’re certain you want exactly one model from exactly one place and that won’t change. New models are released constantly, so consider how certain you are.
Common mistakes when choosing a model
Most bad model decisions come from measuring the wrong thing, or measuring the right thing too late. These are the five we see most.
Treating leaderboard position as a production decision: A high rank on a public leaderboard earns a place on your shortlist, not production traffic. Run your prompts through the model first.
Shopping by price per token: A low unit price hides retries, long completions, and fallbacks. Until get-generation has told you the cost per completed task, you don’t know what the model costs.
Ignoring context shape: Check both the context length and what you pay at that length. Long-context models are capable and expensive. Use the smallest reliable context strategy that does the job, and consider retrieval before you consider a bigger window.
Picking once and not revisiting: The best model for your task in January won’t be the best in July. We added around 40 models in the thirty days to 27 July 2026, so re-run these six steps after any major release in your category, keep an Ori eval in your repo and re-run it on a schedule, or hand the problem to the Auto Router.
Leaving latency and reliability until go-live: Check the latency, throughput, and uptime figures in list-model-endpoints, then exercise the endpoint the way production will. Finding an unreliable provider after launch is an avoidable incident.
Choose for the task, then keep the choice current
The right question isn’t which model is best, but which model is best for what you’re building, at your budget, right now.
With a clear task definition, live data, and a set of real prompts, you can answer that in an afternoon, and re-answer it in minutes when something changes.
- Best is task-specific and time-specific. Judge on cost per completed task and latency, not on rank.
- Benchmarks build the shortlist, and your own data picks the winner.
send-messageandget-generationsettle it. - The whole loop runs from your editor once the MCP server is connected.
Add the OpenRouter MCP server and ask your assistant to shortlist and price candidates for the job you’re shipping this week. If you’re undecided, or running a mix of tasks, use the Auto Router with openrouter/auto-beta and let it pick per request.
Frequently asked questions
How do I choose the best AI model?
Define the task precisely, shortlist candidates from live usage and benchmark data, compare price and latency across the providers serving each model, then test the finalists on your own prompts. Judge the winner on cost per completed task rather than cost per token. On OpenRouter you can run every one of those steps from your editor through the MCP server.
What is the best AI model for coding?
There’s no fixed answer, and coding isn’t one task. We classify coding traffic into nine separate tags covering code generation, debugging, file I/O, shell execution, code review and security, frontend and UI, repo scanning, SQL and database work, and DevOps config, and the leading model isn’t the same across them. Shortlist with list-benchmarks using task_type=coding, cross-check against real traffic with list-task-classifications, then test candidates on a real ticket from your own backlog.
What is the OpenRouter MCP server?
It’s a remote MCP server hosted by us, with nothing to install locally. Once connected, your AI assistant can query live model data, per-provider pricing, usage rankings, third-party benchmarks, and documentation, and send test messages to candidate models, all without leaving your editor. Any MCP client can connect. We document setup for Claude Code, the Codex CLI, OpenCode, the Cursor CLI, and Claude Desktop.
How do I set up the OpenRouter MCP server in Claude Code or Cursor?
In Claude Code, run claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp followed by claude mcp login openrouter. In Cursor, add the server URL to ~/.cursor/mcp.json and verify with cursor-agent mcp list. Authentication is a single browser step, after which we mint a dedicated API key with a seven-day expiry and a $10 spend cap.
What is the difference between cost per token and cost per task?
Cost per token is the advertised unit price for input and output. Cost per task is what it costs to get one successful result, which includes retries, longer completions, and any fallback to a stronger model. A model with a lower token price can cost more per completed task. get-generation returns the actual cost and token counts for each call so you can measure it rather than estimate it.
How do I compare AI models?
Compare them on three axes at once: quality on your task, cost per completed task, and latency. Use third-party benchmarks to build a shortlist, list-model-endpoints to compare price, latency, and throughput across the providers serving each model, and your own prompts to make the final choice. The web view for side-by-side comparison is at openrouter.ai/compare.
How often should I re-evaluate my model choice?
Re-run the framework after any major release in your task category, or whenever cost, latency, or failure rates drift. We added around 40 models in the thirty days to 27 July 2026, so treat model selection as an operational decision rather than a one-time setup step. If you don’t want to track that cadence, route per request with the Auto Router instead.
How do I make model evaluation repeatable?
Use Ori Eval. You ask a question in plain words, and your coding agent finds test material in your project, writes the eval as a *.eval.ts file, runs the candidate models through OpenRouter, and recommends one with the scores, times, and costs behind it. The eval files are normal code, so you can re-run them when a new model is released, compare runs with --baseline, and run them in CI on a schedule.
Should I use one model or route between several?
Use one model when the task is narrow, the prompt is stable, and one candidate clears your evaluation with margin. Route when requests vary in complexity, when reliability matters more than consistency of model, or when you don’t want to revisit the decision every release cycle. The Auto Router classifies each request into roughly 30 task types and picks per request using the community’s share of spend over a trailing seven-day window.
References
Every claim on this page was verified against these sources, including live API calls.
- OpenRouter MCP server docs. The hosted server, per-editor setup, the full tool list, and which tools are billable.
- OpenRouter MCP server announcement. The OAuth flow, the seven-day key expiry and $10 spend cap, and the model suffix variants.
- Models docs. Model metadata fields, including pricing, context length, modality, and supported parameters.
- Model variants docs. The
:online,:nitro, and:freesuffixes and what each one changes about routing. The:floorshortcut is documented under provider selection. - Ori Eval docs. The eval file format,
candidateModels,setupJudge,--baseline, and running evals in CI. - Auto Router docs. Per-request classification into roughly 30 task types, ranking by trailing seven-day spend share, and the
openrouter/auto-betamodel string. - Model fallbacks docs. Provider redundancy and automatic fallback behavior.
- API reference. The production API, for once you have chosen, including how to query cost and stats after a request.
- Model catalog. The live catalog, 400+ models across 70+ providers.
- Rankings. Daily token totals by model, and the task-classification market share.
- Compare. Side-by-side model comparison on benchmarks, price, context, and latency.
- Artificial Analysis and Design Arena. The two third-party benchmark sources surfaced in
list-benchmarks. - Task classification market share. The endpoint behind
list-task-classifications, returning the 29 task tags with usage share and the leading models per tag. - List benchmarks. The endpoint behind
list-benchmarks, filterable bytask_type. - Get request and usage metadata for a generation. Exact cost, token counts, provider, and latency for a single call.
- Chen, Zhang, He, Stoica, Zaharia and Zou, “The Price Reversal Phenomenon: When Cheaper Reasoning Models Cost More”. Independent measurement of listed price against total cost across model pairs. arXiv, March 2026, revised May 2026.