“System One”作为一个模型类别：Jev 1.13 在其中所处的位置

“System One”是 TypeSafe 用来指代其将做决策的模型与负责撰写的模型相分离的类别术语，而 Jev 1.13（typesafe/jev-1.13）是它的首个成员——一个返回类型化答案而非句子的模型。它不是新模型。TypeSafe 于 2026-09-15 发布了 Jev，而本页并非发布稿：该模型已有十五天，超出了本博客所覆盖的七天窗口。窗口内发生的是，OrcaRouter 于 2026-09-24 将该模型加入其目录，并在 https://www.orcarouter.ai/models/typesafe/jev-1.13 为 Jev 1.13 开设了模型卡片——这是它首次可通过第三方网关调用，而不再仅能通过 TypeSafe 自己的端点。类别理念是本页存在的原因；服务变更则是它在今天被标注日期的原因。

这个类别的通俗版本是：LLM 被问一个问题，然后写出答案供人阅读。System One 模型被问一个问题，然后返回一个值，供程序据此分支。TypeSafe 自己的说法是，“LLM 为人产出文字”，而“Jev 产生带类型的决策，更像代码：可靠、快速、自洽且类型安全”。这句话把整个类别压缩进一个分句，值得慢慢拆解，因为这四个形容词承担的工作量各不相同，而其中一个所做的比其他几个更多。

“更像代码”实际上在主张什么

按顺序来看这四条主张，因为它们并不是对“它更好”的四次重述。

• 可靠——输出形态是预先固定的。你声明问题，答案只可能以你允许的取值之一返回。TypeSafe 明确表示，“模型从不产生类型错误”，并指出这是他们的主张中唯一一个在数学上“不可能”用反例证伪的，因为不在你所声明集合中的值，不是模型能够输出的值。

• 快速 — 所有答案都通过单次生成得出，而不是一个 token 接一个 token 地生成。TypeSafe 的发布文章将其表述为：“Jev 并行输出所有概率，而不是按 token 自回归生成。”在我们自己截至 2026-09-30 的七天服务窗口内，typesafe/jev-1.13 的首个 token 时间中位数为 151 毫秒，p95 为 247 毫秒。

• 自洽 — 同一状态面对同样的问题，往往会给出同样的答案。用一个编程类比能让这一点变得清晰易懂，但这也正是类比不再构成证明的地方：编译器的确定性是其构造方式的一种属性，而这里所说的则是对一种行为的断言。我们自己的测量才是对此最诚实的解读——在同一个七天窗口内，我们演练场流量的错误率为 0.49%，所以它的自洽就像一个好函数那样自洽，而不是像算术那样自洽。

• 类型安全——而这一条分量最重。在这里，“类型安全”并不是一个形容品质的形容词，而是一种关于模型相对于类型检查器所处位置的陈述。在普通的生成式流水线中，类型系统在模型完成之后才开始运作：模型写出文本，解析器猜测其形态，验证器对其加以检查，失败路径则处理猜错的情况。而 System One 模型把类型声明移到了调用之前。我们卡片所记录的那三个原语，就是这套类型系统：noul，一种附带校准概率返回的真/假判断；choice，从最多 255 个带标签的选项中选出的一个标签；以及score，在 2 到 10 个等级的有序量表上给出的评分。你选定原语，提供标签或判定标准，而返回的值就取自那个集合。

TypeSafe 确实公开指出了其自家文档与我们文档之间的一处差异，这处差异值得说明，而不是去消解：厂商的文档展示了一个从零开始索引的 Score 示例，而我们的说明卡则将该等级标度记载为 2 至 10 个级别。两者描述的是同一个原语。如果你要构建阈值，请查阅厂商的页面，以确认你的 SDK 所用的确切索引方式。

两种不再存在的失效模式

“不用散文体”带来的有趣后果并不在审美层面，而在于：在生产环境的生成流水线中占主导地位的那两类失败，在这一设计里是根本不存在的，而不是被它缓解了。

格式漂移是第一位的。被要求返回 JSON 的 LLM 大多数时候会返回 JSON，其余时候则返回某种与 JSON 相近的东西——尾随注释、Markdown 围栏、被改名为同义词的字段、schema 本想要字符串却给了嵌套对象。提示词层面的修复手段（更强的指令、少样本示例、系统消息中的 schema）都只是在试图维持一种模型随时可以放弃的形态，因为这种形态是一种请求，而不是约束。TypeSafe 的表述把这种对比讲得很清楚：对于字符串，“可能的输出和结构”是被请求的，响应“需要被解析 + 验证”，并且“总有一定风险，AI 会偏离正轨”。当可能的输出被预先声明时，漂移便无处可去。

无法解析的输出是第二种，而且它实际上是在更糟糕的时刻出现的同一种失败——不是某个返回时略有偏差的字段，而是解析器完全读不出来的响应，偏偏还出现在工作流中最不方便的节点上。而能够输出带类型值的模型则不存在这种状态。

