成本、模型路由與長跑自動化

22.1　/effort：一鍵決定它這次要燒多少腦力與預算

控制成本最直接的一個旋鈕，叫 /effort ✅官方。它有四檔——low、medium、high、max——同時調整 Claude 願意花的 token 預算和推理深度。檔位越高，它想得越久、越仔細，但也燒得越兇；檔位越低，回得快、花得少，適合不需要深思的瑣事。把它想成開車的油門：不是踩到底就最好，而是依路況給剛剛好的力道。

那你怎麼知道每次到底花了多少？關鍵在於：Claude Code 的每一筆輸出都會帶一個 total_cost_usd 欄位 ✅官方，把這次任務的美金花費、以及逐個模型的成本明細攤給你看。成本不是黑箱——你隨時看得到帳，這是「成本感知」工作的起點。

💡 建議執行：碰到難纏的除錯，把力道開到最大再讓它動手

# 在 Claude Code 對話中輸入：把這次的努力檔位拉到最高
/effort max

# 之後在 headless（無互動）模式跑時，輸出的 JSON 會帶成本明細，例如：
# {
#   "total_cost_usd": 0.4213,        ← 這次任務總共花了約 0.42 美金
#   "modelUsage": { ... 逐模型的 token 與費用明細 ... }
# }

值得多花一句話講清楚檔位的本質。官方 --help 目前列出到五個等級——low／medium／high／xhigh／max，加一個定位比較特別的 ultracode——但這些檔位是每個模型自己校準的相對值，不是一把跨模型通用的絕對尺規：同樣選 high，Opus 心裡那把尺跟 Sonnet 心裡那把尺不是同一把，別拿「上次用 Sonnet 開 high 感覺很夠」去推算這次用 Opus 也該差不多。多數目前的模型預設檔位落在 high；但 Claude Code 版本更新頻繁，實際預設值與可選檔位，以你手上那個版本的 /effort 選單或 --help 輸出為準，這裡不寫死。

這六檔裡的 ultracode 比較特別：它不只是「比 max 更用力想」，而是 Claude Code 層級的設定——效果是把力度送到 xhigh、同時放手讓 Claude 自己編排動態工作流（當場寫一支程式去指揮一大批分身，細節見 第 17 章）。它只在當次 session 有效，不會被存進設定檔留到下次開機，每次想用都要重新開。想固定某個檔位跨 session 生效，改用環境變數 CLAUDE_CODE_EFFORT_LEVEL。

還有一個容易被忽略的代價：session 中途切換 /effort 檔位，效果跟切換模型一樣——會讓下一輪的對話快取整段失效、全額重算。「什麼動作會讓快取失效」的完整清單，第 14 章 14.7 已經整理過，這裡不重複；只提醒一句：檔位跟模型一樣，最好在 session 一開始就決定好，別三不五時調整，調一次就多付一次全額重算的代價。

除了 headless 輸出裡的 total_cost_usd，互動模式下你可以直接打 /usage 看這個 session 目前燒了多少——它會列出目前 session 的 token 用量與一個本地估算的花費（可能跟正式帳單有落差，正式金額仍以 Claude Console 的 Usage 頁為準）；付費方案的帳號還會看到用量依 skills／subagents／plugins／MCP servers 拆分的佔比，用 d／w 切換看 24 小時或 7 天的視窗。想知道自己花得算不算多，官方文件公開過一組參考基準：企業部署下平均每位開發者每個活躍日約 13 美元、每月落在 150～250 美元之間，而九成使用者每個活躍日花費低於 30 美元。順帶一提，就算完全沒在跟它互動，背景任務（像 claude --resume 復原對話用的摘要、或 /usage 這類狀態查詢本身）也會耗一點點 token，官方文件標注這個量級通常低於一個 session 0.04 美元——小到可以忽略，但知道它存在，帳單上出現幾筆「我明明沒做事」的零星花費就不會嚇一跳。

22.2　選對主模型：別名、設定優先序與過載時的 Fallback Chain

22.1 講的是「這次要花多少腦力」，這節換個角度，講「你自己在跟哪一顆模型講話」——這件事其實比想像中容易搞混，尤其是你同時用 /model、啟動旗標、環境變數在不同場合切換的時候。

