Claude Code 接上 Jev 更快？自家測試：功能開發慢 83%

Jev 不會讓 Claude Code 變便宜，而且這是 gateway 自己的基準測試說的。這篇文章讀了 jev-gateway 的原始碼和它的基準測試儲存庫，接著在一個真實的 Claude Code session 前面架設紀錄代理，看看一個路由器實際會收到什麼。

Jev 是 TypeSafe 的決策模型：一個在毫秒內回傳的機率，一週內被六支影片接進 Claude Code。賣點是「最便宜的 agentic 編碼迴圈」。而 gateway 自己的數字顯示，開著路由時，Opus 5 在一項功能任務上多發出 47% 的請求，多花 83% 的時間。

一個以毫秒回覆的路由器，要怎麼讓 Claude Code 變慢？答案在一行程式碼裡。在 Claude Code 內部，Jev 只拿到兩句話，而一個正常的 session 每次呼叫都會交給它 40 個工具。

Jev 是 TypeSafe 的決策模型。它不生成文字：你提出一個型別化的問題，它用一個選項、一個分數，或一個是非機率來回答。廠商公布的數字如下：

項目	數值
輸入價格	每百萬 token 0.04 美元
輸出價格	免費（「便宜到不需計費」）
延遲	70 到 500 毫秒
首頁標語	快 194 倍，便宜 445 倍

這個標語下方的部落格文章寫道，這兩個倍數是真實世界成效的高標，是拿兩個前沿模型的平均值來比較，作者也承認這個比較對那些模型有利。

5 天內 6 支影片把 Jev 接進 Claude Code。點閱最高的一支有 139,000 次觀看，稱它是目前為止最便宜的 agentic 編碼迴圈。這波熱潮由兩個儲存庫撐起：jev-gateway，一個給 Claude Code 和 Codex 用的本機代理，5 天前建立，181 顆星；還有 fast-jev-compaction，一個壓縮 plugin，在那前一天建立，6,400 顆星。gateway 是 Claude Code 接入的地方，所以這篇文章從那裡開始讀。

jev-gateway 位於 Claude Code 和 Anthropic API 之間。它用單一一個環境變數 ANTHROPIC_BASE_URL 啟動 Claude Code，指向一個本機連接埠。其他什麼都沒變；原始碼裡的一則註解寫道，沒有 gateway 憑證這回事，所以你的 Pro 或 Max 登入照常運作。

在 adapter 內部（src/adapters/messages.ts，第 99 行），一行程式碼決定 Jev 能做什麼：

steer: thinking || cached ? "hint" : "tool_choice"

只要 thinking 開著，或對話已有快取，gateway 就只能提示。否則它會強制指定工具。這行上方的註解解釋了原因：開著 thinking 時，API 會拒絕強制工具；而改變 tool_choice 會讓 Claude Code 每一輪都重讀的快取對話失效。

為了驗證真實請求長什麼樣子，一個 60 行的紀錄代理取代了 gateway 的位置，架在同一種連接埠上，讓 Claude Code 透過它啟動，對一個真實的儲存庫送出一個請求。這個請求帶著 thinking: adaptive 和三個快取標記；tool_choice 不存在；乾淨安裝下附帶了 24 個工具。把 gateway 那行程式碼套到這個請求上，強制路徑永遠不會被觸發。每一個 Claude Code 呼叫都落在提示模式。README 也是這麼寫的：在很大的工具清單上，期待更好的工具選擇，而不是更低的成本或延遲。

Jev 在 Claude Code 裡能做的事，是附加在最後一則訊息後面的兩句話：「一個路由模型建議，現在這個工具是最相關的動作。如果不合適，請忽略。」這就是全部的介入。模型可以自由忽略它，tool_choice 仍然維持在 auto。

強制指定工具不是一個選項，依 Anthropic 文件所述：在 Opus 5.5 和 Fable 5.1 上，強制工具會回傳 400 錯誤；在其他模型上，搭配手動 thinking 時也會出錯。改變 tool_choice 同樣行不通：prompt caching 文件寫道，這會讓 messages 快取失效，而那是一個長 session 裡最大的一塊。修改工具描述，則會讓整個快取失效：工具、系統與訊息全部作廢。

對請求的改動	對 prompt 快取的影響
在最後一則使用者訊息後附加提示	快取前綴不變
改變 tool_choice	messages 快取失效
修改工具定義	工具、系統與訊息全部失效

