OpenAI 的 Decisions API 止于何处、Jev 始于何处：首位外部客户展示了什么

2026年10月6日23:05 UTC，一个名为llm-openai-decisions的插件在 PyPI 上发布，其自带的 README 中包含了一句发布报道从未刊出的话：“与 Jev 不同，新的gpt-6-luna决策模型除文本外还支持图像输入。”作者是 Simon Willison，他也为 TypeSafe 的决策模型编写了首个客户端，而他所作的对比是在GPT-6 Luna——OpenAI Decisions API 背后的模型——与Jev 1.13（TypeSafe 仅支持文本的 System One 模型）之间。同一篇博客文章还指出，该插件本身是由GPT-6 Astra阅读 OpenAI 的文档写成的。

一个客户端在某个 API 发布一周后才发布，其有用之处就在于此：它是依照请求结构来编写的，而不是依照主题演讲，因此它能暴露出营销文案所抹平的差异。这里没有任何内容是泄密，也没有任何内容未经证实——下文每一个数字都来自 OpenAI、TypeSafe 或该插件自己的仓库所发布的页面，且均于 2026-10-07 查阅。仍然缺少的是对该端点本身的独立测量，而这一缺口会在末尾说明，而不是被粉饰过去。

三个表面，彼此分隔

首先要弄清楚的是，这是三个不同的层面，而媒体报道模糊了它们。

• 端点。OpenAI 的是 POST /v1/decisions，它是一条专用路由，而不是 Responses API 上的一种模式。TypeSafe 的是 POST /v1/systemone。两者都接收一份证据，加上一组带类型的问题，并按你为每个问题指定的名称，为每题返回一个答案。

• 模型。Decisions API 目前只接受一个模型，gpt-6-luna，它同时也是 OpenAI 通用 GPT-6 系列中的廉价档位，于 2026-09-22 作为普通文本与图像模型发布。Jev 1.13 则是彻头彻尾的决策模型——它完全无法输出自由文本。TypeSafe 于 2026-09-15 发布它，并自 2026-09-21 起正式全面可用。

• 客户端。自 2026-10-06 该端点开放公开测试以来，OpenAI 自家的 SDK 就一直在支持它，因此这个插件并不是调用它的第一种方式。但它是我们目前能够验证的、OpenAI 自家 SDK 之外的第一个客户端，也是第一个为命令行工具而非应用库而编写的客户端。

两米，并排放置

这里正是客户的 README 比公告更有价值的地方，因为数字就紧挨着措辞。

• 价格 —— Decisions API 每百万输入 token 收费 $0.10，不收输出费、缓存读取费和缓存写入费。Jev 1.13 每百万输入 token 收费 $0.042，输出免费。两者都对发送的内容收费，对返回的内容不收费，因此在任一价格下，一次决策的成本都不到一美分，而两者之间的差异是 2.4 倍，而不是不同的计费模式。

• 输入——Decisions API 接受文本，或文本与图像混合的用户消息，且该插件的 README 说明支持 PNG、JPEG、WebP 和 GIF 附件，单次请求中最多可包含 128 张图像。图像必须以行内 base64 数据 URL 的形式传入；托管的 HTTP 或 HTTPS 图像 URL 以及 file_id 输入均不被该端点接受，因此插件会在发送前先转换 URL 或本地路径。Jev 1.13 的文档在相反方向上则毫不含糊：“不接受图像、音频或视频输入”，非文本输入应先预处理为文本或结构化字段，再进入状态。

• 问题类型 —— OpenAI 记录了三种：predicate（所述条件成立的概率，取值 0 到 1）、choice（从你的列表中选取一个值，外加一个分布和一个独立的置信度字段），以及 score（在有序层级上的概率加权平均值）。TypeSafe 的三种类型与这三个概念相同，只是名称不同：noul对应是/否，choice，以及score。“Noul”是 Bernoulli 的缩写，这个名字恰好体现了文化差异——一家厂商给出的是大白话名词，另一家给出的则是一个统计学梗。

• 评分算术——两者完全吻合，这是表明它属于同一个产品类别而非两个类别的最有力迹象。OpenAI 的文档为三个严重级别分别赋予 0.1、0.7 和 0.2 的概率，返回的分数是 1.1——刻意落在两个级别之间，而不是取整到最接近的那个。TypeSafe 的级别同样从零开始索引，而 Jev 的插件接受两到十个有序级别。OpenAI 的页面未说明上限；这是其文档中的一处缺失，而非我们可以断言的限制。