/model 除了大家熟悉的 sonnet／opus／haiku，還有幾個別名（model alias）值得認識：default／best／fable／sonnet[1m]／opus[1m]，以及 第 8 章 介紹過的混合模式 opusplan ✅官方。這些別名各自解析到哪一個實際模型版本，依你的帳號方案不同而不同——直接用 Anthropic API 登入，跟走 Bedrock／Vertex／Foundry 企業通道，同一個別名背後接的版本可能不一樣；後綴 [1m] 一般代表該模型啟用擴充上下文視窗的版本，實際規格與是否需要額外開通，以官方模型清單頁面為準。這塊解析規則本身也會隨官方更新調整，這裡不寫死版本號，你在 /model 選單看到的才是準的。

更容易卡關的，是「到底哪個設定會贏」。你可能同時：對話裡打過 /model opus、啟動時加了 --model sonnet 旗標、殼層還設了 ANTHROPIC_MODEL 環境變數、settings 檔案裡也寫了 model 欄位——四個都在講話，聽誰的？優先順序由高到低是：

如果你在企業或團隊帳號底下，上頭可能還有一層組織層級的強制設定——那一層的優先權比這四種都高，第 8 章 已經講過設定檔的分層邏輯，這裡不重複。另外有個容易誤判的細節：用 --resume／--continue 接續一個舊 session，它會沿用那個 session 存檔當下用的模型，不受你「現在」的 /model 設定影響——你今天把預設改成 Sonnet，昨天那個用 Opus 存檔的 session 接回去還是 Opus。

💡 範例：三種切模型的方式，效力範圍不一樣

# 互動中切換，同時把它存成之後新 session 的預設（v2.1.153+）
/model opus

# 只影響這次啟動
claude --model sonnet

# 環境變數同樣只影響這次啟動
export ANTHROPIC_MODEL="sonnet"
claude

選好主模型之後，還有一個你控制不了的變數——Anthropic 那頭伺服器過載。這時候能救你的是 fallback model chain（後備模型鏈）：用 --fallback-model 或設定檔的 fallbackModel 陣列，列出過載時依序改用的備援模型（去重後最多 3 個）✅官方。

💡 範例：主模型過載時自動降級

# 主模型不可用時，依序試 sonnet、再試 haiku
claude --fallback-model sonnet,haiku

如果你是團隊或企業帳號的管理者，還可以反過來限制大家能選哪些模型——設定檔裡的 availableModels 陣列列出允許的別名清單，搭配 enforceAvailableModels: true 強制套用，避免成員不小心選到成本失控的組合。這屬於管理者才需要煩惱的細節，個人使用可以先跳過。

22.3　Prompt Caching 怎麼決定你的帳單

第 14 章 14.7 已經講過快取的三層架構、以及「什麼動作會讓快取失效」的完整清單，這裡不重複那份清單。這節要補的是錢的那一半——快取命中和沒命中，價差有多大、能撐多久，以及一個真實發生過、值得每個做長跑自動化的人記住的教訓 ✅官方。

先講價差：讀取快取（cache read）的費用大約只有標準 input 價格的一成；反過來，第一次把內容寫入快取的價格比標準 input 更貴。這代表快取真正划算的前提是「這段內容之後真的會被重複讀到很多次」——只會被讀一次的東西，寫入快取反而更貴，不如老實用標準 input 送。

快取能撐多久，取決於你的帳號類型：

有個常被忽略的細節：子代理有自己獨立的一份快取，跟主對話分開算，而且固定用 5 分鐘 TTL——就算你的主 session 是訂閱帳號、正享有 1 小時的待遇，派出去的子代理照樣只有 5 分鐘。如果你的自動化流程會密集地一批批派子代理出去做事，兩批派工中間隔超過 5 分鐘，前一批建好的快取就已經過期，下一批等於重新從頭建一次。

如果你用的是 第 8 章 提過的 opusplan 混合模式，也有一筆隱性成本要知道：它在計畫模式與執行模式之間自動切換時，背後其實是換了一次模型（Opus ↔ Sonnet），跟你手動切模型一樣會讓快取重算一次。在計畫／執行兩態之間跳得越勤，累積的「重建快取」次數就越多——不是叫你別用 opusplan，只是提醒這個混合模式的方便，背後有它自己的快取代價。

