比较 OpenRouter 编程模型价格时，正确顺序是先筛掉不符合 Coding 工作流能力要求的模型，再比较实时输入价、输出价、上下文、速度，以及完成一个合格任务的总成本。 把全部模型从便宜到昂贵排序，只是建立候选清单的起点，不等于 Coding 模型排行榜。
原因很简单：一次 Coding Agent 任务远不止一次模型调用。模型可能需要读取文件、提出工具调用、生成改动、查看测试结果、从错误中恢复，再重复整个流程。如果一个低价请求连续失败两次，它的实际成本可能高于一次通过的高价请求。
OpenRouter 的模型页面和 Models API 能让原始比较变得容易，真正困难的是选择正确的比较方式。还需要先理解模型与 Agent harness 的区别：OpenRouter 提供模型和 Provider 访问，而 Agent harness 负责围绕这些调用组织多步骤 Coding 工作流。
“按价格排列 OpenRouter 模型”到底是什么意思？
OpenRouter 为模型列出不同价格字段和运行信息。Models API 支持使用 pricing-low-to-high 排序，但官方文档说明，这个排序基于 prompt、completion、request 和 web search 价格的加权平均。它适合快速发现候选，并不保证第一名就是你的实际请求中最便宜的模型。
下面这些变量都会改变最终账单：
- 输入与输出比例。 仓库上下文很长时，输入成本可能占主导；规划、Patch 和推理很长时，输出成本可能更重要。
- Tokenization。 OpenRouter 明确提示，不同模型切分同一段文本的方式不同，因此同一批源代码可能产生不同 token 数量。
- 非 token 收费。 部分模型或功能可能按请求、图片、推理 token 或 Web Search 收费。
- Provider endpoint。 同一个模型可能由多个 Provider 提供，它们的价格、延迟、吞吐、数据政策和参数支持可能不同。
- 重试。 Rate limit、无效工具调用、失败的 Patch 或测试，都可能把一个逻辑任务变成多次付费请求。
OpenRouter 表示会传递底层模型的推理价格，并在每个模型页面显示细节；其 FAQ 也把推理价格与购买 credits 时的平台费用分开说明。做预算时，应同时查看当前模型页面和当前账号定价，而不是只抄一个 token 单价。
先筛 Coding 能力，再按价格排序
如果模型不能满足请求合同，再便宜也没有意义。对需要工具的 Coding 工作流，应先锁定硬性条件。
Tool Calling
OpenRouter 支持用 supported_parameters=tools 筛选 Models API。其 Tool Calling 文档说明，模型只是提出 Function Call，由调用方真正执行函数，再把结果返回模型。因此，支持 tools 只说明具备集成能力，不能证明模型能可靠完成仓库改动。
还要检查工作流是否依赖 tool_choice、Structured Output、推理控制或其他参数。模型层面的支持和 Provider 层面的支持有关，但不完全等价。如果请求必须保留所有参数，还需要在 Provider routing 中强制这一点。
上下文和输入类型
上下文容量决定一次请求最多能放入多少代码、文档、工具输出和 session 历史。更大不一定更好：无关上下文会抬高成本，也可能带来噪声。应该根据仓库信息如何被检索和组装来设定上下文要求，而不是把 context window 当成质量分数。
如果工作流包含截图、设计图、PDF 或其他文件，也要筛选相应输入模态。一个纯文本模型不应该因为 token 更便宜，就留在视觉排错的候选清单里。
可用性和数据政策
生产工作负载可能要求特定地区、Zero Data Retention、Provider allowlist 或量化策略。这些约束会排除一些看起来价格很好的 endpoint。应该先应用约束，再比较成本，确保留下的路线真的能用。
用 Models 页面或 API 建立实时候选清单
手动检查时，可以在 Models 页面按 Tool Calling、输入模态、上下文、价格和模型家族筛选。需要重复执行时，应该查询 Models API，而不是把一张静态价格表复制到表格后长期使用。
可以从下面这个请求开始：
官方 schema 会返回模型 ID、上下文长度、价格、支持参数、单请求限制和主要 Provider 等字段。OpenRouter 还支持按 p50 throughput 和 p50 latency 排序。模型和 Provider 数据都会变化，因此每次做重要选择时都应重新获取快照，并记录时间。
不要把所有字段压缩成一个总分。至少保留这些列：
API 的价格排序适合第一轮过滤；只有把这些字段按照真实任务的权重比较，候选清单才有意义。
比较“完成一个合格 Coding 任务”的成本
对 Agent 工作流来说，最有用的单位不是每次请求成本，而是 cost per accepted task，也就是产出一个通过相同测试和审核规则的结果，总共需要多少钱。
可以使用一个简单公式：
人工审核时间应单独记录。它不是 API 账单，却经常是失败运行或冗长输出里最大的真实成本。
比较每个候选时，应固定任务、仓库初始状态、Agent harness 配置、工具 schema、timeout 和验收命令，然后记录：
至少测试多个任务再下结论。一次简单 Prompt 可能掩盖可靠性问题；一次罕见失败也可能不公平地否定一个本来合适的模型。
按 Coding 工作负载调整比较重点
不同任务需要不同的价格和性能组合。
仓库问答与初步分类
简短问答、文件发现和 Issue 分类通常更在意低延迟与克制的输出。如果一个低价且支持工具的模型能稳定找到正确文件、返回可验证答案，它就可能足够。
编辑、测试与修复循环
实现工作更依赖工具调用可靠性、指令遵循和从测试失败中恢复。因为 Patch、日志和多轮推理可能很长，输出价格和 Throughput 都很重要。如果模型不断调用错误工具或生成无法通过校验的修改，最低 token 价会迅速失去优势。
规划与高风险改动
架构、迁移和影响范围大的改动，可能需要能力更强的候选，或者使用分阶段工作流：一个模型规划，另一个执行，再由确定性的测试裁决。比较时要计算整个流程，不能只看规划模型的价格。
这也解释了为什么 GLM-5.3-Flash 这类新模型应该按工作流适配度评估，而不只看价格。较低标价可以成为测试理由，但不能代替兼容性和验收检查。
价格排序与 Provider routing 解决不同问题
选择 Model 回答的是“哪个模型处理这个任务”；选择 Provider 回答的是“哪个 endpoint 实际承载这次模型请求”。OpenRouter 可能通过多个 Provider 提供同一模型，并在它们之间路由。
这会影响成本、延迟、吞吐、参数支持和 uptime。锁定预算前，应先理解 OpenRouter 如何选择 Provider。如果保留默认 routing，实际处理请求的 endpoint 未必就是你根据单张模型卡所假设的那一个。
自动选择模型又是另一层选择。Auto Router 与 Free Models Router 不是同一件事：前者按照自己的路由逻辑从合格模型中选择，并可能产生被选模型的费用；后者只在当时可用的免费模型中选择。
这些层都不能代替 Coding Agent harness。Harness 仍负责仓库访问、工具执行、session 状态、审批、重试和验证。有效的比较应该让 Model、Provider 和 harness 变量保持可见，而不是把所有结果都归因于其中一层。如果要进一步区分模型路由入口与托管 Coding Workspace，可以查看 OpenRouter 与 Agent.Space 的对比。
一套可执行的 OpenRouter Coding 模型决策流程
可以按以下顺序把比较控制在小而可复现的范围内：
- 定义一个 Coding 任务和验收命令。
- 列出不能妥协的能力：Tools、上下文、输入模态、Structured Output、数据政策或地区。
- 查询当前 Models 页面或 API，移除不合格模型。
- 按价格排列剩余候选，再分别查看输入和输出价格。
- 比较当前 Throughput、Latency 和可用 Provider。
- 用同一 Agent harness 配置测试 2–3 个候选。
- 记录完整循环的费用、重试、耗时、工具错误和验收结果。
- 只有结果在同类任务上足够可重复，才保留模型。
最终结果可能是一套小型 routing policy，而不是一个通用赢家：快速低价模型处理分类，另一个模型处理困难改动，再由第三个模型审核高风险变更。合理分工只能来自自己的验收数据。
常见问题
OpenRouter 上最便宜的 Coding 模型是哪一个？
没有长期有效的固定答案，因为模型价格和可用性会变化，而且最低价模型未必满足工具与可靠性要求。应使用 Models API 的 supported_parameters=tools 和 sort=pricing-low-to-high 获取实时候选，再做同条件测试。
OpenRouter 会给模型 token 价格加价吗？
OpenRouter 当前 FAQ 表示会传递底层 Provider 的推理价格，但用户购买 credits 时另有平台费用。因此，总账号成本不能只看 token 费率；预算前要重新核对 Pricing 与 FAQ。
最快的模型一定总成本最低吗？
不一定。Throughput 和 Latency 影响时间，价格与 token 数影响 API 支出，而可靠性、重试和人工修正决定一个快速请求能否变成合格结果。
OpenRouter 能代替 Coding Agent 吗？
OpenRouter 提供模型访问和路由；Agent harness 负责围绕模型与工具组织多步骤工作流。两者可以组合，但解决的是不同层级。
结论
OpenRouter 的实时价格排序适合用来开始比较，不适合直接结束决策。先筛选 Coding 请求合同，再查看当前模型与 Provider 数据，最后在同一个 Agent harness 配置中比较完整的合格任务。
可以从一个带确定性测试的小型仓库任务开始，让一组精简的 tool-capable 候选完成同一任务，再保留在该类工作负载中能稳定平衡成本、速度和验收结果的模型与 routing policy。