• 预算——Jev 精确记录了自己的窗口：每个请求约 64,000 个 token，其中约 32,000 个用于承载状态加上最长的那一个单独问题，而我们自己的目录中作为通用模型的 GPT-6 Luna 所携带的上下文为 1,050,000 个 token。OpenAI 的决策页面根本没有公布任何 token 预算，只注明区域性处理附加费和长上下文输入倍数仍然适用于该费率。

客户透露了公告未透露的内容

插件及其 README 中有三个细节值得单独拿出来说，因为每一个都会改变你配置端点的方式。

第一点是，一个 decision 可能会以 refusal 的形式返回。OpenAI 的文档从未用文字解释过这一点，但每个 SDK 示例都会对它做分支判断——answer.type === "refusal"（JavaScript 中如此，Ruby 中则是 OpenAI::Models::Decision::Answer::Refusal 这个 case）——而且该插件的 README 明确指出，被拒绝的提问会以 {"name":"...","type":"refusal"} 的形式保留下来。因此，answer 类型实际上有四个取值，而不是三个，任何生产环境的循环都必须处理一个没有任何公告提及过的第四个分支。

第二点是插件中缺失的内容，而不是其中存在的内容。Willison 自己的文章将这项工作描述为让 GPT-6 Astra 阅读新文档并据此构建客户端——从文档到客户端，一次完成，无需人工教程。如今这已成为编写客户端的一种常规方式，这意味着一个端点的文档是否完整到足以据此生成一个可运行的客户端，这个问题已经变成了一个实践问题，而不是编辑问题。对于这个端点，答案基本上是肯定的，而拒绝类型则是可见的接缝。

第三点是问题数组的形态。你可以把多个问题放进同一次输入——在一次调用中既检查产品是否有破损，又对其品类进行分类——但如果后一个问题依赖前一个问题的答案，就必须拆成相互独立的请求。Jev 出于同样的理由采取了相同的立场：它的问题是针对同一个状态并行执行的，因此任何有先后依赖的事情都必须变成两次调用。两家厂商都是为扇出而设计的，它们向你传达的是同一件事：延迟预算究竟该花在哪里。

该类别现在有三个成员，其中两个不是通用模型

值得点名第三个，因为只有把三者都纳入视野，决策端点这一框架才说得通。Perplexity 也推出了自己的 Decisions API，由 pplx-decider-v1-27b——一个 270 亿参数的决策模型——提供服务，该模型于 2026-10-01 以 Apache 2.0 许可发布，权重已上传至 Hugging Face。这让该品类呈现出与 OpenAI 真正不同的形态：Jev 1.13 是闭源的且仅支持文本，Perplexity 的决策模型则是开放权重的，并接受图像输入，而 GPT-6 Luna 的入场之作是一个围绕通用模型搭建的框架，而非一个为决策而生的模型。

对今天做选择的读者来说，实际分野比宣传的要窄。如果你的证据是一句话或一条记录，并且你想要最低的单次调用成本、同时行为差异最小，那么 Jev 1.13 是那个专精者，其 $0.042 的费率是我们能核实的三项公布价格中最低的。如果你的证据包含一张照片，或者你希望由一个你已在日常任务中熟悉的模型来做决定，那么 Decisions API 是两个闭源选项中唯一接受图像的。开放权重选项回答的是另一个问题——控制权与自托管——而我们尚未测试它。

我们实际能测量什么，以及无人拥有什么

OpenAI 对该端点的说法是，它“评估文本、图像或两者，并返回类型化答案，速度比 Responses API 快约 10 倍”。这是厂商自述且未经复现：没有区域、没有输入规模、没有并发级别、没有服务等级协议，而且基线是泛泛的 Responses API，而不是任何具体工作负载。仅凭单一的加速数字来设定截止期限，是用错了数字。

我们能在它旁边列出的，是我们自己在下方这两个模型上、基于 playground 流量得出的、截至 2026-10-07 的七天服务窗口数据——而且有必要说明这些数字不是什么。它们描述的是普通的生成请求，而不是决策。