還有一種常被忽略、但代價很高的情境：升級 Claude Code 版本後，直接 --resume 一個很久沒動過的長 session。因為系統提示詞已經跟著新版變了，快取的 prefix 對不上，整段對話歷史會整段 cache miss、從頭全額重算。官方文件直接點名：這可能是你會送出的最貴一次請求。手上有個放很久又長的 session，升級之後要接回去之前，值得想一下這筆帳划不划算，還是乾脆開新的。

想在事前就發現「命中率怎麼突然變差了」，可以盯 API 回傳裡的兩個欄位：cache_read_input_tokens（命中快取讀到的量）跟 cache_creation_input_tokens（重新寫入快取的量）。如果 cache_creation 持續偏高，代表你的 prefix 一直在變動，回頭查是不是踩了第 14 章列的那份「會讓快取失效」清單裡的哪一項；這兩個欄位也能掛進你的狀態列腳本即時顯示，長期監看用。

最後提醒一個容易漏算的成本：/fast（fast mode）能讓 Opus 回應快上不少，但單價也拉高不少，且只走 usage credits 計費、不算進訂閱方案的內含額度——實際加價幅度以官方定價頁為準。更關鍵的是什麼時候開：如果對話已經進行到一半才開 fast mode，它會用「未快取的 fast mode 高單價」把當時已經累積的整段歷史重算一次，等於一次補繳一大筆過去的帳。想用 fast mode，在 session 一開場就決定，別中途臨時起意。

22.4　成本拆分的核心心法：Opus 當領班、Sonnet 當工班

這節是整章最該帶走的一個觀念。當你開一群代理平行工作時，不需要每一個都用最貴的模型。有位實踐者 Alexander Opalic 示範過一套很實用的拆法（非官方規範）🌐社群：派一群專門的 QA 代理平行去測網站的不同面向——頁面回應、內容渲染、連結有沒有壞、SEO 與中繼資料、無障礙——但這些跑腿的隊員用比較便宜的 Sonnet，只有居中協調、最後彙整優先順序清單的領班留給 Opus。

為什麼這樣分會省很多？因為一個任務裡，「需要高階判斷」的部分其實是少數，大部分是機械性、照表操課的執行。讓昂貴的腦力只花在領班的綜合決策上，把可預測的雜活交給便宜模型，整體帳單可以差非常多，產出品質卻幾乎不受影響。這跟你在 第 16 章 看到的「輕量唯讀的活路由到小模型」是同一條思路，只是這裡把它放大成整個團隊的成本架構。

22.5　Plan 先行，再分波次執行：別讓昂貴的執行中途翻車

拆好了模型角色，下一個會吃掉預算的地方是執行到一半才發現方向錯了——前面燒掉的 token 全打水漂。同一位實踐者給的解法是「先規劃、再分波執行」🌐社群：先用 第 15 章 的計畫模式探一遍 codebase，產出一份大約一萬 token、可以給你審的實作計畫，當成一個檢查點。計畫你點頭了，才讓代理團隊照依賴波次動工。

所謂依賴波次，就是按「誰要等誰」排出先後：

這樣排的好處是：每一波動工前，它依賴的東西都已經確定，大幅降低做到一半才發現要重來的機率。規劃當檢查點花的那一萬 token，換來的是避免後面整批昂貴執行白做——這筆帳非常划算。

22.6　把輕量 worker 路由到小模型：用環境變數一次設定

22.4 講的是「人工」決定誰用哪個模型，這節給你一個系統性的開關。Claude Code 有個環境變數 CLAUDE_CODE_SUBAGENT_MODEL 👤達人，獨立實踐者 Hidekazu Konishi 指出，你可以用它把唯讀、輕量的子代理統一路由到較小、較便宜的模型，重活才留給 Opus。

它的價值在於「一次設定、全體套用」：你不必每次派子代理都手動指定模型，凡是吃這個變數的輕量 worker，自動走便宜路線。爬 log、列檔案清單、跑一遍唯讀檢查這類低風險的活，本來就不需要頂級模型的判斷力，把它們整批降級，省下來的算力留給真正需要深思的環節。

💡 參考用法：把子代理預設路由到較便宜的模型（實際模型名以官方當前清單為準）

# 啟動 Claude Code 前，先設好這個環境變數
# 之後派出的輕量子代理就會走這個較便宜的模型，主代理仍用你選的 Opus
export CLAUDE_CODE_SUBAGENT_MODEL="sonnet"
claude

