成本、quota、token caching 與模型路由

15.0 先回答：更新到 Gemini 3.6 後，使用方法有沒有改變？

答案不是一句「有」或「沒有」，而是看你站在哪個入口。Gemini 3.6 Flash 在 2026-07-21 發布，API 文件截至 2026-07-23 已標為 GA／可投入 production；但模型升級、產品入口換線與 API schema 遷移是三件不同的事。下面的判斷以 2026-07-26 查證結果為準，固定價格也只代表該日期。

✅官方 入口證據：Gemini 3.6 發布文、Antigravity 共享 models 頁（CLI 入口）、Antigravity Agent API、Gemini API latest-model 與開源 Gemini CLI model selection。不要以「同樣都叫 Gemini」抹平這些 surface。

15.1 成本從哪些地方來

成本通常由幾個部分組成：送進模型的 input tokens、模型產生的 output tokens、模型內部推理可能使用的 thinking tokens、可重用上下文的 cache 讀寫與儲存、影像／音訊／影片等多模態處理、工具呼叫造成的外部服務成本，以及重試與失敗請求的浪費。不同產品路線的計費口徑可能不同；下表只記錄 Gemini API pricing page 在 2026-07-26 查證的 standard paid tier checkpoint，不代表 Gemini App 訂閱、Antigravity 額度、Vertex direct 或企業合約價格。

2026-07-26 Gemini API 價格 checkpoint

同一 pricing page 另列 Batch／Flex／Priority 與 cache storage 價格；不要把這張 standard 表拿去估算 App 或 Antigravity 的方案額度。輸出價格包含 thinking tokens，實際帳單仍取決於輸入長度、thinking level、工具回合與所在 tier。官方 pricing 更新後，預算文件要一起記錄查證日期。

15.2 Token：input、output、thinking

input tokens 是你交給模型的上下文，包含任務說明、規則、程式碼片段與工具輸出；output tokens 是模型回傳的文字或結構化資料；thinking tokens 則是某些模型在推理時額外使用的內部計算量。對開發工作流來說，最容易爆量的是反覆貼完整檔案、完整 stack trace、完整測試輸出，或讓 agent 在沒有邊界的情況下「自己研究整個專案」。

低成本 prompt 範本：
目標：修正 tests/auth/session.test.ts 的一個失敗案例。
上下文：只讀 src/auth/session.ts、tests/auth/session.test.ts。
限制：不要掃全 repo；不要重寫 public API；先說明預估影響再改。
輸出：列出修改檔案、測試命令、剩餘風險，控制在 10 行內。

值得特別記住的一點：thinking tokens 不是「模型內部偷偷用掉、不會出現在帳單上」的東西。開啟 thinking 的模型，計費方式是「一般 output tokens ＋ thinking tokens」一起算，而且 thinking tokens 是用跟一般 output tokens 相同的單價計費——不是打折的內部運算，也不是另一種更便宜的 token 種類。一個回答看起來只有三行字，如果模型在背後想了很久，帳單可能跟一個真的輸出很長內容的請求差不多。

3.x 的 thinking 控制改用 thinking_level；minimal 是偏速度，不保證完全關閉 thinking。這不是全域欄位改名：GenerateContent 的 2.5 仍有 thinking_budget／thinkingBudget，3.x 才按各 surface 使用 thinking_level／thinkingLevel；同一 request 不要混送兩套欄位。模型專屬遷移文件對不相容組合有 HTTP 400 警告，但確切行為仍取決於模型與 endpoint（UNVERIFIED）。批次分類通常用 Flash-Lite 的 minimal，需要自主 subagent、工具回合或複雜 coding 再考慮 medium／high；先用實際 token 與錯誤率量測，不要只看模型名字猜成本。

15.2A 3.6 API 遷移：舊寫法與新寫法

