什么是 TypeSafe AI？Jev 1.13 背后的实验室做的是决策，而非句子

TypeSafe AI 是旧金山一家小型实验室，它出售一款写不出句子的模型，而 Jev 1.13（typesafe/jev-1.13）正是这里所说的那个模型。它接收一段状态数据——一封电子邮件、一行日志、一张支持工单、一个 JSON 数据块——再加上一组具名问题，然后为每个问题返回一个带类型的答案，每个答案都有自己的置信度值。没有散文，没有代码，没有解释，也没有聊天框。该模型本身发布于 2026-09-15，所以它并不新，这里讲的也并非一则发布消息：本页面的存在，是因为一个更小、日期明确的变化。2026-09-24，OrcaRouter 将 typesafe/jev-1.13 加入其目录，并在自己的地址上开放了该模型卡，这是 Jev 首次可以经由第三方网关调用，而不再只能通过 TypeSafe 自己的端点。这就是那个事件；截至 2026-09-30，它已发生六天；也正是它，让尚未与 TypeSafe 签约的读者如今能够把一个 System One 模型与它本就旨在与之并排放置的生成式模型放在同一个密钥上。本页面其余内容，都是关于打造它的那家公司的背景信息。

对时间节点的诚实说明，因为这关系到其中有多少内容经过验证：Jev 在两周多以前发布，并自 2026-09-21 TypeSafe 取消候补名单以来一直全面可用。处在七天窗口内的是路由变更，而不是模型。如果你来这里是想看发布评测，那么发布已经发生，另有几篇文章已经报道过了。

一个带有宣言、但没有架构图的公司页面

TypeSafe 在自己的元描述中如此描述自己：“一家构建面向自动化的机器原生智能基础设施的 AI 实验室”，其系统“旨在在软件内部作出决策”。其主页标着版本 0.01，页脚印着“旧金山制造”。有一份宣言主张，通往 AI 形态经济变革的最短路径在于让智能可组合，使软件可以像调用函数一样调用语义判断；公司对自己计划的概括是：先交付机器原生可组合 AI 的形态，再让它可靠到足以支撑真正的自动化，然后提供足够稳定、可供叠加的更高层抽象。其标语是“我们在造生产系统，不是造神。”团队页面列出三位创始人——Diogo Almeida 任 CEO，Sasha Sheng 任 COO，Erik Gafni 任 CTO。这就是该公司关于自身所说的全部内容：一个定位、一个产品、三个名字，以及关于公司本身没有任何数字。

网站没有提供的东西，恰恰是工程师在评估一个新依赖项时最先会去找的内容。没有架构页面，没有参数量，没有训练算力披露，也没有学术意义上的模型卡。TypeSafe 自己的基准测试仪表盘仍标记为待定。对于一家卖点建立在可靠性之上的公司来说，披露面很单薄；这是关于已发布内容的事实，而不是对其隐瞒了什么的指控。

System One：该类别，以及为什么借用这个名字

Jev 是 TypeSafe 所称的 System One 模型中的第一个。这个名字源自 Daniel Kahneman 对快速、直觉的系统 1 思维与缓慢、深思熟虑的系统 2 推理所作的区分，该公司的发布文章也直接说明了这一点——文章同时承认，“系统 1 思维”一直带有容易出错的意味，并主张这些模型可以做得比其他替代方案更可靠。TypeSafe 并未创造这个术语，也不拥有它。

这个类别的实际内容是刻意的分工：一个负责决策的模型和一个负责写作的模型。你应该把算术、日期排序、计数和字符串比较保留在普通代码中，因为在那里它们是精确的，而把语义判断交给 Jev。它能回答的是三类问题：

• noul — 一种真/假判断，返回时附带经校准的概率

• 选择 — 从最多 255 个带标签的选项中挑选一个

• 得分 — 按有序评分；我们发布 2-10 个等级，而 TypeSafe 自己的文档展示了一个从 0 开始索引的示例，所以把供应商的当作定义，把 2-10 当作什么

