如何控管常駐 AI agent 的 API 費用

如何避免常駐 AI agent 持續產生高額費用

在 VPS（virtual private server）上控管 AI agent 成本，重點是在 agent 啟動前設定上限，因為執行期間不會有人持續監看用量。使用 max_tokens 限制每次回應， 在程式碼中限制迴圈迭代次數，快取提示中不會變動的部分，並記錄每次回應的用量數據，以確認是哪個工作消耗費用。伺服器租用費是固定的月費。模型 API 依 token 計費，而無人監看的迴圈很容易在不知不覺中持續消耗 token。

本文假設你已有一個 agent，且它會從你管理的主機呼叫 Messages API。在 VPS 上使用 Claude 建立 AI agent 說明 agent 本身的建置方式。

為什麼無人值守代理程式的成本結構不同

互動式工作階段中有人員參與。模型走錯方向或讀取 40,000 行的日誌時，監看人員會將其停止。無人值守的代理程式沒有這項煞車機制：它會持續執行直到迴圈結束，接著由計時器再次啟動。

頻率是人們最容易忽略的倍數。一項每 5 分鐘執行一次的工作，每天會執行 288 次，每月約執行 8,640 次。單次執行的成本是多少，就用這個數字來乘。許多「always-on」代理程式其實不需要持續運作。它們只需要在指定的分鐘數內回應，而這就是排程。

代理程式還會處理聊天視窗無法支付的費用。

• Tool definitions ride along on every request. The tool-use system prompt costs 290 tokens on Claude Opus 4.8 with tool_choice of auto or none, and 410 with any or tool. The bash tool adds 325 more. Every MCP server you attach adds its schemas to that weight, MCP being the model context protocol.
• Tool results are input tokens. A command that prints 8,000 lines puts 8,000 lines into the next request, and into every request after it in that turn.
• Fetched pages are input tokens. An average 10 kB web page is roughly 2,500 tokens and a 500 kB research PDF roughly 125,000. max_content_tokens truncates the text ones only, because it "applies to text content, not to binary content such as PDFs". Bound a PDF with max_uses and allowed_domains instead.
• Web search is priced per search, at $10 per 1,000 searches, however many results come back. A search that errors is not billed.

這些工作沒有哪一項只需付出一次成本。每一項都要付出 8,640 次成本。

硬上限與軟上限解決的是不同問題

max_tokens 會強制執行。 這是單一請求的總輸出硬上限，包含思考內容與回應文字。Claude 不會超過此上限產生內容，而且模型看不到這個數值。達到上限時會產生 stop_reason: "max_tokens"，並回傳遭截斷的答案。對代理程式而言，問題在於工具使用迴圈中的每個請求都有自己的 max_tokens，因此它限制的是單次回應，而不是整項工作。每次工具呼叫上限為 4,000 時，10 次工具呼叫在本輪共有 40,000 個 token 的上限。

工作預算是建議值。 task_budget 位於 output_config 之內，用來告知模型整個代理程式迴圈可使用的 token 數量，包含思考內容、工具呼叫、工具結果與輸出。

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

「工作預算是軟性提示，不是硬上限。」Claude 可能在一次動作中超過預算，而輸出的強制上限仍是 max_tokens。「倒數資訊只有模型看得到」，回應中也不會附帶剩餘預算欄位。接受的 task_budget.total 最低值為 20,000 個 token；低於此值會回傳 400 錯誤。若預算不足以完成工作，模型可能出現類似拒絕的行為，因此會縮小工作範圍或提早停止。

有一項設定會增加成本，而不是節省成本。如果用戶端在每次後續請求中遞減 task_budget.remaining，變更後的值會使任何包含該值的快取前綴失效。請在第一個請求中設定一次即可。

工作預算目前在 Claude Fable 5、Claude Opus 4.8 和 Claude Opus 4.7 上處於 beta 階段。Claude Sonnet 5 和 Claude Haiku 4.5 列為 Not supported；工作預算不適用於 Claude Code，因此 在 tmux 中脫離的 Claude Code 工作階段 取決於工作階段管理是否妥善。