✅官方遷移規則 從 Gemini 3.6 Flash／3.5 Flash-Lite 起，這些規則也會影響後續模型：把 model ID 改成正式 GA ID；移除 temperature、top_p、top_k；用字串 enum thinking_level 取代 thinking_budget；移除 Gemini 3.x 不支援的 candidate_count；不要以 model turn 預填答案；多輪 GenerateContent 要保留完整且未改寫的 history 與 thought signatures；Interactions 多輪可用 previous_interaction_id。目前取樣參數可能只是被忽略，但未來模型可能直接回 HTTP 400，現在就移除最穩。

# Python：google-genai >= 2.3.0，Interactions API
from google import genai

client = genai.Client()
interaction = client.interactions.create(
    model="gemini-3.6-flash",
    input="只用三點說明這個 diff 的風險，繁體中文。",
    system_instruction="先列證據，再列風險；不要編造未出現在輸入裡的資訊。",
)
print(interaction.output_text)

# GenerateContent 仍支援；REST 的 thinkingConfig 使用 camelCase
# generationConfig: {"thinkingConfig": {"thinkingLevel": "MEDIUM"}}
# 不要再放 temperature / topP / topK / candidateCount。

# REST：GenerateContent（仍支援，模型 ID 仍是正式 GA ID）
curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.6-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{"parts": [{"text": "只用三點說明這個 diff 的風險。"}]}],
    "generationConfig": {"thinkingConfig": {"thinkingLevel": "MEDIUM"}}
  }'

Function calling 要分 surface：Interactions 的 function result 以 call_id 對回前一個 call，並帶 name；GenerateContent 的詳細官方 REST 範例則是 functionResponse: {"name": "…", "id": "call_id", "response": {…}}。不要把 call_id 直接當成 GenerateContent JSON 欄位，也不要漏掉 name／對應 ID。latest-model checklist 對 GenerateContent 使用 call_id 的文字，和詳細 GenerateContent 範例的 id 不一致；此處依 wire example 分開處理，該文件衝突標為 UNVERIFIED。若使用 thought signatures，保留 SDK 回傳的完整 model content，不要自行重建或刪掉 signature。

previous_interaction_id 只屬 Interactions 的 server-side state，不是 GenerateContent 欄位；若使用 stateful 對話可沿用它，若 store=false 或採 stateless，就自行保存並原樣重送完整 steps。若你早已採用 Interactions API，還要另外檢查 2026-06-08 schema breaking change：outputs 改為 steps、response_mime_type 移除並改用 polymorphic response_format、streaming event 也改名。新專案可直接採目前 SDK；既有程式先按Interactions breaking changes guide逐項對照。Interactions 已 GA 且是新專案建議入口，但 GenerateContent 仍完整支援，不必為了 3.6 發布就盲目重寫 API 類型。

15.3 Context caching 的概念

context caching 的核心想法是：把多次請求都會用到的大段穩定內容先放進 cache，例如產品規格、長篇政策、SDK 文件摘要、固定資料結構或大型 code context。後續請求引用 cache，可以少重送相同 input，降低延遲與重複處理。不過 cache 不是免費魔法；你要確認建立 cache、讀取 cache、保存 cache 與過期策略在目前產品路線上的實際成本。

適合 caching 的內容要穩定、常被重用、體積夠大，而且不含短期秘密。若每次任務都改 prompt 前綴、塞入不同 log，或 cache 內含會快速過期的資料，反而可能增加複雜度。把 cache key、來源版本、建立時間、過期時間與資料分類記錄下來，才有辦法追蹤成本與刪除不該保存的內容。

官方把 context caching 分成兩種，運作方式差蠻多，值得先分清楚。Implicit caching（隱含快取）是 Gemini 2.5 以後的模型預設就會自動做的事：你不用寫任何額外程式碼或呼叫任何 API，只要這次請求的開頭部分剛好跟前一次重複，系統偵測到就自動命中、自動打折，命中與否你甚至不一定會注意到。Explicit caching（明確快取）則是你主動宣告「這段內容我要快取」，指定一個存活時間（TTL），之後多次請求引用同一個 cache；除了讀取有折扣，還要另外付一筆儲存費——官方範例曾用大約每百萬 token 每小時幾塊美金的量級來說明，實際費率請直接查當下的 pricing 頁，不要拿這個數字去編預算。

