OpenCode 团队新开源的神器：145 家模型供应商一站查

现在给项目换一个 AI 模型，早就不是改个模型 ID 那么简单了。

你要查价格、上下文、输出长度、工具调用、结构化输出、图片输入，还要看不同 provider 有没有自己的限制。同一个底层模型可能被十几个 provider 转发，价格不一样，能力不一样，接入方式也不一样。查完官网、文档、定价页、SDK 示例和社区帖子，人基本也麻了。

models.dev 有意思的地方，不是又做了一个模型排行榜，而是把这些信息整理成了一层可以被程序消费的元数据。

模型数量少的时候，我们选模型靠记忆：Claude 写作、GPT 综合、DeepSeek 性价比、Gemini 长上下文。到了 2026 年，这套记忆法就不够用了。同一个名字下面可能有不同的上下文窗口、输出限制、价格、工具调用支持和结构化输出支持，再加上 OpenRouter、Vercel AI SDK、各家云平台和国内中转服务，真正麻烦的问题变成了：我怎么在代码里稳定知道一个模型能做什么？

这就是 models.dev 想解决的问题。它把散落在供应商文档、定价页和 SDK 里的信息，整理成一份可以查询、可以校验、也可以直接接入代码的数据源。

先把项目说清楚

models.dev 的官网是 models.dev，GitHub 仓库是 anomalyco/models.dev。根据 2026 年 6 月 28 日抓取到的页面信息，它已经有 5.4k+ stars、1.2k+ forks、数千次提交，开源协议是 MIT。

它来自 SST / opencode 背后的团队。官方 README 的定位很短：这是一个“开放模型数据库”，目前收录 100+ 供应商的模型信息，并且提供静态 JSON API。换句话说，它不是推理平台，不帮你直接调用模型；它更像一个结构化的“模型目录层”。

这层目录现在主要有三个公开端点，分别对应不同的使用方式：

我在 2026 年 6 月 29 日重新请求了一次，api.json 返回了 145 个 provider，models.json 返回了 228 条模型记录，catalog.json 则把 models 和 providers 放在同一个对象里。这里要分清楚：145 说的是供应商数量，不是模型数量；228 才是当前 API 里按模型维度统计到的记录数。

这两个数字以后肯定会变，所以更重要的不是记住它们，而是理解它的维护方式：数据是开源仓库里的结构化文件，社区通过 PR 持续补齐和修正。

它到底整理了哪些信息？

如果只看网页，你会觉得它像一个 AI 模型搜索引擎：输入 glm-5.2、grok、kimi，就能看到模型名称、供应商、上下文窗口、价格和能力标签。

但对工程师来说，更关键的不是页面长什么样，而是它把模型能力拆成了可以被程序理解的字段。一个模型条目通常会包含这些信息：

这就是它比“模型排行榜”更实用的地方。排行榜回答的是“谁第一”，而 models.dev 回答的是“我的这个任务需要哪些能力，哪些模型满足约束，哪个 provider 成本和接入方式更合适”。

先看一个完整例子：GLM-5.2

比如你最近想试一下 GLM-5.2，正常流程是先找智谱官网，再找价格页，再看有没有第三方 provider 支持，最后还要确认上下文、输出长度和工具调用能力。用 models.dev 的话，直接在搜索框里搜 GLM-5.2，这些信息会集中出现在同一个页面里。

我按 2026 年 6 月 29 日的 catalog.json 核了一遍，它的基础模型信息是这样的：

这张表看起来只是“信息汇总”，但对做 Agent 的人很关键。1M 上下文意味着它可以吃下更长的文档、代码仓库片段或多轮任务记录；tool_call 决定它能不能接工具链；structured_output 决定它能不能稳定吐出 JSON、表单、审查结果这类结构化数据；reasoning 则说明它更适合放进规划、分析、代码修复这种复杂环节。