每个问题都带有自己的说明，对于选择题和评分，也有各自的标准。超过大约 64K 输入令牌的请求会在到达模型之前被拒绝，并且响应不会以流式方式返回。供应商另行记录的状态预算——状态加上单个最长的问题——为 32K 令牌，这比卡片上的 65,536 令牌上下文要小，但与之并不矛盾。

他们的论点，用他们自己的话来说

TypeSafe 把这一论点表述得比任何总结都好，所以这里逐字引用：“LLMs 为人产出词语。Jev 产出带类型的决策，更像代码：可靠、快速、自洽且类型安全。”其背后的训练方法也是他们自己的，而这个术语值得准确归属，因为它在别处已被当作通用说法采用。TypeSafe 称之为校准决策强化学习（Reinforcement Learning for Calibrated Decisions，简称 RLCD），并将其与 RLHF 和 RLVR 相对照：后两者优化的是人类偏好或可通过程序验证的奖励，而按照该公司的说法，RLCD 的目标是“在 System One 任务上给出具有认知诚实性的概率答案”。应把 RLCD 视为 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 倍。”还有一个标题为“零幻觉”的部分，细看之下，这其实是一项关于置信度估计的主张，而不是对零错误的证明：每个 Jev 决策都带有置信度估计，因此软件可以在置信度高时采取行动，在置信度不高时升级处理。这四项都是 TypeSafe 的数据，基于 TypeSafe 自行选择的工作负载，且没有一项经过独立复现。发布文章本身表示，团队预计其 193.6 倍和 444.6 倍会处于现实世界增益的高端，并指出这些工作流是由其自己的能力团队构建的，参考答案则由竞争对手的模型生成。我们自己在同一模型上的七天服务数据将错误率定在 0.49%，这是在不同工作负载上的不同测量，也是对把“零”当作绝对值的诚实制衡。

他们尚未发布的内容

Jev 的架构、参数量、训练算力和权重均未公开，公司 GitHub 组织中也没有权重仓库。截至 2026-09-30 核查，该组织共有十一个公开仓库；其中有实质内容的都是工具类项目，均采用 MIT 或 Apache-2.0 许可——一个 agent-skills 仓库、一个 Python SDK、一个 TypeScript SDK、一个由其他 LLM API 提供支持的即插即用客户端适配器、一个 Dagger 模块集合、一些已发布的工作流评测代码、一个 n8n 节点，以及该组织自己的网站。Star 数和推送日期会变动，所以请当天查看，而不是照搬本页的内容。

这十一个中有三个是无关项目的 fork：vLLM、LLaDA，以及一个用于 ClickHouse Cloud 的 Pulumi provider。它们是对他人工作的 fork，并不能说明 Jev 是如何构建的——尤其是，不能说明 Jev 是基于扩散的。对于 Jev 是否开源，一句话的回答是：工具是开源的，模型则不是。

他们自己承认的

发布帖里的两处坦白比大多数供应商的免责说明更有价值，因为它们点明了证据薄弱的确切位置。关于价格：“我们无法证明它没有获得补贴；要证明我们定价的可持续性，还需要长期表现（我们预计价格会下降，而不是上涨）。”关于速度：“我们公布的评估通常是在西海岸的笔记本电脑上运行的（我们目前的服务基地就在这里）。”还有第三处，对任何基于它进行构建的人来说都更有用：对于高基数选择集，Jev 运行一个两阶段系统，先独立评分，然后做出明确选择，“因此偶尔会出现变慢。”这是供应商在解释为什么延迟在不同问题类型之间并非保持不变，而这类信息通常只能从支持帖里了解到。

截至今天，你实际可以在哪里调用它

通过 TypeSafe 自己的 API，该模型已正式可用，且主页仍使用供应商自己的说法“early access”——这种措辞是当前有效的，值得保留，而“waitlisted”则已弃用：文档公布了具体的运行限制（每秒 100K 个 token、每秒 40 个请求，超过任一限制会返回 429，并由 SDK 退避处理），并且完全不含候补名单相关措辞。另外，自 2026-09-24 起，也可通过 OrcaRouter 使用。