快取折扣與儲存費會依模型、API product surface、tier 與 pricing page 改變；不要再把舊版「Gemini 2.5 約九折、2.0 約七五折」當成 3.6 的預算常數。對 3.6／3.5 Flash-Lite，直接抄當日 pricing page 的 cache input 與 storage 行，不要只用世代名稱推算。

用 Google 帳號登入的 OAuth 使用者，完全用不到 caching

這是一個很容易讓人誤會成 bug、其實是刻意設計限制的狀況：如果你是用 Google 帳號登入（也就是 OAuth，走 Code Assist API 那條路），Gemini CLI 裡的快取重用完全不會生效，不管 implicit 還是 explicit 都一樣。原因寫在官方 FAQ 裡，但很容易被忽略——Code Assist API 這條路徑本身就不支援建立 cached content，快取只在 API key 或 Vertex AI 認證下才會運作。很多人打開 /stats，看不到任何 cache 相關的節省數字，第一反應是懷疑自己是不是設定漏了什麼，其實答案很單純：認證方式從一開始就不支援這件事，不是你設定錯。

上一段提到「內容要穩定」，具體怎麼安排順序也有講究：cache 命中的判斷方式是看這次請求開頭跟被快取的內容能對上多長一段，只要中間任何一個字元變了，快取就從那個變動點開始整段失效，後面即使內容一樣也救不回來。實務上比較有效的做法，是把「幾乎不會變」的大宗內容——像 GEMINI.md、專案規範、長篇參考檔案——固定放在對話最前面，把「每次都不一樣」的臨時提問放在最後面；隨手把一條新指示插進中間，等於把整段前綴都作廢重算一次。

15.4 Batch、flex、priority 的取捨

同一批工作不一定都要即時完成。可延遲的摘要、分類、文件補標、測試報告整理，通常適合 batch 或較彈性的處理路徑；互動式 CLI 修 bug、PR review blocking comment、事故排查，通常需要較低延遲或較高優先權。不同產品可能用 batch、flex、priority、provisioned throughput 或其他名詞表達類似取捨，請以當前官方文件為準。

以 Gemini API 的 Batch Mode 為例，具體折扣是所有模型的 input／output tokens 都打 5 折，交換條件是 SLA 訂在 24 小時內完成（實務上常常更快，只是官方不保證）。適合丟給 batch 的，是那種「翻譯一批檔案」「跑一輪分類」「資料遷移腳本」這類不急著看結果、可以離線跑完再回頭收成果的工作。有一點容易被忽略：快取折扣（最多省九成）跟 batch 折扣（省五成）不會疊加——同一個請求如果兩邊條件都符合，系統只算快取折扣，不會兩個一起扣。所以省錢的思考順序應該是「先確認能不能快取，再考慮要不要額外送 batch」，而不是兩個一起衝，以為省下來的錢會加倍。

如果你是在 Vertex AI 上跑，吞吐量還有另一組跟本節取捨很像、但機制完全不同的概念：Dynamic Shared Quota（DSQ）與 Provisioned Throughput（PT）。新模型預設走的是 DSQ——把隨用隨付（PayGo）的算力容量，在所有客戶之間動態分配，你不用申請固定配額，但尖峰時段可能被其他人的流量排擠。PT 則是企業級的「買下保證吞吐量」訂閱制，用一種叫 GSU（Generative AI Scale Unit）的單位計價，可以選一週、一個月、三個月或一年的承諾期。

15.5 Quota 與 rate limit

quota 是一段時間內可用的總量或資源上限，rate limit 則是單位時間內的請求、token 或並行限制。CLI 使用者最常遇到的是 429、排隊變慢、請求被拒，或 CI 同時跑多個 job 時把額度用完。處理方式不是盲目重試，而是先判斷限制種類：每分鐘請求數、每分鐘 token、每日額度、地區限制、模型限制，或帳務尚未開通。

無論哪條路線，都不要只看 request 次數：1M context、64K output 是模型上限，不等於方案允許你每次用滿；實際成本與限流還會受 token、thinking、工具呼叫、並行與 cache 影響。把查證日期、project、model ID、tier 與錯誤 JSON 一起記錄，才有可重現的 quota 報告。

