全网对不上的数字Jev 的速度倍数 193 倍还是 200 倍成本 444 倍还是 400 倍较真一下【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction9 月 15 日前 OpenAI 研究员创办的 TypeSafe AI 发布了不生成文本、只输出结构化决策的模型 Jev一天之内在 HN 冲到上千分、数百条评论随后以 fast-jev-compaction 为代表的生态项目把热度延续到 Claude Code 插件圈。热度越高数字越乱同样是比 LLM 快多少、便宜多少全网至少流传着三个版本——193 倍/444 倍、200 倍、40–200 倍/40–400 倍。本文不追热点把三个版本的数字摆在一起再结合 fast-jev-compaction 仓库源码拆解这些倍数从哪来、能不能复现以及爆款数字在传播中究竟经历了什么。同一组数字全网至少三个版本先把流传的版本逐条列出来微信公众号传播的文章标题Jev 全量开放速度快 193 倍、成本低 444 倍并称其只做选择题。虎嗅报道OpenAI 前研究员创办 TypeSafe AI推出非大语言模型 Jev速度提升 200 倍。掘金实测帖给 Codex 配 JevAgent 决策比 LLM 快 40-200 倍便宜 40-400 倍即一个区间。而如果把视线从模型挪到压缩插件本身还有第二层数字CSDN 多篇文章分别称压缩耗时 5–20ms实测 token 消耗降低近 100%实现 91.5% 上下文压缩率。同一件事速度 193 还是 200成本 444 还是 400区间还是端点较真的第一步是把它们当成四个不同的命题而不是一个命题的四处抄写错误——它们的测量对象、测量时间和传播层级本来就不一样。数字的口径是怎么裂开的第一层裂口原始测量 vs 转述转写193/444 与 200 都是Jev 对比 LLM的结论但原始口径多半是特定基准、特定版本、特定计费档位下的测量值。193 与 200 之间 3.5% 的差距本身就在正常测量波动范围内——任何跑过基准的人都知道一次模型更新、一个并发参数、一次网络抖动结果差出几个百分点太正常了。所以193 还是 200很可能根本不是谁抄错了而是两个时点、两套测量各自取了不同的结果至于444 还是 400更可能是原始区间取端点与取整的差别。第二层裂口模型快 ≠ 工程快这是最容易被忽略的一层。Jev单次决策比 LLM 快 200 倍是模型命题fast-jev-compaction压缩上下文是工程命题。把前者直接安到后者头上就会产生压缩也快了 200 倍的暗示。看仓库源码就知道一次压缩远不止一次模型调用src/compact.ts 中compact()先把全部历史装配成 statefitState再对每个候选工具调用拆出两个noul问题questionsFor这个 call 该不该留、它的 result 该不该留batchCalls按maxRequestTokens默认 30000把问题分批每一批都把完整 state 原样重发一遍然后用Promise.all并发请求README.md 的 Limitations 里写得很直白The full state is repeated with every request, so a history near the state ceiling costs one request per handful of questions——历史接近 state 上限时每十几个问题就要多付一次完整请求的输入 token。所以每次决策便宜 400 倍和每次压缩便宜 400 倍是两个数字。前者成立不代表后者成立后者还取决于历史长度、分批数量以及reductionRatio是否达标——hooks/fast-jev.ts 里minReductionRatio默认 0.25压缩率低于 25% 直接回退 Claude Code 内置摘要连 Jev 的账都不让你付。第三层裂口推理时间 vs 墙钟时间CSDN 文章说压缩耗时 5–20ms。这个数字在仓库里能对上号吗看 src/compact.ts 里stats.ms的来源const started Date.now(); // ... fitState、batchCalls、并发 askBatch、applyDecisions ... ms: Date.now() - started,这是客户端墙钟时间包含了 Jev API 的网络往返、并发调度和 JSON 序列化不是模型推理时间。5–20ms更像是 Jev 单次小请求的推理延迟把它说成压缩耗时等于把两个口径缝在了一起——而这种缝法在传播中几乎必然发生。快多少能不能复现从仓库源码看基准的边界较真的核心问题是这份仓库能不能复现200 倍/400 倍答案藏在三个文件里。第一单元测试根本不联网。tests/fast-jev-compaction.test.ts 全程用fakeJev替身回答问题README.md 也明说The unit tests use a fake Jev and never contact TypeSafe. The demo is the live network check. 也就是说仓库内唯一能给出真实延迟与成本的入口是npm run demoexamples/demo.ts而它只打印一次压缩的stats.ms和字符缩减率并不与 LLM 对照。第二演示是演的。仓库自带的 macOS 动画演示 demo/JevDemo/main.swift 是一个 SwiftUI 小应用README 对它介绍得很坦率It never calls the API; it exists to be screen recorded——脚本化、戏剧化、专为录屏而存在。它是传播视频里的效果演示不是基准测试。第三token 数字本身是估算值。src/state.ts 的estimateTokens用字符规则估算 token一个单词按每 6 个字母计 1 token、数字按半个、其他符号按 0.9注释承认它是校准出来的近似值calibrated to land 2–18% above the true count。连仓库自己的计数都要靠校准逼近真实值社区里那些整齐到吓人的百分比可信度可想而知。所以结论是200 倍/400 倍在这份代码里既无法证伪也无法复现——因为它根本不是这份代码承诺的东西。这份代码承诺的是保真不重写、只删除、保留的内容逐字不动README 第一段everything kept stays verbatim。把模型的倍数安到工程头上是传播中的错位。比倍数更该较真的压缩率的三个口径顺手把91.5% 压缩率也验算一遍。仓库里reductionRatio的定义在 src/compact.tsexport function reductionRatio(result: PickCompactResult, stats): number { const { charsBefore, charsAfter } result.stats; return charsBefore 0 ? 0 : (charsBefore - charsAfter) / charsBefore; }这是字符口径。而stats里同时有消息条数、调用数、state 估算 token 数、请求数——任何一个都能算出自己的压缩率。同一个压缩过程字符可能省 91.5%消息条数却省不了这么多因为文本消息在输出里永不删除README LimitationsOnly tool calls and results are candidates; text messages are never removed真正被删的只有工具调用及其结果。至于token 消耗降低近 100%本仓库每次压缩都要为完整 state 付输入 token——近 100%顶多指不再为摘要生成付输出 token绝不是总成本归零。三个口径三个结论都出自同一份代码。爆款数字该不该先验算回到最初的问题193 还是 200、444 还是 400较真之后的答案不是二选一而是承认它们可能都对只是都不完整。事实上在 Jev 刷屏的一周里质疑声并不少——InfoQ 报道过 Redis 之父直说绝大多数开发者其实不需要它掘金上也有《别吹 Jev 了》这样的反向文章。热度与口水齐飞的时候一套可落地的验算清单比立场更有用找原始出处而不是转载链。转载每过一手区间变端点、实测变宣称的概率就大一分。看区间别看端点。40–200 倍比200 倍诚实任何把单一整数写进标题的结论都应该先问测量边界在哪。分清模型命题和工程命题。Jev 快不等于 fast-jev-compaction 快后者还要算上分批重发完整 state 的代价。区分推理时间与墙钟时间。单次推理 5–20ms 和一次压缩 5–20ms 是两回事。警惕演示与生产的距离。录屏动画 demo/JevDemo/main.swift 是戏剧化脚本真实数字要看联网 demo 和线上压测。自己跑一遍是最便宜的验算。这个仓库npm install npm test全程不联网不花钱fake Jev 兜底npm run demo才需要TYPESAFE_API_KEY——验算成本低到没有理由不验。Jev 值不值得关注和它到底快多少倍是两件事。值不值得关注可以由代码质量判断——src/state.ts 里fitState那套多级收缩策略输入截断 → 文本缩写 → 旧消息折叠 → 调用单行化 → 无调用消息剔除 → 连续调用合并确实扎实而快多少倍只能由可复现的基准回答。下一次再看到XX 倍的标题先问一句这个倍数在哪份代码、哪次测量、哪个口径下成立【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
全网对不上的数字Jev 的速度倍数 193 倍还是 200 倍成本 444 倍还是 400 倍较真一下【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction9 月 15 日前 OpenAI 研究员创办的 TypeSafe AI 发布了不生成文本、只输出结构化决策的模型 Jev一天之内在 HN 冲到上千分、数百条评论随后以 fast-jev-compaction 为代表的生态项目把热度延续到 Claude Code 插件圈。热度越高数字越乱同样是比 LLM 快多少、便宜多少全网至少流传着三个版本——193 倍/444 倍、200 倍、40–200 倍/40–400 倍。本文不追热点把三个版本的数字摆在一起再结合 fast-jev-compaction 仓库源码拆解这些倍数从哪来、能不能复现以及爆款数字在传播中究竟经历了什么。同一组数字全网至少三个版本先把流传的版本逐条列出来微信公众号传播的文章标题Jev 全量开放速度快 193 倍、成本低 444 倍并称其只做选择题。虎嗅报道OpenAI 前研究员创办 TypeSafe AI推出非大语言模型 Jev速度提升 200 倍。掘金实测帖给 Codex 配 JevAgent 决策比 LLM 快 40-200 倍便宜 40-400 倍即一个区间。而如果把视线从模型挪到压缩插件本身还有第二层数字CSDN 多篇文章分别称压缩耗时 5–20ms实测 token 消耗降低近 100%实现 91.5% 上下文压缩率。同一件事速度 193 还是 200成本 444 还是 400区间还是端点较真的第一步是把它们当成四个不同的命题而不是一个命题的四处抄写错误——它们的测量对象、测量时间和传播层级本来就不一样。数字的口径是怎么裂开的第一层裂口原始测量 vs 转述转写193/444 与 200 都是Jev 对比 LLM的结论但原始口径多半是特定基准、特定版本、特定计费档位下的测量值。193 与 200 之间 3.5% 的差距本身就在正常测量波动范围内——任何跑过基准的人都知道一次模型更新、一个并发参数、一次网络抖动结果差出几个百分点太正常了。所以193 还是 200很可能根本不是谁抄错了而是两个时点、两套测量各自取了不同的结果至于444 还是 400更可能是原始区间取端点与取整的差别。第二层裂口模型快 ≠ 工程快这是最容易被忽略的一层。Jev单次决策比 LLM 快 200 倍是模型命题fast-jev-compaction压缩上下文是工程命题。把前者直接安到后者头上就会产生压缩也快了 200 倍的暗示。看仓库源码就知道一次压缩远不止一次模型调用src/compact.ts 中compact()先把全部历史装配成 statefitState再对每个候选工具调用拆出两个noul问题questionsFor这个 call 该不该留、它的 result 该不该留batchCalls按maxRequestTokens默认 30000把问题分批每一批都把完整 state 原样重发一遍然后用Promise.all并发请求README.md 的 Limitations 里写得很直白The full state is repeated with every request, so a history near the state ceiling costs one request per handful of questions——历史接近 state 上限时每十几个问题就要多付一次完整请求的输入 token。所以每次决策便宜 400 倍和每次压缩便宜 400 倍是两个数字。前者成立不代表后者成立后者还取决于历史长度、分批数量以及reductionRatio是否达标——hooks/fast-jev.ts 里minReductionRatio默认 0.25压缩率低于 25% 直接回退 Claude Code 内置摘要连 Jev 的账都不让你付。第三层裂口推理时间 vs 墙钟时间CSDN 文章说压缩耗时 5–20ms。这个数字在仓库里能对上号吗看 src/compact.ts 里stats.ms的来源const started Date.now(); // ... fitState、batchCalls、并发 askBatch、applyDecisions ... ms: Date.now() - started,这是客户端墙钟时间包含了 Jev API 的网络往返、并发调度和 JSON 序列化不是模型推理时间。5–20ms更像是 Jev 单次小请求的推理延迟把它说成压缩耗时等于把两个口径缝在了一起——而这种缝法在传播中几乎必然发生。快多少能不能复现从仓库源码看基准的边界较真的核心问题是这份仓库能不能复现200 倍/400 倍答案藏在三个文件里。第一单元测试根本不联网。tests/fast-jev-compaction.test.ts 全程用fakeJev替身回答问题README.md 也明说The unit tests use a fake Jev and never contact TypeSafe. The demo is the live network check. 也就是说仓库内唯一能给出真实延迟与成本的入口是npm run demoexamples/demo.ts而它只打印一次压缩的stats.ms和字符缩减率并不与 LLM 对照。第二演示是演的。仓库自带的 macOS 动画演示 demo/JevDemo/main.swift 是一个 SwiftUI 小应用README 对它介绍得很坦率It never calls the API; it exists to be screen recorded——脚本化、戏剧化、专为录屏而存在。它是传播视频里的效果演示不是基准测试。第三token 数字本身是估算值。src/state.ts 的estimateTokens用字符规则估算 token一个单词按每 6 个字母计 1 token、数字按半个、其他符号按 0.9注释承认它是校准出来的近似值calibrated to land 2–18% above the true count。连仓库自己的计数都要靠校准逼近真实值社区里那些整齐到吓人的百分比可信度可想而知。所以结论是200 倍/400 倍在这份代码里既无法证伪也无法复现——因为它根本不是这份代码承诺的东西。这份代码承诺的是保真不重写、只删除、保留的内容逐字不动README 第一段everything kept stays verbatim。把模型的倍数安到工程头上是传播中的错位。比倍数更该较真的压缩率的三个口径顺手把91.5% 压缩率也验算一遍。仓库里reductionRatio的定义在 src/compact.tsexport function reductionRatio(result: PickCompactResult, stats): number { const { charsBefore, charsAfter } result.stats; return charsBefore 0 ? 0 : (charsBefore - charsAfter) / charsBefore; }这是字符口径。而stats里同时有消息条数、调用数、state 估算 token 数、请求数——任何一个都能算出自己的压缩率。同一个压缩过程字符可能省 91.5%消息条数却省不了这么多因为文本消息在输出里永不删除README LimitationsOnly tool calls and results are candidates; text messages are never removed真正被删的只有工具调用及其结果。至于token 消耗降低近 100%本仓库每次压缩都要为完整 state 付输入 token——近 100%顶多指不再为摘要生成付输出 token绝不是总成本归零。三个口径三个结论都出自同一份代码。爆款数字该不该先验算回到最初的问题193 还是 200、444 还是 400较真之后的答案不是二选一而是承认它们可能都对只是都不完整。事实上在 Jev 刷屏的一周里质疑声并不少——InfoQ 报道过 Redis 之父直说绝大多数开发者其实不需要它掘金上也有《别吹 Jev 了》这样的反向文章。热度与口水齐飞的时候一套可落地的验算清单比立场更有用找原始出处而不是转载链。转载每过一手区间变端点、实测变宣称的概率就大一分。看区间别看端点。40–200 倍比200 倍诚实任何把单一整数写进标题的结论都应该先问测量边界在哪。分清模型命题和工程命题。Jev 快不等于 fast-jev-compaction 快后者还要算上分批重发完整 state 的代价。区分推理时间与墙钟时间。单次推理 5–20ms 和一次压缩 5–20ms 是两回事。警惕演示与生产的距离。录屏动画 demo/JevDemo/main.swift 是戏剧化脚本真实数字要看联网 demo 和线上压测。自己跑一遍是最便宜的验算。这个仓库npm install npm test全程不联网不花钱fake Jev 兜底npm run demo才需要TYPESAFE_API_KEY——验算成本低到没有理由不验。Jev 值不值得关注和它到底快多少倍是两件事。值不值得关注可以由代码质量判断——src/state.ts 里fitState那套多级收缩策略输入截断 → 文本缩写 → 旧消息折叠 → 调用单行化 → 无调用消息剔除 → 连续调用合并确实扎实而快多少倍只能由可复现的基准回答。下一次再看到XX 倍的标题先问一句这个倍数在哪份代码、哪次测量、哪个口径下成立【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
