兩種帳單，兩種形狀
主機帳單是容量。你加 CPU、頻寬、儲存，指針跟著流量曲線走；看過一個月，下個月能猜到幾個百分點以內的誤差。
token 帳單是行為。兩個流量完全一樣的團隊，帳單可以差 20 倍——因為一個團隊每次請求帶 12,000 token 的檢索上下文，另一個只快取了 400 token 的系統提示、其餘什麼都不帶。同樣的使用者、同樣的功能，帳單天差地遠。
這不是定價的貓膩，而是計量方式決定的：你按 token 付費，而 token 數量是設計決策。
讓花費變跳的三個效應
1. 輸入通常遠多於輸出，兩者單價還不一樣。 在多數對話與檢索功能裡，輸入 token 是輸出的 5～20 倍，而輸出 token 的單價往往是輸入的幾倍。所以「我們只生成一小段回答」這句話，對成本沒有任何說明力。
2. 快取輸入是另一套費率。 供應商對重複出現的輸入給更便宜的價格——固定的系統提示、不變的長文件、大段指令。忽略快取，就等於每次請求都為同樣的 3,000 token 付全額。
3. 每次請求的上下文能差一個數量級。 一個每輪都追加對話歷史的摘要任務，等於每次都把整份紀錄重新送一遍。成本成長比輪數更快：第 20 輪很貴，是因為第 1 到 19 輪又在帳單上出現了一次。
重試與工具呼叫還會再加一個在任何用量圖表裡都看不見的乘數：一次失敗後重試的呼叫會計費兩次；每輪呼叫四個工具的 Agent，每輪計費五次。
槓桿，按收益排序
團隊的第一反應通常是去換模型。那很少是最大的槓桿。建議按這個順序試：
- 先砍上下文。 刪掉檢索到卻不影響答案的文件、限制回溯的歷史長度、把永遠不變的部分放進快取。這往往是單項收益最大的一步。
- 限制輸出長度。 直接要求形狀（「三條要點，不要前言」），而不是給一個寬鬆的 token 上限。模型生成的那 900 token 客套話，是你在付費。
- 不緊急的走批次。 夜間補數、回填、評測這類任務通常可以接受更慢但更便宜的路徑。
- 最後才換模型。 把摘要任務降級到更小的模型確實是省錢——但這是在前面三步已經壓小的那個數字上，再省一次。
上線前先估一遍
你需要每次請求的兩個數字：輸入 token 與輸出 token。功能已經上線，就直接從 API 回傳值讀，不要估。還沒上線，只能先猜：
每月成本 ≈ 每天請求數 × 30 × (輸入 ÷ 1M × 輸入單價 + 輸出 ÷ 1M × 輸出單價)
猜的時候有兩個坑：一是平均數會掩蓋最貴的那次請求（一份長文件的 p95 請求可能是中位數的 30 倍，而帳單正是它決定的）；二是多輪功能讓平均數失去意義，因為每一輪都拖著完整歷史。
AI 成本計算器 用一份可編輯的費率表完成這套算術：貼用量日誌就按模型彙總，或者描述工作量（每次請求 token、每天請求數、快取命中率、批次折扣）得到每次請求、每天、每月、每年的數字。對比頁會把同一份工作量套到每一條費率上——這是判斷「換模型到底值不值得搬」最快的方式。
訂閱還是按量付費
這是個用量問題，不是方案偏好。如果你實測的每月 API 成本低於訂閱價，那麼訂閱是你為方便多付的錢；如果遠高於，通常訂閱更划算——直到你撞上它的用量上限，而那是平衡點算不出來的另一個限制。
真正有用的輸出是平衡量：按你自己的每次請求成本，每天要超過多少次請求，固定月費才開始划算。把它和你的實際流量放在一起看，這個決定就不再靠感覺。
關於數字的一句實話
價格會變、方案會變，而一個把價格寫死在程式裡的計算器，會在別人更新價格頁的那一刻就變成錯的。所以這個工具給的是範例佔位值，要求你填自己帳單上的費率；你的修改留在瀏覽器本地，不抓取、不上傳、不在伺服器上留快取。
算術部分可以做到完全正確，費率部分只有你的帳戶能回答。
如果 AI 的輸出還會進報表，另外兩個工具處理相鄰的問題：AI 數字核驗器 標出找不到出處的數字，護欄產生器 則為編碼 Agent 產生規則檔與權限清單，讓它待在自己的車道裡。