更有用的是 provider 对比。同一个 GLM-5.2，在 catalog.json 里能看到几十个 provider 版本，模型 ID、上下文限制、输出限制和价格并不完全一致。比如 Zhipu AI、OpenRouter、AIHubMix、CrofAI、Deep Infra、Vercel AI Gateway 都提供了相关条目，有的保持 1M 左右上下文，有的输出上限更低，有的价格更便宜，还有一些 coding plan 或 token plan 显示为 0 成本。

这就是它真正省时间的地方。你不是只看到“GLM-5.2 很强”，而是能继续问几个工程问题：我要官方 provider，还是聚合平台？我要最大上下文，还是最低输出价格？我要 open weights 方便本地部署，还是只要 API 能稳定调用？以前这些问题要靠十几个网页拼起来，现在至少有了一个统一入口。

真实工程里，模型选择已经变成约束匹配

以前我们选模型，经常是一个主观动作：试一下，感觉不错，就写进配置。但当模型和供应商数量越来越多，选型就更像一次数据库查询：先确定任务需要哪些能力，再从候选模型里筛掉不满足条件的选项。

下面这个例子可以直接复制运行。它会从 catalog.json 拉取全量目录，筛出适合 Agent 场景的模型：要求支持推理、工具调用、结构化输出，并且上下文窗口不低于 128K。最后它会按输出价格从低到高打印前 10 个候选项。

// 保存为 pick-agent-models.mjs
// 运行：node pick-agent-models.mjs

const catalog = await fetch("https://models.dev/catalog.json").then((res) => {
  if (!res.ok) throw new Error(`request failed: ${res.status}`)
  return res.json()
})

const minContext = 128_000
const candidates = []

for (const [providerId, provider] of Object.entries(catalog.providers)) {
  for (const [modelId, model] of Object.entries(provider.models || {})) {
    const base = catalog.models[modelId] || {}
    const context = model.limit?.context ?? base.limit?.context ?? 0

    const matched =
      (model.reasoning ?? base.reasoning) &&
      (model.tool_call ?? base.tool_call) &&
      (model.structured_output ?? base.structured_output) &&
      context >= minContext

    if (!matched) continue

    candidates.push({
      model: model.name || base.name || modelId,
      modelId,
      provider: provider.name || providerId,
      context,
      inputPrice: model.cost?.input ?? "-",
      outputPrice: model.cost?.output ?? "-",
      api: provider.api || "-"
    })
  }
}

const priceValue = (value) => typeof value === "number" ? value : Number.POSITIVE_INFINITY

candidates.sort((a, b) => {
  return priceValue(a.outputPrice) - priceValue(b.outputPrice) || b.context - a.context
})

console.table(candidates.slice(0, 10))

这段代码只是一个小例子，但已经能说明问题：模型选择正在从“人肉查资料”变成“用元数据筛选候选集”。比如你要做一个代码审查 Agent，它至少需要：

如果这些字段都靠人工查，最后大概率会变成几张互相打架的内部表格。models.dev 的意义，就是把这些字段放进一个可维护的数据源里。

它和 OpenRouter、Vercel AI SDK、LiteLLM 有什么区别？

很多人第一次看 models.dev，会把它和 OpenRouter、LiteLLM、Vercel AI SDK 放在一起比较。其实它们不在同一层。

你可以把 models.dev 看成这些系统旁边的一张“模型能力表”。它不替你发送请求，但可以帮你决定请求该发给谁、发之前要检查哪些能力、展示给用户时应该怎么描述限制。

官方 README 也特别强调了和 Vercel AI SDK 的关系：很多 provider 的 npm 字段对应 AI SDK 的 provider 包，模型 ID 也便于直接映射到 SDK 使用方式。这一点对做工具型产品很有用，因为你不用自己维护一份“展示 ID”和“调用 ID”的映射表。

为什么它最近值得关注？

