如何在编辑器里实时挑选最佳 AI 模型

要选择 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 的第三方评分，同时结合我们自身的使用数据。

排行榜无法替你做出最终选择。分数存在噪声，热门基准容易招致针对性调优，而且它们都没有运行过你的提示词。用排行榜来缩小候选范围，用你自己的测试来做最终决定。

不同的任务需要不同的能力侧重。编程需要推理质量和可靠的工具调用。摘要总结需要大上下文窗口和较低的输入定价。信息抽取更需要稳定遵循既定 schema，而非流畅度。聊天需要低延迟。视觉任务需要一个能接受图像输入的模型，这一点在考虑质量之前就已经大幅缩小了候选范围。

没有任何模型能在所有类别中领先。为所有事情只选一个模型，会得到一个昂贵的默认选择——它在演示中表现优异，但在你实际运行的工作上却表现不佳。

设置 OpenRouter MCP 服务器

下面的每一步都要通过 MCP 服务器来执行，所以请先连接好它。

OpenRouter MCP server由我们托管，因此无需在本地安装任何东西。任何 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: <app name> 的密钥，作用域限定为该客户端，有效期为七天，并带有 $10 的额度上限，你可以在该界面上修改（MCP 公告）。该密钥默认短期有效且设有上限，你可以随时断开连接，也可以从你的 密钥管理面板 撤销它。

该流程会重定向到 localhost，这对于 Claude Code 或 Cursor 这类桌面客户端来说是正常现象，但这意味着我们无法验证是哪个本地应用接收了密钥。只有当你刚刚亲自发起连接时，才应批准该请求。

你将使用的工具

大多数工具都是对实时数据的只读查询。例外情况是 send-message、generate-image、transcribe-audio 和 generate-speech，它们会发起计费的推理调用；以及 send-feedback，它会对你自己生成的某条内容写入反馈（MCP 文档）。

助手针对 code:general_impl 标签调用 list-task-classifications，返回领先模型及其使用量和 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 总量，外加每天一行聚合后的 other 数据。你可以按用例类别（如 programming 或 roleplay）、按模态或按工具调用活动来缩小范围，但类别切片来自按周聚合的采样数据集，因此请将这些总量视为估算值。它告诉你什么在增长，而不是什么在你的任务上表现好。同样的视图也可以在 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 started

Ori 会为一次运行解析出一个测试框架和一个模型，并在该次运行中的每个测试里都沿用这一组合，因此同一批评测文件跑两次会使用相同的配置。它通过 OpenRouter 发送请求，所以一次对比可以涵盖来自多家服务商的模型。上述说明是在临时目录中执行的。如果你改为按照手动步骤操作，评测文件就会作为普通代码保留在你的项目中，这样当新模型发布时你可以重新运行它们，用--baseline与更早的一次运行进行对比，还可以在 CI 中按计划定时运行。

第 5 步：衡量每个已完成任务的成本

每次测试调用结束后，将生成 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 标价为 $2.00 和 $10.00，约为前者的 2.4 倍。以一项 2,000 输入 token、800 输出 token 的任务为例。如果 Sonnet 5 在首次尝试时就有 95% 的成功率，那么每千次完成任务约花费 $12.63。mini 若要达到同等水平，其首次尝试成功率需达到 40%。低于 40% 时，那个每 token 便宜 2.4 倍的模型，反而成了完成这项工作的更昂贵方式。

当你向他人汇报这一结果时，请使用每千次完成任务的成本。token 最便宜的模型，往往并不是完成工作的最便宜方式。

下图绘制的是整条曲线，而非单一数据点。曲线才是更值得保留的内容，因为盈亏平衡点会随着你所对比的两个候选模型之间的价格差距而变化。差距越大，较便宜的模型在落败之前所能承受的成功率下限就越低。

同一个已跑通的示例，但这次把成功率从单一取值扩展到全区间来绘图。为便于参照，Sonnet 5 的成功率被固定在 95% 保持水平，而 mini 的成功率则随之变化。列表价格为 2026 年 7 月 27 日当日价格，任务设定为 2,000 个输入 token 和 800 个输出 token，成功率是被扫描的变量，而非我们实测得到的任何结果。

按任务类型，该优化什么

这是一个起点参考，而非排名榜单。每一行告诉你该优化什么、该调用哪个模型，具体模型名称由实时数据给出。我们不公布胜出者名单，因为任何一份胜出名单在下一个版本发布时就会过时。

编程： 先明确你说的编程属于哪一类。我们的任务标签把代码生成与调试、代码审查、前端和仓库扫描区分开来，而各类别的领先模型各不相同。应该用你 backlog 里的真实任务单来测试候选模型，而不是用玩具式的小问题。