GPT-6 Luna，所有请求形态：中位数为 1,448 毫秒，p95 为 4,912 毫秒，七天内 643,394,111 个 token 的错误率为 1.31%——这就是模型生成时约每秒 125 个输出 token 的吞吐量所呈现的样子。

• Jev 1.13：中位数为 149 毫秒，p95 为 245 毫秒，在 110,193,080 个 token 上错误率为 0.10%。这是一个真正快速的端点，它之所以快，是因为它不生成响应——它返回的是对只摄取一次的状态的数字。

把这两行放在一起对照来看，它们是一个警示，而不是一种比较。一次决策请求只会发出少量 token，因此在 Decisions API 上，那个在 Luna 总体画像中占主导地位的输出吞吐量数字不再构成约束瓶颈，而开始变得重要的数字，是模型读取证据所需的时间。我们尚未在决策端点上测量过这一点，而据我们所知，OpenAI 之外的任何人都没有公布过这一数据。

更深层却未被衡量的问题是校准，而正是它决定这一切是否有用。可见损伤的概率为 0.92，只有在你的全部流量中，评分接近 0.92 的照片大约有 92% 确实存在损伤时，才值得据此进行分流。OpenAI 的文档告诉你，要根据带标签的示例设定阈值，并依据假阳性与假阴性的成本来选择阈值。这是正确的建议，同时也等于承认：这些数字的校准必须由你自己来确立。作为初步验证，先在一个你已知答案的样本上测量返回概率的分布。如果返回的结果全是 0.99 或 0.01，那么阈值就毫无作用，这个端点就是一个非常昂贵的布尔值。

如何在不拿生产路径去赌的情况下试用其中任意一个

来源说明，直白地说：本文中的端点契约、价格和图像规则来自 OpenAI 自己的 Decisions API 文档和该插件的 README，两者均于 2026-10-07 查阅；Jev 1.13 规范来自 TypeSafe 自己的模型文档；服务数据是我们自己的 playground 数据，覆盖截至 2026-10-07 的七天窗口；软件包时间戳来自 PyPI 和该项目的 Git 历史记录。10 倍速度的说法是 OpenAI 的，并已如此标注。开放权重决策器的许可证和发布日期来自其模型仓库。

Decisions API 本身是 OpenAI 自家的封装，我们并不为其提供路由；如果你想要的是那个特定的端点，它就在 OpenAI 那里。底层的模型则是另一回事。GPT-6 Luna 是 OrcaRouter 上的一条实时路由，按 OpenAI 的标价提供，零加价转嫁，而 按标价提供的 typesafe/jev-1.13 也在同一个密钥下，这让本文中的对比成为你可以实际运行、而不只是阅读的东西：相同的状态、相同的问题、两个端点、一份需要管理的合同，而且不会有第二张账单。

这也是采用一种尚未经验证的接口的稳妥做法。把这项决策放在降级方案之后，这样即使遭到拒绝、超时，或者 beta 限制在你脚下发生变化，也会退化成一次基于提示词的调用，而不是一次服务中断；并且把这个降级方案与主方案挂在同一个密钥上，这样当该端点走向全面可用时，就无需重新接线。OpenAI 表示，预计全面可用将在未来几周内到来，而且gpt-6-luna在此期间是唯一可用的模型；这两点都是现在就针对其形态进行构建并加以观测的理由，也都不是现在就把它放到支付授权背后的理由。

接下来看什么

有三件事可以解答本文无法回答的问题。为 decisions 端点公布一个 token 预算，这样请求就可以被估算，而不是靠猜。任何 GA 公告——那正是纯输入计费不再只是 beta 承诺的时间点。还有一项对该端点自身延迟与校准的独立测量——第一个把几千对已标注样本跑通并公布可靠性曲线的人，对这个品类所做的贡献，会比那两篇发布文章中的任何一篇都更大。

在那之前，诚实而又有用的总结是这样的：如果你需要决定的东西是文本，Jev 1.13 更便宜，并且在我们流量中大约 150 毫秒内返回数字。如果你需要决定的东西包含图像，OpenAI 的 Decisions API 才是会查看它的那个，价格是输入价的 2.4 倍，包装上还带着 beta 标签。截至本周，两者都可以从命令行调用，这比七天前它们中任何一个的处境都要好。