决策接口（Decisions API）可评估文本、图像或两者，并返回类型化答案，速度比响应接口（Responses API）快约10倍。它能给出条件为真的概率、固定集合中的选项或依据量规的评分，用于分类内容、路由请求及优先处理任务。可在游乐场（Playground）试用后再编写代码。该接口目前处于公开测试版，预计数周内 GA，唯一可用模型为 gpt-6-luna，需使用专用端点 POST /v1/decisions。请求包含模型、输入与问题三部分。

Decisions API 评估文本、图像或两者，返回类型化答案，速度约为 Responses API 的 10 倍。你可以得到某个条件成立的概率、从固定集合中选出一项，或按评分标准给出分数。用这些答案在应用中分类内容、路由请求、排定优先级。

可以在 Playground 中试用 Decisions API，先试验问题和输入再写代码。

Decisions API 目前处于公开测试阶段，预计几周内正式可用。当前只有 gpt-6-luna 一个模型，使用专用端点 POST /v1/decisions。

一个请求包含三部分：

• model：执行评估的模型，目前仅支持 gpt-6-luna。
• input：问题共用的证据，可以是文本字符串，也可以是包含文本和图像的用户消息。
• questions：要评估的内容，包括每个问题的类型、指令，以及允许的选项或评分级别。

响应包含一个 answers 数组。给每个问题一个唯一的 name 来标识其答案，API 会在响应中原样返回该名称。

选择问题类型

• predicate：检查某个条件，例如可见损伤或段落相关性。主要结果是 probability，即条件为真的估计值，0 到 1 之间。
• choice：选择一个选项，例如部门或内容类别。主要结果是 choice，即你提供的值之一。
• score：按有序级别对输入评分，例如问题严重程度。主要结果是 score，即各级别索引的概率加权平均值。

choice 和 score 都会返回离散选项上的概率。类别没有顺序时（如部门）用 choice；级别有序时（如严重程度）用 score，它取各级别数字索引的概率加权平均，因此分数可能落在两个级别之间。

应用需要上述答案类型时用 Decisions。如果需要生成符合自有 JSON schema 的对象（如提取字段或书面说明），应使用 Responses API 的 Structured Outputs；如果需要模型请求带参数的工具调用，应使用 function calling。

用 predicate 问题可以检查产品照片是否有可见损伤。请求把图像与指令组合在一起，要求查找裂纹、撕裂或凹痕：输入为一条用户消息，内容是文本「Inspect the product in this photo.」和一张 base64 内联图像；问题类型为 predicate，名称 visible_damage，指令询问产品是否有可见损伤，如裂纹、撕裂或凹痕，忽略阴影和包装损伤。

响应示例中，answers 里有类型 predicate、名称 visible_damage、probability 为 0.92。这个概率是模型对条件为真的估计，可按你选择的阈值标记照片待人工审核。

图像必须是内联 base64 data URL。该端点不支持托管在 HTTP 或 HTTPS 上的图片 URL，也不支持 file_id 输入。把 input_text 和 input_image 部分组合在一条用户消息中，即可结合指令或其他上下文评估图像。

choice 问题从你提供的选项中选出一个值。选项值要各不相同，描述要说明每个选项适用的情况。

下面的请求路由一条客户投诉。输入是「I was charged twice for my order.」，问题类型为 choice，名称 department，指令问该投诉应由哪个部门处理。选项包括：billing（付款、发票和退款）、technical（使用产品时遇到的问题）、shipping（配送和追踪）、other（这些类别之外的请求）。

响应示例中，choice 字段是所提供的值 "billing"，还带有各选项的 probabilities 数组（billing 0.95、technical 0.02、shipping 0.01、other 0.02）和 confidence 字段 0.93。设置阈值的指引见「解释答案」部分。

当类别无法覆盖所有可能的输入时，加入 other 之类的兜底选项，应用可以把这类结果送入通用复核队列。

score 问题按有序的 levels 评估输入。为每个级别定义标准，并从低到高排列。

示例请求的输入是「Export fails in Safari but works in Chrome.」，问题类型为 score，名称 severity，指令问问题有多严重。级别依次为：Cosmetic（仅影响外观，功能未丢失）、Workaround available（任务失败，但有其他方式可用）、Fully blocked（任务失败且没有变通办法）。

响应示例中，score 为 1.1，各级别 probabilities 为 0（Cosmetic）0.1、1（Workaround available）0.7、2（Fully blocked）0.2，confidence 为 0.55。

级别索引从 0 开始，这里 0 表示仅外观问题，1 表示有变通办法，2 表示完全受阻。返回的 score 是概率加权平均，因此可能落在级别之间；本例中 0.1、0.7、0.2 三个概率得出 1.1。答案还包含 confidence 和每个级别的 probabilities。score 概括了跨级别的分布；如果要选出单一类别，用 choice。

相互独立的问题可以放进同一个 questions 数组，对共享输入做评估。例如对一张产品照片，可以在一个请求里同时检查损伤并分类产品类别，每个问题可以用不同类型。

依赖于前一个答案的决策要分开发送请求。例如先检查是否有损伤，再根据结果决定是否请求维修类别。

