TypeSafe Jev 评测：定价、真实延迟与诚实的局限

我的内容流水线中最昂贵的部分不是写作，而是决策。这正是 TypeSafe Jev 要解决的问题，也正因如此，我花了一个上午研究一个无法写出句子的模型。

每篇经过它的文章都会触发一系列小判断：这个主题值得报道吗？这是科技文章还是音乐文章？草稿足够好，可以通过编辑审核吗？这个 SEO 分数是否值得重写？这些问题都不需要散文。它们需要的是一个 switch 语句能够读取的答案。而直到上周，我唯一能获得这种答案的方式，就是租用一个 frontier model，让它生成一段文字，再把文字包装进 JSON，同时还要为这两部分付费。

2026 年 9 月 15 日，一家名为 TypeSafe AI 的实验室发布了一个专门用来终结这种模式的模型。TypeSafe Jev 是一个 System One model：它完全不生成文本，输入价格为每百万 tokens 0.042 美元，输出价格为零。

我还没有亲自使用过它。早期访问目前需要排队。因此，这不是一次实测，而是我在决定是否将它列入路线图之前所做的研究：发布内容中经得起审视的部分、经不起审视的部分，以及它实际会如何嵌入我已经在运行的系统。

TypeSafe 实际发布了什么

TypeSafe AI 经历了大约两年的隐身开发期，并获得了由 DCVC 领投的 4000 万美元种子轮融资。创始团队成员包括 Diogo Almeida、Erik Gafni 和 Sasha Sheng。

Almeida 的背景是这次发布受到关注、而不是被人快速划过的原因。他曾任职于 OpenAI，是 InstructGPT 论文的共同贡献第一作者之一，并参与了 GPT-4 的工作。一些发布报道将其简化为“ChatGPT 的共同发明者”，这有些夸张，把一项庞大的集体成果压缩成了一个人的功劳。更准确的说法依然很有分量：他参与构建了让对话助手能够工作的指令遵循研究，而现在他认为，这种方式并不是自动化的正确接口。

他的核心问题很精彩：模型多年来在聊天方面已经超越人类，那么自动化究竟在哪里？

TypeSafe 的答案是，瓶颈从来不是智能，而是一个用散文回复的模型并不是适合构建软件的东西。你提出问题，得到一个字符串，解析它，验证它，处理它拒答的情况，处理它先写三段推理再给答案的情况，然后才能进行分支。结构化输出让这一过程没那么痛苦，但并没有改变底层接口仍然是生成式的事实。

Jev 则从决策空间出发。命名的两端都经过了刻意设计：“System One”致敬 Kahneman 所说的快速、直觉式 System 1 思维；Jev 则以 William Stanley Jevons 命名，他提出的悖论认为，成本下降会推动消费上升。TypeSafe 正在告诉你，它预计调用量会发生什么变化。

三种原语，这就是全部 API

你发送程序状态和类型化问题，得到类型化答案，每个答案都带有经过校准的概率。问题类型一共只有三种。

Choice、Score 和 Noul

Choice 从一个声明的选项集合中选择一个选项，最多支持 255 个选项，并返回所有选项的概率分布以及一个置信度值。

Score 将输入放置在由你用文字描述的、包含 2 到 10 个有序等级的光谱上。它返回一个可以落在等级之间的连续位置，因此 1.035 也是有效答案。

Noul 评估一个二元命题，并返回 0 到 1 之间的单个数字：该命题为真的概率。它没有单独的置信度字段，因为这个数字本身就是信念程度。

一次真实调用是什么样的

下面是 TypeSafe 的 Python SDK 文档所展示的调用形式：

python from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

response = client.system_one( state={ "ticket": {"subject": "Duplicate charge", "body": "I was charged twice for order A-104."}, "order": {"id": "A-104", "charges": [{"amount_usd": 49}, {"amount_usd": 49}]}, "refund_policy": "Duplicate charges are eligible for a refund.", }, questions={ "department": Choice( instructions="Which team should handle this", criteria={ "billing": "Payment or subscription issues", "technical": "Bugs or integration problems", "other": "Anything else", }, ), "frustration": Score( instructions="How frustrated the customer appears", criteria=["Calm, just stating facts", "Frustrated but civil", "Very angry"], ), "refund_requested": Noul(instructions="The customer is explicitly asking for a refund"), "policy_supports": Noul(instructions="The stated refund policy covers this situation"), }, )

if response.answers["refund_requested"].noul > 0.7 and response.answers["policy_supports"].noul > 0.8: start_refund_flow("A-104")

四个判断，一次请求，一次往返。模型提供语义理解；策略则保留在代码中，我可以阅读、比较差异并进行测试。

最后这一点才是架构层面的论据，而且比定价更有意思。与其让模型“处理这个客户”，不如明确需要理解的内容，并把接下来发生的事情保留在普通的源代码管理中。

TypeSafe Jev 的成本

