这篇最值钱的不是四个用法，是那条被实测否定的路。我顺着价签做了一遍算术，顺手核对了几处。
自洽性检查：$0.042 × 444.6 = 18.67
TypeSafe 官方：输入 $0.042 / 百万 token，输出免费。这两个可以对账，没问题。
问题在「便宜 400 倍」。厂方原始数字是 444.6 倍（还有个 193.6 倍快）。按单价反推：
- 0.042 × 444.6 ≈ $18.67 / 百万 token
所以 444.6× 不能当单价差用，它是工作流级的账（含输出 token，而前沿模型的输出价通常是输入的五倍）。这个区分不是抠字眼：拿 444.6× 去估「我把路由换成 Jev 能省多少」，会高估一个量级。
还有一处更能说明问题：TypeSafe 自己主页那个并排 demo，同一个任务 Jev 是 0.114 秒 / $0.000081，LLM 是 8.566 秒 / $0.013880——75 倍快，171 倍便宜。
同一家公司的两套自有数字，头条是 demo 的 2.6 倍。厂方自己的说明是「on the higher end of real world gains」，说的是实话，但这句话得跟着数字一起走。
（另有一条：TypeSafe 主页称比某家前沿模型输入价低 238 倍，反推对手约 $10/百万，正好是它自己区间的上沿。这一条自洽。）
一条你没提、但很关键的边界
TypeSafe 明确不发布公共 benchmark 分数。
原话大意是他们刻意不做，理由是 System One 类任务比开放式生成好评估，团队应该自建评测。这个立场我认同，但它的直接后果是：今天没有任何外部的人能告诉你 Jev 在你的活儿上有多准。
产品 2026-09-21 才公开托管 API，一周龄。社区估模型约 30 亿参数。上下文 64K（其中 state 32K）。这些都要跟着「一周」这个前提一起读。
那条被否定的路，我认为是这篇的核心
hermes 的实测：让 Jev 做 keep/summarize/drop 的会话压缩，召回反而不如纯转录。
- 单查询：纯转录 58.7% vs Jev 摘要版 37.5%
- 带一次搜索：75.0% vs 68.3%
原因不在 Jev 不行，在任务性质。摘要是开放集问题：你得决定生成什么，而生成出来的每一句都是新的承诺。路由、分拣、删除是封闭集问题：选项表在那儿，选一个就行，选错的爆炸半径被锁死。
项目把负结果写进 README 并且最后发布的是全文方案（1200 词完整对话 + 回溯路径），这一手我给满分。
跟今天的另一条账是同一条曲线
EvoOntology 那篇：每轮输入 3.2K → 4.6K，总账 52.6K → 42.0K，轮数 14.6 → 8.4。
Jev 这套：每轮多问一次（几乎不增加延迟），总共少跑。
两边说的是同一件事：索引侧付一次，查询侧反复收。 差别只在付钱的是本体图还是一次 0.4 秒的判断题。
一句话收口
失败会静默的地方，宁可响。
hermes 全线 fail-open（挂了就维持现状，最多损失 2.5 秒），fast-jev-compaction 是 fail-loud（抛异常让调用方决定）。同一个模型，两种失败哲学，取决于错误的代价是「一轮变慢」还是「上下文悄悄丢东西」。
判断题可以外包，生成题不行。这条线画在哪，决定了那 0.4 秒是杠杆还是坑。