編按：本文綜合整理自 Simon Willison 部落格原文、AWS 9 月 16 日公告、Google Cloud 7 月 28 日部落格、Cloudflare AI Gateway 6 月公告，並加入 Siami 編輯部觀點與分析。
知名 AI 觀察家 Simon Willison 在 10 月 3 日發文呼籲：所有按用量計價（pay-by-usage）的服務都應該把「硬預算上限（hard budget cap）」設為預設值，而非可選功能。這篇文章的時機特別敏感——AWS、Google Cloud 近期相繼補上這塊 20 年來一直欠缺的拼圖。
事件的開端：一個讓人睡不著覺的噩夢
Simon 在文章開頭講了一個再熟悉不過的情境：半夜被一封「預算警告」信叫醒，打開信箱才發現那隻跑歪的服務，在你睡著的幾小時內已經吞下「好幾百、甚至好幾千美元」的用量。
「沒人想半夜被警告信吵醒，然後發現自己已經被多收了一萬美元。」—— Simon Willison
他主張這類消費型 API 必須有「過了 $X/月就強制切斷」的功能。關鍵字是「hard」：軟性上限（只發警告信）不夠，因為錢已經花掉了；只有真正「切斷服務、開始回傳錯誤」的硬上限，才能止血。
更進一步，他主張這應該是預設行為。想裸奔的人自己去打勾：「我了解風險，請不要幫我設上限」，並把這選項放進合約條款。
為什麼這件事重要
2026 年是 AI Agent 大爆發的一年。coding agent 把「寫程式」門檻拉到接近零，但也把「意外產生費用」的門檻同樣拉到接近零。一個小學生程度的開發者能在 30 分鐘內部署出一個會自己呼叫付費 API 的代理程式，而這個代理程式失控時的成本，可能不是幾塊錢，而是幾萬美元。
這個問題的規模遠比表面看到的大。Siami 整理了近期幾個真實事件：
- 2026 年 4 月：Uber 把 2026 全年的 AI 預算在 4 個月內燒光，原因是 Claude Code 在工程團隊內被大量使用
- 2026 年 5 月：某企業一個月內在 Claude 燒掉 5 億美元——因為忘記設上限
- 2026 年 5 月：一位開發者一晚在 Claude Code 燒掉 6,000 美元
- 2026 年 6 月：Uber 對每位工程師 Claude Code 設 1,500 美元上限
這不是個別事件。整個產業正集體撞上一個從來沒有的問題：AI 工具太好用，好用到人會在不知不覺中花掉六位數的雲端帳單。硬預算上限不只是「貼心功能」，它是 AI Agent 時代的基礎安全設備。
雲端三巨頭的反應：AWS、GCP 終於補課
好消息是，2026 下半年雲端三巨頭已經在快速補課。Simon 文章裡特別引用了兩個案例：
AWS：9 月 16 日的新體驗
AWS 在 9 月 16 日推出全新的「Builder Experience」，最關鍵的變化是把「專案層級月費上限」變成預設值。從 9 月服務更新公告可以看到，新客戶從最低 $20/月 就能設定上限，觸發時 AWS 會自動暫停整個專案（不是只發信），使用者可以調高額度再恢復。
但這個功能目前只對「簡化版註冊」的新客戶開放，文件警告「目前正在向少數客戶釋出」，傳統老帳號何時能用還沒時程。
Google Cloud：7 月底上線 Spend Caps
Google Cloud 在 7 月 28 日上線 Spend Caps，可以針對「特定服務」設月費上限（不是全帳戶），觸發後同樣會自動暫停。Medium 上 GCP Finally Has a Kill Switch 這篇文章直接把它叫作「GCP 終於有開關了」。
Cloudflare AI Gateway：6 月搶先
Cloudflare 在 6 月就把 spend limits 放進 AI Gateway 核心功能——而且是用「美元」而非「token」計價，這對非技術背景的決策者友善得多。文件寫得很清楚：「累積花費到達上限時，AI Gateway 直接停止轉發請求」。
三巨頭一致的方向說明一件事：硬預算上限正在從「進階功能」變成「平台預設」。
數據解讀與質疑
把這幾個事件放在一起看，會浮現幾個值得追問的訊號：
訊號一：金融海嘯的規模
前面引用的「4 個月燒光全年預算」、「一個月 5 億美元」，這些數字大到一般人無法直觀理解。把它換算一下：
| 場景 | 金額 | 對照 |
|---|---|---|
| Uber 全年 AI 預算 4 個月燒光 | 約數千萬美元 | 一家中型 SaaS 全年營收 |
| 企業一個月 Claude 帳單 | 5 億美元 | 某些中型上市公司的市值 |
| 個人開發者一晚 Claude Code | 6,000 美元 | 台灣新鮮人年薪 |
「個人燒 6,000 美元」聽起來像個案，但乘以全球數百萬開發者的使用率，就是企業級的金融災難。
訊號二：產業被迫集體轉向
從 Uber、微軟（把內部團隊從 Claude Code 換到 Copilot CLI）的動作可以看出，cost control 已經從「IT 議題」升級成「財務議題」。CFO 開始介入 AI 工具採購，這在 2024 年是難以想像的。
質疑：硬上限會不會反而變成攻擊破口？
HN 討論串裡有個高讚留言提出反向思考：
「硬預算上限 checkbox 比失控帳單更危險——如果真的遇到攻擊者，他們會故意觸發 cap 讓你所有依賴該服務的業務一起停擺。這是 DoS 攻擊的新手法。」
這個質疑有道理。AWS 目前「整個專案一起暫停」的設計，在 multi-tenant 架構下確實可能造成連鎖停擺。理想的設計應該是「單服務暫停 + 跨服務配額獨立」，但這會大幅增加平台複雜度。
另一個質疑來自前線客服經驗：有 HN 用戶分享在「硬上限」服務商的工作經驗：
「很多企業客戶每月 1 號直接撞牆，客服電話被打爆，最後還是要靠銷售手動調整額度。」
這是「硬上限」的副作用：它把問題從「帳單爆掉」變成「業務停擺」。兩者都是災難，只是換個形式。
Simon 的結論：讓 Agent 來守護 Agent
Simon 在文末提出一個有意思的延伸構想：
「如果 AI agent 能學會在推薦服務時，優先推薦有硬上限的提供商，並警告新手開發者不要部署沒上限的應用，那就太好了。」
這是 AI Agent 時代的「守門人設計」：當人類無法預判風險時，讓另一個 agent 來做風險管理。這跟 Cloudflare 把 spend limits 放進 AI Gateway 的設計哲學一致——把成本控制變成 LLM 應用的預設 middleware。
如果你是開發者，現在能做的三件事：
- AWS 用戶：檢查自己是否符合新 Builder Experience 資格，若符合就設定專案上限
- GCP 用戶：在 Cloud Billing 啟用 Spend Caps（Preview 階段可向業務申請）
- LLM API 用戶：不論透過 Vercel AI Gateway、Cloudflare AI Gateway 或 LiteLLM，都加上每帳戶/每金鑰的硬上限
至於 Simon 文章最後那句「軟上限沒用，硬上限該是預設值」，Siami 編輯部認同這個方向，但要加一個但書：硬上限要設計成「精準暫停」而非「整體停機」，否則會從「帳單災難」變成「營運災難」。
網友熱門留言 (3)