第三個上限位於 Claude Console：為代理程式建立專屬 workspace，然後在該 workspace 上設定每月支出上限與每分鐘速率限制。「你無法在 Default Workspace 上設定限制」，而且「Organization-wide limits 一律適用，即使 workspace limits 的總和更高」。請加入支出通知，讓系統在達到上限前於超過指定門檻時通知你。

每個工作都應個別選擇模型，以及真正會改變成本的因素

模型選擇應依每個工作個別決定。截至 2026 年 7 月，每 1 million tokens 的輸入與輸出價格如下：Claude Fable 5 分別為 $10 與 $50；Claude Opus 4.8 和 Opus 4.7 分別為 $5 與 $25；Claude Sonnet 5 分別為 $3 與 $15；Claude Haiku 4.5 分別為 $1 與 $5。Sonnet 5 目前的價格低於標示價格，因為「每 1 million 個輸入／輸出 tokens $2／$10 的導入價格，適用至 2026 年 8 月 31 日」。只分類 log 行的步驟不需要 Opus。忙碌的排程也沒有免費額度可供使用，因為 Claude API 沒有免費方案，只有註冊時提供的小額 credit。

Effort 是第二個可調整的因素。output_config.effort 接受 low、medium、high、xhigh 和 max，預設值為 high，因此明確設定 high 的效果等同於省略它。降低 effort 不只會縮短推理長度。文件指出，這會讓 Claude 減少 tool call，並將多個操作合併成一次。對 agent 而言，這通常能節省更多成本，因為省略一次 tool call，就等於完全不發出一個 request。

問題在於，effort 會影響快取。變更 requests 之間的值會使 prompt caching 失效。在文件提供的範例中，request 2 回報 cache_read_input_tokens: 3546；request 3 將 effort 從 high 改為 medium 後，回報 cache_creation_input_tokens of 3546 和 cache_read_input_tokens of 0。因此，請依不同工作調整 effort，但不要在同一個已快取的對話中調整。若要在不破壞快取的情況下控制回答深度，請在 prompt 中指定，例如在最新的 user message 加入「直接回答，不要進行詳細推理。」即可保留先前的 breakpoints。

Thinking tokens 會按照 output rates 計費，並計入 max_tokens，因此回答遭截斷時，通常表示 thinking 耗盡了預算。請查看 usage.output_tokens_details.thinking_tokens 取得數值。Claude token 帳單實際由哪些項目組成 會逐項說明計費內容。

快取穩定前綴，避免意外破壞

在 5 分鐘快取中，寫入快取的成本是基本輸入價格的 1.25 倍；在 1 小時快取中則是 2 倍。讀取快取的成本是 0.1 倍。因此，「5 分鐘效期的快取只要讀取 1 次就能回本（寫入成本為 1.25 倍）；1 小時效期的快取則要讀取 2 次才能回本（寫入成本為 2 倍）」。

有一句話說明這為何適合持續執行的代理程式：「每次使用快取內容時，系統都會免費重新整理快取。」每 2 分鐘針對 5 分鐘快取執行一次的工作，只要寫入 1 次，就能讓前綴整天保持在快取中。

以下是 3 種在未察覺的情況下遺失快取的方式。

會變動的前綴。「快取前綴會依下列順序建立：tools、system，接著是 messages。」只要這個順序中較前面的任何位元組發生變更，後面的所有內容就會失效；編輯工具定義則會使整個快取失效。最常見的自我造成問題，是在系統提示中放入時間戳記或執行識別碼：如此一來，每個請求都會攜帶不同的前綴，以 1.25 倍成本寫入新的項目，卻無法讀取既有內容。相同外觀的呼叫若顯示 usage.cache_read_input_tokens 為 0，就是這種問題的徵兆。請將易變動的文字移至最新的使用者訊息中。

