2026.09.25 | Primer | Jev

• 自己跑一遍：20 份 expert call transcript 过 Jev。看筛得准不准、说 0.9 的那批是不是真有九成对。一个下午，比所有第三方数据都直接；准确率 ≥ 90% 且校准好 → "语义 if"这一层 (第 7 节) 对我们自己的研究流程就成立；明显差于 nano → 它的优势只剩速度唯一能自己动手的验证，排第一
• OpenRouter 用量：爬坡停不停、谁在用。这是唯一的实际数据。现在约 2% 全平台 token，头部 app 是数据标注和打标。到 10 月底占比过 5%、且 agent 框架或 coding 工具进入前五 → "进不了主循环"要重新检查，bull 更近；停在 2–3% 且头部仍是 pipeline → base 成立对应第 7、10 节；已有每日 tracker
• 独立校准复测。校准是它唯一的壁垒，现在只有一个 ECE 0.25 的数据点。复测低于 0.1 且自训小模型做不到 → 公司判断要改；还在 0.2 以上 → "接口留下公司不一定"成立对应第 2、6 节
• OpenAI / Anthropic 有没有出 decisions endpoint。读选项概率谁都能做，开源一周就复刻了。大厂出了 → TypeSafe 被吸收；三个月没出 → 说明校准比我们想的难，壁垒要重估对应第 2 节"谁都能做吗"
• 有没有客户说砍了多少 LLM token。现在一个都没有。有人披露砍掉 15% 以上 → 第 10 节的参数错了，先查是不是 compaction 在起作用；一个季度没人说 → base 3.5% 都偏高对应第 10 节

一句话：Jev 是一个只会打勾的审核员：读一段材料，在事先印好的选项上打勾，并写上有几成把握，但一个字都不会写。软件用它来做"从几个选项里选一个"的判断。

先说 LLM 怎么干活

• LLM 干活分两步：先把整段输入读一遍 (prefill)，这一步可以并行，很快；再一个字一个字往外写 (decode)，每写一个字都要再过一遍模型，这一步慢而且贵
• 所以 LLM 的 output 比 input 贵 5–10 倍，开了 thinking 还要先写一大段草稿再给答案
• 很多软件里的判断其实只要一个"是 / 否"或"选 A 还是 B"，却也得让 LLM 写一段 JSON，再由程序去解析

Jev 做了什么

• 只做第一步，不做第二步：读完材料，直接在你给的选项上给概率，不写任何字
• 三种问题：是 / 否 (给一个概率)、多选一 (给每个选项的概率)、打分 (给一个刻度上的期望值)
• 输出不可能出格：选项是调用前写死的，它只能在里面选，不会写出不合法的 JSON

三个核心指标

• 每次判断多少钱：$0.042 / 百万 input token，output 免费。OpenRouter 上实测每次判断平均读约 3.3k token，一次约 $0.00014，一天一百万次约 $140
• 多快：官方说 70–500 毫秒，第三方测到中位数 236–276 毫秒
• 概率准不准 (校准)：它说"九成把握"的那一批，是不是真有九成对。这是它和"让 LLM 自己报个概率"最大的区别，也是它唯一的壁垒。目前实测一般 (见第 3 节)

和最近的替代品差在哪

• 小 LLM (GPT-5 nano、DeepSeek)：也能做选择题，但要写 JSON、概率是编的；价格上 Jev 只比 nano 便宜约 20%，比 DeepSeek 便宜约 6 倍
• 自训分类器 (ModernBERT 一类)：比 Jev 更快 (33 毫秒对 276 毫秒)、更便宜、校准更好，但要标注数据、要训练，任务一变就得重训
• 前沿 LLM：能做任何事，但做选择题要贵两个数量级
• 所以 Jev 的位置是：不想训练、量又大到不值得用 LLM 的判断

拿来干什么：筛 expert call 的例子

• 要从 500 份 expert call 纪要里找 HBM4 定价。老做法全部交给 Fable 读，750 万 token，input 就要 $75
• 新做法：Fable 写一个 50 行的脚本，每份纪要丢给 Jev 问四句 (跟存储有关吗、HBM 还是 NAND、有没有价格数字、专家来自哪类公司)，$0.30、几分钟出一张 500 行的标签表，按阈值筛剩 30 份，Fable 只读这 30 份，$4.5。Fable 的 token 降 94%
• 这就是"语义 if"：以前代码里 if 后面只能跟算得出来的条件，现在可以跟一个读得懂人话的判断