這條環境變數的優先權其實比想像中更高——它甚至會蓋過子代理 frontmatter 裡寫死的 model 欄位。完整的四層解析順序 第 16 章 16.2 已經整理過，這裡不重複；這裡想補的是「值不值得」這把尺：社群估算 Haiku 比 Sonnet 便宜約八成、快約兩倍 🌐社群——這也是為什麼把找檔案、跑測試摘要、生成 commit message 這類唯讀雜活整批降到它，帳單差距會很有感。

22.7　長跑自主三件套：auto mode ＋ /goal ＋ worktrees

前面都在談「怎麼省」，這節談「怎麼讓它放著跑」——而且跑久了還不出事。要讓 Claude 無人值守跑上好幾個小時、自己正確收尾，達人的組合是三件套 ✅官方 👤達人：

• auto mode——背景分類器（跑 Sonnet 4.6，獨立於你替主任務選的模型）審查每個動作，擋掉生產部署、資料庫遷移、破壞性 git 操作（force push／reset --hard）、向外部端點送敏感資料，以及你在對話裡講過的會話邊界（例如你說過「別 push」，它就不會 push），免去逐次跳出來問你（完整原理見 第 15 章 的 15.4，那裡把這個權限模式講透了）。
• /goal——給它一個「達成才算完」的可驗證條件，它每一回合都重新檢查到底達標了沒，沒到就繼續做（見 第 15 章 15.3）。
• worktrees——用 Git worktree 讓多個分身各有獨立工作目錄、互不覆蓋（見 第 18 章）。

三者合起來：auto mode 讓它不必停下來等你點頭、/goal 給它一條清楚的收工線、worktree 確保平行的幾路不會打架。跑本地週期任務用 /loop（每隔一段時間重跑，最長約三天）；要跨過你關掉筆電還繼續跑，就用 /schedule 丟到雲端。跑完透過 Slack 或瀏覽器通知你一聲。

1. 1
   ✋動手做

   切到 auto mode，讓它不必逐次問你

   用 Shift+Tab 循環到 auto，或啟動時加 --permission-mode auto。這樣它在跑的過程中不會每個動作都停下來等你確認，但背景分類器仍在把關高風險操作。

2. 2
   ✋動手做

   用 /goal 設一條「達成才算完」的收工線

   把完成條件寫成可驗證的句子，例如下面這行。它每一回合都會重新檢查是否達標，沒到就繼續，達到了才停——這就是它「自己知道何時收工」的依據。負責這項檢查的是另一個較小、較快的模型（預設 Haiku），每回合判斷一次，官方文件指出這筆評估花費相對主要任務通常可以忽略不計。條件文字本身有 4000 字元上限，而且 /goal 沒有內建的輪數上限——不希望它在達不到條件時無限跑下去，記得自己在條件句裡加一句「or stop after N turns」之類的子句畫界線。

   /goal "all test files pass and branch is clean for PR"

   複製
3. 3
   ✋動手做

   在獨立 worktree 裡跑，再用 /loop 讓它週期重跑

   為這個長任務開一個專屬 worktree（第 18 章），讓它跟你其他工作隔離、不互相覆蓋；接著用 /loop 讓它每隔一段時間自動重跑。要跨過關機也繼續，就改用 /schedule 丟雲端。

   ✅ 預期會看到

   你可以離開座位，它在獨立目錄裡一回合一回合往 /goal 的條件推進，達標就停、跑完通知你。整段過程不需要你守在旁邊逐次按確認。

22.8　/loop（本地）對上 /schedule（雲端）：兩種長跑怎麼選

上一節把兩者當工具用，這節把它們的分工講清楚，讓你以後一眼知道該挑哪個 ✅官方 👤達人。

一句話分辨：要不要關機後還繼續？不需要、就這幾天盯著看 → /loop；需要跨過關機、長期定時 → /schedule。