過短的前綴。每個模型都有可快取長度下限。低於此長度時，請求會在未使用快取的情況下處理，而且「不會回傳錯誤」。其中包括 Claude Opus 4.8 和 Claude Sonnet 5 的 1,024 個 token，以及 Claude Haiku 4.5 的 4,096 個 token。因此，將工作從 Sonnet 移至 Haiku 可能會讓快取無聲無息地停用。

對話超出回溯範圍。「回溯視窗為 20 個區塊。」系統在每個斷點最多檢查 20 個位置，之後就會停止。在文件所示的範例中，某一回合包含 35 個區塊，且第 35 個區塊設有斷點；系統會檢查第 35 到第 16 個區塊，而前一回合位於第 15 個區塊的項目已超出視窗，因此不會命中。代理程式每回合附加數個工具使用和工具結果區塊時，兩到 3 個回合就會超過 20 個區塊。每個請求有 4 個斷點，請將其中 1 個用於最近的訊息。

將所有可以等待的工作送至 Batches API

「所有用量均按標準 API 價格的 50% 計費」，輸入與輸出皆適用。批次處理是非同步的，「大多數批次會在 1 小時內完成」。系統會在所有請求完成時提供結果，或在 24 小時後提供結果，兩者以較早者為準。這是一般情況，不代表一定如此。

持續輪詢 processing_status，直到其值為 ended。回傳 errored、canceled 或 expired 的請求不會計費。若依賴支出上限，需注意一點：「批次可能會略微超過 Workspace 設定的支出上限。」

這些折扣可以疊加。此外，由於批次處理時間可能超過 5 分鐘，文件建議讓共用內容的批次使用 1 小時快取。因此，應將工作分流：人員或 webhook 必須等待的工作留在即時處理路徑，夜間摘要或前一天的日誌分類則送入批次，以半價處理。

將每次回應的用量欄位記錄到自己的儲存區

未記錄的支出無法歸屬。每次回應都會告訴你這次請求的成本。

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

每次 API 呼叫在 JSON-lines 檔案中附加一列，並標記工作名稱。一週後，你就能判斷哪些工作正在產生支出，哪些工作只是看起來很忙。注意 cache_read：整欄都是 0，是自架 agent 最常見的成本錯誤。

有一個欄位很容易誤讀。input_tokens 只計算最後一個 cache breakpoint 之後的 token，因此實際的 prompt 大小是 total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens。大型 prompt 的 agent 若回報 input_tokens: 400，並不代表成本低廉；其餘內容來自 cache。

在傳送前先計數。Token 計數不收費，且使用不同於訊息建立的 rate limits，因此請使用 count_tokens 拒絕過大的附件，而不是付費後才發現它超出限制。結果只是估算值，因此應針對每個模型重新測量，絕不要重複使用其他供應商 tokenizer 的計數。Claude Opus 4.7 及後續 Opus models、Claude Fable 5 與 Claude Sonnet 5 使用較新的 tokenizer，該 tokenizer「對相同文字產生約多 30% 的 token」。Claude Sonnet 4.6 及更早版本，包括 Claude Haiku 4.5，使用前一代 tokenizer。

如需權威資料，Admin API 會在 https://api.anthropic.com/v1/organizations/usage_report/messages 回報用量，並在 https://api.anthropic.com/v1/organizations/cost_report 回報成本。兩者都接受 admin key (sk-ant-admin01-...) 作為 x-api-key: $ANTHROPIC_ADMIN_KEY，搭配 anthropic-version: 2023-06-01 使用，並接受 bucket_width=1d、group_by[]=model 及 api_key_ids[]=。有一項限制：「個人帳戶無法使用 Admin API。」

最後一個參數提供簡易的歸屬方式：為每個工作建立專用 API key，使用 api_key_ids[] 篩選，再使用 group_by[]=api_key_id 依 key 分組報表。篩選條件是複數，分組維度是單數。請將 keys 存在環境變數中，而不要寫入程式碼；在 VPS 上建立第一個 Claude API 應用程式也是這樣處理。

限制迴圈，因為沒有其他機制會替你處理