现在到哪一步

• 9 月 15 日 early access 上线；Vercel AI Gateway 第二天接入，称它是网关历史上被采用最快的模型；OpenClaw 9 月 23 日以可选插件接入，默认关闭
• OpenRouter 上 9 月 17 日开始有调用，9 月 25 日已到每天 1.32 亿次、4,390 亿 token，约占全平台 2%
• 还没有任何客户披露"砍掉了多少 LLM 花费"；Browser Use 的极速网页自动化模式仍在 waitlist

一句话：快和便宜全部来自"不写字"；它能干多少活，卡在底模的理解力、32K 的输入上限和校准质量三处，而最后由谁把它接进软件，决定它有多少用武之地。

快和便宜从哪来

• 没有 decode，整个请求只剩 prefill。prefill 可以并行，吃算力不吃显存带宽，一次读完就结束
• TypeSafe 说是新架构加并行采样器，没有公开；社区推测是 transformer 读选项位置的概率，或 encoder 加分类头 (推测)。社区一周内用 Qwen 3.5-4B 直接读选项概率就复刻了接口，21 个问题 1.02 秒，比让同一模型写 JSON 快 5 倍 (社区实测)。说明"读选项概率不写字"这件事本身谁都能做
• 参数量没公开。按定价反推，底模应在几 B 到十几 B，和 GPT-5 nano、Llama 8B 一档 (推测)

卡在哪：五段，每段谁说了算

• TypeSafe 自己能定义的只有底模、校准、输入上限三段，其中能构成壁垒的只有校准，而校准数据目前不好看
• 用量由网关和框架决定。网关 (Vercel、OpenRouter) 让开发者一行代码就能试；agent 框架 (OpenClaw) 默认关闭，说明主循环还没把它当标配

判断一个任务能不能给 Jev，只问一句：答案能不能在调用之前列成有限的几个选项，而且判断所需的材料不超过 32K token。

• 两条都满足 → 能给它。分工单、审命令、打标签、判真假
• 答案要写出来 (代码、邮件、摘要、参数) → 不能
• 材料超过 32K (整个 coding 现场、长报告) → 不能，哪怕答案只是"是 / 否"
• 能给它，也要看值不值：一天几千次判断，用 nano 也就几美元，不值得多接一个供应商；一天百万次以上，或延迟预算在 100 毫秒以内，才是它的量级 (第 5 节算给你看)

市场问的是"Jev 能省多少钱"。正确的问法是：同一个判断，交给前沿 LLM、小 LLM、自训分类器、Jev，各要多少钱，谁能做、谁做不了。

自训分类器的固定成本是标注加训练，按"任务多久变一次"摊到每天。材料超过 32K 时 Jev 做不了；自训分类器每换一次任务就要重来。

• 一天几千次：Jev 和 nano 每天都不到 1 美元，差别没有意义；自训分类器反而最贵，标注训练摊不下来
• 一天百万次、任务常变：Jev 最便宜，但只比 nano 便宜约 20%；它真正多给的是延迟和校准过的概率
• 一天百万次、任务一年不变：自训分类器便宜约 3 倍，而且更快、校准更好
• 材料超过 32K：Jev 出局，只能用 LLM
• 交叉验证：OpenRouter 上的头部用户 (数据标注、内容打标、媒体库整理) 正是"量大、任务常变、懒得训练"的那一格

• 天生缺的四项 (生成、推理、规划、填参数) 是同一件事：都要一个字一个字地写，而 Jev 的定义就是不写。补上它就是普通 LLM，快和便宜同时消失
• 这四项正好是 coding 和 agent 主循环最吃 token 的部分，所以"进不了主循环"不会因为下一个版本翻掉；会翻的只有看图和桌面界面
• 设计三角：快便宜、能力强、不写字，只能选两个

谁在用：OpenRouter 头部 app

• 头部是数据标注、打分评审 (rubric judge)、内容初筛、媒体库整理、仿真，都是"批量跑判断"的 pipeline；没有 coding agent 或 agent 框架进入前五

三层位置

网页自动化和 Fable 的 computer use 差在哪

• 还是审核员的比方：你在电话里指挥一个没见过电脑的人订机票。他每次把屏幕上能点的东西编号念给你，你只说"做什么、对几号"，要打的字由旁边的助手说。Jev 就是电话这头只说编号的人
• 所以它能跑的是"页面能读成文字、动作能列成菜单、十步以内的直线任务"，取代的是一个网站写一份的 RPA 脚本；陌生网站、模糊任务、跨系统长流程要看图和推理，仍是 Fable、Astra 的活
• 对 token 的含义："agent 替人上网，每步都要截图推理"这条最乐观的推演要打折，简单网页任务大部分不需要看图推理

