models.dev：用一份 TOML 数据源，统一 AI 模型查询与定价
项目速览：人工智能模型的开源数据库。使用模型 ID 字段对任何模型进行查找； AI SDK使用的标识符。
秒懂
- 它是什么？
- models.dev 是一个开源的 AI 模型数据库，以 TOML 文件维护模型规格、定价与能力，并提供 JSON API 供 AI SDK 查询。它的核心设计是模型元数据与提供商信息分离，用 base_model 继承机制减少重复维护。
- 适合谁用？
- 适合需要以编程方式获取模型规格、定价与能力信息的开发者，尤其是使用 AI SDK 构建工具或服务的人。不适合需要实时价格或动态模型列表的场景，因为数据完全依赖社区手动更新，存在滞后风险。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个模型，两种身份：从 Model ID 到 Provider 详情
AI 模型的数量增长很快，但没有任何单一数据库能覆盖所有模型。models.dev 想解决的就是这个信息分散问题。它的核心是一个模型 ID，例如 openai/gpt-5。这个 ID 同时用于 AI SDK 的查询。你可以在 models.dev 上用 Model ID 做查找。数据分两层：models/ 目录存放模型本身的元数据，providers/ 目录存放各提供商的服务细节。这种分离是它的关键设计。同一个模型可能由多个提供商托管，但模型本身的事实只有一份。
数据流：从 TOML 到 JSON API 的生成管线
仓库中的数据以 TOML 文件形式存储，按提供商和模型组织。每个模型文件包含 name、family、release_date、knowledge 等字段。还有 [limit] 表记录上下文和 token 限制，[modalities] 表记录输入输出类型。提供商文件则通过 base_model 字段引用模型元数据。生成时，提供商字段覆盖模型字段。例如 providers/openai/models/gpt-5.toml 可以设置 base_model = "openai/gpt-5"，然后只写 [cost] 和 [limit] 的覆盖值。最终通过 API 输出 JSON。README 明确说：provider fields win over model metadata during generation。
三个 API 端点，三种粒度
API 提供三个端点。curl https://models.dev/api.json 返回完整数据，包含提供商和模型信息，适合直接查找。curl https://models.dev/models.json 只返回模型本身的元数据，与提供商无关。curl https://models.dev/catalog.json 则同时包含两者。这种拆分让不同使用场景各取所需。如果你只关心模型能力，不需要价格，models.json 更轻。如果要做价格对比，api.json 或 catalog.json 更合适。另外，提供商 logo 通过 https://models.dev/logos/{provider}.svg 获取，provider 使用 Provider ID。没有 logo 时会返回默认 SVG。
base_model 继承：减少重复，但需要自律
base_model 机制是 models.dev 维护效率的核心。它允许提供商文件引用 models/ 下的模型文件，只写差异字段。规则很明确：base_model 必须指向 models/ 下的 TOML 文件，路径格式为 <provider>/<model-id>。覆盖时只能写提供商特有的字段，不能重复描述、日期等。嵌套表如 [cost]、[limit] 是整体替换，不是深合并。数组和原始值直接替换，普通对象深合并。还有 base_model_omit 选项，用点路径字符串移除继承的字段，例如 base_model_omit = ["limit.input"]。这套机制能避免大量重复，但要求贡献者严格遵守覆盖规则。一旦有人把相同字段写进多个文件，数据就会不一致。
贡献流程：从 provider.toml 到 logo.svg
添加新提供商有固定步骤。首先在 providers/ 下创建目录，里面放 provider.toml。这个文件包含 name、npm 包名、环境变量键和文档链接。如果提供商没有 npm 包但提供 OpenAI 兼容端点，就设置 npm = "@ai-sdk/openai-compatible"，并加上 api 字段指定基础 URL。然后必须添加 logo.svg，要求使用 currentColor 填充，不能有固定颜色。最后在 models/ 目录下创建模型 TOML 文件，文件名就是模型 ID。如果 ID 包含斜杠，就用子文件夹。整个流程是手工操作，没有自动化工具。README 明确说：We need your help keeping the data up to date。这意味着数据的时效性完全依赖社区贡献。
维护成本与许可证：MIT 下的社区驱动风险
仓库使用 MIT 许可证，可以自由使用和修改。但维护成本不容忽视。数据全部存储在 TOML 文件中，每次模型更新或价格变动都需要手动编辑。没有自动化爬虫或验证机制。README 没有提及任何测试或 CI 流程。这带来的直接风险是数据滞后。例如一个提供商调整了输出 token 限制，如果没人提交 PR，API 返回的就是旧值。另一个问题是 base_model 覆盖规则复杂，新贡献者容易出错。README 举例了 reasoning_options 的写法，但这类细节需要仔细阅读。对于生产环境，依赖社区维护的数据必须谨慎。
替代方案：与官方 API 和模型注册表的差异
与 models.dev 最接近的替代方案是各提供商自己的 API。OpenAI、Anthropic 都提供官方的模型列表端点，数据实时且准确。但它们是孤立的，无法跨提供商比较。另一个方向是 Hugging Face 的模型库，它覆盖开源模型，但定价和提供商信息不完整。models.dev 的差异在于它把模型元数据与提供商服务细节分开，且专门服务于 AI SDK 生态。官方 API 没有这种统一的 Model ID 概念。如果你只需要单家提供商的数据，官方 API 更可靠。如果你需要跨提供商对比，models.dev 的 catalog.json 是现成的聚合数据，但必须容忍其滞后性。
编辑结论
适合需要以编程方式获取模型规格、定价与能力信息的开发者，尤其是使用 AI SDK 构建工具或服务的人。不适合需要实时价格或动态模型列表的场景，因为数据完全依赖社区手动更新，存在滞后风险。若采用，应先用 curl 检查 catalog.json 中目标模型的最新更新日期，并确认 base_model 覆盖规则是否满足你的查询需求。在依赖任何定价数据前，务必与提供商官方文档交叉验证。
社区笔记