这是一个结构性论证，它就应当作为一个结构性论证来陈述。它并未说明某个具体答案是否正确——选择题可能选错标签，而 noul 也可能在诚实答案为假时以高置信度返回 true。真正消失的，是解析器本会捕捉到的那一类失败。这是一种实实在在且有用的削减，但它与“答案是正确无误的”并不是同一个主张。

为什么价格是一种形态，而不是折扣

该模型的定价为每百万输入 token 0.042 美元，输出计费为零——而这个零并非促销价，而是设计使然。一个只输出三个 token 结构化答案的模型，没有可计量的输出量，因此按输出 token 计费也就无从附着。计费形态是按输入 token 收费，外加一项决策。我们的目录以 0% 加价率透传提供商的标价，因此 0.042 美元是 TypeSafe 的数字，而不是我们设定的数字；供应商一旦调价，当天就会生效。

把这两种形态并排放在一起，差异并不是一个百分比。生成式流水线的成本，随模型说了多少而伸缩：同一个决策，冗长的回答比简洁的回答更贵；而思维链推理模型会为它在作答前用于思考的 token 计费，无论答案是否因此变得更好。而一次 System One 调用的成本，则随你给它看的内容多少而伸缩——也就是状态和问题。针对一份长文档只问一个问题，你就要为整份文档付费。而针对同一份状态塞进四十个问题（我们卡片上的输入预算是状态与问题合计 65,536 个 token，约 64K；如果你在早前的 OrcaRouter 文章中见过“约 32,000 个 token”这个数字，那只是状态预算，并不是另一个与之竞争的总量），你只需为文档付一次费，就能拿回四十个决策。

这就是为什么对于这一类场景，正确的单位是每次决策成本，而不是每 token 成本——也是为什么计量方式与大多数团队的预期正好相反。生成式成本削减的典型做法是“让模型少说点”。而在这里，没有什么可少说的。

TypeSafe 自家公布的数字由供应商提供，尚未被独立复现，且直指那一对比：“快 193.6 倍，便宜 444.6 倍”，脚注为“基于 System One 任务的工作流（证明）”，并给出了一个计算示例：“TypeSafe AI 成本 $0.000081，在 0.114 秒内完成 / LLM 成本 $0.013880，在 8.566 秒内完成。”首页还列出“每十亿输入 token 42 美元”，对比“输入价格比 Claude Fable 5.1 低 238 倍”。要把这一切都视为供应商的论点，而不是实测结果：发布文章承认，“我们公布的评估通常是在西海岸的笔记本电脑上运行的”，并且“我们无法证明它没有获得补贴；我们需要长期来证明我们定价的可持续性（我们预计价格会下降，而不是上涨）。”这两处让步都出自供应商自己，也是看待页面上每一个倍数的正确框架。

校准是这个想法的后半部分。

如果这个类别仅仅是“结构化输出”，那它描述的不过是多加了几步的函数调用。让它自成一类的地方在于，每个答案都附带一个概率，而这些概率就是训练目标。TypeSafe 将这一方法称为 Reinforcement Learning for Calibrated Decisions（RLCD）——这是他们自己的术语，不是通用缩写——发布文章中的对比表把它与 RLHF 和 RLVR 并列：RLHF 优化的是人类评分者偏好的东西，RLVR 优化的是可程序化检查的输出，而 RLCD 优化的是“在 System One 任务上给出认识论上诚实的概率的答案”。

实际差别在于这个概率是用来做什么的。在生成式流水线中，置信度估计是二次生成：你问模型它有多确定，它写出一个数字，而这个数字本身就是一段带有同样失败模式的文本。在这里，概率是与决策一起、在同一轮中返回的，而它正是你据以分支的依据。TypeSafe 自己对收益的表述是：一个能在 95% 的情况下完成任务的模型，如果“不会说明自己何时落在那 5% 里”，就无法用来自动化该任务；而置信度为你提供了一个安置升级处理的位置——升级给人工，或升级给推理模型。

TypeSafe 的主页将这一点表述为“零幻觉”，并解释说每个决策都附带一个置信度估计，因此软件可以“在置信度高时行动，在置信度不高时升级处理”。请仔细读这句话：它是一个关于置信度估计的主张，而非一个声称任何回答都从不出错的主张。我们自己的卡片正是与之相衡的另一面——在截至 2026-09-30 的七天里，在我们的流量上，由我们自行测得 0.49% 的错误率。这个数字是一个滚动窗口，而非固定的测试集：就在几天前，同一窗口的读数还是 0.57%，而且它还会再次变动。

系统一与系统二并排之处

“快/慢”这套词汇远早于 TypeSafe 出现。它源自卡尼曼的 《思考，快与慢》，并且在此之前的许多年里就一直被 AI 研究者借用——早在 TypeSafe 存在之前，“系统 2”这个标签就已经被贴在思维链和审慎推理模型上了，而 TypeSafe 也并未声称自己创造了其中任何一个术语。他们所做的，是把这一区分应用到了产品边界上，而不是某种提示模式上。