模型供应链正在碎片化。同一个底层模型会被多个 provider 提供，有官方 API，也有聚合平台、云厂商、企业网关、区域代理。价格、上下文、限流、可用性都可能不同。只看模型名字已经不够了，必须看“模型 + provider”这个组合。

Agent 产品也开始需要模型治理。一个成熟的 Agent 系统不会永远只调用一个模型，它会把任务拆成规划、检索、执行、校验、总结等环节。便宜模型做轻量分类，长上下文模型读文档，强推理模型处理关键决策。这个过程中，模型元数据就是路由策略的输入。

成本优化也不能再靠感觉。如果一个团队每月只有几百美元 API 预算，模型选择是体验问题；如果每月有几万美元甚至更高的调用成本，模型选择就是财务问题。models.dev 这类数据源，可以让成本估算进入代码、仪表盘和评估流程。

开源维护速度本身也是信号。GitHub 页面显示这个仓库近期仍有持续提交，并且存在大量开放 PR，很多 PR 都是在添加新模型、新供应商或修正价格字段。这说明它不是一次性整理的静态清单，而是一个被社区持续推着走的数据项目。当然，这也意味着你不能把它当成绝对事实源；涉及生产计费和 SLA 时，仍然要回到供应商官方文档做最后确认。

可以怎么用？

最轻量的用法，是把它当查询网站。打开 models.dev，搜索模型名，看看上下文、输出长度、能力标签和供应商。这个场景下，它已经能替代一堆收藏夹。

更进一步，如果你的应用允许用户选择模型，可以定时拉取 catalog.json，在本地缓存后做筛选和展示。这样你的页面不需要手工维护“哪些模型支持工具调用”“哪个模型有 1M 上下文”。

如果你在做 Agent，也可以把它变成候选模型池：先按能力过滤，再按 provider 可用性、价格、上下文长度排序。最终路由时，不一定每次都实时请求 models.dev，更稳妥的方式是定期同步到自己的数据库，生产运行时读本地缓存。

它还可以用于评估和成本分析。在一套 eval 里，你可以把候选模型的价格、上下文窗口、能力标签和实际得分放在一起看。这样讨论就不会停留在“某模型感觉更聪明”，而是可以落到“在这个任务上，它多花了多少钱，换来了多少质量提升”。

但别误用它

models.dev 很有用，但它不是万能答案。它不负责模型调用，不保证某个 provider 在你所在区域一定可用，也不能替你判断供应商的稳定性、合规性、企业合同和限流策略。价格字段也可能滞后，尤其是新模型发布、供应商改价、限时免费额度变化时。

更合理的姿势，是把它当作初筛和同步来源，而不是把它当成最终裁判：

我对这个项目的判断

models.dev 看起来很小，但它踩中了 AI 工程里一个越来越真实的痛点：模型不再是几个固定名字，而是一条快速变化的供应链。

当模型选择还靠人记忆时，团队会不断重复三件事：查文档、问同事、更新配置。等项目变复杂，大家就会各自维护一份表格，最后每张表都不一样。models.dev 的价值，是把这件事变成开源数据工程：字段公开、格式统一、PR 可审、API 可读。

我不建议把它神化成“模型选择终局”。真正上线时，你依然需要自己的评测、监控、账单和降级策略。但如果你正在做 AI 工具、Agent 平台、模型网关、内部 Copilot 或成本分析系统，它很值得放进工具箱里。

最后给一个实用检查清单，判断你的项目值不值得接入它：

别再只把模型当成一个字符串配置了。接下来真正有工程价值的，不是“我知道某个模型很强”，而是“我的系统知道每个模型适合做什么，并且能在约束变化时自动调整”。

参考资料

• models.dev 官网：https://models.dev
• GitHub 仓库：https://github.com/anomalyco/models.dev
• GitHub PR 列表：https://github.com/anomalyco/models.dev/pulls
• JSON API：api.json、models.json、catalog.json