OpenRouter 详解如何在编辑器内用实时数据选出最合适的 AI 模型

要选择 AI 模型，先定义任务，从实时使用数据和基准测试数据中筛选出候选名单，比较各提供商的价格和延迟，然后用自己的提示词测试入围者。以每个已完成任务的成本而非每个 token 的成本来评判，并预期随着新模型的发布，答案会发生变化。

我们不会给出唯一一个最佳模型的名称。我们印出的任何名字都会在一个月内过时，而且正确的模型取决于你在构建什么，以及你愿意为正确的结果支付多少。

本文介绍了我们用来回答这个问题的框架，以及如何在不离开编辑器的情况下运行它。我们的 MCP 服务器 会将你的助手连接到实时使用排名、第三方基准测试、各提供商的定价，以及向候选模型发送测试提示词的途径。

太长不看版

• 「最佳」指的是你的任务、你的每个已完成任务的成本，以及你的延迟预算。排行榜排名不在三者之列。
• 用基准测试来构建候选名单，用你自己的提示词来选出胜者。Ori Eval 可以为你编写并运行这类比较。
• 通过 MCP 在编辑器中查询实时排名和价格，然后用 get-generation 衡量每次测试调用的成本。
• 如果没有模型明显胜出，就用 openrouter/auto-beta 按请求路由，而不是只选一个。

为什么没有唯一最佳的 AI 模型

没有唯一最佳的 AI 模型，只有针对特定任务、预算和时刻的最佳模型。

不同的任务需要不同的能力。摘要和代码编写对模型的要求各不相同。信息抽取更需要每次调用都返回有效的 JSON，而不是优美的文笔。聊天功能取决于第一个 token 到达的速度，这与完整答案的质量是两回事。在代码基准测试中排名第一的模型，在处理长文档时仍可能表现不佳，且对于常规抽取任务而言成本过高。

一个更有用的问题应包含具体的工作。与其问“什么是最佳的 AI 模型”，不如问“从扫描发票中抽取明细项目用哪个模型最佳”，或者“审查 TypeScript pull request 用哪个模型最佳”，或者“总结 90 分钟的通话记录用哪个模型最佳”。写下你自己的版本，然后根据当前数据而非过时的排名来回答。

我们的流量数据表明，答案因任务而异的程度有多大。我们将一部分请求样本分为 29 种任务类型，并发布市场份额。仅代码类就占其中九种，涵盖代码生成、调试、代码审查、仓库扫描、SQL 工作和 DevOps 配置。这九类并不共享同一个领先者。在截至 2026 年 7 月 25 日的七天内，有一个模型在其中八类中领先，而另一个模型在代码审查和安全类中领先。“编码的最佳模型”这个问题即使在编码领域内也太宽泛了。

基准测试是过滤器，而不是答案

基准测试有助于将数百个选项缩小到可以认真测试的少数候选者。我们会在自有使用数据旁展示来自 Artificial Analysis 和 Design Arena 的第三方评分。

排行榜无法替你做出最终选择。分数存在噪声，热门基准测试会吸引针对性调优，而且没有一个基准测试运行过你的提示词。用排行榜来筛选候选名单，用自己的测试来做决定。

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

没有任何模型能在所有类别中领先。为所有任务选同一个模型，会得到一个昂贵的默认选择：它在演示中表现出色，但在你实际运行的工作上表现不佳。

设置 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 login 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 login 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 文档）。

助手调用 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 总量，以及每天一行聚合的 other 数据。你可以按用例类别（如 programming 或 roleplay）、模态或工具调用活动进行筛选，但类别切片来自每周聚合的抽样数据集，因此这些总量应视为估计值。它告诉你什么在增长，而不是什么在你的任务上表现好。同样的视图可在 openrouter.ai/rankings 查看。

第 3 步：比较成本、提供商和延迟

对每个入围模型，调用 list-model-endpoints。你会得到服务该模型的每个提供商的信息，包括价格、上下文长度、过去三十分钟的吞吐量和延迟、正常运行时间、量化方式以及支持的参数。同一个模型在不同提供商之间的价格、速度和可靠性可能不同，最好在这里发现这些差异，而不是在生产环境中。

当你需要与他人分享时，对比页面会在浏览器中显示相同的数据。

第 4 步：用自己的数据测试入围名单

基准测试帮你筛选出入围名单，而你自己的提示词做出最终选择。

用 send-message 跑你实际拥有的工作：真实的工单、真实的文档、真实的模式（schema），包括那些通常导致失败的例子。一个干净的评估集会让每个模型看起来都胜任，这正是它无法区分它们的原因。

测试时有三种变体会有帮助。:floor 会路由到服务该模型的最便宜的提供商，从而控制评估成本。:nitro 会路由到最快的提供商，用于检查延迟预算。:online 会在任务需要最新上下文时添加网络搜索。

注意 :online 的成本。用三种方式运行同一个简单提示词，:floor 花费 $0.0000030，:nitro 花费 $0.0000024，而 :online 花费 $0.0052576。对于单个提示词来说，这大约是普通调用的两千倍，所以要有意使用它，而不是让它一直处于开启状态。

用 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 started

Ori 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 attempts

Most 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.

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.

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