這裡不能省略有限的迭代次數。迴圈由你撰寫，因此計數器也由你控制：

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

上方的兩個上限都無法替你完成這件事：max_tokens限制單一回應，而模型只會得知任務預算。代管產品會在這裡停止，就像Claude 在單一回合中的工具呼叫上限會終止工具呼叫過多的工作階段；但自行撰寫的迴圈在你加入防護機制前，不會內建這類後備限制。

在程序外再加一道限制。不要讓工作以永久執行的程序運作，而是透過 systemd timer 啟動，並在其服務單元中設定 RuntimeMaxSec=。設定 RuntimeMaxSec=600 後，失控的執行會在 10 分鐘後終止，不會持續執行到你才發現。將程式作為 systemd 服務與 timer 執行說明單元檔案本身的設定方式。使用 journalctl -u triage-agent.service --since "1 hour ago" 查看一次執行所完成的工作。

也要限制重試次數，因為無限重試的處理常式會為每次嘗試計費。429 或 500 錯誤適合搭配退避機制重試幾次。400 錯誤則不應重試，因為相同的請求仍會以相同方式失敗。

AI 代理程式的成本控制始於讀取自己的數據

沒有人能直接告訴你常駐代理程式的成本，因為成本等於每次執行的 token 數量乘以每天的執行次數，而這兩項都由你決定。先執行一次，讀取你記錄的使用量欄位，再乘以排程每天執行的次數。2 天後檢查成本報告，與上述計算結果比對。如果兩者不一致，差異幾乎總是來自快取失效，或迴圈執行時間超過預期。

這裡假設使用 API key，因為代理程式是由你自行撰寫，並呼叫 Messages API。若是你自己的互動式工作，哪個 Claude 方案符合你的工作方式涵蓋訂閱方案的選擇。這裡的每項價格與限制都已在 July 2026 依據 Anthropic 的文件核對，因此在編列預算前，請重新閱讀定價頁面。

FAQ

在 VPS 上執行持續運作的 AI agent 需要多少費用？

費用分成兩項，只有一項可預測。伺服器是固定的月租費。模型 API 按 token 計費，因此費用取決於每次執行的用量，再乘以執行頻率。Anthropic 沒有公布自架持續運作 agent 的費用，因此任何引用的數字都只能視為估算。記錄一次實際執行的 usage，再依排程計算。

max_tokens 與 task budget 有何不同？

max_tokens 會強制套用，且模型看不到。它會限制單次請求的輸出量，其中包含思考內容；達到上限時會產生 stop_reason: "max_tokens"。task budget 則相反：模型會得知這個數值，並依此調整 agentic loop 的執行速度，但「Task budgets are a soft hint, not a hard cap」，實際強制套用的限制仍是 max_tokens。

為什麼我的 agent 的 cache_read_input_tokens 一直是零？

因為每次呼叫的前置內容有所變更，或內容太短而無法快取。最常見的原因是將 timestamp 或 run id 插入 system prompt：快取以此前置內容為鍵，因此任何位元組變更都會使其後的全部內容失效。變更工具定義或 effort 值也會造成相同結果。否則原因是內容大小：較短的 prompt 不會快取，且不會回傳錯誤。

如何防止 AI agent 無限迴圈？

在迴圈程式碼中計算迭代次數，並在達到固定上限時停止，因為 max_tokens 只限制單次回應，而 agent 會執行多次請求。在程序外加上實際時間限制：從 systemd timer 啟動工作，並設定 RuntimeMaxSec=，讓卡住的執行依排程終止。也要限制重試次數，因為每次重試都會產生費用。

可以為單一 Claude API key 設定支出上限嗎？

文件所述的支出上限是以 workspace 為單位，而不是以 key 為單位。因此，請為 agent 建立專用 workspace，並在其中限制每月支出。「You cannot set limits on the Default Workspace」。加入支出通知，讓系統先在達到門檻時通知你。若要歸屬各項費用，請為每個工作發行專用 key，再使用 group_by[]=api_key_id 彙整使用量報告。