AIDive重點摘要
- 在 Claude Code 裡，jev-gateway 從不強制指定工具。一行程式碼
steer: thinking || cached ? "hint" : "tool_choice"，只要請求帶有延伸思考（extended thinking）或已快取的對話，就會切換成提示模式（hint mode），而真正的 Claude Code 請求在第一輪就兩者兼具。 - 提示是附加在最後一則使用者訊息後的兩句
<system-reminder>。模型可以自由忽略它；如果 Claude Code 已經把自己的 system reminder 放在最後一個區塊，這則提示根本不會被附上。 - 閘道自己的基準測試（120 個工作階段）顯示，對 Claude 模型而言，路由在除錯上划算，在功能開發上反而吃虧：Opus 5 在功能任務上輸入 token +61%、請求數 +47%、耗時 +83%，Sonnet 5 則是輸入 +16%、耗時 +37%。
- Jev 真正有效的地方是 Codex：閘道在那裡會強制指定工具，Jev 引導了 76 到 100% 的 Codex 請求，Claude Code 請求則只有 34 到 51%。
- 我們在自己機器上的實測：乾淨的 Claude Code 2.1.280 請求本身就帶有 24 個工具與 47,411 個前綴 token；掛了 MCP 伺服器的一般設定帶有 40 個工具與 57,277 個 token，而閘道每次呼叫都會把這份工具清單重新送給 Jev。
- fast-jev-compaction 是星數最多的 Jev 工具，但它有未解決的 issue，指出其 hooks 在目前的 Claude Code 版本上無法註冊，且完整對話記錄會送往第三方 API。暫時不要用。
測量結果說明
Jev 是決策模型，不是文字生成模型。供應商的定價是輸入 $0.042 / MTok、輸出免費，宣稱端到端回應時間為 70ms-500ms，並在「193.6x faster, 444.6x cheaper」的標題下方自己寫明，這些數字「are on the higher end of real world gains」s3。同一篇文章也承認，參考答案是 GPT-6 Astra 與 Fable 5.1 的平均，使比較偏向 OpenAI 和 Anthropic 的模型 s3。
jev-gateway 只靠一個環境變數接上 Claude Code：bin/clients.mjs 把 ANTHROPIC_BASE_URL 指向本機閘道，並保留你的 Max 登入不動 s1。在 src/adapters/messages.ts 裡，閘道先問 Jev 下一步適合哪個工具，再決定如何傳遞答案。當請求啟用 thinking 或帶有 cache_control 區塊時，它就給提示；否則設定 tool_choice s1。提示的內容是：一個工具路由模型認為所指名的工具是最相關的下一步，如果它不符合使用者實際要求的內容就忽略。它以 <system-reminder> 區塊的形式附加在最後一則使用者訊息後 s1。
Anthropic API 沒有給其他選擇。啟用手動延伸思考時，tool_choice: any 和 tool_choice: tool 不受支援並會回傳錯誤，而 Claude Opus 5.5、Claude Fable 5.1 和 Claude Mythos 5.1 不論有沒有思考，只要強制使用工具都會回傳 400 s4。閘道自己的註解漏掉了一個細節：文件說 Claude Opus 5 在開啟思考時確實支援強制工具選擇 s4。在快取方面，層級順序是 tools、system、messages；更動 tool_choice 只會讓 messages 快取失效，而修改工具定義則會讓整個快取失效，這就是閘道選擇附加一個區塊，而不是改寫工具描述的原因 s5。
幾乎沒人引用的基準測試，其實是閘道作者自己做的。六個模型、兩個任務、每種模式跑五次，共 120 個 agent 工作階段，時間在 2026-09-18 和 19 日，GPT 模型在 Codex 0.154，Claude 模型在 Claude Code 2.1，每個 agent 都是乾淨環境，沒有 MCP 伺服器、外掛或技能 s2。在 chess-bugfix 上，每個模型啟用路由後都用了更少 token，且沒有任何結果變差。在功能任務 chess-san 上，路由讓 Opus 5 和 Sonnet 5 明顯變差，作者也點出原因：閘道對 Claude 模型只給提示，所以不合適的提示會造成一次繞路，而不是被免費忽略 s2。路由也曾讓正確率下降一次：GPT-5.6 Luna 單獨跑時 chess-san 五次全過，開啟路由後只過三次 s2。作者補充，輸入 token 大多已快取（80 到 96%），所以節省輸入的價值低於節省同樣數量的輸出 token，而且每五次執行 Jev 本身的花費介於半美分到十美分之間 s2。120 次執行中有一次，Luna 系列的 chess-bugfix.on.3，在 agent 於 /tmp 找到另一次執行的測試腳本後，被標記為 contaminated s2。
促使我們自己做測試的是 README 的一則註腳：使用 --user-tools 時，某個設定每個 Claude Code 請求都送出 285 個工具和約 200,000 個 token，乾淨環境則是 6 個工具和 7,000 個 token s2。我們量了同一個位置。乾淨的 Claude Code 2.1.280 請求帶有 24 個工具、87,547 個字元的工具定義，以及 47,411 個計費前綴 token（寫入 16,221、讀取 31,190）；完整設定帶有 40 個工具、93,179 個字元的定義與 57,277 個前綴 token，全部都是寫入。兩者都帶有 thinking: {type: "adaptive"} 和 3 個 cache_control 區塊，沒有 tool_choice，這正是讓 messages.ts 鎖定在提示模式的條件 s1。一句「ok」的回覆，在乾淨的 Sonnet 5 上以 API 等值計算花費 $0.07，在完整的 Fable 5.1 上則是 $1.15，數字取自 Claude Code 自己的 total_cost_usd 和 usage 欄位，也就是閘道啟動器所處的同一個位置 s1。
關於 fast-jev-compaction，也就是「instant compaction」討論串（分數 495、117 則留言）背後的外掛 s9，比起星數，未解決的 issue 更值得看：#21 回報安裝後顯示 Hooks (0)，因為在 Claude Code 2.1.272 上 session.compact 和 turn.complete 不是可識別的 hook 事件；#88 指出 hooks 無法取代壓縮，且完整對話記錄會送往第三方 API；#65 記錄了一次壓縮後連續 9 份捏造的「work done」報告；#89 指出 --resume 時壓縮會被還原 s7。討論串中 84 分的最高票抱怨，針對的是供應商的服務條款與資料控制 s9。技能建議 cookbook 是供應商針對 agent 工具清單公布的唯一一項實測成果：載入錯誤技能的比例從 16.8% 降到 7.3%，在沒有合適技能時仍載入技能的比例從 9.8% 降到 4.0% s13。
測量數據
閘道的基準測試，百分比是相對於同一模型關閉路由時的結果 s2。
chess-bugfix：找出並修正五個被植入的 bug
| 模型 | 解題數，開 / 關 | 輸出 token | 輸入 token | LLM 請求數 | 秒數 | Jev 引導率 |
|---|---|---|---|---|---|---|
| GPT-6 Astra | 5/5 · 5/5 | 1,226 (-57%) | 96k (-7%) | 5 (0%) | 41 (-39%) | 100% |
| GPT-5.6 Sol | 5/5 · 5/5 | 3,211 (-57%) | 202k (-40%) | 9 (-36%) | 78 (-36%) | 93% |
| GPT-5.6 Luna | 1/4 · 0/5 | 10,519 (-12%) | 506k (-10%) | 19.5 (-15%) | 200 (+10%) | 86% |
| Fable 5.1 | 5/5 · 5/5 | 8,675 (-13%) | 276k (-19%) | 14 (-22%) | 148 (+6%) | 45% |
| Opus 5 | 5/5 · 5/5 | 16,693 (-7%) | 406k (-22%) | 18 (-14%) | 218 (+2%) | 38% |
| Sonnet 5 | 5/5 · 5/5 | 16,623 (-41%) | 616k (-48%) | 26 (-26%) | 243 (-25%) | 34% |
chess-san：為一個可運作的引擎加上代數記譜法
| 模型 | 解題數，開 / 關 | 輸出 token | 輸入 token | LLM 請求數 | 秒數 | Jev 引導率 |
|---|---|---|---|---|---|---|
| GPT-6 Astra | 5/5 · 5/5 | 3,663 (0%) | 143k (+2%) | 7 (0%) | 88 (+8%) | 95% |
| GPT-5.6 Sol | 5/5 · 5/5 | 5,096 (-9%) | 147k (-39%) | 7 (-36%) | 78 (-16%) | 86% |
| GPT-5.6 Luna | 3/5 · 5/5 | 6,809 (-14%) | 315k (-51%) | 14 (-42%) | 121 (-14%) | 76% |
| Fable 5.1 | 5/5 · 5/5 | 13,497 (-24%) | 331k (-27%) | 13 (-19%) | 167 (-26%) | 51% |
| Opus 5 | 5/5 · 5/5 | 20,152 (+22%) | 676k (+61%) | 25 (+47%) | 390 (+83%) | 44% |
| Sonnet 5 | 5/5 · 5/5 | 23,487 (+9%) | 991k (+16%) | 32 (+3%) | 327 (+37%) | 42% |
我們自己的請求擷取，也就是 jev-gateway 所處的位置 s1。
| 乾淨 | 完整 | |
|---|---|---|
| Claude Code 選用的模型 | claude-sonnet-5 | claude-fable-5-1 (使用者設定, 1M) |
請求中的 thinking |
{type: "adaptive"} |
{type: "adaptive"} |
cache_control 區塊數 |
3 | 3 |
tool_choice |
無 (auto) | 無 (auto) |
| 請求中的工具數 | 24 | 40 (28 個內建 + 12 個 MCP) |
| 工具定義字元數 | 87,547 | 93,179 |
| 系統提示字元數 | 27,754 | 12,436 |
| 整個請求字元數 | 134,882 | 155,718 |
| 計費的前綴 token (快取寫入 + 讀取) | 47,411 (16,221 寫入, 31,190 讀取) | 57,277 (全部寫入) |
| 輸出 token | 4 | 4 |
| 一句「ok」的 API 等值成本 | $0.07 | $1.15 |
測試方法：在 127.0.0.1:8790 上跑一個 60 行的記錄代理，把每個請求逐位元組轉發到 https://api.anthropic.com 並記錄其內容，正是 bin/clients.mjs 給 jev-gateway 的那個位置。Claude Code 2.1.280 以無介面模式執行，指令為 claude -p "Reply with the single word ok. Do not use any tool." --output-format json --max-turns 1，在一個私有的 Expo 儲存庫（1,021 個受追蹤檔案）中，使用 claude.ai 訂閱。乾淨環境：CLAUDE_CONFIG_DIR 指向空目錄、--strict-mcp-config、--setting-sources project。完整環境：這台機器的一般使用者設定、專案 .mcp.json、使用者 MCP 伺服器與已安裝的外掛。每種設定只跑一個請求，只看第一輪；我們沒有 Jev 金鑰，所以迴歸數據是重播閘道的基準，而非自行重現。
週一就做
- 在加任何路由器之前，先量你自己的位置：啟動一個記錄代理，把
ANTHROPIC_BASE_URL指向它，執行claude -p "Reply with the single word ok." --output-format json --max-turns 1，然後讀輸出中的cache_creation_input_tokens加上cache_read_input_tokens。 - 數一數那個請求裡的工具數。如果你很少用的 MCP 伺服器把清單撐大了，就從
.mcp.json移除，或改成依專案設定範圍；不論有沒有路由器，這項削減都會作用在每個請求上。 - 如果你仍想在 Claude Code 中使用 Jev，打開你 jev-gateway clone 裡的
src/adapters/messages.ts，確認steer那一行：開著思考或快取時，你買到的是提示，不是路由。 - 用
--user-tools在你自己的儲存庫上跑閘道的基準測試，不要輕信西洋棋的表格；只有當找 bug 的任務顯示請求變少、且解題結果沒變時，才保留路由。 - 在 issue #21、#88 和 #89 關閉之前，不要安裝 fast-jev-compaction；安裝後確認
/hooks列出的 hooks 多於零個。 - 貼上金鑰之前先讀供應商的服務條款：每個被路由的請求都會送出你的工具清單與最後一則訊息，而壓縮外掛則會送出完整對話記錄。
- 如果你也用 Codex，先在那裡測試 Jev：基準顯示有回報的正是強制
tool_choice。
延伸閱讀
- 各模型的強制工具使用表，包含哪些模型會回傳 400，以及哪些思考模式會擋住
any和tools4。 - 快取失效表：先
tools、再system、再messages，以及解釋閘道設計的tool_choice那一列 s5。 - jev-gateway 的 issue #24：整個工作階段不變的工具清單在每個請求都被重新送給 Jev，是儀表板沒顯示的成本中心 s14。
- 基準 README 的資料完整性章節：120 次執行中有 119 次保持獨立，一次在
runs.jsonl中被標記為contaminateds2。 - 在程式碼 agent 框架之外，把 Jev 當作分類器或過濾器，用於公開與私有資料的獨立評測 s12。
- 為什麼供應商的評測是對照兩個模型而非真實標準答案，以及這對標題倍率有什麼影響 s11。
- 第三方對 jev-gateway 的評論，逐步解析「Jev 選擇，LLM 撰寫」的分工，以及當天就修好的 localhost 暴露問題 s8。
- HN 發表討論串，定價與補貼問題在其中公開辯論 s10。
來源
- jev-gateway, GitHub, vinilana。為什麼值得讀：
src/adapters/messages.ts裡有決定提示或強制工具的那一行，bin/clients.mjs則顯示啟動器只設定ANTHROPIC_BASE_URL。 - jev-gateway-bench, GitHub, vinilana。為什麼值得讀：完整的 120 個工作階段表格與作者自己的解讀，包括那次被污染的執行。
- Introducing System One Models & Jev, TypeSafe AI。為什麼值得讀：供應商自己公布的定價、延遲，以及為 444.6x 說法加上限定的註腳。
- Forcing tool use, Anthropic docs。為什麼值得讀：各模型下哪些
tool_choice值會出錯的對照表。 - Prompt caching, Anthropic docs。為什麼值得讀：迫使採用提示設計的快取失效層級。
- fast-jev-compaction, GitHub, tamaratran。為什麼值得讀：先看 issues 分頁，再看 README。
- jev-gateway Review: Jev Picks, the LLM Writes, mrjev.com。為什麼值得讀：外部人士對閘道架構的逐步解析。
- Instant Claude Code compaction is my favorite use of Jev so far, r/ClaudeCode。為什麼值得讀：實際使用者的討論串，最上面就是對服務條款的質疑。
- HN: Introducing System One Models and Jev, Hacker News。為什麼值得讀：關於定價與可持續性的發表辯論。
- The Evals: Measured Against Two Models, Not Against Truth, novcog。為什麼值得讀：對供應商倍率背後評測方法的批評。
- Testing Jev on public and private data: classifier or filter, Aman Kumar。為什麼值得讀：在程式碼 agent 之外的獨立測量。
- Skill suggestion cookbook, TypeSafe docs。為什麼值得讀：唯一公布的工具清單選擇數據，16.8% 降到 7.3%。
- jev-gateway issue #24, GitHub。為什麼值得讀：沒人計算過的工具清單重送成本。
- Jev + Claude Code: compaction and a Sonnet 5 source check, jevmodel.ai。為什麼值得讀：對壓縮說法的第二次檢視，含 Sonnet 5 的檢查。
FAQ
jev-gateway 在 Claude Code 裡會強制指定工具嗎？
只有當請求既沒有延伸思考、也沒有 cache_control 區塊時才會。我們擷取的第一輪請求，無論乾淨或完整設定，兩者都有，所以實際上閘道只會給提示。
為什麼閘道不乾脆改寫工具描述來更強力地引導？
修改工具定義會讓整個提示快取失效，包括 tools、system 和 messages。把區塊附加在最後一則使用者訊息後，只會動到 messages 這一層，是放提示成本最低的位置。
那 Jev 對寫程式就沒用嗎？
不是。基準顯示它在 Codex 上有回報，那裡工具是被強制的，76 到 100% 的請求被引導；對所有模型的除錯任務也有回報。閘道自己的數字不支持的，是「最便宜的 Claude Code」這種說法。
我該試試 fast-jev-compaction 嗎？
等 hook 註冊相關的 issue（#21、#88）與 --resume 的 issue（#89）關閉後再說，並先決定完整對話記錄送往第三方 API 在你的儲存庫中是否可以接受。