Claude Code / agent 迴圈一晚燒掉幾千元，怎麼辦？

早上醒來滑手機，打開 API 供應商後台，看到一個讓你倒抽一口氣的數字。昨晚睡前開的 Claude Code session，或是你隨手跑起來的 agent 流程，在你睡著之後一直沒有停下來——沒有跳錯誤、沒有當機，只是安靜地、持續地在燒錢，燒了一整夜。

這不是罕見的個案，是現在獨立開發者社群裡最常見的抱怨之一。隨著 Claude Code、Cursor 的 agent 模式、Aider 這類 agentic coding 工具愈來愈普及，一種特定的失控模式也跟著愈來愈常見：agent 卡進重試迴圈、每一輪都重新讀一次巨大的上下文、或是背景留了一個沒人記得要關的 process——而這一切呼叫都是按 token 計費，完全沒有上限。

為什麼 agent 迴圈特別燒錢

一般的聊天對話有真人在盯著每一次發送；agent 沒有。它會規劃、呼叫工具、讀結果、再規劃、再呼叫，一個任務裡可能重複幾十輪，而且每一輪往往都帶著累積下來的完整對話紀錄當上下文。一旦出錯——工具呼叫格式錯了、測試一直用同樣的方式失敗、prompt 讓模型每一輪都重新讀一次同樣的檔案——agent 不一定會停下來，它會繼續嘗試，每一次嘗試都是全額計費，連同那疊愈滾愈大的上下文一起算錢。

按用量計費的模式，結構上完全沒有誘因幫你踩煞車：迴圈跑得愈久，供應商賺得愈多。如果是轉發 API、抽價差的中轉服務，誘因更薄弱——燒的又不是它的錢。

三個實際能做的防範措施

不管你用哪家的 API，這幾件事都值得先做好：

先幫 API key 設用量硬上限。 多數供應商後台都能設每月或每日的花費上限，加上 email 告警。要在開始跑長任務「之前」設好，不要等帳單來了才後悔——凌晨兩點自動斷掉的上限，遠比隔天早上才想起來設定便宜得多。

先小規模測試，確認邏輯正確再放大跑。 新的 prompt 或 agent 流程，先用小任務、短上下文驗證會不會卡迴圈、會不會每輪都重讀同樣的檔案，確認乾淨結束之後，再放去長時間背景跑。

收工前一定要檢查，別留背景 process 沒關。 tmux／screen 開的背景 session 是最容易忘記關的地方——十次帳單爆炸的案例裡，有很高比例都是這個原因。真的沒辦法盯著，就別讓它在沒設上限的情況下留著跑。

在 agent 框架裡設「呼叫次數上限」，不要只設 token 預算。 一個「單次很便宜」的迴圈，只要沒東西攔它，在同一個檔案上重複個 50 次照樣能把帳單堆起來。

但這些終究是治標，真正的問題出在計費模式本身

以上每一步都是在幫一個「從沒設計給自主迴圈用」的計費模式擦屁股。按 token 計費在「每一次呼叫都是真人打字送出」的年代很合理；但當發送請求的東西變成一支可以自己無限重試的程式，這套邏輯就不成立了。

這才是 agentic coding 真正曝露出來的問題：計費模式跟實際用量型態，根本對不上。

固定月費怎麼從結構上解決這件事

TokenTable AI算力平台走的是固定月費制，不是按 token 跳表——個人方案 NT$600（美金 $19）起。不管你的程式在背後做了什麼，帳單金額不會變，你在寫下第一行程式碼之前，就已經知道要付多少錢。

有兩個機制讓這件事在「agent 迴圈式用量」下也撐得住：

• 副餐真正無限量。 TokenTable 的 AI 智能路由會判斷每個請求實際需要什麼，把 agent 迴圈最常產生的那種例行、重複步驟自動導去副餐模型——不額外扣費，把主餐配額留給真正需要旗艦推理能力的請求。實務上，把 Claude Code 接上 TokenTable、模型選 auto，寫程式類任務常會路由到程式旗艦副餐模型如 kimi-k2.6，背景輕量步驟則路由到更省的模型——完全不會像跳表 API 那樣讓一次失控的迴圈直接吃掉整月配額。
• 主餐配額有每日上限，不是只看每月。 即使是付費方案，每日主餐用量也有上限（約月配額 ÷ 15），就是為了不讓單一一個晚上的失控把一整個月的配額燒光。額度用完後自動切回副餐繼續跑，不斷線、不會收到意外帳單——只是安靜度過本來會很可怕的一夜。

如果你正在用 Claude Code、Cursor、Aider 或任何 agentic 工具，已經被燒過帳單、或正在擔心下一次會不會就是你——固定月費的開發者方案 就是為這個情境設計的。也可以先 到聊天介面試用，實際感受 AI 智能路由怎麼運作，再決定要不要接進開發工具。