9 月 15 日，TypeSafe AI 发布 Jev：输入一段业务信息和一组问题，它直接返回可供程序使用的选择、评分或概率。9 月 29 日，OpenAI 在 DevDay 宣布 Decisions API，也让开发者在预设答案中选择，并将结果用于内容分类、请求路由和 Agent 下一步行动。两个产品瞄准了同一类高频判断。TypeSafe 的发布说明与OpenAI 的发布回顾都确认了各自的产品方向。
这足以说明 Jev 遇到了直接竞争，却不足以宣判它已经出局。对正在搭建 Agent 或自动化流程的团队，更实际的问题是：在自己的任务上，谁能以可接受的成本和延迟，给出足够可靠的判断？
两家公司争的是同一个工作环节
设想一套客服系统收到新工单。程序需要判断它该去账单、技术支持，还是销售队列。调用聊天模型当然也能完成：写提示词、要求只输出标签，再解析返回的文字。但工作流最终需要的是一个可执行的类别，而不是一段解释。
Jev 把这类工作拆成三种问题。Choice 在给定选项中选择，并返回各选项的概率；Score 按预先定义的等级评分；Noul 返回一个是非判断的概率。TypeSafe 的文档说明，Choice 与 Score 还提供置信度，Noul 则没有单独的置信度字段。Choice 最多支持 255 个选项。这些是产品接口能力，不意味着每个概率在任何业务数据上都准确。TypeSafe 产品文档、Choice 说明、发布说明。
OpenAI 的 Decisions API 使用 Luna，接受文本或图片上下文，让开发者定义有限答案，再返回可用于分类、路由或行动选择的结果。它与 Jev 在“把开放式生成收窄为程序可用的判断”这一点上相近；但截至 10 月 3 日，OpenAI 公开的发布回顾只明确了有限预览与上述用途，没有给出足以核对其定价、候选答案上限或概率校准方式的完整公开说明。不能把普通 GPT-6 Luna 的 API 价格直接当作 Decisions API 的价格。
报道转述的演示数字是：Decisions API 完成一次判断约 150 毫秒，普通 Luna API 约 1.6 秒。这比较的是 OpenAI 自己的两种调用方式，并非 Decisions API 与 Jev 的对测；演示条件也不能代替生产环境的延迟保证。OpenAI 演示图的新闻记录。
Jev 有明确报价，OpenAI 仍有关键空白
TypeSafe 公布的 Jev 价格为每百万输入 token 0.042 美元，输出 token 不收费；它声称端到端响应通常为 70—500 毫秒，在其选定的结构化任务中较通用大模型更快、更便宜。这些是供应商价格与测试口径，具体任务仍须另测。TypeSafe 当前模型报价、发布时的速度说明。
Jev 的商业热度同样需要分清状态。《金融时报》署名记者 Michael Acton 的报道称，TypeSafe 此前估值约 2 亿美元，随后收到了按 100 亿美元或更高估值讨论的潜在投资意向。这是融资洽谈中的估值，不能写成公司已经以 100 亿美元完成融资，更不能用它证明 Jev 已经赢得市场。
这家公司也并非只靠一个新接口吸引关注。创始人 Diogo Almeida 是 InstructGPT 论文的作者之一，列在 OpenAI 的 GPT-4 贡献名单中；TypeSafe 团队页同时列出 Erik Gafni 和 Sasha Sheng。团队背景解释了市场为何认真看待 Jev，却无法替代对产品准确率的验证。
OpenAI 的优势是现成的开发者入口。如果两家的判断质量和总成本接近，已有 OpenAI 集成的团队可能更愿意在原平台接入新功能。这是基于集成成本的商业推断；目前没有公开证据说明 Decisions API 已与哪些 OpenAI 产品打通，也没有同条件的价格和准确率比较。
模仿输出形式，离复制竞争力还有一段距离
Jev 的接口形式已经有人复现。Bespoke Labs 发布的 Nimble在 Qwen3.5-9B 基础上训练，用候选答案对应的模型分数生成选择和概率；Kev-0.5B则以更小的 Qwen2.5 模型、LoRA 适配器和额外的选择模块做研究原型。这说明“返回有限答案”并非 TypeSafe 独有，却不能证明这些项目复制了 Jev 的内部架构、训练数据或实际表现。TypeSafe 自称采用新的架构、并行采样和面向概率校准的训练方法，尚未公开足以独立确认全部内部细节的材料。TypeSafe 发布说明。
真正难比较的是概率质量。比如客服系统把“属于账单问题”的概率阈值设为 0.9：模型报出 0.9，长期来看究竟有多少次判断正确？在分类和路由里，错误的高置信判断可能比慢几百毫秒更昂贵。对 Jev 的一项独立预印本评估在 37 个数据集上发现，其 Choice 概率校准表现较好，但二元概率用固定 0.5 阈值时仍有问题。这是特定模型版本和测试集的结果，不能直接外推到所有企业流程，更不能拿来推断尚未公开对测的 Decisions API。
原文引用的 Reddit 讨论中，一名用户声称在 800 条记录、每批 20 条的内部测试里，普通 Luna 比 Jev 快 1.6 倍、成本高 1.2 倍、准确率大致相同。该帖没有提供足够信息复核数据集、计时和准确率定义；它比较的也不是 Decisions API。因此，这个数字只能作为用户自述，不能作为产品选型结论。
如果现在要选型，先测这四件事
第一，用自己的真实任务准备测试集，保留难例和“没有合适选项”的情况，分别记录正确率与误判代价。第二，在相同输入、并发和部署地区下测延迟，至少看中位数和高分位数，而非只看发布演示。第三，核算完整流程费用：输入 token、必要的前处理、重试、人工复核与接入成本。第四，检验概率能否支持你的动作阈值；高风险判断应有回退或人工审核路径。
这四项是选型建议，不是对任何一方的实测排名。眼下能确定的是，OpenAI 已进入 Jev 所在的产品方向，而 Jev 有公开的价格与接口细节。下一步决定 TypeSafe 位置的，不是“谁先宣布了相似功能”，而是两家产品在相同业务任务里的准确率、概率校准、稳定延迟和总成本。