Jev 模型是什么？API 价格、适用场景与快速接入教程

2026 年 10 月 24 日更新：新增 Jev 1.14，现已通过 jev-latest 提供。

Jev 模型是 TypeSafe AI 的 System One 模型：输入 state 加带类型的问题，直接返回类型化答案。用 model: "jev-latest" 调用，现在就是 Jev 1.14：每百万输入 token $0.042，输出免费，单次请求 64K token。

这让 Jev 适合分类、分派工单、排序、验证和 Guardrail，但它不是聊天模型、编程模型、计算器或确定性业务规则的替代品。

Jev 模型一览

官方拼写是 Jev，并不是需要逐字母展开的 J-E-V 缩写。TypeSafe 表示，这个名字来自经济学家 William Stanley Jevons；“System One”则借用了 Daniel Kahneman 在《思考，快与慢》中推广的快速直觉式 System 1 概念。

Jev 1.14 有什么新变化？

Jev 1.14（jev-1.14.0）从 2026 年 10 月 14 日起成为稳定版本，jev-latest 与 jev-preview 现在都指向它。价格和默认限制都没变，真正的新东西是两个要手动打开的实验室功能。

两个功能都藏在 TypeSafe 称为 “danger zone” 的请求头后面。加上 TypeSafe-Danger-Zone-Images: true，请求才能带图片素材，并启用新的 Box 问题类型，它返回图片里的坐标。加上 TypeSafe-Danger-Zone-Long-Context: true，窗口提到单次请求、单个问题各 262K token；这个开关默认关闭，不加就和以前一模一样。TypeSafe 的发布文章（2026 年 10 月 24 日核对）写明这两个功能要自己承担风险，我们也还没有通过 OmniaKey 测过这两个请求头。

把 jev-1.13.0 写死在请求里的调用照样能用，默认请求体也没变：state、questions，可选的 model。切回旧版只改一行，所以先用你自己的一批真实任务在 1.14 上跑一遍，再迁移生产流量。

Jev 模型到底做什么？

可以把 Jev 理解成一个带概率的语义函数：

非结构化或结构化状态
  + 预先定义的问题与答案空间
  -> 类型化决策与概率分布

普通 LLM 的核心任务是延续 token 序列并生成字符串。即使开启 JSON mode，应用仍是在要求生成式模型“写出”一份答案。Jev 放弃自由生成：调用方先定义允许的输出形状，模型再针对同一份状态评估所有问题。

TypeSafe 把它的训练方法称为 Reinforcement Learning for Calibrated Decisions（RLCD，面向校准决策的强化学习）。目标不仅是选答案，还要让概率在一组相似预测上反映真实正确率。理想情况下，模型给出 0.8 的一批判断应约有 80% 正确。但校准是群体统计性质，不能保证某一次 0.8 的答案一定正确。

Choice、Score 与 Noul

Jev 提供三种问题类型。它们是 API 的核心原语，不是生成完成后附加的格式化选项。

一个 Choice 最多可包含 255 个选项；一个 Score 可定义 2–10 个有文字描述的等级。Noul 不另带 confidence 字段，因为它的 0–1 数值本身就是“是”的概率。

同一请求中的多个问题会针对相同 state 独立、并行评估。这适合一次拿到多组信号，但也意味着一个答案不会自动影响另一个答案。如果问题 B 依赖问题 A，应该由代码明确表达这种依赖。

一个 Jev API 请求

下面的精简示例把 TypeSafe 官方请求结构发送到 OmniaKey：一次调用同时判断客服消息该由谁处理、用户有多不满，以及是否紧急。

curl https://api.omniakey.com/v1/alpha/search \
  -H "Authorization: Bearer $OMNIAKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "我的付款已经连续三天失败，正在损失订单，请马上帮忙。",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "应该由哪个团队处理？",
        "criteria": {
          "billing": "付款、账单或退款",
          "technical": "Bug、故障或集成问题",
          "sales": "价格、升级或新账户"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "客户有多不满？",
        "criteria": ["平静", "不满但克制", "非常生气"]
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "这条消息是否表达了紧急性？"
      }
    }
  }'

响应会保留同样的问题 ID。department 返回三个允许值之一，以及三个选项的完整概率分布；frustration 可能是小数，因为它是各等级位置按概率计算的加权结果；is_urgent 只返回“是”的概率。

具体数值会随输入、判定标准和模型版本变化。最终由代码而不是模型决定，多高的概率才足以执行动作。

Jev 与 LLM、传统分类器有什么不同？

Jev 处在两者之间一个很有用的位置，区别值得说清楚。

说 Jev “只是分类器”会忽略它能在请求时动态定义答案空间；说它是“更快的 LLM”则会忽略它不能解释、写邮件、写代码，也不能创造你没有提供的新答案。Liquid AI 的 d1 模型做的是同一类有界决策，也同样以开放权重形式发布；详见Liquid AI d1 API 评测。