这是让人们开始关注的数字。

输出免费并不是促销。它没有自回归解码循环，因此没有需要计量的内容。0.042 美元是否可持续，还是由风险投资补贴，目前无法得知；TypeSafe 在自己的发布文章中也直接说明了这一点。它预计价格会下降而不是上涨，这一说法只能交给时间验证。

上下文限制的工作方式与 LLM 不同，因为状态只需摄取一次，问题会在其上并行运行：状态和所有问题合计大约 64k tokens，其中状态加最长单个问题约为 32k。只支持文本和结构化 JSON。不支持图片、音频或视频。

延迟声明，以及实际测量结果

TypeSafe 发布的端到端延迟为 70-500 ms。发布文章坦诚说明，这些运行结果来自团队在美国西海岸使用自己的笔记本电脑进行的测试，对于托管在美国的 API 来说，这是最佳情况。

Classmethod Malaysia 的一名工程师将它用于一个真实的路由任务。他成功获得了候补名单资格，直接调用 POST https://api.typesafe.ai/v1/systemone，并使用 Choice 复现 NVIDIA NeMo Switchyard 路由设置中的分类器，将对话分为四个等级。共调用 40 次，每个等级 10 次。

40 次全部成功，40 次全部匹配预期等级。中位延迟为 0.64-0.67 秒。每次调用成本为 0.000025 至 0.000027 美元。

这大约是宣传中 70 ms 的十倍，但仍然是整个发布周期中最有意思的结果。因为它替代的是中位延迟 2.1 秒的 Gemini 3.5 Flash 分类器，或中位延迟 7.2 秒的 DeepSeek V4 Flash 分类器。Jev 的速度约为快速但昂贵选项的 3 倍、便宜但缓慢选项的 10 倍，同时每次调用的成本只有几分之一美分。

这次测试中有一个细节比速度数字更有价值。在三个没有歧义的等级上，置信度均为 1.0。在真正处于边界的“中等”等级上，置信度下降到 0.57-0.67。模型知道哪次调用比较困难。这是你无法可靠地从聊天模型中获得的特性，也是它真正改变周边代码编写方式的地方。

其他人如何评价 TypeSafe Jev

这次发布引发了 Hacker News 上一个包含 256 条评论的讨论帖。它有用的地方在于，几乎没有人认为这项技术是假的。几位评论者表示愿意将其投入生产。批评主要针对营销方式，在任何人据此制定路线图之前，都值得读一读。

“Frontier model”承担了太多含义

Jev 无法写代码、进行对话或生成句子。把它与 GPT 或 Claude 放在同一个短语中，借用了它尚未独立赢得的可信度。一位评论者提出了更诚实的标题：它推进了结构化决策的速度和成本边界。这是真实的成就，但并不是同一句话。

“无法产生幻觉”比听起来更有限

一个永远不会输出自由文本的模型确实无法编造引用或工具名称，TypeSafe 所称的 0% 类型错误率也确实是由构造方式保证的，而不是通过测量得出的。但一个被限制在三个允许类别中的模型，仍然可能自信地选错类别。被消除的是格式错误的答案，而不是错误的判断。TypeSafe 的 CEO 也在讨论帖中直接同意了这一点。

速度比较可能并非完全可比

70 ms 的数字是与 LLM 自回归生成完整结构化答案进行比较得出的，其中包括 schema 名称和格式，而不是与被限制为输出同等简短决策的 LLM 比较。这一方法论问题尚未解决。

评测是自行设计的

TypeSafe 没有运行公开基准，而是构建了一种新的“工作流评测”格式，并使用 GPT-6 Astra 和 Fable 5.1 的平均预测作为评分依据，而不是使用真实标签。公司也标注了自身的局限：工作流由自己的团队构建，参考模型会使结果偏向 OpenAI 和 Anthropic，竞争 LLM 则通过 TypeSafe 自己的适配器运行。它还表示不会参与公开排行榜，这一点被一些人认为很方便。

没有架构论文。RLCD，即 Reinforcement Learning for Calibrated Decisions，是整个论述所依赖的训练方法，但目前只有描述，没有公开细节。没有奖励函数，没有校准曲线，也没有任何可由外部独立复现的内容。正如 Anthony Maio 指出的，用于校准的强化学习本身也并不新；此前的“Rewarding Doubt”等工作探索了相同领域。可能具有新意的是整体组合，而不一定是方法本身。

大多数报道跳过的那个数字

在 TypeSafe 自己的评估中，涵盖安全事件响应、agent-trace 可观测性、发票处理和客户服务四个工作流，其中隐藏着准确率情况。

仔细读一下，因为这会重新定义一切。Jev 以大约七十六分之一的成本和二十五分之一的延迟，达到了中档 frontier models 的水平。它并没有达到顶级水平。具体到发票处理，差距最大：Jev 为 61.8%，而 Sol 为 79.1%。