配額到底幾點重置：官方說法跟實測不一樣

官方文件寫的是「太平洋時間午夜重置」，聽起來像個固定的整點鬧鐘。但社群這幾年在 GitHub 上累積了不少實測回報（issue #2981、#22643、#23318），描述的行為比較接近「以你當天第一次呼叫的時間起算，24 小時之後才重置」的滾動視窗——跟「固定在太平洋午夜歸零」是兩回事，兩者常常對不上，也因此才有一長串「我的配額為什麼還沒重置」的困惑回報。🌐社群 也有人提過 feature request，希望能讓重置時間變成可自訂的固定時刻，但查證當下這個提案還沒有被實作。實務上的建議很簡單：不要預期整點準時歸零，把它當成大約 24 小時的滾動視窗來抓，真正的確切行為以你當下的官方頁面或 gemini --help 為準。

429/Quota runbook：
1. 讀錯誤訊息，分辨是 rate limit、quota exhausted、billing、region 或 auth。
2. 停止無上限重試；把任務排隊或降級為較小 prompt。
3. 對可重試請求使用 exponential backoff + jitter。
4. 對非互動任務改用 batch/flex 或降低並行數。
5. 對長期需求申請 quota、調整模型路由，或移到企業/Vertex 計費治理。

15.6 依任務風險與延遲做模型路由

模型路由的目標不是永遠用最強模型，而是把任務送到「足夠可靠、足夠快、成本可接受」的模型。低風險任務如命名、短摘要、格式轉換，可以用較快較省的模型；中風險任務如單檔測試修復，要限制可改路徑並要求驗證；高風險任務如付款、資安、資料遷移、跨模組重構，才使用較強推理模型、人工審核與更完整測試。

外部 agent 榜單只作定位：Arena snapshot（2026-07-21）

✅Arena 官方頁 Agent Arena 是以 Agent Mode 真實使用 session 做的動態 agent leaderboard；公開 snapshot payload 的 lastUpdated 是 2026-07-21、1,242,857 sessions、38 models，我在 2026-07-26 擷取。頁面 metadata 的 dateModified 另為 2026-07-26；它是頁面更新訊息，不等於固定資料截止日。它比較的是「在工具編排任務裡的 agent 表現訊號」，不是模型綜合智力、價格、CLI 體驗或所有工作負載的絕對排行。下表保留完整前十，再列出 snapshot 中所有 Google 相關列；表內 ± 是 avgScore.ci 轉成百分比後的 95% confidence interval，正負號也依 avgScore.value 保留。

方法上的邊界很重要：Arena 的官方方法說它從真實 Agent Mode session 讀取 confirmed success、praise vs complaint、steerability、bash recovery、tool hallucination 等訊號，並以 causal tracing 估計 orchestrator model 的 net improvement；目前榜單主要評估「主 orchestrator」，不是把每個 API base model 在相同 CLI harness 裡重跑一次。Rank 的第一個數字是 raw rank；後面的 spread 是依各模型 CI 重疊推導的可能區間，不能讀成穩定嚴格先後。這使它適合回答「這個入口的 agent 編排訊號如何」，不適合公平外推成 Gemini API、Gemini CLI、Antigravity、Codex CLI、Claude Code 之間的全產品勝負。動態榜單要定期重查；下一次更新只應替換有新日期的 snapshot，不要覆蓋本次歷史紀錄。

知道「該送到哪一級」之後，還有一層更基本的問題：你使用的入口是否真的支援這個 model ID。Gemini API 的正式 ID、Antigravity 的 selector、開源 Gemini CLI 的 Auto／Manual 不是同一套解析器。就開源 Gemini CLI 而言，官方文件目前仍描述下面這條設定優先順序；它不能拿來證明 3.6 已進入該 CLI：

