Jev 1.13 的崩溃之处：TypeSafe 自身的限制清单

Jev 1.13（typesafe/jev-1.13）发布于 2026-09-15，这意味着它比最近七天还早了两周，所以它的发布并不是重点。有明确日期的事件是 2026-09-24：那一天 OrcaRouter 将 typesafe/jev-1.13 加入其目录，并为它开设了模型卡片——这是 Jev 首次在第三方网关中获得服务支持；在此之前的两周里，调用它的唯一途径是 TypeSafe 自己的端点。这一点在这里之所以重要，有一个具体原因。Jev 的不寻常之处在于，其供应商会发布一份它失败方式的清单，而一份你只能阅读的清单，远比一个你能实际调用的模型更容易被跳过。

本页就是那份清单，仅保留 TypeSafe 自己所述的内容，再加上运行限制和账单。

TypeSafe 发布了自己的参差不齐列表

docs.typesafe.ai 上有一个页面，标题为 Jev 1.13 的粗糙边缘。它明确适用于 jev-1.13，并标注了 2026-09-17 的复审日期，开篇是供应商自己的表述：“Jev 并非完美。以下是我们已知 jev-1.13 存在的一些粗糙边缘。其中许多将在后续版本中修复。”随后是九种具名模式，每种都附带一个具体案例和一个“改为：”的补救措施。以下内容均非推断而来，也未经过任何弱化——措辞属于 TypeSafe，而在公司给出自己的示例之处，其中的数字也是他们的。

字面解读：它回答的是你写下的那个问题

限定范围的词语、否定词和隐含条件都按字面意思来理解。问题是根据指令中的字面措辞来回答的，“而人则可能会读出指令背后的意图。”

厂商的诊断信息才是有用的部分：当你看到一个错误答案，并发现自己正在解释你真正想表达的意思时，那个解释就是指令中缺失的另一半。补救办法是：在指令中写明确切条件，把边界情况放进标准中，而在确实无法避免解释的地方，把问题拆成两个字面问题，并在代码中把它们组合起来。

数学和数字：这不是计算器

TypeSafe 明确表示，要在代码中实现数学逻辑。这背后存在三个具体的失败之处：

• 计数并不可靠。这涵盖单词中的字符、文章中某一术语的出现次数，以及长列表中的条目。“模型识别的是答案的形态，而非逐一清点，且错误会随着被计数对象的规模而增大。”供应商自己关于究竟该不该提问的检验标准是：如果正则表达式或解析器能找到该单元，那么计数就应当归入代码，模型毫无增益。

• 数值表示的表现不如语义表示。使用十六进制值的颜色问题比使用英文颜色名称的同样问题更差；给定 RGB 三元组或十六进制，Jev 无法可靠地判断两个值是否接近。同样的差距也出现在低级代码上——汇编或二进制编码指令——与高级语言相比。在代码中进行转换或分桶，并将模型保留给真正需要判断的部分。

• 分数输出不携带精确的量级。供应商表示，Jev 的分数等级在数值校准方面较弱。期望值可用于测试某事物是否超过阈值；但不能用于通过在两个最接近的等级之间插值来重建该数值。对于一整类误用——将分数当作测量值来解读——这是坚决不允许的。

日期和时间：日期按文本读取，而非按数量读取

对两个日期进行排序、度量它们之间的间隔，或判断其中一个是否落在某个窗口内，都是不可靠的，而且在混合格式、相对引用以及诸如季度、结算窗口和应计期间之类的领域边界下还会进一步恶化。

推荐的分工很清晰。抽取是一种判断，所以交给模型。日期的每一个组成部分都是一个小的封闭集合——十二个月份、三十一个可能的日期、有界的年份范围——这使抽取变成了在枚举选项之间做选择，而不是自由形式的解析，并且让你有一个地方可以放置明确的"未说明"，这样缺失的部分会被报告出来，而不是被猜测。代码负责组装这些部分，并接管此后的一切，包括顺序、时长、偏移量和星期。

间接性：双重否定和额外跳转会降低准确性

带有双重否定或层层间接的指令，其回答的可靠性会降低。询问某个属性的属性，或者需要多次推理跳跃的问题，都会牺牲准确性。补救办法是尽可能直接地书写指令，并直接点出状态中的相关部分，而不是对它们加以描述。

一个充满无关细节的大型状态会损害准确性

随着状态因与决策无关的内容而增长，准确率会下降。无关细节会充当干扰项，而庞大的状态会让人更难判断输入的哪一部分产生了错误答案。TypeSafe 自己在结尾备注中的提醒很直白：“Jev 深受上下文腐化困扰，因此状态中的无关材料会让你损失准确率。”