我们提供的内容值得精确说明，因为调用形态才是不同之处。目录条目为 typesafe/jev-1.13，名称为 TypeSafe: Jev 1.13，支持的端点类型为“systemone”——因此它通过 POST /v1/systemone 访问，而不是 OpenAI 聊天补全形态，非流式，输入文本、输出结构化 JSON，状态与问题合计最多约 64K 输入 token。输入为每百万 token $0.042，输出计费为零，因为没有需要计量的输出 token：类型化决策不是散文。那是提供商的标价原样传递，0% 加价，使用与目录中其他 200+ 个模型相同的密钥——一个 API 对应 200+ 个模型，0% 加价（提供商标价原样传递，因此供应商降价当天即在此生效）。如果你阅读关于 TypeSafe AI 的原因，是想在将生产路径交给它之前，先弄清楚 Jev 的校准在你自己的数据上是否站得住脚，那么把它与你已经信任的生成式模型并排运行，是成本低廉的验证方式；当 Jev 返回的置信度较低时故障转移到那个模型，就是低成本上线它的方式。

我们自己的截至 2026-09-30 的七天服务数据，这些数字来自我们自己的流量，而不是供应商的基准：p50 151 ms、p95 247 ms、约每秒 349 个输出 token、0.49% 的错误率，以及已服务 76.2M token。该窗口内每日 p50 依次为 175、170、163、161、170、147、143 ms，因此中位数一直在小幅下降。该序列中有一天，09-28，p95 为 2,448 ms——这是数据中的真正离群值，不是常态，也不是可用于规划延迟预算的数字。这些数据每日滚动更新；卡片是来源。

根据 TypeSafe 的说法，模型薄弱之处

供应商为 Jev 1.13 发布了一个关于参差不齐性的页面，最后审查于 2026-09-17，其中比大多数发布材料都更坦率地指出了失败模式。在基于该模型进行构建之前，这是该读的页面，它自己的清单如下。Jev 回答的是你写下的问题，而不是你本意所指的问题，因此范围限定词、否定词和隐含条件都需要明确写出来。它不是计算器：在数学问题上比在语义问题上表现更差。它把日期读作文本，而不是有序数量，因此排序、间隔和窗口归属都不可靠，格式混杂时更糟。双重否定和多跳间接会牺牲准确率。当状态因无关细节而增长时，准确率会下降——该页面称其“遭受上下文腐烂”——所以先在代码中进行过滤就是解决办法。状态被视为数据，而不是默认被当作敌对内容，因此注入的指令可能会改变答案。指令与标准不匹配会使其困惑。结构性不变量无法得到保证：一个 noul 输出和一个 choice 输出不必相互对应，而一个问题加上其否定命题也不必总和为一，因此阈值不应在两者之间移植。而且它并未经过生成文本的训练——通过链式选择强迫它生成“效果不会好，而且会非常慢。”

如何解读路由变更六天后的 TypeSafe AI

该公司正在提出一个有力、具体且可证伪的主张：在那些需要判断而非一段文字的工作子集上，窄域决策模型可以比通用模型更快、更便宜且更值得信赖。这一主张合理，且有部分自证——置信度估计是真实的设计差异，价格是真实的，我们在自身流量上测得的延迟也与厂商处于同一数量级。缺失的是能让外部人士核查其余部分的那一环：没有架构，没有参数，没有权重，没有独立基准测试，还有一个公司自己都说无法证明可持续的价格。失效模式已有记录，这比大多数实验室做得都多，也是认真对待该模型的最有力理由。

如果你在决定是否要关注：拿你已经标注好标签的输入来运行 Jev，并保留标签，看看它的置信度能否将它答对的情况与答错的情况区分开。这个测试的成本几乎可以忽略不计，每百万输入 token 仅 $0.042，而且它是唯一能回答你实际问题的那一个。如果你在决定是否要信任这家公司：披露就是披露，而诚实的答案是，目前的证据只有供应商的一面之词，再加上你自己生成的那些。