视觉：多模态质量因领域不同而差异很大，所以先筛选出支持图像输入的模型，然后运行你自己的截图测试。现成的演示集会让每个候选模型都看起来不错。

无论哪种情况，都要运行查询，查看本周的数据，并从中做出选择。

为什么要通过 OpenRouter 运行整个流程

你完全不必锁定于一个模型。

一次集成即可获得跨提供商的全部模型目录。当更好的模型下个月发布时，你只需更改一个模型字符串，而不必集成另一个 SDK 并重新测试集成路径。选择和执行位于同一平台上，借助 MCP，选择数据可以直接在你已经在用的编辑器中获取。你还能获得提供商冗余和自动回退，以及精确到每次请求的成本数据，足以让上述每任务成本的计算变得准确而非估算。

如果你确定只想从某个特定来源使用某一个模型，并且不会改变，那么直接对接提供商是合理的选择。新模型在不断发布，所以请考虑一下你的确定程度。

选择模型时的常见错误

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

把排行榜名次当作生产决策：公开排行榜上的高名次只值得进入你的候选名单，而不值得直接接入生产流量。先用你自己的提示词测试这个模型。

按每 token 价格选购：低廉的单价掩盖了重试、长补全和回退的成本。在 get-generation 告诉你每个已完成任务的成本之前，你并不知道这个模型的实际成本。

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

一次选定后不再回顾：一月份最适合你任务的最佳模型，到七月份未必还是最佳。在截至 2026 年 7 月 27 日的三十天里，我们新增了约 40 个模型，所以在你的类别中出现任何重大发布之后，请重新执行这六个步骤，在代码库中保留一个 Ori 评估并定期重新运行，或者把这个问题交给 Auto Router。

把延迟和可靠性留到上线才检查：查看 list-model-endpoints 中的延迟、吞吐量和正常运行时间数据，然后按生产环境的方式对端点进行实测。上线后才发现提供商不可靠，这是一次本可避免的事故。

为任务而选，并让选择保持最新

正确的问题不是哪个模型最好，而是当下在你的预算范围内，哪个模型最适合你正在构建的东西。

有了清晰的任务定义、实时数据和一组真实提示词，你可以在一个下午内得出答案，并在情况发生变化时几分钟内重新解答。

• “最佳”是针对特定任务和特定时间的。以每个已完成任务的成本和延迟来评判，而不是以名次。
• 基准测试帮你构建候选名单，你自己的数据选出胜者。send-message 和 get-generation 一锤定音。
• 一旦连接了 MCP 服务器，整个流程就可以在你的编辑器中运行。

添加 OpenRouter MCP server，让你的助手为你本周要上线的任务筛选候选模型并给出报价。如果你犹豫不决，或要同时处理多种任务，可以使用 Auto Router 搭配 openrouter/auto-beta，让它按请求自行选择。

常见问题

如何选择最佳 AI 模型？

精确定义任务，从实时使用量和基准测试数据中筛选候选模型，比较提供各模型的各个服务商的价格和延迟，然后用自己的提示词测试入围模型。以每个完成任务的成本而非每 token 成本来评判胜者。在 OpenRouter 上，你可以通过 MCP server 在编辑器中完成所有这些步骤。

最佳的编程 AI 模型是什么？

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

什么是 OpenRouter MCP server？

这是我们托管的远程 MCP server，本地无需安装任何东西。连接后，你的 AI 助手可以查询实时模型数据、各服务商定价、使用量排名、第三方基准测试和文档，还可以向候选模型发送测试消息，全程无需离开你的编辑器。任何 MCP 客户端都可以连接。我们为 Claude Code、Codex CLI、OpenCode、Cursor CLI 和 Claude Desktop 提供了设置文档。

如何在 Claude Code 或 Cursor 中设置 OpenRouter MCP server？

在 Claude Code 中，先运行 claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp，再运行 claude mcp login openrouter。在 Cursor 中，将 server URL 添加到 ~/.cursor/mcp.json，并用 cursor-agent mcp list 进行验证。身份验证只需一步浏览器操作，之后我们会生成一个专用的 API key，有效期为七天，消费上限为 $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 server 文档。托管服务器、各编辑器的配置、完整的工具列表，以及哪些工具是收费的。
• OpenRouter MCP server 公告。OAuth 流程、七天的密钥有效期和 $10 消费上限，以及模型后缀变体。
• Models 文档。模型元数据字段，包括定价、上下文长度、模态和支持的参数。
• Model variants 文档。:online、:nitro 和 :free 后缀，以及每个后缀对路由的改变。:floor 快捷方式记录在 提供商选择 之下。
• Ori Eval 文档。评估文件格式、candidateModels、setupJudge、--baseline，以及在 CI 中运行评估。
• Auto Router 文档。按请求分类为约 30 种任务类型、按过去七天的消费份额排名，以及 openrouter/auto-beta 模型字符串。
• 模型回退文档。提供商冗余与自动回退行为。
• API 参考。正式生产环境的 API，供你完成选择后使用，包括如何在请求后查询成本与统计数据。
• 模型目录。我们提供的所有模型及其背后提供商的实时目录。
• 排行榜。按模型统计的每日 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 月修订。