三個晚上不到，我用 Gemini 3.1 Preview 燒掉了 600 美

你有沒有過那種，覺得自己抓到一個超猛的工作流、興奮到連續三個晚上不睡覺，結果隔天早上被一封「您的用量已達 100%」的信打回現實的經驗？我這禮拜剛經歷過——而且不是貴 50 美 100 美那種剛剛好的痛，是三個晚上、$608 USD、一封 GCP 用量警示信那種痛。

先講前情提要，因為這個悲劇有點層次。

第一晚：gemini-cli 完全用不了一點

5/27 那天我下班沒會，晚上 23:00 才坐下來。第一件事是手癢試 gemini-cli 配 gemini-2.5。

怎麼說呢——非常失智。指令下下去它的反應像是聽不太懂中文也聽不太懂英文，給它一個明確的任務它會自己加戲、改檔案改一半跑去看別的目錄、然後跟我說「我已經完成了」（並沒有）。試了一個多小時我就放棄了，完全用不了一點。

那時候我還很無辜——以為今晚就到這了。沒想到我接下來開了第二個實驗。

第二晚：litellm + gemini-3.1-preview + Claude CLI，「進步神速」

我同一晚跑去測另一個組合：用 litellm 把 gemini-3.1-pro-preview 包成 OpenAI 相容介面，然後用 Claude CLI 當 UI——讓 Claude 負責人機溝通、Gemini 3.1 負責出力。

這個組合一上手就讓我倒抽一口氣，進步神速。我手癢想試試看它能不能獨立寫一個新功能，於是讓它先寫 spec、再寫 plan、然後實作。

結果差強人意——做是做出來了，跟我心裡想的還有點差距，而且跑得有點慢。

當時我只覺得：「嗯，可能是 preview 模型還在優化吧。」

我完全沒注意到錢。

第三晚：把 Claude 當 spec writer，總算有戰力

5/28 晚上 20:00 我又坐下來。這次學乖一點：讓 Claude CLI 寫 spec & plan，上傳到 GitLab issue；Gemini 3.1 Preview 從 issue 拿回來實作。

這個分工真的有差啊。Gemini 沒辦法自己規劃，但只要 Claude 把計劃寫得夠細，它可以老實照做。算是姑且有戰力了——我那時候滿開心的，覺得這套組合再調一下就可以變主力。

依然沒注意到錢。

然後信就來了

5/29 早上我打開 mail，看到一封 GCP 寄來的「用量已達 100%」——我那時候設的上限是 $50/月，結果三天燒了 $608。

我馬上跑去 Cloud Monitoring 拉了三天的 Vertex AI token metrics，畫面長這樣（節錄重點）：

模型                       Input tokens     費用 (USD)
gemini-3.1-pro-preview     288,388,613      ~$586
gemini-2.5-pro              16,355,629       ~$21
gemini-3.1-flash-lite        1,021,804       ~$0.10
合計                       305,766,046      ~$608

288M input tokens。三天。一個人。下班後寫的 side project。

我盯著那個數字看了滿久。

誤診：我以為是我「跑太多次」

第一個反應是「我是不是真的跑太多任務」。但拉出時間軸看就知道不是——尖峰落在深夜 00:00–03:00，5/28 02:00 那一小時單獨吃掉 71M tokens。我那時候人在睡覺，不可能在下指令。

第二個猜測是 agentic loop——模型反覆呼叫自己。5/28 一天 4,311 次 API call，這個密度確實像 loop 在跑。我想說可能是 Gemini 3.1 卡在某個 tool call 自己打自己。

聽起來很合理吧。但其實這也不是根因。

真相：context window 才是真兇

我把監控資料按「每次呼叫平均 token」拉出來看——高峰時段每次呼叫平均攜帶 ~67,000 tokens。

67k tokens/次 × 4,311 次/天 ≈ 將近 290M。對上了。

那 67k tokens 是哪來的？我去翻了 Gemini CLI 的行為，加上 kdan-bpm-all 這種重量級 repo 的內容，心算一下：

GEMINI.md + AGENTS.md:      ~5,000 tokens
knowledge/ 整坨知識庫:       ~30,000 tokens
backend + frontend 程式碼:   ~20,000 tokens
對話歷史累積:                ~10,000+ tokens
────────────────────────────────────────
合計                         ~65,000+ tokens/次

剛好。

也就是說——每一次 Gemini 3.1 Preview 的呼叫，都把整個 codebase 拖進 context。一次呼叫 0.13 鎂，看起來像零頭，但乘上 agentic loop 在深夜自己跑的 4,000 多次，就是一台二手車的錢。

更慘的是——preview 模型不受免費 quota 保護，定價還比 GA 高。我等於是在「最貴的車道」上開了一台「會自動加速的車」，然後去睡覺。

可遷移的教訓

寫到這裡我想了一下，這次學到的不是「Gemini 3.1 很貴」這麼窄的事，而是兩條更通用的：

第一條，agentic 工具的成本不在「單次呼叫」，在「context × 次數」這個乘積。 你看單價會覺得還好，看用量也覺得還好，但兩個一乘就會炸。任何一個會自己跑迴圈的 agent，都要先設預算上限再開來玩。 GCP Budget Alert 設個 $50 / 月只要兩分鐘——我那次沒設，痛到我以後每開一個新 GCP project 第一件事就是設這個。

第二條，preview 模型先當煙火看，不要當主力用。 它沒有免費 quota 保護、定價可能更高、行為也比較不穩。要試可以，但把 context 縮到最小、跑完就關、不要拿來跑長批次任務。我那三晚就是反過來——拿最不穩的模型、配最大的 context、跑最長的 agentic loop。完美的燒錢三件套。

如果再來一次，我會這樣：日常用 gemini-2.5-flash 做初步篩選（同樣 305M tokens 只要 $46，是 preview 的 1/13），只在 flash 真的搞不定的時候才切 Pro，而且先把 .geminiignore 寫好，把 knowledge/、docs/、node_modules/ 全部排除。

收尾

先不說了啦，我得去 GCP Console 把每一個 project 的 Budget Alert 都設好，順便寫個 cron 每天提醒自己看一次帳單——畢竟下次再翻車，我大概沒臉跟老婆解釋為什麼這個月信用卡多了一台 iPhone 的錢。

這些實驗進行於 2026 年 5 月 27 至 29 日，文章整理於 2026 年 5 月 29 日深夜，那封 $608 的帳單還躺在我的信箱裡。