1. --model 命令列參數——當次執行明確指定，優先權最高。
2. GEMINI_MODEL 環境變數——沒下旗標時的次要來源。
3. settings.json 裡的 model.name——專案或全域的預設值。
4. 本機 Gemma router（若啟用）——見下方「auto 路由背後」一節。
5. 都沒有指定，退回預設值 auto——交給智慧路由自己判斷。

換句話說，只要你在命令列打了 --model，前面提到的設定就不應再當作那次執行的預設；實際解析仍以目前 CLI 文件與 gemini --help 為準。除錯「為什麼模型不是我要的那個」時，先記下 CLI 版本、帳號路線、輸入的 alias／ID 與最後的 usage report，不要只看 prompt 回答猜模型。

auto 路由背後：目前能證實到哪裡

在 CLI 文件列出的模型中，才依任務類型手動選擇：高風險架構或 code review 選較強模型；高頻率抽取、分類選 Flash-Lite；每次都記錄實際模型與 token。若你要在 API 直接使用 3.6，請改看 15.2A，而不是先假設 CLI 的 auto 會替你路由到 3.6。

配額用完時的降級：會提示的，跟不會提示的

撞到配額或容量限制時，某些入口會提示降級，某些工具呼叫可能採靜默 fallback；但 2026-07-26 的官方資料沒有給出一條可以套用到 Gemini API、Antigravity 與開源 CLI 的共同 fallback 鏈。先保留錯誤 JSON、usage、CLI／SDK 版本，再依當前 surface 的說明處理，不要用回應風格反推它剛才換了哪個模型。

settings.json 裡跟成本、路由有關的欄位

跟本章主題直接相關的 settings.json 欄位，整理在下表；它們是 CLI 設定 schema，不是 Gemini API 生成參數。欄位名稱與預設值會隨版本調整，且這份查證沒有證明它們會把開源 Gemini CLI 路由到 3.6；實際請以你安裝版本的官方 configuration 文件為準：

第 5 章提過另一個相關欄位 chatCompression.contextPercentageThreshold，作用同樣是設自動壓縮的觸發門檻；如果你在自己的 settings.json 裡兩個名字都試過還是對不上，這通常是欄位隨版本改過名稱或路徑，直接查官方 configuration 頁的目前 schema 最準。

15.7 Gemini API key、Vertex 與企業帳務

個人或小型專案常從 Gemini API key 開始，設定快、適合原型與低風險工具；但團隊一旦需要集中帳務、IAM、專案隔離、quota 管理、審計、資料治理、企業採購或更嚴格的合規流程，就應評估 Vertex AI 或 Gemini Enterprise 相關平台。路線不同，價格表、可用模型、資料處理條款、區域、quota 申請與發票管理也可能不同。

在 CLI 場景中，還要分清楚「Gemini CLI/Antigravity 產品本身的登入與功能」和「你自己的程式使用 Gemini API 或 Vertex AI」。前者的指令與功能會隨版本變動；後者則要依 API/Cloud 帳務與 IAM 管理。Gemini CLI 與 Antigravity 的能力、旗標、登入方式與限制都很版本敏感，請用目前安裝版的 /help、官方 repo 與文件驗證。

走 Gemini API 付費路線時，請以當前 AI Studio／API pricing、rate-limit 與 project dashboard 顯示的 tier 為準；本章不再把舊版付款門檻或短時間花費數字寫成永久規則。固定成本預估可先採 15.1 的 dated price checkpoint，再用小流量實測 input、output、thinking、tool call 與 retry。

Spend Cap：真正擋得住超支的護欄

若你的 AI Studio／Cloud project 提供 Spend Cap 或 budget controls，請把它當作專案層級的額外護欄，並以當前控制台說明確認 enforcement、延遲與適用 endpoint；不要把某個產品頁的功能自動套到另一個產品入口。

15.8 預算護欄與用量估算

預算管理要從工程流程做起：為每個環境分開 API key 或 Cloud project、設定每日與每月預算告警、限制 CI 並行數、記錄每次請求的模型與 token 估算、對高成本任務要求人工確認。對 agent 工作流，最有效的護欄通常是限制可讀檔案、可修改路徑、最大回合數、最大輸出長度與可使用模型。

