為什麼 API 應該只在成功時收費 —— 支持 HTTP-200 計費的理由
大多數 API 對每次可計費的呼叫都收錢。AI Agent 在上游服務不穩時會不斷重試 —— 也就是說，傳統的「一律收費」模型實質上是在對韌性課稅。本文是支持「只對 HTTP 200 計費」的理由，以及它對你設計 Agent 的方式有何改變。
一句話總結
- •AI Agent 對暫時性失敗（5xx、逾時、速率限制）做合理重試。在「一律收費」的計費下，每次重試都是一筆真實收費 —— 把一個 99.5% 可用度的上游，在那壞掉的 0.5% 期間變成 5 倍的成本懲罰。
- •「只對 HTTP 200 收費」讓供應商的誘因與客戶的誘因一致：供應商修好不穩定，客戶不必為此買單。
- •它還解鎖了一些設計模式 —— 積極的重試預算、樂觀預取、冗餘呼叫 —— 這些在「一律收費」下昂貴到無法採用。
- •大多數供應商不這麼做，是因為他們的舊式基礎設施把計量綁在上游呼叫、而非回應上。那是一個被包裝成政策的計費系統限制。
我們想鼓勵的那種行為
AI Agent 是一種新型的 API 用戶端。它們不是 2015 年那種謹慎的企業整合 —— 攔到一個錯誤就寄 email 給待命工程師。它們是一些迴圈：當某件事失敗時，睡一會兒再試一次 —— 有時試五次或十次 —— 而且根本不會把結果呈現給人類看。這個迴圈的全部重點，就是讓暫時性失敗對終端使用者隱形。
這是個很棒的模式。它打造出有韌性的產品。它把公開網際網路那一團亂的現實對使用者藏了起來。問題在於，API 的計費模型是在重試既罕見、又昂貴到足以讓人預設想避免的年代定下的。它至今仍是那樣運作。每次重試都是一筆可計費的呼叫，不管它有沒有回傳任何東西。
具體來說：一個打到 99.5% 可用度 API、並在暫時性失敗時最多重試五次的 Agent，在那壞掉的 0.5% 期間，會產生最多 5 倍的呼叫 —— 以及 5 倍的帳單。Agent 做的是對的事。客戶卻為上游的不穩定買單。
更簡單的替代方案
只對 HTTP 200 收費。確切地說，只對帶有所載回應格式的成功回應收費。其餘一切 —— 呼叫方錯誤的 4xx、我方錯誤的 5xx、逾時、速率限制、部分但格式錯誤的回應 —— 全部免費。
這聽起來像是個小變動。其實不是。它改變了雙方在經濟上的理性選擇：
- 供應商 現在有了直接的財務誘因去修好不穩定。每一個三天兩頭出現的 503 都是一筆錯失的銷售，而非免費的午餐。我們發現，採用「只對成功收費」是把可靠性工作拉到路線圖最上方的最大單一力量 —— 當你正在白白放掉那些呼叫帶來的收入時，沒有任何試算表的把戲能讓停機看起來沒事。
- 客戶 可以把重試預算抓得很積極。當暫時性失敗的最壞情況是一次付費呼叫（最終的成功），而不是六次（每次嘗試各付一次）時，一個 5 次重試、指數退避的迴圈根本是理所當然。
- 市場 可以用「每次成功呼叫多少錢」、而非「每次嘗試多少錢」來比較 API。那才是對的單位。如果兩家 API 都標榜「每次呼叫 $0.001」，但一家可用度 99.9%、另一家 95%，在「一律收費」下使用者看到的成本差了 5 倍，在「只對成功收費」下則差了恰好 0%。買家該偏好哪一家不言可喻 —— 而「只對成功收費」讓這件事看得見。
它如何改變你建構 Agent 的方式
1. 重試預算變成免費的
在「一律收費」的計費下，一個暫時性失敗處理器的合理重試預算大約是 1 至 2 次 —— 再多，重複失敗的成本就開始要緊了。在「只對成功收費」下，預算就是「使用者能等多久」。我們經常看到那種 5 次重試、指數退避、加抖動（jittered）的 Agent 迴圈 —— 在舊式計費下這會是魯莽之舉。
2. 樂觀預取變得便宜
一個在「一律收費」下昂貴到無法採用的模式：在使用者還在打字時就投機性地發出一個搜尋呼叫，以防預測的查詢是對的。如果預測錯了，就把結果丟掉。在「只對成功收費」下這很便宜，因為被取消／未使用的呼叫會回傳成功，但你把回應丟掉 —— 所以你為了可預測性與低延遲付出一點小溢價。在「一律收費」下，每次錯誤的預測都是一筆付費呼叫，這讓這個啟發式做法貴到不值得出貨。
3. 冗餘呼叫變成一種可靠性工具
有時最便宜的可靠性策略，就是對兩個不同的 API 各發一個請求，採用先回來的那個，把較慢的丟掉。在「一律收費」下這會讓你的帳單翻倍。在「只對成功收費」下，被丟掉的那次呼叫是免費的（你沒用回應，就沒付錢）。一瞬間，那些原本昂貴而流於抽象的避險策略，就變得實際可行了。
「成功」必須代表什麼
這個模型只有在「成功」毫不含糊時才行得通。我們把它定義得很緊：
- 帶有所載回應結構描述的 HTTP 200 —— 可計費。
- HTTP 200 但回應 body 裡包著一個錯誤 —— 不可計費（這會是個會把整個模型搞垮的漏洞）。
- HTTP 4xx —— 不可計費。這包括 401（驗證）、402（credit 不足）、422（驗證失敗）、404（在某些情境下為找不到）。
- HTTP 5xx —— 不可計費。
- HTTP 429（速率限制）—— 不可計費。
- 在抵達我方邊緣之前的網路錯誤／逾時 —— 不可計費。
對於批次端點（例如一次呼叫帶 25 個 URL 的 URL Extract），只要有任何 URL 成功，整次呼叫就算一次 HTTP 200，按每 URL 費率計費。各別 URL 的 status 欄位告訴呼叫方哪些 URL 失敗了。工作做了；可計費。
為什麼大多數供應商不這麼做
三個原因，按各自重要性排序：
- 計費基礎設施。標準的做法是在 API 閘道處計量，也就是在還不知道回應之前。閘道把一個可計費事件丟進 Kafka，計費系統彙整它，帳單就寄出去。要把計量重新接成在上游服務以狀態碼回應 之後 才觸發，需要的不是 (a) 把閘道耦合到後端健康狀態（製造出新的失敗模式），就是 (b) 寫一條回溯地為失敗呼叫退費的對帳管線。兩者都是實打實的工程工作。
- 習慣。這個模式是由可靠的後端定下來的 —— Twilio、AWS、Stripe。當你的上游在 99.99% 可用度時，它運作得很好。包裝 LLM、爬取網頁，或呼叫緩慢資料夥伴的 API 可靠得多 —— 不對，是不可靠得多，但這個計費模式是從可靠的年代繼承來的，從未更新過。
- 收費。「一律收費」就是錢更多。大多數供應商還沒被迫在這個維度上競爭，因為大多數客戶還不是 Agent 流量，而同步的人類使用者對偶發失敗的容忍度，比他們對閱讀計費模型的容忍度更高。
第一個是真正的工程。第二個和第三個是慣性。隨著 Agent 流量成為 API 消費的多數，兩者都會讓步 —— 而趨勢線顯示，對大多數公開 API 而言，這在 18 個月內就會發生。
身為買家該注意什麼
如果你正在為一個 Agent 工作負載評估資料 API，明確問三個問題：
- 「你們是只對 HTTP 200 收費，還是每次可計費的嘗試都收？」 —— 要求直接回答。別接受「通常」或「視套餐而定」。
- 「HTTP 207／部分成功是怎麼計費的？」 —— 把那個漏洞型答案逼出來。
- 「你們公告的可用度是多少？如果沒達到，SLA 的退費機制是什麼？」 —— 「只對成功收費」是個強訊號，但它不能取代一份實際的 SLA。兩者都該有。
這指向的轉變
AI Agent 改變了它們所觸及的每一個 API 的單位經濟。為 Agent 時代設計的 API 長得不一樣 —— 更簡單的格式、可預測的結構描述、機器友善的驗證、透明的定價 —— 它們的計費模型也長得不一樣。「只對成功收費」是其中較簡單的一項轉變。較難的那項仍在我們前方：當沒有單一一方掌握完整路徑時，要如何替跨供應商的多步驟 Agent 工作流程定價。
眼下，盡你所能向供應商要求「只對成功收費」。打造能善用它的 Agent。而當你在選購 API 時，請用「每次成功呼叫多少錢」、而非「每次嘗試多少錢」來算這筆帳。
常見問題
「只在成功時收費」難道不會誘使供應商把成功誤判成失敗嗎？
理論上會，但反向的壓力更強：開發者是用真實世界裡每次有用呼叫花多少錢來比較 API，而那正是「只對成功收費」所衡量的。一家偷偷把成功重新歸類成失敗的供應商，幾天內就會面對一個怒火中燒的客服佇列與一條公開的評論軌跡。這個市場夠小，會自我修正。
如果我的呼叫只部分成功怎麼辦 —— 例如批次擷取 25 個 URL 裡有 2 個失敗？
兩種合理的模型。(a) 只要有任何 URL 成功，整次呼叫就是 HTTP 200；個別 URL 的失敗回報在各別 URL 的狀態裡。工作確實發生了，所以可計費。(b) 部分成功用 HTTP 207（multi-status）—— 每個 URL 各自計費。我們選了 (a)，因為它讓定價可預測：Agent 知道一次成功的 HTTP 200 代表最壞情況就是公告的 credit 成本。(b) 比較「公平」，但較難用來抓預算。
什麼算是失敗？
我們的規則：明顯是呼叫方的錯的 HTTP 4xx（格式錯誤的 body、缺少驗證、credit 不足）不收費。HTTP 5xx 永不收費 —— 那是我們的問題。我們這一側的網路錯誤與逾時永不收費。速率限制（429）永不收費。唯一會收費的，是帶有公告回應格式的 HTTP 200。
為什麼大多數供應商每次呼叫都收費？
三個原因，多半是歷史因素。(1) 舊式計費系統在 API 閘道處計量，也就是在還不知道回應之前。要把計費接成回溯地依回應狀態觸發，並不容易。(2) 這個模式是 Twilio 與 AWS 在後端可靠的年代定下來的；包裝 LLM 或爬取網頁的 API 可靠得多 —— 不對，是不可靠得多，所以那個假設站不住了。(3) 收費更多。前兩個是藉口；第三個才是真相。
有沒有「一律收費」才合理的情況？
當該呼叫無論結果如何，每次叫用都實打實消耗一筆固定成本時 —— 例如硬體外呼（已送出簡訊）、在邊界上具原子性的變更（DNS 更新），或一個後端無法區分「我們試了但失敗」與「我們做了只是你沒注意到」的服務。對於讀取式的資料 API 與搜尋 API，這個模型並不適用。
本文使用的 API
Sarah Choy 是 API Pick 的 CEO，專注於為 AI Agent 與 LLM 工作流打造可用於正式環境的 API。