Jev 接入 Codex 真的能省 90% Token 嗎？Skill 與路由實測解讀

TypeSafe Skill 實際安裝了什麼#

官方提供的安裝指令是：

1
npx skills add typesafe-ai/skills --skill typesafe-ai

這會把 TypeSafe 的 Agent Skill 安裝到選定的 agent 環境。Skill 內容主要教 agent：如何讀最新文件、選擇 Choice／Score／Noul、設計問題、呼叫 API，以及如何把機率與信心值交給程式處理。

它不是常駐 Proxy，也不是 Codex 的模型選擇器。若只有安裝 Skill 並輸入「使用 TypeSafe skill」，Codex 仍然需要先收到你的請求、理解任務、決定是否呼叫 Jev，再讀回結果。

因此，Skill 比較像整合說明書。它能降低 Codex 寫錯 API 介面的機會，但不等於 Jev 已經插在所有請求前面。

四種接法會省到不同的東西#

如果目標是讓產品 API 便宜，直接把分類與篩選移出生成式模型通常最清楚。如果目標是節省 Codex 訂閱額度或 API 成本，則需要外部 Router 能在模型執行前選擇較便宜的模型；這已經不是安裝 Skill 可以完成的事。

237 個 Codex 回合的回測說了什麼#

社群專案 jev-codex-router 公布一組七天、237 個真實 Codex turn 的歷史回放。它根據舊 session log 的 Token 使用量，讓 Jev 重新判斷每一回合應走 Luna、Sol 或 Astra，再以當時牌價重新估算。

公布結果為：

這比「省 90%」保守，也比較有方法說明，但仍不是正式線上對照實驗。作者列出的限制包括：

• 各情境沿用相同 Token 量，沒有完整模擬推理強度改變。
• 切換模型可能讓 Prompt Cache 失效，實際節省可能更低。
• 資料只來自一位使用者，任務組成不代表其他人。
• 回測衡量牌價，沒有證明較便宜路由的任務品質相同。
• 9 月 20 日更新的現行 policy 尚未完成品質與額度量測。

另一個值得注意的結果是，最早的 policy 在低信心時退回最高階模型，最後只省下 11.9%；改為退回中階模型後才得到 59.9%。這表示成本不只取決於 Jev 分類準不準，也取決於 fallback 規則怎麼設計。

真正可行的 Codex 分工方式#

若不想改動 Codex 的模型傳輸層，較容易控制的是讓 Jev 處理明確且可批次的小判斷，Codex 保留規劃與實作：

1
程式先整理候選資料
2
    ↓
3
Jev：分類、相關性、風險或下一個工具
4
    ↓
5
程式套用門檻與 policy
6
    ├─ 固定流程可以處理 → 不呼叫 Codex
7
    └─ 需要解釋或修改程式 → 交給 Codex

例如大型程式庫搜尋，可以先由傳統搜尋取得候選檔案，再讓 Jev 排序相關性，只把高分片段交給 Codex。這可能減少無效上下文，但需要比較「加入 Jev 前後，實際送進 Codex 的 Token」；不能只看到 Jev 很便宜就推定 Codex 額度一定下降。

若要把 Jev 做成 MCP，也要先做 MCP 能力與權限盤點。第三方 Jev MCP 可能會把程式碼、提示詞或文件內容送到 TypeSafe API；應確認 server 原始碼、實際傳送欄位、金鑰存放方式與 fallback 行為。

怎麼驗證自己的節省幅度#

先不要從 90% 當目標倒推。至少記錄兩組可比較資料：

1. 沒有 Jev 時，每個任務的模型、輸入／快取／輸出 Token、完成時間與是否需要返工。
2. 加入 Jev 後，Jev 請求成本、Codex Token、所選模型、fallback 次數與任務結果。

省下成本但增加錯誤、返工或 cache miss，不一定划算。比較時也要把 TypeSafe API 費用與額外延遲加回去，並以完成同一批任務為前提。

我會先用 shadow mode：Jev 只提供建議，實際仍走原本模型。等累積足夠資料，確認低階模型在哪些任務不會降低完成率，再逐步讓 Router 接管。這個過程也適合套用 AI coding agent 的可驗證完成條件，避免只用模型「看起來有回答」判斷路由成功。

想先理解 Jev 的問題型別與限制，可讀 Jev 是什麼？；若要自己做 API 流程，再接著看 Jev TypeScript API 教學。若不想把分類資料送到雲端，可評估 Laya 本機 System One 模型。

常見問題#