最容易忽略的帳單陷阱：環境變數靜默覆蓋 OAuth

這是社群公認影響範圍最大的一個陷阱，而且介面完全看不出任何差異：只要 GEMINI_API_KEY、GOOGLE_API_KEY、GOOGLE_GENAI_USE_VERTEXAI 這三個環境變數任何一個被設定——哪怕只是之前裝別的工具時寫進 shell profile、你自己早就忘了這回事——Gemini CLI 就會悄悄改走按 token 計費的付費路徑，不會用你以為的免費 OAuth 登入。社群把這稱為一個「known defect」：畫面上完全沒有提示你正在用哪一條認證路徑。

💡 建議執行：開新 session 前先確認這三個環境變數是空的

echo $GEMINI_API_KEY
echo $GOOGLE_API_KEY
echo $GOOGLE_GENAI_USE_VERTEXAI

三行只要有一行印出非空字串，這個 session 就是走付費路徑。真實案例不少：GitHub Discussion #4472 與後來被廣泛轉載的一篇 Medium 文章，都在講同一種遭遇——使用者以為自己用的是免費額度，結果 Pro 模型在背景「進入推理迴圈」，5 小時內燒掉超過一億顆 token，收到一張 $142 美金的帳單。🌐社群 養成習慣，開新 session 前先跑一次上面三行確認是空的——尤其是換了電腦、剛裝完別的 AI 工具之後。

確認認證路徑之後，下一步是把用量看得見。headless 模式（第 12 章介紹過）帶 --output-format json 執行，會回傳一個單一 JSON 物件：

gemini -p "your query" --output-format json

回傳結構含三個頂層欄位：response（模型的回覆內容）、stats（token 用量與 API 延遲統計）、error（失敗時的錯誤資訊）。stats 裡確切有哪些欄位，官方文件目前沒有列出完整 schema，建議自己先跑一次、印出完整 JSON 看實際長什麼樣，或查當下的 gemini --help 確認。把這個輸出接進自己的 log 或 CI 儀表板，會比肉眼盯終端機裡的 /stats 更適合長期追蹤預算趨勢。

互動模式下，/stats 系列指令是查看單一 session 用量最直接的方式：/stats 顯示整體摘要，/stats model 拆成各模型的用量分佈，/stats session 看這次對話的統計，/stats tools 看工具呼叫的次數。前面 15.3 節提過，用 OAuth 登入的使用者在這裡看不到任何 cache 節省的數字，原因不是 bug，是認證路徑本身不支援 caching。

還有一個常被低估的固定成本：GEMINI.md 越養越大之後，不只是第 5 章談過的「規則互相打架、模型開始瞎猜慣例」這種品質問題——它每一輪對話都會整包重新送出當作 context，等於每次都在繳一筆固定的 token 底稅，不是只有第一次載入才算數。控制在精簡範圍、必要時拆成子目錄各自的 GEMINI.md，省的不只是模型的判斷品質，也包括每一輪對話實際的 token 帳單。

{
  "request_id": "req_2026_06_30_001",
  "feature": "ci-pr-review",
  "model_route": "medium-risk-review",
  "estimated_input_tokens": 18000,
  "estimated_output_tokens": 1800,
  "cache_key": "repo_rules_v3",
  "retry_count": 0,
  "user_or_job": "pull-request-4821"
}

估算不需要一開始就完美，但要能回答三個問題：哪個功能花最多、哪個模型最常被高估、哪種錯誤造成最多重試。只要 log 能串到 feature、model route、token 估算與 retry 次數，就能逐步調整路由與預算。

15.9 安全重試與停損

重試只適合暫時性錯誤，例如網路中斷、部分 429、部分 5xx。認證失敗、權限不足、billing 未啟用、prompt 太大、格式設計錯誤，通常重試也不會成功。安全重試要符合 idempotent：同一請求重送不會重複下單、重複寄信、重複建立 ticket、重複改檔或重複扣款。