问题要围绕可观察的标准来写。把不同的关注点拆成不同问题，让各选项含义互不重叠，定义评分级别时保证相邻级别的标准有明确区别。

predicate 返回条件为真的估计概率。choice 和 score 返回概率分布以及单独的 confidence 字段。

用应用中的带标签样本设定路由、过滤或审核的阈值，依据假阳性和假阴性的代价来选择。

使用 gpt-6-luna 时，输入价格为每 100 万 token 0.10 美元。只对输入 token 计费，没有缓存读取、缓存写入或输出 token 费用。

区域处理溢价和长上下文输入价格乘数仍然适用。这些费率适用于 /v1/decisions；其他使用 gpt-6-luna 的请求按适用的模型与处理层定价计费。

Decisions API 对符合条件的客户支持零数据保留（ZDR）和 HIPAA 用途。支持在美国和欧洲（EEA 加瑞士）进行数据驻留与区域处理。资格要求、所需协议和限制见数据控制文档。

使用 Live API 的客户端委派，可以从语音请求中选择操作，并把结果报告给用户。

讨论整体偏向怀疑：多数人承认 OpenAI 跟进决策类模型在预期之内，但争论焦点是它到底有没有护城河——一方认为决策模型本身太容易复现、纯属价格战，另一方只认可图像输入这一项现实差异。

这是意料之中的快速跟进，Jev 已经证明了方向

• 早前就有人判断 OpenAI 会很快跟上，现在看果然如此，接下来值得观察其他大厂是否跟进（较多人）
• Jev 靠"快、便宜、只要一个是/否/置信度"打出了系统一模型的价值，开源版本随即涌上模型社区，如今大厂宁可放弃一部分输出 token 的驱动力也要留住客户（较多人）
• 事后回看，这一步几乎是必然的（较多人）

质疑它没有护城河，决策模型本身就是商品

• 跑一个可比的决策模型很便宜也很简单，OpenAI 真正的本钱是能跑超大参数模型的机房；决策类服务既不难做也不贵，看不出为什么要为此付费（较多人）
• 这轮价格战应该能定论 AI 业务是不是商品市场：如果真是，OpenAI、Anthropic 该做的是让产品尽可能黏，否则用户会涌向最便宜的那个（较多人） > 跑一个决策模型容易得多也便宜得多，他们真是在蹭这波热度吗？（@dvt）
• 社区里还流传着一句反问：知道一个罐头有没有凹痕，这信息到底值多少？——可以代表对"是/否判断"价值的整体调侃（少数人）

实测下来比 Jev 更慢、更贵、置信度更差

• 有人用自建评测集（UI 组件选择、聊天图表、标签选择、个人知识管理场景，不到 600 次调用）在 OpenRouter 上对比了 Jev 和 Mercury Decide：延迟比 Jev 高，与 Mercury Decide 相当，但不像后者那样随输入线性增长；在模糊的 UI 组件和特定响应结构任务上置信度更低，0.6 以下常常不达标；出现了两个竞品都没有的失败调用；平均成本是 Jev 的约 3.1 倍（少数人）
• 结论是整体偏"半生不熟"，希望前沿实验室别急着跟风，直到能在价格或性能上拿出竞争力；不过此人尚未测试图像输入，也承认自己的用例不一定有代表性（少数人）
• 同一人还顺带批评近期一连串发布都像在克隆既有竞品，并提醒参照某款浏览器产品的快速退场，对这类新东西不必投入太多（少数人） > 我这套用例里它比 Jev 慢、贵、能力也差，跟 Mercury Decide 大致持平。（@Topfi）

图像输入是目前对 Jev 最实在的差异

• 决策接口已经支持图像输入，而这正是此前在 Jev 上发现的第一个大缺口（较多人）
• 至少在当下，能收图像是两者之间一个明确区别，而图像输入是相当普遍的需求（较多人）

端点形态本身可能成为行业事实标准

• 从实测调用看，接口返回的是带概率的谓词结果，输出 token 计数为零，输入约 310 token；这类由 OpenAI 亲自定义的端点，往往会顺带成为其他厂商的事实标准（较多人） > 通常 OpenAI 一旦定义这样一个端点，它最终会成为其他厂商的事实标准。（@simonw）

期待决策能力被内建进模型本身

• 好奇为什么"决策路由"不直接整合进所有模型，而要单独开一个接口（较多人）
• 这让人想到早期补全 API 与指令 API 并存的阶段；问题是这种能力未来会不会被折进模型和后训练流程，从而让模型输出更校准（较多人）

有价值的补充

• Python SDK 3.26.0 版已覆盖该接口，已经在用 SDK 的人不必手写 HTTP 调用
• 想在 CPU 上跑决策模型的，可以看看 gutsy
• 冷知识：郁金香狂热时期最贵的"火焰纹"郁金香其实是被郁金香碎色病毒感染的产物——泡沫的成因往往就是泡沫本身的一部分
• 有人想拿它试视频游戏操作（例如体育类游戏），因为现有的最快模型都太慢，而这类接口又快又能读图，值得一试
• 也有人关心实际使用层面的问题：定价与 Jev 相比如何、能否走订阅、基准测试数据在哪里