先在代码中检索和过滤，只发送问题所需的字段。在请求之前无法过滤的情况下，供应商建议使用 noul 来筛选相关性，然后评判幸存者。

状态中的对抗性内容会改变答案

State 即数据，而 jev-1.13 默认不将其视为敌意。注入的指令、故意误导性的表述，或为其自身分类进行辩护的文本，都可能改变结果。这是唯一一种供应商明确将修复列为未来工作的模式——“我们预计未来会对此进行改进”——而临时建议是：在判定标准中要明确，并在面向大量用户之前彻底测试该集成。

相互矛盾的指令和标准会让它感到困惑

当指令和标准要求不同的事情时，模型可能会感到困惑。TypeSafe 的例子是一个 noul，其中 true 映射到 no，false 映射到 yes，这比用一致方式表述的同一问题表现更差。指令要求将标准视为指令的延伸，并用普通人能读懂和理解的语言将两者对齐。

它不保证的结构不变量

这是最有可能击垮一个建立在无人写下过的假设之上的系统的模式。Jev 在通常意义上极其一致——语义相似的输入会产生数量上相似的输出——但你可能期望成立的结构性恒等关系并无保证。供应商公布了两份完整案例。

• 同一个问题，两种问题类型。对于工单“我对合身度不满意。我有哪些选择？”，把“客户是在要求退款吗？”当作 noul 来问，和当作是/否选择来问，会返回 0.22 的 noul，以及“是”0.01、“否”0.99 的选择，置信度为 0.97。这些是同一个问题的答案。

• 一个问题及其否定形式。“客户是在要求退款吗？”和“客户是在要求退款以外的其他东西吗？”，作为工单“同一订单我被扣了两次款。有人能查一下吗？”上的两个 nouls 提出，分别返回 0.72 和 0.47。它们相加为 1.19。

这些补救措施是可操作的，而非修辞性的：不要依赖预期的结构不变性，不要把在 noul 上调好的阈值套用到选择上，也不要用不同问题之间的算术恒等式来约束模型。原因是，选择是相对的——它确定的是哪一个选项——而每个 noul 都是绝对的，并且可能对所有这些选项都返回低值。

生成：它没有被训练来写作

jev-1.13 并未经过生成文本的训练。你可以通过串联选择来强制输出，而 TypeSafe 直接指出，这“效果不好，而且会非常慢”。对于抽取任务，指导建议是用正则表达式或生成式模型提取候选值，然后让 Jev 选出正确的那一个；或者——当答案空间有限时——将抽取转化为在选项之间做选择，而不是直接要求给出该值本身。

选择题的 255 个选项上限

一道选择题：Jev 集成不是锯齿状的边缘，而是产品的形态。这些值得单独区分出来，因为再多的提示词工作也改变不了它们：

• 不生成文本。它返回的是决策，而不是散文。这是设计，不是缺陷。

• 无对话。Jev 是一个结构化决策模型，而非聊天模型。你发送一个状态和一组具名问题；它会针对每个问题返回一个结构化答案。无需围绕轮流交互进行设计。

• 不支持多模态输入。输入仅为文本——字符串、JSON 对象或文本值数组，不包含图像、音频或视频。非文本材料必须先预处理为文本或结构化字段，然后才能成为状态的一部分。

• 非流式响应。只有一个结构化响应，没有流式模式。这一点之所以无关紧要，原因和它之所以值得说明的原因一样：没有什么可供流式传输。一个带类型的决策——一个带概率的布尔值、集合中的一个标签，或量表上的一个等级——没有值得逐词元透露的部分形式。

• 英语是主要语言。其他语言（包括中日韩文字）虽也能处理，但效果并不一样好。TypeSafe 的建议是：在将 Jev 用于非英语工作负载之前，先用自己的内容进行测试，并在路由时倚重置信度。

选择题的 255 个选项上限

选择题会从最多 255 个带标签的选项中选出一个，而这个上限是硬性的。TypeSafe 还用厂商自己的话解释了为什么大型选项集运行得更慢：“对于基数更高的选项，我们采用两阶段系统：先独立评分，再做出明确选择，因此偶尔会出现变慢。”所以，大选项集的延迟成本是结构性的，而非偶然的，而且是厂商在告诉你它源自何处。

我们自己在 typesafe/jev-1.13 上的服务窗口（读取自 2026-09-30 的模型卡）展示了这在七天自有流量中的实际表现：中位数为 151 毫秒，p95 为 247 毫秒，每秒 348 个输出 token，以及在 7620 万个已服务 token 上 0.49% 的错误率。每日中位数在一个很窄的区间内浮动——从 2026-09-24 到 2026-09-30 分别为 175、170、163、161、170、147 和 143 毫秒——但 2026-09-28 的每日 p95 为 2,448 毫秒，大约是其前后几天的大约十倍。我们无法将那个单日离群值归因于选项基数，也不会这样做；诚实的解读是：长尾确实存在，对延迟敏感的工作流应当针对长尾而非中位数来设计。