本地 /loop 還有幾個實作細節，決定它到底多「即時」：一個 session 最多同時掛50 個排程任務，排程器每秒檢查一次、以低優先權插隊——只會在 Claude 兩輪對話之間找空檔觸發，不會硬生生打斷正在進行中的回應。週期性（recurring）任務建立滿 7 天後會自動過期（跑完最後一次就自動刪除，不是無限期跑下去）；而且它刻意加了隨機延遲（jitter）——週期任務可能比預定時間晚最多 30 分鐘或半個間隔才觸發，一次性提醒則是頂多提早 90 秒，用意是避免大量使用者的排程同時撞在整點、一起打爆 API。不管是本地 /loop 還是雲端 /schedule 用 cron 表示的排程，卡在整點或半點都比較容易被這套刻意的抖動延後，換成非整點的分鐘數（例如 cron 寫 3 9 * * * 而不是 0 9 * * *）通常能避開。另外，如果你在 Bedrock／Vertex／Foundry 上用 /loop 且沒給明確間隔，它不會讓 Claude 自己動態決定該等多久，會直接改成固定 10 分鐘排程。

如果你的長跑任務本質是「盯著一支背景腳本、等它印出關鍵字」這種輪詢，除了 /loop 反覆整段重新問一次 Claude，還有一個更省 token 的做法：用 Monitor 工具在背景跑那支腳本、把輸出逐行串流回來 ✅官方。因為 Claude 每次只需要處理新增的那幾行輸出，不必每隔幾分鐘就重讀一次完整 context，通常比週期性重新 prompt 更省成本、反應也更即時。

還有一個跟成本與正確性都相關的點：Opus 4.8 之後，你可以對 Claude 說「use a workflow」，觸發它自己寫一支程式來協調上百個分身、做扇出與綜合 ✅官方。官方提到這套機制有助於對抗長跑時容易出現的偷懶和目標漂移——因為流程被寫成可重複、可恢復的程式碼，而不是靠它每回合臨場發揮。這條正是 第 17 章 動態工作流的主題，想把長跑做到生產級的話，那一章值得回頭細讀。

22.9　無人值守要撐得住：容錯重試與成本護欄的真相

前面幾節都在講怎麼省，這節談另一半：讓它長時間沒人看著也不會半路暴斃、也不會偷偷燒爆。無人值守的自動化最怕兩件事——伺服器一時抽風就整條斷掉，以及你以為設了安全上限、結果它其實沒真的擋住。

先講第一件事。跑批次、跑排程時，你偶爾會撞到 529 或 429 這兩個錯誤碼（第 24 章 提過它們大致代表「伺服器忙，稍等再試」，這裡把差別講細一點）：529 是 Anthropic 整體服務過載，不算進你自己的用量配額；429 則是你自己的帳號或 key 撞到速率限制上限。這類暫時性錯誤（還包括 5xx、逾時、沒帶配額標頭的 429）Claude Code 預設會自動重試，上限由 CLAUDE_CODE_MAX_RETRIES 控制（預設 10 次、一般情境封頂 15 次）✅官方。如果你的場景是 CI 或完全無人值守，想讓它撐過更久的壅塞期，可以開 CLAUDE_CODE_RETRY_WATCHDOG=1，讓 429／529 用指數退避幾乎無限重試（約可撐 3 小時），不必自己在 CI 腳本外面再包一層重試迴圈。

💡 參考設定：無人值守場景的韌性組合

# CI / 排程等無人值守場景：撞到過載類錯誤時盡量撐住，別輕易整條失敗
export CLAUDE_CODE_RETRY_WATCHDOG=1
export CLAUDE_CODE_MAX_RETRIES=15

第二件事，是 第 20 章 介紹過的 --max-turns 和 --max-budget-usd——它們是無人值守的安全氣囊沒錯，但兩者都有一個容易被誤解的地方，值得說清楚，免得你把身家壓在一個沒有你想像中那麼硬的上限上。

--max-budget-usd 不是逐 token 即時攔截的斷路器，它是每一輪結束後才加總檢查一次——這代表實際花費可能超過你設的上限。第三方實測過一個極端案例 🌐社群：設定 0.01 美元的上限，實際花到 0.084 美元，超支超過八倍。超過上限時，Claude Code 會用 error_max_budget_usd 這個錯誤子類型中止、印出「Reached maximum budget」字樣、結束碼為 1——但那筆超支的錢已經花出去了。--max-turns 也有類似的落差：社群回報過用 --resume 接續 session 時，這個上限可能被忽略（相關討論見官方 GitHub issue），而且它長期沒有列在 --help 的輸出裡。

知道這些之後，設多少輪、多少預算才合理？沒有標準答案，但可以照任務量級分層抓一個起點，實測後再調 🌐社群：

先保守起步，看實際幾輪能穩定完成任務，再依實測數字微調——這比憑感覺挑一個數字，或乾脆不設（讓它可能無限迭代下去），都可靠得多。