JSON mode 也不是一回事。JSON mode 约束生成文本的语法；Jev 约束的是答案空间本身，并返回用于决策的完整概率分布。只有当问题能被拆成有限答案的判断时，这种差异才真正有价值。

Jev API 价格是多少？

TypeSafe 给 Jev 1.14 的价格和 1.13 一样：每 100 万输入 token 为 $0.042，即每 10 亿 token 为 $42。输出目前免费，官方称其“便宜到无需计量收费”，不过响应仍会记录 output token 用量。

这些只是按公布单价计算的算术结果，不是账单实测。它们不包含重试、预处理、级联中的其它模型、存储、工程成本与未来价格变化。

Jev 上下文窗口与调用限制

上下文有两个同时生效的限制：全部状态与问题合计不得超过 64K token；状态加单个最长问题不得超过 32K。上下文越长并不一定越好，TypeSafe 自己的 jaggedness 文档明确写着，无关细节会让准确率下降。

官方公布的 250,000 token/s 和 1,200 请求/分钟是账户速率限制，不是单次请求速度保证。TypeSafe 也明确提醒，这些限制在 early access 阶段仍会动态调整。

这些是 TypeSafe 官方直连限制。OmniaKey 账号可能有自己的可用模型、价格和调用限额。完整请求、响应字段、Python/Node.js 调用及错误处理，见 Jev API 接入教程。

速度宣传应该怎样理解？

TypeSafe 报告的 Jev 端到端响应时间为 70–500 ms，并称在“System One 形状”的问题上，以相近智能水平比较时可比前沿模型快 40–200 倍。发布材料还重点展示了一组工作流评测：Jev 快 193.6 倍、便宜 444.6 倍。

这些是厂商结果，不是中立 benchmark。TypeSafe 主动披露了几个重要限制：

1. 延迟测试通常从公司成员位于美国西海岸的笔记本发起，当时服务也部署在西海岸。
2. 工作流由 TypeSafe 模型能力团队制作，因此可能存在选题偏差。
3. 参考答案取 GPT-6 Astra 与 Fable 5.1 的平均值，可能偏向这两个模型家族。
4. 对比 LLM 通过 OpenRouter 和 TypeSafe 的结构化 wrapper 调用。
5. TypeSafe 自己也称 193.6 倍与 444.6 倍属于预期真实收益的高位。

因此，更稳妥的结论是：受限输出和并行评估让 Jev 在答案有限的决策任务上具备极低延迟与成本的可信路径；这些数字不能证明它在所有任务上都快 40–200 倍、拥有与前沿 LLM 等价的通用智能，或更擅长生成与多步推理。

“零幻觉”必须先定义清楚

TypeSafe 宣传 Jev 不会产生幻觉。其中最可辩护的是结构安全：Choice 不会凭空编出第四个选项，代码期待数字时，服务也不应该突然返回一段散文。TypeSafe 表示，这类输出匹配是结构保证，不是靠抽样测出的零错误率。

但类型正确的答案仍可能在语义上错误。TypeSafe 自己的 Jev 1.13 文档列出了这些失败模式：

• 对字面表述过度敏感，错过隐含意图；
• 计数、算术、日期和数值精度不可靠；
• 不擅长多跳间接推理；
• 状态里混入大量无关内容后准确率下降；
• 可能受对抗内容或 Prompt Injection 影响；
• 指令与判定标准矛盾时容易混乱；
• 分开问出的概率不一定满足人们直觉中的数学恒等式；
• 不适合任何需要生成文本的任务。

所以实际可采用的说法是：不会生成 Schema 之外的输出，不等于不会做错决策。生产代码仍需自有评测集、保守阈值、确定性校验与升级路径。

Jev 适合放在哪里？

当三个条件同时成立时，Jev 值得测试：答案空间有限；问题是语义判断而不是精确计算；结果将由另一段软件消费。

写作、摘要、代码生成、开放式抽取、精确算术、日期比较和长链因果推理都不应默认使用 Jev。精确逻辑交给普通代码；需要创造输出时，使用生成式或推理模型。

生产接入清单

1. 确定性工作留在代码里。 日期解析、计数、金额计算和权限检查不需要模型。
2. 每次只问一个原子问题。 把“要不要批准”拆成真正决定它的独立事实。
3. 写清所有限制。 Choice 不穷尽时加入 other 或 none，并为 Score 写具体等级。
4. 用自己的数据测试。 英语是主要训练语言；TypeSafe 明确表示中文等 CJK 语言表现并不完全相同。
5. 按动作风险校准。 可逆的界面操作与高影响自动化不能共用一个置信度阈值。
6. 阈值稳定后固定版本。 jev-latest 会移动；应记录响应中的版本 ID，并主动迁移阈值。
7. 为不确定性准备出口。 模糊案例转人工或更慢的推理模型，不要强迫系统自动决定。
8. 衡量每个已接受任务的总成本。 把重试、误判、人工复核和下游 LLM 调用都算进去。