因此，诚实的定位不是“更便宜的 frontier intelligence”，而是“Sonnet 级别的判断能力，价格低到可以在每次请求中调用，而不是只在部分请求中调用”。对于路由器、分类器或预过滤器来说，这种取舍非常出色。对于出错代价高昂的决策而言，与 Sol 相差 12 个百分点才是全部重点。

TypeSafe Jev 在我的技术栈中的位置

将它与我已经在运行的系统进行对照后，有三个场景可行，两个不可行。

内容流水线中的文章审核门

运行本站多 agent 流水线的协调器，每次运行都会做出十几个有边界的判断。科技与音乐之间的分类目前使用标签分布启发式方法。编辑、润色和 humanizer 流程都会回答某种形式的“这篇准备好了吗”。这些其实都是披着 LLM 外衣的 Choice 和 Noul 问题。这里校准比价格更重要：置信度分数让我可以自动通过明确的案例，只把有歧义的案例交给更大的模型。

Apify actors

其中一个会为现有文章评估 SEO 质量，这本质上就是评分任务；这里唯一影响盈亏平衡的因素，是 API 内部的模型支出。使用每次调用 0.000026 美元的 Score 原语，与使用 frontier model 完成同样工作相比，这是利润率变化，而不是优化。这个场景我会先测量，再相信。

电商侧的客户问题路由

收到的 FAQ 问题需要一个类别、一个紧急程度判断，以及一个“是否需要人工处理”的标记。三个并行问题，一次请求，亚秒级响应。这是典型用例，也是发布演示围绕构建的场景。

它不适合的地方

有两个地方，而且都是硬性限制，而不是判断问题。Mixanalytic 是音频分析，而 Jev 只接受文本和 JSON，因此必须先进行转录或特征提取；到那时，真正有趣的工作已经完成。另一个是任何需要写作的任务：文章草稿、推文生成、翻译。Jev 从设计上就不返回字符串。它不是更便宜的 Claude，而是一个不同的组件。

我会坚持这一点。这不是模型替换，而是一个位于 LLM 调用之下的新层，负责处理那些当前由 LLM 处理、但其实超出其能力需求的决策。

如何开始使用 TypeSafe Jev

可以通过 console.typesafe.ai 排队申请访问，也可以通过 Vercel AI Gateway 使用。Classmethod 的工程师报告称，注册后立即获得了访问权限，因此实际排队时间可能很短。

bash export TYPESAFE_API_KEY="sk-..."

pip install typesafe-sdk # Python 3.10+ npm install @typesafe-ai/sdk # Node 20+

两个 SDK 都会从环境变量中读取 TYPESAFE_API_KEY，并默认使用 jev-latest。如果你完全不想使用 SDK，也可以直接调用唯一的端点 POST https://api.typesafe.ai/v1/systemone。控制台包含一个 playground，并提供工单路由、简历筛选和支持 agent 审计的完整示例。

在第一次调用之前，有两点值得了解，二者都来自最初 48 小时内发布的实用指南。应当一次性预先提出所有问题，而不是先进行一次廉价调用再跟进，因为问题会并行评估，所以第十个问题会增加 tokens 消耗，却几乎不会增加时间；TypeSafe 的 cookbook 报告称，批量提问比逐个提问便宜约 12 倍、快约 10 倍。另外，始终在 Choice 中加入明确的 other 选项，这样模型可以表示没有任何选项匹配，而不是选择一个最接近但错误的选项。

对 TypeSafe Jev 的结论

定价是标题，架构才是真正的论据。去掉“frontier model”的包装，以及建立在自行设计评测之上的 200 倍数字后，剩下的仍然是我本季度读到的 AI 基础设施领域最有意思的内容：一个能够在软件内部做出有边界的判断、附带诚实的不确定性，同时让确定性代码继续掌控执行流程的组件。

我不会做的是把校准视为已经得到证明。所有重要的主张——概率是否诚实、准确率能否在其他人的领域中保持、这一切能否经受生产负载——目前都由一家进入早期访问仅一周的公司自行报告，没有论文，也没有第三方复现。速度和价格可以在第一天验证。校准则需要数千个带标签的结果，而目前还没有人发布这些数据。

所以，正确的做法是：注册候补名单，选择一个我已经在高频运行的评分任务，并亲自进行测量，然后再决定是否迁移。这就是对一个发布仅一周、拥有真正好想法、但公司之外还没有任何人核验过凭据的模型，恰如其分的热情程度。

来源

披露：本文于 2026 年 9 月 19 日，通过我个人网站的 MCP 使用 Claude Opus 5 进行研究和起草，资料来自 TypeSafe 发布文章以及六篇独立文章，其中包括一次实际 API 测量。我没有 Jev 的早期访问权限，也不声称对其进行过第一手测试。文中的供应商报告数据均已明确标注；这里的每个数字都可以追溯到上方的某个来源。