• 系统二推理模型在作答前会消耗更多算力，并且在需要这种能力的难题上表现更好。它的输出仍然是文本，而额外的算力会按输出 token 计费。

• 在 TypeSafe 的意义上，System One 模型不会为了给出更好的答案而思考更久。它一次就能作答，而它为速度所放弃的，是生成除类型化值以外的任何东西的能力。

• 二者是工作流中的互补，而非比较中的对手。一次 System One 调用负责那些必须快速、低成本且清晰可辨的决策；推理模型则接手那些被置信分数标记为不确定的案例。带类型的输出正是让交接变得干净利落的关键——你传给下一阶段的是一个值和一个概率，而不是一个需要重新解析的句子。

术语变得含混的地方，在于把"System One model"当作其他厂商已经采纳的既定类别来对待。这一点并无证据支持，本页也不应被解读为在如此声称。TypeSafe 用这个词来指称它自己的一类模型；我们自己卡片中的免责声明也以省略的方式表达了同样的意思——只为一个模型列出单一端点类型。如果另一家实验室开始用这个说法来指称同一种架构，那将是一个值得报道的事实，而且报道时需要用他们自己的话。

我们的卡片还把参差不齐列为诚实边界的一部分，而不是把它当作意外：九种已命名的失败模式。字面解读和间接表达这两项，直接源自“更像代码”的类比——一个模型回答了你写下的问题，而不是你想问的问题，它就像一段严格按照代码所述执行的函数。计数这一项则不然。一个“识别答案的形状而不是逐项计数”的模型，根本不像代码，这正是 TypeSafe 自己建议用代码去计数、并且在确实需要判断时，对每个条目只问一个问题、然后自己把答案加总起来的原因。

两个限制塑造的是设计，而非分数

两者同源：没有字符串，就意味着没有可流式传输的内容，也没有可分段发送的内容。

• 非流式——首个输出就是最终答案，因此 System One 调用是单一响应，而不是流式。问题不在于它能否流式输出，而在于什么会流式输出。

• 一种请求形态——该模型在我们的目录中通过 POST /v1/systemone 提供服务，而不是采用 chat-completions 形态；对于它“说自己的请求形态”这一较早说法，这才是诚实的版本。你在调用方式上确实存在差异：传入一个状态对象和一个具名问题映射；每个问题返回一个结构化答案。你需要为它编写一个映射器，而且由于输出是带类型的，这个映射器就是整个集成——它下面没有防御性解析层。

在压测之前值得了解：延迟在不同问题类型之间并非一致的。TypeSafe 用他们自己的话解释了原因——“对于更高基数的选项，我们会采用两阶段系统：先独立打分，然后做出明确选择，因此偶尔会出现变慢。”一个 4 选项的路由决策和一个 200 选项的分类，在纸面上是同一种原语，在实践中却是不同的工作量。截至 2026-09-30 的七天里，我们的每日中位数依次为 175、170、163、161、170、147、143 ms。该序列中的一天，2026-09-28，其 p95 为 2,448 ms——这是一个真实的单日离群值，它如实地存在于该序列中，但并不代表该服务的形态。

首次集成前，另一件需要了解的事是你连接的是什么。围绕 Jev 的工具链以 MIT 和 Apache-2.0 许可证开源——包括 Python 和 JavaScript SDK、一个以普通 LLM API 为后端呈现同一客户端的适配器、workflow-evals 代码，以及一组 agent 技能，它们都在 TypeSafe 的公开仓库中，其 star 数和推送日期最近在 2026-09-26 和 2026-09-29 还有变动。模型则不是。没有权重仓库：Jev 的架构、参数数量、训练算力和权重均未发布，而查验这一点的人不应被该组织中的三个仓库误导——它们是与无关项目的 fork：一个 vLLM fork、一个 2025 年的扩散语言模型发布版，以及一个 Pulumi provider。它们都没有说明 Jev 是如何构建的。一句话的答案是：工具链是开放的，而模型不是。

今天运行它，以及对读者来说有什么变化

Jev 1.13 已在 OrcaRouter 上以 typesafe/jev-1.13 的形式提供，可使用与 200+ 个其他模型相同的密钥访问，并按提供商的标价以 0% 加价率透传。在一篇关于某个类别的页面上，这一点的实际价值很有限，但值得准确说明：试用某个 System One 模型，不再需要为一个你可能还不知道自己想要的模型单独开设账户、单独获取密钥并单独处理发票。它就在同一工作流的生成式那一半旁边——分类器和撰写器共用一份凭据、处于同一处，并统计你实际调用了哪些内容及次数。

这里没有任何东西改变这个模型本身是什么。它于2026-09-15发布，TypeSafe仍将其描述为早期访问；自那以后，它的本质没有变化。2026-09-24发生变化的是，读者现在不必先承诺建立第二个供应商关系，就能了解它在实际中会让自己付出什么成本。如果你一直在观望这个类别是否值得做一个原型，那正是发生变化的地方。