Decision Model
最後更新
由 TypeSafe 或 OpenRouter 提供的快速分類模型，回答分派、監看檢查與內容過濾所需的型別化問題。
Decision model（
internal/agents/decision）不是聊天模型：它接收一份 JSON 狀態與一組選擇題，對每題回傳一個選項與信心值。供應商有兩家：typesafe 與 openrouter。可選模型即時列出：TypeSafe 取自其 models API，OpenRouter 取自輸出模態含 decisions 的模型，並排除 5 個輸入格式與其他模型不同的 OpenRouter 模型。各供應商的清單快取 15 分鐘（TTL_MODELS_CACHE_SEC），該供應商存入 key、完成 OAuth 或清除登入時即失效。選定值以 <provider>@<model> 存於 config.json 的 decision_model；空值或 off 代表關閉。設定分兩步。先存 key：TypeSafe 位於
/model add 的 API Key 分頁（按 o 開啟 https://console.typesafe.ai/keys），存完 key 會寫入 TYPESAFE_API_KEY 後直接結束，不進入選模型；OpenRouter 沿用聊天模型的 OPENROUTER_API_KEY。HTTP 則以 POST /v1/provider/typesafe/key 存 key。接著在 /model → decision 選模型（第一項 disable 為清除）、在 Web 模型設定的 Decision 選擇，或以 POST /v1/model {decision} 設定；不在 decision_options 內的值回 400。每次呼叫時限 3 秒（
TIMEOUT_DECISION_CALL）。請求文字截至 2,048 個 rune（MAX_DECISION_RUNES）；項目多時分批送出，每批最多 120 題（MAX_DECISION_QUESTIONS）、狀態約 20,000 個 rune（MAX_DECISION_STATE_RUNES）。除了 skill 過濾，判斷結果只在信心值至少 0.7 時才生效（DECISION_MIN_CONFIDENCE，監看檢查亦同）；呼叫失敗或逾時則維持原內容。用途
| 用途 | Decision model 判斷的內容 |
|---|---|
| 分派 | 工作類別、請求是否指名模型、主題是否延續（見下文） |
| 監看檢查 | background_command 被錯誤關鍵字標記的輸出是否真的是錯誤，以及是否只是重複上次回報；無害或重複的命中不回報，呼叫失敗則附註後未經檢查直接回報。沒有 decision model 時每次命中都回報。run_command_background 與 run_websocket 的 interval／prompt 監看移除於 v1.3.2 |
search_web | 移除與請求無關的結果；全部無關時回覆說明並要求改寫查詢 |
fetch_page | 抓取的頁面存快取前先移除噪音區塊；與請求無關的頁面不交給模型 |
read_files / chat_history | v1.3.11 起，read_files 讀取的檔案或 chat_history mode=read 讀取的 task 與請求無關時不交給模型，改回傳一段說明。只檢查至少 4,096 個 rune 的內容，帶 around 的 read_files 項目不檢查，同一檔案或 task 在每個 session 最多擋一次，第二次讀取即回傳內容 |
| Turn context | 沒有工具能滿足請求時，加上指向 reasoning_guide(topics=["tool_generate"]) 的工具缺口提示；並從 skill 清單隱藏判定不相關的 skill |
| Session summary | 合併摘要前，移除噪音對話與過時的 key_decisions / past_discussions 條目；v1.3.7 起，摘要注入 turn context 時也只保留與請求相關的 key_decisions / past_discussions / current_discussion 條目（語言、格式、工作流程這類通則算相關），判斷失敗時全部保留，全都無關時不放摘要 |
| Context 超限 | 依最舊優先刪減之前，先移除請求已用不到的工具步驟 |
分派
只要設定了 decision model，每次需要路由的請求會同時發出 decision 呼叫與 LLM dispatcher，採用先取得的有效回覆；decision 呼叫失敗則採用 LLM dispatcher 的結果。未設定 decision model（
decision_model 為空或 off）時只跑 LLM dispatcher。沒有獨立開關：dispatcher_beta（設定欄位 DispatcherDecision）、/model → dispatch 與 Web Dispatcher 清單中的 Decision Model 項目，以及 POST /v1/model {dispatcher_beta} 皆移除於 v1.3.2；改為設定或清除 decision model，config.json 殘留的 dispatcher_beta 會被忽略。該呼叫最多問三題：請求屬於哪一類工作、是否明確要求使用某個候選模型，以及 session 已有前文且記錄了上一次的模型時，請求是否延續上一則使用者訊息的主題。工作類別決定 tier 順序與 reasoning 等級：
| 工作類別 | Tier 順序 | Reasoning |
|---|---|---|
code | S > A > B > C | xhigh |
research | S > A > B > C | high |
work（其餘情形的預設） | A > S > B > C | medium |
chat | B > C > A > S | none |
fetch | C > B > A > S | low |
請求中指名的模型排第一；未指名且主題未變時，由 session 上一次使用的模型佔此位置，以重用其 prompt cache。上一次的模型居首時，只要記錄的是合法等級就沿用上一次的 reasoning，且這些居首的選擇不受供應商優先序重排，只有其後依等級排序的候選會。上一次的模型在每次成功回覆後記錄，
openai / codex 30 分鐘、gemini 60 分鐘、其他供應商 5 分鐘後失效。其餘候選依 tier 排序，先讀 model_tag，未設定則套用命名規則；同 tier 內 claude-code、其次 codex 的模型排前，其餘依模型家族決定先後。research 工作中，copilot@ 模型因 Copilot context window 較小而排在同等級其他模型之後。pass 模型不參與此排序。送出的 context 為最後 4 則 user 與 assistant 訊息，每則截至 2,048 個 rune。TypeSafe/Jev beta dispatcher（
dispatcher_beta 直接呼叫 jev-latest，有自己的 TYPESAFE_API_KEY 提示與 missing_key 400）移除於 v1.3.1，改由上述 decision model 取代，TypeSafe 成為其供應商之一。