AI 模型路由能省 coding agent 成本嗎？信心度實測與 jevgrep 拆解｜AIRUN
能不能省，要用自家帳單算。本文引用的實測公布的是準確率，唯一的成本數字來自 jevgrep 開發者的十題自測。這次測試顯示，在 ProofWriter 邏輯題上，GPT-6 Luna 自報的高信心度並不可靠；路由器若直接採信，可能放行不少錯誤。
發稿日是 2026 年 10 月 2 日。OpenAI 在 9 月 29 日的 DevDay 宣布 Decisions API，目前限量預覽。它從開發者定義的選項清單中挑出一個答案，讓程式據此分流：分類訊息、分派請求、決定 agent 下一步做什麼（Anthus，2026-10-01）。同時，GitHub 上的 jevgrep 從另一頭處理 coding agent 的成本：先幫 agent 找對檔案。
兩件事指向同一個問題：coding agent 的每一步該交給誰、該花多少 token。下面拆數據、拆做法，最後給老闆一份自己驗證的清單。
AI 模型路由是什麼？Decisions API 和它有什麼關係？
AI 模型路由是在任務送出前先判斷難度，再決定交給哪個模型：簡單的走便宜模型，困難的才付旗艦價。Decisions API 這類「從清單挑一個答案」的服務，正好可以拿來做這個判斷。
先講兩個名詞。coding agent 是會自己讀程式、改程式、跑測試的 AI 助手；token 是模型計費的單位，大約是字詞的片段，讀得越多、寫得越多，帳單越高。
據 The Decoder 與 Axios 報導，Decisions API 跑在 GPT-6 Luna 的某個版本上，Luna 是 OpenAI 的低價模型；OpenAI 自己的圖表標示每次決策約 150 毫秒。Anthus 形容它是 OpenAI 對 Jev 的回應，Jev 是既有的專用決策模型。
如果你的團隊每個任務都預設丟給最強的模型，連「把這個變數改名」也一樣，路由要處理的就是這一段。
Anthus 實測量了什麼？能當成「便宜模型能接多少 coding 工作」的證據嗎？
不能直接當。Anthus 用 ProofWriter 邏輯題測低價的 Luna，公布的對照組是 Jev、Kev、Laya 等專用決策模型，題目也不是 coding 任務。它公布的指標是準確率，不是成本。
測試在 2026 年 10 月 1 日發表（原文），出自 Anthus 自家的 Hard-Decisions benchmark。題目來自艾倫人工智慧研究所的 ProofWriter 資料集，共 3,600 題，每題是一小段用英文白話寫成的事實與「如果…就…」規則，再附一句陳述要模型判斷。Anthus 把 Luna 和 Jev、Kev、Laya 放在同一套題目上，每題只送一次請求，從固定選項中作答。原文另有依推理步數拆分的準確率結果，有興趣可直接讀原文。
讀這份數據要守四條邊界：
- 受測的是 Luna 本體。Anthus 自己說明，OpenAI 在 Decisions API 用的是特化版本，目前也沒有文件可供測試，所以這只是預覽。
- 對照組是專用決策模型。Anthus 公布的對照組為 Jev、Kev、Laya。「便宜模型和旗艦通用模型差多少」，不是這份測試要回答的問題。
- 題目是邏輯推理題。「改文案、補型別可以降級」這類 coding 結論，不能從這裡推出來。
- 兩份來源都不是第三方獨立測試。Hard-Decisions 是 Anthus 自家的 benchmark，以 Jev 等模型為對照；jevgrep 本身靠 Jev 運作，30% 出自開發者的 README。兩個來源都和 Jev 有關，數字請當廠商自述看待。
本文的數據都量準確率。路由實際能省多少錢，要用自家任務和帳單算。這份測試對路由真正有用的部分，在下一節：信心度。
路由器靠「信心度」分派任務，可以直接信嗎？
不能直接信。這次測試的條件是 GPT-6 Luna 本體、ProofWriter 邏輯題、每題一次請求；在這個條件下，Luna 自稱 99% 以上有把握的答案，實際只有 68% 答對。路由器若設定「99% 有把握才自動處理，其餘交給人」，這條規則就跟那個 99% 一樣不可靠。這只是一個模型版本、一種題型的結果，不能直接外推到 coding 任務；但足以說明，信心度在校準之前不該拿來當閘門。
這裡的關鍵詞是「校準」：模型說九成把握時，實際上真的有九成答對，信心度才有用。Anthus 從 2023 年起就依模型信心度分派工作：在 Call Criteria 這項服務裡，模型依數百份客戶評分表替通話打分，系統沒把握的通話交給真人複核。他們發現，從 OpenAI 模型的 token 對數機率（模型替每個候選答案內部打的機率分數）讀出的信心度過度集中，幾乎每個答案看起來都很確定；較新的推理模型則常常不提供這項數據。所以他們自己建信心度：抽出每個答案背後的機率，拿已標註正確答案的資料比對、校準，確認可信之後才拿來分派（Anthus）。
換成 coding agent 的情境：路由器判斷「這是簡單任務」本身就是一個決策，判斷錯了，便宜模型就會在一個其實需要多步推理的 bug 上亂改。省下的 token 費，可能花在工程師返工上。
「先找對檔案再動手」為什麼能省 token？jevgrep 怎麼做？
coding agent 接到陌生任務時，有一部分成本花在翻找該改哪些檔案。jevgrep 把這段搜尋交給專門的工具，先回傳相關檔案與原始碼片段，agent 再動手實作。開發者公布整體 coding agent 成本約低 30%，但沒有拆解省在哪一段。
jevgrep 是一個命令列工具，指令叫 jg。你用白話問「請求進到 handler 之前在哪裡檢查身分驗證？」，它用 Jev 判斷資料夾、檔案與宣告的相關性，一次回傳摘要、檔案清單、帶行號的原始碼片段。截至發稿，這個專案在 GitHub 約有 2k 顆星。
開發者公布的數據是：在十個 SWE-bench 任務的比較中（SWE-bench 是用真實 GitHub 問題測 AI 修程式能力的基準），jevgrep 與基準組同樣完成其中 8 題，成本較低，README 標語寫「約低 30%」（README）。README 稱的是整體 coding agent 成本，我們讀到的段落未拆解省在哪一段，也未說明是否含 jevgrep 自身的呼叫費用。十題是很小的樣本，而且是開發者自己跑的，當作方向參考即可。
導入前要知道的限制：
- 需要 Node.js 22 以上，並自備 Vercel AI Gateway、OpenRouter 等服務商的金鑰。我們讀到的 README 段落未見 jevgrep 自身呼叫模型的費用說明；既然要自備金鑰，導入前請自行試算。
- 只裝 CLI 不夠，要另外執行
jg skill安裝技能檔，coding agent 才會用它。支援 Claude Code、Codex、OpenCode 等。 - 宣告解析（讀出程式裡的函式與類別定義）支援 Python、TypeScript/JavaScript、Go、Rust，其他語言走備援模式。
- 開發者明講：輸出是給 agent 的線索，不保證找齊所有相關檔案；已知確切函式名稱或路徑時，直接讀檔或用
rg（ripgrep，一種快速文字搜尋工具）搜尋就夠了。
三種路由做法，哪一種適合小團隊？搜尋前置怎麼算？
小團隊建議從「規則路由」起步：用任務類型這種看得見的條件分級，等累積足夠的標註紀錄，再考慮依信心度自動分派。一開始就全自動，最容易在看不到的地方出錯。
下表是作者依三種做法整理的判斷，不是實測結果：
| 做法 | 怎麼運作 | 導入成本 | 需要的資料 | 出錯時誰發現 | 適合誰 |
|---|---|---|---|---|---|
| 全部用旗艦 | 每個任務都丟最強模型 | 最低，不用改流程 | 不需要 | 測試與工程師審查 | 任務量很小、出錯代價極高 |
| 規則路由 | 依任務類型分級，例如改字、補測試走便宜模型 | 中等，要寫分級規則並持續維護 | 任務類型清單、各類任務的返工紀錄 | 測試與真人抽查；規則分錯要靠返工紀錄回頭查 | 多數中小團隊的起點 |
| 信心度路由 | 模型自評難度或把握度，自動決定升級 | 最高，要建校準流程並投入人力 | 一批已標註正確答案的任務，用來校準 | 只有校準與抽查抓得到；未校準時錯誤可能直接被放行 | 有標註資料、能做校準的團隊 |
搜尋前置要另外算。jevgrep 這類工具處理的是 agent 找檔案那一段，可以和上面任何一種路由疊加使用。它本身也靠 Jev 判斷相關性，需要自備服務商金鑰，導入前要把這筆費用一起算進去。
這對台灣中小企業和接案工作室意味著什麼？
我們的判斷：每月 AI 寫程式帳單已經讓你皺眉的團隊，可以從規則路由和搜尋前置開始分級；但任何自動升降級機制，在用自家任務驗證之前，都不該接手會碰到客戶交付的工作。
如果你的專案毛利薄、AI 帳單占營收的比重高，分級的效益最明顯。日常任務裡常見淺層修改：改文案、補型別、照既有模式加欄位。這些任務能不能安全降級，目前沒有公開的 coding 實測可以回答，Anthus 的邏輯題數據也不能代答。我們判斷它們出錯時較容易被測試抓到、返工成本較低，適合當第一批試降級的對象。
台灣團隊還要多看一點：ProofWriter 的題目以英文寫成，中文需求單、中文註解、中文文案這類任務的表現，這份測試沒有涵蓋。如果你的任務以中文為主，抽查樣本裡要放進足夠的中文任務。
另一頭，除錯和跨模組重構，在我們看來是最耗 token、也最需要多步推理的工作，這是作者判斷。把這類工作降級，帳面省下的費用可能被返工和客訴抵銷。
所以分工建議是：淺層、有測試保護的任務先試降級；多步、跨檔案的任務留在旗艦；中間地帶靠真人抽查決定。
老闆要怎麼自己驗證路由有沒有省到錢？
用自家最近一個月的真實任務重跑一次，分別記錄每個任務的費用、完成率與返工時間。廠商跑分只能參考，你的程式庫、你的任務組合，才是唯一有效的尺。
- 挑樣本：從近期工單挑 20 到 30 個任務，涵蓋簡單修改與困難除錯。
- 記成本：每個任務記下用了哪個模型、花多少 token、多少錢。
- 記品質：測試是否通過、是否需要工程師返工、返工花幾分鐘。
- 查信心度：若路由器依信心度分派，抽查它標「簡單」的任務，實際錯誤率是多少。
- 留閘門：會動到客戶正式環境、合約交付的變更，一律保留真人審核。
- 每季重測：模型改版、降價都會改變結論，數字要定期更新。
我們的立場一句話：先分級、後自動化，任何「省多少」的說法，都等自家帳單上的數字出來再算數。
常見問題
AI 模型路由真的能省錢嗎？
可能，但目前公開資料沒有直接證明。Anthus 的測試公布的是準確率，不是成本；本文唯一的成本數字來自 jevgrep 開發者的十題自測。README 稱整體 coding agent 成本約低 30%，未拆解省在哪一段，也未說明是否含 jevgrep 自身的呼叫費用。路由實際省多少，要用自家任務組合和帳單算。
便宜模型在什麼情況下不能用？
目前沒有公開的 coding 實測能劃出這條線。Anthus 用 ProofWriter 邏輯題測低價的 GPT-6 Luna，公布的對照組為 Jev、Kev、Laya 等專用決策模型，題目也不是 coding 任務。我們的判斷是：跨模組除錯、大範圍重構這類出錯代價高的工作，先留在旗艦模型，等自家任務量測過再調整。
路由器自己說有把握，可以直接相信嗎？
不建議直接相信。Anthus 用 ProofWriter 邏輯題測試發現，GPT-6 Luna 自稱 99% 以上有把握的答案，實際只有 68% 答對。這是單一模型版本、單一題型的結果，但足以提醒：信心度要先拿已知正確答案的資料比對校準，確認模型說九成把握時真的九成答對，才適合拿來決定任務要不要升級。
jevgrep 是什麼？中小團隊值得裝嗎？
jevgrep 是讓 coding agent 用白話找程式碼的命令列工具，先回傳相關檔案與原始碼片段，再交給 agent 實作。開發者自己跑的十題 SWE-bench 比較中，完成題數與基準組相同、整體成本約低 30%，這是開發者自述，不是第三方測試。程式庫大又陌生的團隊值得試；需要 Node.js 22 以上，並自備模型服務商金鑰。README 未見 jevgrep 自身呼叫模型的費用說明，導入前請自行試算。
旗艦模型降價後，還需要模型路由嗎？
要看價差是否大過返工成本。旗艦降價會縮小價差，但便宜模型做錯時的返工時間不會跟著降價。目前沒有公開資料能替你回答，請把新價格和自家返工紀錄代入重算，再決定分級規則要不要調整。