判断一个模型是否支持「思考」：models.dev 与 OpenRouter 实测

接一个新模型前要回答两个问题：它支持思考吗？思考档位怎么传？用 models.dev 看能力清单、用 OpenRouter 看调用参数，两个公开 JSON 就能查清。附实测字段与 curl 示例。

接入一个新模型时，最先要回答的其实是两个很具体的问题：它到底支不支持思考（reasoning）？ 以及 支持的话，思考强度该怎么传？ 靠翻各家文档非常费劲，而且容易过期。

好消息是这两件事都有现成的公开数据源，一个偏「能力清单」，一个偏「调用参数」，组合起来就够用了。

方案一：models.dev —— 能力清单

models.dev 是一个开源的 AI 模型能力数据库，仓库托管在 GitHub，用 GitHub Actions 定时 sync 各家厂商的数据，对外只暴露静态 JSON。它被 opencode 等工具直接当作模型元数据来源，所以字段设计是冲着「程序判断」去的。

三个端点：

curl https://models.dev/api.json       # 带 provider 维度（含各家实际支持情况）
curl https://models.dev/models.json    # provider-agnostic 的模型元数据
curl https://models.dev/catalog.json   # 上面两者合并

实测体量（2026-09-18）：

每条模型记录里，和「思考」直接相关的字段有：

• reasoning：布尔值，是否支持思考
• reasoning_options：最有价值的一个字段，直接说明思考怎么控制
• tool_call / structured_output：工具调用与结构化输出
• limit：{context, input, output} 上下文与输出上限
• modalities：{input, output} 支持的模态
• knowledge：知识截止时间（8457 条里有 4369 条带值）
• release_date / last_updated、open_weights、status、family、cost

reasoning_options 的取值形如：

[{ "type": "effort", "values": ["none", "high"] }]
[{ "type": "toggle" }]

也就是说：toggle 表示只有开/关，effort 表示有档位，且档位取值直接列出来了。这比读文档靠谱得多。

查询某个模型的能力：

curl -s https://models.dev/api.json \
  | jq '."openai".models | to_entries[]
        | select(.value.reasoning)
        | {id: .key, opts: .value.reasoning_options, ctx: .value.limit.context}'

方案二：OpenRouter /api/v1/models —— 调用参数

OpenRouter 把各家模型归一化成统一 schema，每个模型带一个 supported_parameters 数组，看这个数组就知道调用时能传哪些参数：

curl https://openrouter.ai/api/v1/models

实测（2026-09-18）：458 个模型，其中

• 带 reasoning 参数的：330 个
• 带 reasoning_effort 参数的：202 个
• 另有 include_reasoning、structured_outputs、tools 等

除了参数清单，它还提供 knowledge_cutoff、context_length、pricing、architecture，适合直接拿来做路由和成本估算。

筛选支持思考档位的模型：

curl -s https://openrouter.ai/api/v1/models \
  | jq -r '.data[]
           | select(.supported_parameters | index("reasoning_effort"))
           | "\(.id)\t\(.context_length)\t\(.knowledge_cutoff)"'

两者怎么配合

实践建议：

1. 启动时拉一次、本地缓存，两个 JSON 都是静态文件，配合 ETag 或按天缓存即可，不要在请求链路上实时拉。
2. 以能力字段驱动 UI：如果 reasoning_options 是 toggle，就只给一个开关；如果是 effort，就把 values 直接渲染成档位选择器，不要硬编码 low/medium/high。
3. 做好回退：查不到就按「不支持思考」处理，避免把非法参数传给模型导致 400。
4. 两个源字段命名不同（reasoning_options vs supported_parameters），建议在本地归一化成自己的内部结构，业务代码只依赖内部结构。

参考

• models.dev：https://models.dev（api.json / models.json / catalog.json）
• OpenRouter 模型列表：https://openrouter.ai/api/v1/models