• P：企业 pipeline 占全部 LLM token 的比例；A：agentic / coding 的比例。chat / 消费端的判断今天多半跑在免费的专用分类器或自家小模型上，不算
• f：这块 workload 里"纯判断"调用占调用次数的比例；j：一次判断读多少 token；g：一次生成调用多少 token
• S：这块 workload 里能交给 Jev 的 token 份额
• c：用 Jev 每轮修剪上下文，能削掉 agent 输入的比例
• j 改了：v11 按 300–600 token 算，OpenRouter 实测每次判断平均读 3.3k (9/22：2,760 亿 token ÷ 8,360 万次)。判断和生成读的材料差不多长，所以 pipeline 里能交给 Jev 的份额比 v11 以为的大
• base 只算 pipeline：只有今天由 LLM 单独调用做的判断移走才算减少；agent 框架里的判断今天多半不是单独的 LLM 调用，放到 bull

Base → Bull：pipeline 的 f 0.4 → 0.5、g 4k → 3k，渗透率 40% → 60%，并计入 agentic (f 0.6、j 800、g 40k) 和上下文修剪 (c 6%)。上限：Bull 的参数，渗透率 100%。

agentic 为什么这么小：拿一次真实 session 算

• 主模型 50 次 × 平均 40K = 200 万 token；护栏 50 次 × 300 = 1.5 万，只占 0.75%
• 第 12 轮最说明问题：模型只写了 100 个字，看起来像判断，但它是读完 50K 才决定的，下一轮还要接着用这 50K，所以一个都省不下
• 真正能超过 5% 的是修剪上下文：第 20 轮的 60K 里有 20K 是过期的 tool 输出，每轮删掉，后 30 轮每轮少读 20K，约占全 session 的 25%。但 Claude Code 本来就有压缩，Jev 的增量我估 5–10%，而且删错一段 agent 就丢了线索，没有准确率数据，所以 base 给 0、bull 给 6%

对算力和 HBM：被移走的都是短上下文、不写字的调用，是整个池子里最便宜的 token。base 对推理算力的影响约 1%，bull 约 3%。两个抵消项：这些调用本来就在往 nano、DeepSeek 迁；决策便宜之后会长出新的判断量 (Jevons)，OpenRouter 上的数据标注很可能就是。

怎么把锚做硬：

• 自己的账单：Claude Code 或 Cowork 的 usage 拉一周，按 input 分桶，小于 2K 算判断、大于 10K 算生成，f、j、g 就都是实测
• 企业 pipeline：LLM observability 厂商 (Langfuse、Helicone) 的公开调用分布
• 替代还是新增：问 OpenRouter 头部 app 的开发者，接 Jev 之前这些判断是用什么做的

• TypeSafe：Introducing System One Models & Jev (2026-09-15)；官方文档与 eval
• TechCrunch (9/18)；The Rundown AI；TechTarget (9/23)；CellCog 时间线 (9/24)；explainx 对 HN 讨论的整理 (9/27)
• LiteLLM 基准 (9/18)；Laya 独立测试；browser-use repo；Vercel 博客 (9/16、9/18)；OpenClaw v2026.9.6 发布说明 (9/23)
• OpenRouter model activity，经 Jev OpenRouter Tracker 整理 (数据截至 9/25 全日)
• 各家 API 公开价；v11 的独立测试数字本次未重新核实

v1–v11 · 2026-09-15 至 09-22 · 首版及逐轮更新 (标题 Jev Primer)
v12 · 2026-09-28 · 按更新后的 new-thing-primer 重写：标题改为"日期 | 类型 | 主题"并加 tag，去掉标识栏，加左侧目录；第 1 节改成白话，全篇用"只打勾的审核员"一个比方；第 2 节拆成五段并标谁定义；新增第 5 节"一次判断交给谁最便宜"计算器、第 8 节管理层口径、OpenRouter 实际用量 (KPI、第 1 节图、第 7 节头部 app)；第 10 节改为"base 只算 pipeline"，j 由 300–600 换成实测 3.3k，base 从 2% 调到 3.5%、bull 从 7% 调到约 10%；Follow-up 把 Browser Use waitlist 并入第 7 节，新增 OpenRouter 跟踪