OmniaKey 现在能调用 Jev 吗？

可以。Jev 已通过 OmniaKey 以 jev-latest 提供，这个 ID 现在就是 Jev 1.14：OmniaKey 把它原样交给 TypeSafe，TypeSafe 换版本你也不用重新接入。无需申请 TypeSafe early access 或等待 waitlist 审批。先在 API Key 面板创建用途明确的 Key，即可开始调用；目录里的条目在 Jev 1.14 模型页。

把 Jev 原生请求体发送到 POST https://api.omniakey.com/v1/alpha/search。这是 Jev 专用接口，不是 OpenAI Chat Completions 路径，因此继续使用上面的 state 与 questions 结构。我们在 9 月 20 日完成的 smoke test 返回了 HTTP 200、解析后的模型 jev-1.13.0、类型化 answers 和 token usage；同样的请求现在会解析到 jev-1.14.0。如果目标是开放式编程和 Agent 工作，编程 Agent 模型指南介绍的是技术栈中另一层的生成式模型。

最终结论

理解 Jev 模型最好的方式，是把它看成一种新的语义决策接口，而不是万能 LLM 的替代品。它最有价值的想法很简单：模糊判断交给模型；输出限定为程序理解的类型；把不确定性显式暴露出来；组合与精确逻辑继续由代码控制。

当前 API 的纸面价格非常低，整个接口也围绕低延迟设计。但模型仍处于 early access，默认只收文本，英语效果最好，官方也列明了它在数学、日期、间接推理、无关上下文和对抗输入上的弱点。在同条件独立测试出现前，速度与智能对比应视为厂商说法。

常见问题

Jev 是 LLM 吗？

TypeSafe 把 Jev 称为 System One Model，而不是 LLM。它能理解自然语言状态，但不生成自由文本。我们查过的公开资料还没披露足够的架构细节，无法独立判断它的底层网络与传统语言模型究竟有多接近。

Jev 能替代 GPT 或 Claude 吗？

不能。Jev 不会写作、解释、编程或做开放式生成。它可以作为生成模型的补充，用来把请求分派到合适的位置、检查输出、给候选答案打分，或判断何时值得调用更慢的推理模型。

Choice、Score 和 Noul 分别是什么？

Choice 从封闭集合中选择并返回所有选项概率；Score 把状态放到 2–10 个已描述等级之间；Noul 返回一个是非命题成立的概率。

Jev 真的零幻觉吗？

它不会返回声明类型之外的值，因此消除了大量解析与 Schema 错误；但它仍可能选择错误的合法选项，或给出误导性的概率。类型安全不等于语义正确。

如何无需等待 TypeSafe waitlist 直接使用 Jev？

创建 OmniaKey API Key，然后把 Jev 原生请求体发送到 POST https://api.omniakey.com/v1/alpha/search，并把 model 设为 jev-latest。不需要单独注册 TypeSafe 账户，也不需要等待 early-access 审批。

Jev API 多少钱？

TypeSafe 给 Jev 1.14 标价每 100 万输入 token 为 $0.042，输出免费。Early access 阶段直连价格与速率限制都可能变化。

jev-latest 现在指向哪个版本？

Jev 1.14（jev-1.14.0）。jev-preview 目前也指向同一个版本；想在请求里固定版本，就写 jev-1.13.0 或 jev-1.14.0。

Jev 支持图片或中文吗？

默认只收文本：字符串、JSON 对象和数组最终都必须承载文本。Jev 1.14 在 TypeSafe-Danger-Zone-Images: true 请求头后面加了图片素材，TypeSafe 把它标为实验功能。中文等 CJK 文字可以输入，但 TypeSafe 表示英语效果目前最好，其它语言要拿自己的数据测过再上。

Jev 免费吗？

核验时官方直连按每百万输入 tokens $0.042 收费，输出 tokens 免费。输出免费不等于一次请求完全免费。试用、赠送额度和网关账单各有条件，应核对具体账号活动，不能默认所有用户都有免费额度。

Jev 模型有多少参数？

TypeSafe 的模型页（2026 年 10 月 24 日核对）列出了上下文和输入格式，没有列参数量。64K、32K 是 token 限制，不是模型参数数量，不能据此推断权重大小或本地运行所需硬件。

一手来源

• TypeSafe：Jev 1.14 发布文章（2026 年 10 月 24 日核对）
• TypeSafe：Introducing System One Models & Jev
• TypeSafe 文档：Introduction
• TypeSafe 文档：System One
• TypeSafe 文档：模型与价格（2026 年 10 月 24 日核对）
• TypeSafe 文档：HTTP API 参考
• TypeSafe 文档：Confidence
• TypeSafe 文档：Jev 1.13 jaggedness

价格、限制与 Jev 1.14 的细节于 2026 年 10 月 24 日重新核验。网关 smoke test 仍是 9 月 20 日那次，本次更新不是新增付费测试。Jev 更新很快，生产使用前请重查版本 ID 与账号条件。