字符串 / 生成文本。字符串非常灵活，可以是任何东西：聊天回复、代码、幻觉、拒绝回答，甚至是类型安全的结构化值。要被软件使用，响应需要经过解析+验证。而且始终存在 AI 跑偏的风险。
类型安全的结构化值。可能的输出和结构事先定义。模型永远不会出现类型错误。所有答案都附带经过校准的概率和置信度评分。
串行。一次生成一个 token，每个 token 都以前一个为条件。
并行。单次查询生成所有输出。极其高效且充分适配硬件。
输出 token：比输入 token 贵约 5 倍。
输入 token：$0.042 / 百万 token（每十亿 token $42）。
输出 token：免费（便宜到无需计量）。
前沿模型的端到端响应时间为 3 至 329 秒。与人类交互足够快，但集成到代码中时是重大瓶颈。
TypeSafe 的端到端响应时间为 70ms-500ms。对于 System One 形态的查询，在同等前沿智能水平下，速度可提升 40-200 倍。
即使被提示给出置信度估计，模型也往往过度自信且不一致。如果一个模型 95% 的时间能完成任务，但不说出自己何时处于那 5% 的失败区间，它就无法将该任务自动化。
每个输出都会传达置信度和不确定性。经过校准：置信度越高意味着准确率越高。更一致：相似输入返回相似答案。
人机协作任务（聊天机器人、copilot、编码 agent）。通用且强大，但需要人工监督，因为它们的自由也意味着可能跑偏。
可验证问题（数学证明、内核优化）。当正确性可以被廉价且自动地检查时，LLM 可以生成、测试并迭代，直到找到可行的方案。
演示原型。字符串的灵活性让它非常适合快速制作只能偶尔成功的原型。
AI 驱动的工作流 / 智能 if 语句。结构化输出作为模糊决策规则嵌入普通软件：在手写逻辑过于脆弱的地方进行分类、路由、评分、抽取或分支。周围代码约束了它们的自由，使其更容易组合成可靠系统。
对大数据进行 map-reduce。将 PB 级数据转化为特征和洞察。实时应用。100ms 的速度意味着你可以在 UX 至关重要的场景中使用 AI。验证一切。对 LLM 提示词、推理轨迹和/或输出进行评分、判断、验证、设置护栏并检测越狱攻击。
我们欢迎怀疑者，我们自己也是怀疑者。
有些声明你可以轻松验证：
单次调用速度：我们确实有那么快，尽管我们的（原文在此处中断） 单次调用成本：我们的定价透明。我们无法证明其没有补贴；需要长期运行来证明定价的可持续性（我们预计价格会下降，而不是上涨）。 无类型错误：只需一个反例就能轻易证伪这一点，但它在数学上是不可能的。
对于更大胆的声明，我们希望尽可能提供细致的说明。
我们的并排对比演示展示了我们的模型与 LLM 的一个关键区别：Jev 并行输出所有概率，而不是按 token 自回归生成。字符串极其强大且通用，但代价高昂。“放弃"字符串实际上给了我们很多超能力！
对于拥有 TypeSafe 早期访问权限的用户，这是实际的查询。
该查询高度简化，questions 的键被选为描述性的、人类可读的形式，以便屏幕上的输出易于理解。
state 也是一段简短、密集且详细的段落，以突出采样方法的差异。相对较短的输入让我们的模型处于有利位置。
对于眼尖的读者，在录制的运行中，与 GPT-5.6 Terra 唯一的分歧在于"流失可能性等级”。我们认为实际答案确实存在歧义。
本示例中我们使用了默认推理设置的 GPT-5.6 Terra，因为我们发现它在平均智能水平上与 Jev 最具可比性。
有趣的是：正是类似的演示让我们决定全力投入 System One Models 方向！
我们设计了一种新型评估方法来衡量 AI 在代码中的表现。我们不针对真实标签分类进行优化，也不允许随意更换测试框架和模型（这可能通过工程化测试框架导致过拟合）。相反，我们假设存在一个正确的计算图（以代码表示的"工作流"），并使用最大、最智能、最昂贵的外部模型的预测作为参考概率。
换句话说：每个模型使用相同的工作流。我们测试它们与最智能模型平均值（此处为 Astra 和 Fable）的对比表现。
Jev 的表现超出图表范围——在接近 2 个数量级的范围内独占帕累托前沿。我们还与使用生成式提示、在思维链中完成所有逻辑的模型进行了比较，但这种方式的表现明显不如直接使用工作流本身。
请注意，这里的调用比上面的并排演示复杂得多。这是因为它们更能代表真正业务自动化所需的生产工作负载类型。以下是我们发布的 4 个工作流中最简单的一个：
最可靠的真实世界工作流往往包含许多独立、分解的问题，其细粒度行为依赖于概率而非离散决策。最终结果是离散分支，但如何得出最终答案涉及大量需要高度一致执行的领域特定工程。
请访问我们的工作流评估网站查看全部细节：示例、分歧、完整查询以及每个工作流。
这就是我们主页上"快 193.6 倍、便宜 444.6 倍"声明的来源，我们预计这些数字处于实际收益的较高区间。
这些工作流的内容并非刻意挑选或构建以美化我们的模型，也不在我们的训练分布中。不过，它们是由我们模型能力团队的成员制作的，因此可能存在一些偏差。
我们使用 GPT-6 Astra 和 Fable 5.1 的平均值作为参考答案，这会使结果偏向 OpenAI 和 Anthropic 的模型。我们很可能低估了自己模型和 DeepSeek 模型的相对表现。
LLM 使用我们的 System One LLM 封装器，它限制 LLM 输出与我们的 API 兼容的结构化决策。我们发现这是从 LLM 获取决策最准确的方式，但比直接给出不带概率的决策更慢、更昂贵。
幻觉与类型安全本质相关，我们认为后者是自动化的基本门槛。幻觉的工具调用在 agent 中只是不方便，但如果它位于有延迟保证的系统中，或深埋在依赖链的多个层级中，那就是绝对的致命问题。现有模型无论多智能，仍然会产生幻觉和类型错误。
LLM 的数据来自 OpenRouter，也就是说这里几乎肯定存在偏差：更复杂的查询可能被路由到更好的模型。
我们的数据不是经验测量值。Schema 匹配是有保证的，因此我们可以放心地在图表中加入 0%。
或许我们工作中最令人兴奋的部分是解锁新用例。我们还有更多内容要展示，但这里先分享团队的几个最爱：
我们很喜欢这个 doomo 演示如何展示实时智能以及"代码 + AI"能实现什么。负责的工程师曾担心每秒发起 10 次查询（最终成本约 $7/小时）的开销，但我们其他人一致认为这低于预期！这太有趣了，我们计划不仅发布深入的指南，还将举办一些活动让大家来hack这个项目。