输入账单即为完整账单

在 Jev 上，输出按零计费，这有时会被解读为“Jev 是免费的”。事实并非如此，因为输入是按量计费的，而且大型状态并不会仅仅因为输出侧没有内容就免费。供应商价格为每百万输入 token 0.042 美元——TypeSafe 将同一个数字表述为每十亿 42 美元——而 OrcaRouter 以 0% 的加价率透传提供商的标价，因此供应商降价当天就会在此生效。

以下是使用供应商自己的费率时，它会对一个真实形状产生什么效果：

• 一个小请求。一张 1,200 token 的客服工单，再加上大约 300 token 的评分标准和问题，就是 1,500 个输入 token，每次调用 $0.000063。

• 一个大型请求。一份 55,000 token 的合同，加上将请求推高至 60,000 token 的问题，token 数是原来的 40 倍，所以每次调用 $0.0025——每次调用仍然很小，而对于同一个答案，比第一种情况大 40 倍。

• 按用量规模计算。每次调用 60,000 个 token，每天 10,000 次调用，就是每天 6 亿个输入 token，也就是 0.6 个十亿，因此每天 $25.20，按 30 天一个月约 $756。同样的调用次数用于 1,500 个 token 的请求，则是每天 1,500 万个 token：每天 $0.63，每月约 $18.90。

最后两行之间的差距不是定价花招，而是按量计量的状态。这就是为什么“上下文腐坏”一节里的过滤建议不仅是一项准确性措施——削减状态也是唯一能撬动账单的杠杆。

已公布的操作限值，让任何人都无需猜测

TypeSafe 的模型页面发布了具体的数值，因此规划者无需自行推断：

• 吞吐量与速率。根据 docs.typesafe.ai/models.md，为每秒 100K tokens、每秒 40 个请求。超过任一限制的请求都会返回 429 Too Many Requests；厂商的客户端 SDK 默认会以退避方式重试，并在响应中带有 retry-after 响应头时遵循该响应头。

• 限额会变动。供应商表示，随着容量上线，速率限制会动态调整，并且“可能随时变更，恕不另行通知”，自定义和企业方案可获得更高限额。请将 100K/40 视为当下的数值，而不是合同承诺。

• 上下文预算。请求预算在状态和所有问题合计约为 64,000 个 token——模型卡公布的是 65,536——而供应商的模型页面则单独将状态加上单个最长问题限制在 32,000 个 token。第二个数字是状态预算，而不是第一个数字的较小版本；两者都是真实存在的，且彼此并不矛盾。

• 别名会在你脚下变动。jev-latest 和 jev-preview 目前都解析到 jev-1.13.0，而厂商注明当前没有可用的预览版本。新版本发布时别名就会随之变动，因此如果你已针对某个具体版本调整了置信度阈值，请固定使用带版本号的 ID，并按自己的节奏推进。

您的用例需要是什么样子

从头到尾读下来，供应商自己的清单所描述的，是一个范围狭窄但实用的工具。当判断是有边界的，而算术不是模型该做的事时，Jev 就有了用武之地：这条记录是否符合政策、这些标签中哪一个适用、在五级量表上该如何评定——在你自行筛选出的状态上提问，并配以字面明确的指令和与之相符的标准，同时每一次计数、比较和日期测算都由周边的代码完成。

当任务需要计数、排序或日期运算时，当需要多跳推理时，当输入材料不是文本时，当状态是一片干草堆而问题是一根针时，或者当来源的任何方面都带有敌意时，它都不合适。这些不是提示词中的缺口；它们是模型行不通的地方，而 TypeSafe 正是这样表态的一方。

在接入之前，还有一件事值得了解：Jev 的调用方式存在一个实实在在的区别。在 OrcaRouter 上，目录是通过专用的 systemone 端点 POST /v1/systemone 来访问 Jev 的，而不是通过 OpenAI chat-completions 的形式。这是你编写请求时的一个真实差异，也是对早前“Jev 使用自己的请求格式”这一说法的正确版本。除此之外，一切都与账户上任何其他模型相同——一个密钥即可使用 200+ 个模型，我们不收取按 token 计费的费用，而且路由出现问题时会自动故障转移。TypeSafe 于 2026-09-21 取消了等候名单；供应商自己的主页仍将 Jev 描述为抢先体验，其自己的基准测试页面也仍标记为待定，因此本页面上唯一的性能数据就是我们自己测量的服务数字以及供应商自己的说法，并已标注为他们的说法。