22.10　小結

這一章的主軸是「把錢花在刀口上」。/effort 一鍵調整這次要燒多少預算——檔位是每個模型自己校準的相對值，中途切檔位跟切模型一樣會讓快取重算；headless 輸出帶 total_cost_usd，互動模式還有 /usage 可查，成本從頭到尾看得到。選主模型本身有一套設定優先序（互動 /model ＞ --model 旗標 ＞ 環境變數 ＞ 設定檔），過載時靠 --fallback-model 接住——但接不住認證、帳務、速率限制這幾類你自己的問題。Prompt caching 的 TTL 與讀寫價差，往往是長跑帳單暴走的真正根因，那晚 6000 美元的教訓值得刻進腦子裡。接著是整章最該帶走的拆分心法——貴模型做判斷、便宜模型做執行：Opus 當領班綜合決策，Sonnet 當工班跑機械性的雜活，還能用 CLAUDE_CODE_SUBAGENT_MODEL 把輕量唯讀的子代理系統性地降級（記得它的優先權比 frontmatter 還高）。為了不讓昂貴的執行中途翻車，先讓計畫模式產出可審的計畫當檢查點，再照依賴波次分批動工。最後我們組起長跑三件套——auto mode＋/goal＋worktree——讓它無人值守跑數小時自己正確收尾，本地週期用 /loop（留意 jitter 與 7 天過期）、跨關機長跑用 /schedule；撐過伺服器一時抽風靠重試護欄，但 --max-turns／--max-budget-usd 別當成絕對硬上限，兩個都用、且部署前自己實測過一次。務必記住那條紅線：auto mode 還是 🧪 研究預覽、大約每六個危險動作漏放一個，碰到生產與破壞性操作，要用 deny 規則硬擋，別只靠它記住邊界。一句話帶走：省成本的本質不是少做，而是讓每一分算力都花在它最該花的地方；放手讓它長跑的前提，是先把破壞性的退路堵死、把觀測的眼睛留著。

22.11　動手試試

1. 1
   ✋動手做

   同一個任務，用兩個 /effort 檔位各跑一次，比成本

   挑一件不大不小的工作，先用 /effort low 跑一次、再用 /effort high 跑一次，兩次都看輸出裡的 total_cost_usd。親手感受檔位對花費的影響。

   ✅ 預期會看到

   高檔位那次明顯花得更多、想得更久。你會開始對「這件事值不值得開高檔位」有手感，而不是反射性地一律拉到 max。

2. 2
   ✋動手做

   替你的下一個多代理任務，先畫好「誰用 Opus、誰用 Sonnet」

   在派工前，把任務拆成「需要判斷的」和「照表操課的」兩堆。判斷那堆留給 Opus 當領班，執行那堆全部標記成走便宜模型——可以搭配 CLAUDE_CODE_SUBAGENT_MODEL 一次設定。

   ✅ 預期會看到

   同樣的產出，帳單明顯比「全程都用 Opus」低。你會養成派工前先分「腦力活 vs 力氣活」的習慣，這是長期省成本最有效的一個動作。

3. 3
   ✋動手做

   組一次長跑三件套，並先把破壞性操作用 deny 堵死

   挑一個安全、可重複的任務（例如「把測試全部修綠」），切 auto mode、設好 /goal 條件、開一個獨立 worktree。動工前先確認部署、資料庫遷移這類破壞性操作已用 deny 規則封死，再放手讓它跑。

   ✅ 預期會看到

   它在獨立目錄裡朝 /goal 的條件一回合一回合推進，達標才停；就算它一時想做危險動作，也會被你預設的 deny 規則擋下。你會體會到「放手」和「堵死退路」是同一件事的兩面。

4. 4
   ✋動手做

   打開 /usage，找出這個 session 錢花在哪

   在任何一個進行中的 session 打 /usage，看目前這輪對話的 token 用量與估算花費；如果輸出裡有依 skills／subagents／plugins／MCP 拆分的佔比，找出哪一塊吃最兇。之後跑 headless 呼叫時，也養成看一眼 total_cost_usd 的習慣。

   ✅ 預期會看到

   成本從一個模糊的「帳單月底才知道」變成「這個 session 現在就看得到」。你會開始對哪些動作特別花錢有具體的數字感，而不只是憑印象猜。