摘要： 要把输入价格和上下文长度放在一起看，因为只看其中任何一项都会误导你。一个更便宜但窗口很大的模型，往往胜过定价更高但更强的模型。

信息抽取： 一个每次都能返回有效 JSON 的小模型，胜过一天会弄坏两次字段的更强模型。要测试那些困难的输入：缺失字段、含混记录、格式错误的源文本。

视觉： 多模态质量因领域差异很大，所以要按图像输入筛选，然后拿你自己的截图去跑。一套现成的演示集会让每个候选模型看起来都很好。

无论哪种情况，都要实际跑一遍查询，看看本周的数据，然后从中挑选。

为什么通过 OpenRouter 跑这个循环

你根本不必只绑定一个模型。

一次集成就能让你接入跨提供商的整个目录。下个月有更好的模型发布时，你只需改一个模型字符串，而不用再集成另一个 SDK、重新测试一遍集成路径。选型与执行位于同一平台之上，而且借助 MCP，选型数据可以直接出现在你日常使用的编辑器里。你还能获得提供商冗余与自动故障转移，以及精确到足以让上述单任务成本计算做到准确而非估算的每次请求成本数据。

如果你确定自己只想要某一家提供的某一个模型，而且这个需求不会改变，那么直接对接该提供商是合理的选择。但新模型发布非常频繁，所以请想清楚你到底有多确定。

选择模型时的常见错误

大多数糟糕的模型决策，都源于衡量了错误的对象，或者太晚才衡量正确的对象。以下是我们最常见的五种错误。

把排行榜名次当作生产决策依据： 在公开排行榜上名列前茅，只能让它进入你的候选名单，而不是直接上生产环境。先用你的提示词跑一遍这个模型再说。

只看每 token 单价： 低廉的单价背后可能隐藏着重试、超长补全和回退成本。在 get-generation 告诉你每个完成任务的实际成本之前，你根本不知道这个模型到底要花多少钱。

忽视上下文形态： 既要检查上下文长度，也要检查在该长度下你需要支付多少费用。长上下文模型能力很强，但也很贵。请使用能完成任务的最小可靠上下文策略，并且在考虑更大的窗口之前，先考虑检索方案。

只选一次，之后不再复查： 一月份最适合你任务的模型，到了七月份未必还是最好的。在截至 2026 年 7 月 27 日的三十天内，我们新增了大约 40 个模型，所以在你所在类别有任何重大版本发布后，请重新执行这六个步骤；在你的代码仓库中保留一个 Ori eval，并定期重新运行；或者干脆把这个问题交给 Auto Router。

把延迟和可靠性问题留到上线前才处理： 请查看 list-model-endpoints 中的延迟、吞吐量和可用性数据，然后按照生产环境的实际方式调用端点。上线后发现供应商不可靠，是一次本可避免的事故。

按任务选模型，然后让选择保持最新

正确的问题不是哪个模型最好，而是哪个模型最适合你正在构建的东西、符合你的预算、并且适用于当下。

有了清晰的任务定义、真实数据和一组真实提示词，你一个下午就能回答这个问题；而当情况发生变化时，几分钟内就能重新回答一遍。

• “最好”是随任务和时间而变化的。要以每完成一个任务的成本和延迟来判断，而不是看排名。
• 基准测试用来建立候选名单，而你自己的数据来选出赢家。send-message 和 get-generation 可以一锤定音。
• 一旦 MCP 服务器连接好，整个流程都可以从你的编辑器里直接运行。

添加 OpenRouter MCP 服务器，然后让你的 AI 助手为你本周要发布的任务筛选候选模型并给出报价。如果你还没拿定主意，或者同时运行多种任务，可以使用带 openrouter/auto-beta 的 Auto Router，让它按每个请求自动选择。

常见问题解答

如何选择最佳的 AI 模型？

先精确定义任务，再从实时使用数据和基准测试结果中筛选候选模型，比较各服务商提供每个模型的价格和延迟，最后用你自己的提示词测试入围的模型。评判标准应看完成每项任务的成本，而不是每个 token 的成本。在 OpenRouter 上，你可以通过 MCP 服务器在编辑器里完成上述所有步骤。

最适合编程的 AI 模型是什么？

没有固定答案，而且编程也不是单一任务。我们将编程流量划分为九个独立标签，涵盖代码生成、调试、文件 I/O、shell 执行、代码审查与安全、前端和 UI、仓库扫描、SQL 和数据库工作，以及 DevOps 配置，不同类别下的领先模型并不相同。使用 list-benchmarks 结合 task_type=coding 进行筛选，用 list-task-classifications 对照真实流量交叉验证，然后从你自己的待办事项中挑一个真实任务来测试候选模型。

什么是 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 月修订。