成本控制
這是什麼
這是一種跨工作流程的設計習慣：只有新資訊值得模型處理時，才承擔昂貴呼叫的成本。
白話解釋
它像一座只有實際過橋才收費的收費橋，而不是不論有沒有開車都要支付的月票。成本控制的重點是：只有情況確實需要模型呼叫時才花費，而且只有必要時才選用高價模型。
為什麼重要
排程、喚醒條件、無模型工作與 provider 選擇都服務同一項設計原則：只有新資訊會改變答案時，才執行昂貴的模型呼叫。即使監控流程運作正確，每 15 分鐘都用大型模型檢查一次「是否有變更」仍是成本控制失敗。這個模式橫跨多個概念，並不是某一個通用預算設定。
運作方式
Hermes 具體實作的是模型選擇時的成本防護，而不是通用 runtime 預算閘門。選擇模型時，系統會依已知定價目錄檢查；若每百萬 token 的輸入成本高於 $20，或輸出成本高於 $100，hermes_cli/model_cost_guard.py 會在套用選擇前顯示明確確認，列出模型、provider 與已知單價。價格未知時不會出現警告。這套機制不執行每輪或每月支出上限；provider 入口網站顯示的月度上限仍是由 provider 管理的唯讀帳戶狀態。
具體範例
有人在模型選擇器中，為原本只需快速完成的一次性工作選到高價前沿模型：
- Hermes 從定價目錄查詢該模型的 token 單價。
- 系統發現輸出成本超過每百萬 token
$100的門檻。 - 在下一則訊息以該價格送出前，介面先顯示確切費率並要求確認，而不是默默套用選擇。
如何連結
「成本控制」屬於「營運」系列，最直接相關的概念包括「提供者切換」、「專案隔離」、「代理執行環境」與「個人作業系統」。
來源證據
run_agent.py#run_agent.AIAgent— 已驗證的精確符號對應；AIAgent透過薄型轉送方法，把系統 prompt 建構委派給agent.system_prompt.build_system_prompt、把 APIkwargs建構委派給chat-completion輔助函式，並把串流請求委派給interruptible_streaming_api_call。