gateway 的註解說明了為什麼提示要放在最後：這樣快取的前綴才能和 Claude Code 下一輪重送的內容逐位元組相同。它前面還有一道防護：當最後一則訊息不是使用者的訊息時，請求會原封不動地通過。我擷取到的兩個請求，都是以 Claude Code 自己附加的 system 區塊結尾，一個是環境提醒，另一個是某個 hook 的輸出。在這種結構下，提示無處可落。但它確實會落在其他輪次上，因為工具結果會以使用者訊息的形式回來，而基準測試計算出 Jev 主導了三分之一到一半的 Claude Code 請求。

gateway 自己的基準測試，jev-gateway-bench，回答了開頭的問題。它在同一個 Claude Code、同一種所有人都在用的訂閱方案上，跑了 120 個 session，每個項目跑 5 次，不用任何 MCP 伺服器、plugin 或 skill。兩項任務都在一個小型西洋棋引擎上進行：一項是抓蟲，找出 5 個被植入的 bug；另一項是功能開發，加入代數記譜法。

模型、任務	開啟路由 vs 關閉路由
Opus 5，功能開發	輸入 token +61%，請求數 +47%，時間 +83%（仍然 5/5 解出）
Sonnet 5，功能開發	輸入 token +16%，時間 +37%
Sonnet 5，抓蟲	輸入 token −48%，時間 −25%

用作者自己的話說，抓蟲任務才是路由划算的地方。他們的解釋，正是問題的答案：gateway 只對 Claude 模型提示，所以一個不合適的提示，付出的是繞路的代價，而不是被免費忽略。

Codex 拿到的是強制版本。Jev 決定了 76% 到 100% 的 Codex 請求，相對於 Claude Code 的三分之一到一半。另一個測試框架裡，有一個模型變便宜但答錯了，5 題只解出 3 題而不是 5 題。又便宜又錯，不算省錢。

這個基準測試的侷限是真實存在的：每個項目只跑 5 次，樣本很小；只用了一個玩具等級的引擎；也沒有人重跑過。輸入大多有快取，所以省下輸入的價值，比省下輸出要小。

一個正常的 Claude Code session，每次呼叫會交給路由器什麼？代理紀錄給出了答案：40 個工具。同一個儲存庫，同一個單字提示，兩種設定：一個是空設定、沒有 MCP 伺服器的乾淨安裝，另一個是帶著伺服器和 plugin 的正常設定。

	乾淨安裝	正常設定
請求中的工具數	24	40（其中 16 個來自 MCP 伺服器與 plugin）
計費的前綴 token	47,411	57,277
輸出 token	4	4
一個「ok」的 API 等值成本	0.07 美元	1.15 美元

工具清單就是帳單。最重的定義都是內建的：光是 shell 工具就有 12,000 個字元，agent 工具將近 9,000 個。

基準測試的註腳裡，乾淨安裝看到 6 個工具、7,000 個 token，而一個載滿的設定看到 285 個工具。今天乾淨的 Claude Code 內建的工具遠多於當時，而載滿的情況反而更少見：大多數 MCP 工具都被放在一個搜尋工具後面，延遲載入，所以路由器看到的工具清單其實不大。無論大小如何，gateway 每次請求都會把這份清單送給 Jev；儲存庫上的一個開放 issue 指出，大部分答案被丟棄之前，這筆完整成本早已付出。這一切都不是 Jev 的錯，也不是 Jev 能修的。

在 Claude Code 裡做路由：不要。這只是一個模型可以忽略的提示，它在兩個 Claude 模型上都讓功能開發變慢，唯一的贏面在抓蟲任務。例外是在一個非常大的工具清單上進行一整天的抓蟲，README 本身就點名了這個情境。

壓縮 plugin，fast-jev-compaction：還不行。它需要一個搶先體驗的 hook 旗標，它的開放 issue 說 hook 在部分版本上不會註冊，而且在一次壓縮之後，模型寫了九份報告，全都聲稱工作已完成，而且全是捏造的。使用者比我更早發現這件事：這個 plugin 上最熱門的討論串有 491 個讚，而它最主要的反對理由不是速度，而是把逐字稿傳給第三方所涉及的服務條款。

Codex：那才是真正的目標。在那裡，gateway 會強制指定工具，Jev 主導了最多到每一個請求，而抓蟲任務的輸出 token 少了 57%。

用途	判定
Claude Code 裡的路由	不要，除了在非常大的工具清單上抓蟲
fast-jev-compaction	還不行
Codex	可以

這波熱潮做對的一件事：訂閱登入從沒被動過，gateway 只改了一個 URL。這篇文章的侷限：每個項目只跑 5 次，一個西洋棋引擎，一個沒人重跑過的基準測試儲存庫，還有我自己沒有跑過任何一個真正路由過的 session。我量測的是工具清單和請求本身，不是 Jev。Jev 本身很便宜。繞路才不便宜。