安全重試規則：
- 每個 request 都有 request_id，方便去重與追蹤。
- 只重試明確可重試的錯誤類型。
- 使用 backoff + jitter，避免所有 job 同時重送。
- 設定 retry budget，例如最多 3 次或最多 2 分鐘。
- 超過上限就降級、排隊或交給人處理。
- 寫入型工具呼叫必須有 dry run、確認或 idempotency key。

429 無限重試死鎖：已知限制，不是你的錯

官方 GitHub issue #2140 記錄過一個相當麻煩的行為：CLI 連續撞到速率限制時，重試邏輯有時不會退避，直接無上限持續重送，導致整個 session 卡死、完全沒辦法互動，也看不出是在等待還是當機了。更值得記住的是，官方把「實作 circuit breaker」這個修復提案標記為 closed as not planned——代表查證當下這仍然是一個存在的已知限制，不是還在排隊等修的 bug。🌐社群 遇到這種卡死，目前沒有官方內建的救法，只能中斷重開；如果是跑在自動化流程裡，不要完全信任 CLI 內建的重試保護，自己在外層包一層 retry／timeout 更保險。

YOLO 模式配無人看管＝燒錢風險

YOLO／自動核准模式（第 7 章談過安全面的風險）配上長時間無人看管執行，還有一層本章關心的成本風險。真實案例：有人把 agent 丟著跑過一個週末沒管，回來收到一張 $4,200 美金的帳單。🌐社群 原因通常不是單次呼叫特別貴，而是 agentic 迴圈本身的結構——讀檔、規劃、生成、失敗、重試、再生成，這樣繞一圈下來，實際吃掉的 token 量可以是單次呼叫的 50 到 100 倍，而且完全不會停下來問你要不要繼續。

💡 建議執行：無人看管的自動化任務，先包一層時間上限

timeout 300 gemini --yolo -p "long autonomous task"

timeout 這種外層時間上限，比完全信任 CLI 內建的迴圈保護更踏實——它不管 CLI 內部邏輯是不是卡住或還在正常工作，時間一到就直接砍掉，是最後一道止損線。

本章小結

Gemini 成本治理的重點，是把用量拆成 input、output、thinking、cache、重試與外部工具成本，再依任務風險、延遲與帳務要求做模型路由——但不要把開源 CLI 的 router 行為、產品間 quota 共用或 Arena snapshot 寫成未證實的常數。context caching 的適用性、儲存、有效期、刪除與合規要納入預算；quota 與 rate limit 要依 endpoint、project、plan 及當前文件處理。最容易被忽略、卻最容易燒錢的陷阱，是環境變數靜默覆蓋 OAuth 認證——開新 session 前先確認 GEMINI_API_KEY、GOOGLE_API_KEY、GOOGLE_GENAI_USE_VERTEXAI 是空的，比事後對帳單申訴退款輕鬆得多。所有固定價格、配額數字、排名與限制都應回到原始頁面確認，這章的價格與 Arena 榜只以日期 checkpoint 使用。

動手試試

1. 挑一個常用 Gemini CLI 或 API 任務，寫出它的 input、output、thinking、cache 與 retry 成本來源。
2. 把五個任務分成低、中、高風險，為每一類指定模型路由、最大輸出與人工審核規則。
3. 記下 2026-07-21 的 Arena Agent snapshot；只把它當 agent 編排定位，並標註下次重查日期。
4. 若從舊 API 升級，依 15.2A 清掉取樣參數、prefilled turn 與不相容的 function response 欄位。
5. 設計一份 request log schema，至少包含 feature、model route、token 估算、cache key、retry count。
6. 寫一段 429 runbook，明確區分排隊、降級、重試、申請 quota 與停止任務。
7. 打開目前官方 pricing、rate-limit、caching 頁面，確認你的文件沒有寫死過期價格或限制。
8. 跑一次 echo $GEMINI_API_KEY; echo $GOOGLE_API_KEY; echo $GOOGLE_GENAI_USE_VERTEXAI，確認自己目前的 session 走的是哪一條認證路徑。
9. 打開自己的 settings.json，對照 15.6 節的欄位表，確認 model.name、experimental.useModelRouter 這些欄位目前的值跟你以為的一不一樣。