生產環境中的 Agent 可能在幾分鐘內就燒光額度,而餘額歸零會導致每一次請求都直接中斷。TokenLab 自動加值(Auto Recharge)是我們為防止此類故障模式而建立的組織級設定:當您的餘額低於設定的門檻時,它會自動購買更多額度。若設定得當,Agent 迴圈、批次作業或流量高峰就能持續運行,而不會撞上餘額歸零的牆。以下說明觸發邏輯的運作方式、信用卡在加值過程中被拒絕時會發生什麼事、實際的最低與最高金額限制,以及如何從帳務儀表板啟用此功能。
重點摘要
- 自動加值功能需由管理員或擁有者從帳務儀表板針對各組織手動啟用。預設為關閉狀態。
- 預設設定為:觸發金額 $5、恢復金額 $30、每月加值上限 $300。與加值相關的最低金額為 $1,每月最高上限為 $10,000。
- 若付款失敗,我們不會進行靜默重試。我們會停用自動加值,將交易標記為
payment_failed或requires_action,並發送失敗通知郵件。 - 目前沒有用於設定或監控自動加值的公開 API 或 Webhook。設定需透過儀表板進行;監控則透過儀表板狀態、郵件及交易紀錄來完成。
- 啟用自動加值前,必須先儲存 Stripe 付款方式。
如何啟用 TokenLab 自動加值並設定您的門檻
- 以組織管理員或擁有者身分登入,並開啟帳務儀表板。
- 若尚未新增付款方式,請先新增。若未儲存 Stripe 付款方式,則無法啟用自動加值。
- 設定
When balance drops below(觸發金額)。這是觸發加值的餘額門檻。 - 設定
Restore balance to(恢復金額)。此金額必須大於觸發金額;這是加值後您會擁有的餘額。 - 設定每月加值上限,或確保其額度足以涵蓋至少一個加值週期。
- 儲存並確認自動加值已啟用。儀表板將顯示其目前狀態(啟用中、暫停或已停用)。
如果您未自訂這些欄位,TokenLab 將套用預設值:觸發 $5、恢復 $30、每月上限 $300。這些預設值適合測試 API 的低流量工作區,但對於生產環境的 Agent 或面向客戶的聊天機器人來說,這些數值幾乎肯定太低。請根據您實際使用的模型組合來調整這些數值,詳情如下。
正確的觸發與恢復金額取決於您呼叫的模型,因為 TokenLab 目錄中各模型的每 Token 成本差異極大。若您的恢復金額相對於消耗率設定得太低,您可能會在上次加值尚未結算完成前,就再次觸發加值。
| 模型 | 供應商 | 輸入 ($/MTok) | 輸出 ($/MTok) | Context window | 來源 | 觀察日期 |
|---|---|---|---|---|---|---|
| Claude Sonnet 5 | Anthropic | $2.00 | $10.00 | 1,000,000 | TokenLab 即時定價快照 | 2026-07-09 |
| GPT-5.5 | OpenAI | $5.00 | $30.00 | 1,050,000 | TokenLab 即時定價快照 | 2026-07-09 |
| Gemini 3.5 Flash | $1.50 | $9.00 | 1,048,576 | TokenLab 即時定價快照 | 2026-07-09 | |
| DeepSeek V4 Flash | DeepSeek | $0.09 | $0.18 | 1,048,576 | TokenLab 即時定價快照 | 2026-07-09 |
| GLM-5.2 | Z.ai | $0.70 | $2.20 | 1,048,576 | TokenLab 即時定價快照 | 2026-07-09 |
使用 DeepSeek V4 Flash 進行草稿撰寫並以 GPT-5.5 進行最終輸出的管線,其額度消耗速度與完全使用 GPT-5.5 的管線截然不同。例如,GPT-5.5 使用量大的一週,觸發加值的頻率會遠高於 DeepSeek V4 Flash 使用量大的一週。每次加值都會計入您的每月上限。我們建議在鎖定門檻前先檢查您的實際使用組合。如需查看目錄中完整的費率比較,請參閱定價比較頁面。
觸發邏輯的實際運作方式
自動加值並非透過固定計時器來輪詢您的餘額。我們會在每次結算後檢查餘額,並將其與您設定的觸發金額進行比較。如果結算後的餘額低於觸發門檻,就會啟動加值嘗試。
若符合下列任一情況,觸發將會被跳過(不會執行):
- 目前餘額已高於觸發金額。
- 該組織已有另一筆自動加值正在處理中。
- 觸發鎖定(Trigger lock)處於啟用狀態(防止在快速連續結算時觸發重複加值)。
- 帳戶中未儲存付款方式。
- 執行此加值將會超過每月加值上限。
如果將會超過每月上限,我們會暫停自動加值並記錄 lastFailureCode: "monthly_limit_reached"。這是一個刻意的停止,而非錯誤。如果您的每月上限設定得低於實際使用量,這能保護您免於失控的每月支出。如果您看到此狀態,請將每月上限提高至 $10,000 的上限,或在檢視為何達到上限後手動重新啟用。
當加值觸發時,我們會建立一筆美元計價的 Stripe 發票,並自動向您儲存的付款方式扣款。
當 TokenLab 自動加值期間信用卡被拒絕時會發生什麼事?
這是一個決定您是否信任自動加值以維持生產環境正常運作的關鍵問題。帳務實作直接回答了這個問題。
付款成功時,我們會將額度存入您的組織餘額,並將交易標記為完成。我們會在可用時儲存發票或收據 URL,增加您的每月支出總額,保持自動加值為下次啟用狀態,並發送付款成功郵件。
若付款失敗或需要客戶採取行動(例如 3D Secure 驗證),我們會將交易標記為失敗。我們會停用自動加值,將狀態設為 payment_failed 或 requires_action,記錄失敗詳情,並發送付款失敗郵件。
最後一點比重試次數更重要。我們不會嘗試靜默重試被拒絕的信用卡。我們不會在背景失敗的同時讓自動加值悄悄保持啟用。它會以「失敗關閉」模式運作:該功能會自行關閉,並發送郵件告知您原因。當餘額歸零時,您的請求仍會停止運作,但您不會在自動加值未發揮作用時還被蒙在鼓裡。
這對您的營運設定意味著:
- 將付款失敗郵件視為可執行的警報,而非僅供瀏覽的通知。這意味著在您修復付款方式並從儀表板重新啟用之前,自動加值功能已關閉。
- 保持您儲存的付款方式為最新狀態。過期的信用卡是導致
payment_failed狀態最常見的原因,且此實作中沒有自動切換至次要信用卡的功能。 - 如果正常運作時間至關重要,請勿僅依賴郵件。請建立獨立的餘額檢查機制,以免漏掉或被過濾的郵件演變成未被察覺的停機事故。
是否有 TokenLab 自動加值的 API 或 Webhook?
目前沒有。自動加值設定(觸發金額、恢復金額、每月上限、付款方式)僅供組織管理員和擁有者透過儀表板進行。目前沒有記錄在案的公開 API 端點可用於程式化設定這些門檻,也沒有在觸發、成功或失敗事件時執行的公開 Webhook。
目前存在的客戶端監控介面包括:
- 儀表板狀態: 顯示自動加值是啟用、暫停還是已停用,以及適用的最後失敗代碼。
- 郵件通知: 低餘額警告以及付款成功或失敗的郵件。
- 交易紀錄: 每次加值嘗試的紀錄、結果,以及可用時的相關發票或收據連結。
如果您需要對生產系統進行程式化監控,目前實用的替代方案是編排一個排程作業,透過您的儀表板工作階段所提供的任何已驗證讀取權限來檢查組織餘額。如果餘額低於比自動加值觸發門檻更低的第二門檻,請通知您的團隊。即使自動加值在信用卡失敗後被停用,這也能為您提供獨立的訊號。請勿針對假設的端點或負載格式編寫整合程式碼。如果 TokenLab 發布了帳務 API 或 Webhook 文件,請在將其納入警報管線前,先在 API 參考文件中驗證確切的合約。
最低、最高與預設金額
| 欄位 | 最低 | 最高 | 預設 | 備註 |
|---|---|---|---|---|
觸發金額 (balance drops below) |
$1 | 低於恢復金額 | $5 | 必須低於恢復金額 |
恢復金額 (restore balance to) |
$1 | 受每月上限限制 | $30 | 必須高於觸發金額 |
| 每月加值上限 | 必須涵蓋一個加值週期 | $10,000 | $300 | 達到此上限後,加值會以 monthly_limit_reached 暫停 |
來源:TokenLab 帳務儀表板與自動加值實作,/dashboard/billing,觀察日期 2026-07-09。
如果您正在執行具有實際爆發風險的生產工作負載,$300 的每月預設上限通常過於保守。一個下午的圖像或影片生成,或是繁忙的 Agent 工具呼叫日,很快就會接近該上限。請在評估您的模型組合與典型每日支出後謹慎提高上限,而不是等到工作負載中途被暫停才處理。
誰應該啟用此功能,以及在依賴它之前該檢查什麼?
並非每個工作區都需要自動加值。如果使用量小且可預測,手動加值即可。若符合以下情況,請設定此功能:
- 自主或半自主 Agent: 在 Claude Sonnet 5 或 Kimi K2.7 Code 等模型上運行的 Agent 迴圈可能會不均勻地消耗額度。例如,卡住的迴圈消耗餘額的速度比人類可能察覺到的還要快。
- 面向客戶的聊天機器人: 支援與產品聊天機器人的流量會隨您自身產品的使用量而擴展。週末的流量高峰不應變成週一的停機事故。
- 爆發式生成工作負載: 圖像與影片作業(Nano Banana Pro、Seedance、Veo 3)通常集中在發布或內容批次處理期間。單次渲染工作消耗的額度可能超過典型的一週用量。
- 排程批次作業: 過夜或每週執行的管線,正是中途餘額不足導致診斷與重新執行成本高昂的地方。
| 步驟 | 檢查項目 | 重要性 |
|---|---|---|
| 確認付款方式為最新 | 信用卡未過期,並在儀表板驗證 | 若無有效的儲存付款方式,加值無法執行 |
| 設定高於每日尖峰消耗的觸發金額 | 基於最繁忙的一天,而非平均值 | 若設定太低,流量高峰可能會在加值生效前耗盡餘額 |
| 設定高於每週支出的恢復金額 | 使用上述模型定價表進行估算 | GPT-5.5 密集的一週成本遠高於 DeepSeek V4 Flash 密集的一週 |
| 設定具有實際空間的每月上限 | 預設 $300 對生產環境來說通常太低 | 達到上限會以 monthly_limit_reached 暫停自動加值 |
| 將失敗郵件視為警報 | 將付款失敗郵件路由至值班頻道 | 自動加值失敗時會自行停用;沒有其他機制會通知您 |
| 新增獨立的餘額監控 | 在自動加值觸發門檻之外定期輪詢餘額 | 目前尚無公開 Webhook;請勿僅依賴儀表板的可視性 |
| 每週檢視使用量 | 檢查各模型與各專案的消耗量 | 自動加值消除了停機風險,而非成本可視性 |
如需參考模型成本比較以設定您的門檻,請參閱定價比較頁面。若要將非關鍵呼叫轉移至 DeepSeek V4 Flash 或 Gemini 3.5 Flash 等更便宜的模型,請參閱模型排名頁面。
自動加值是安全網,而非空白支票。它解決了一個特定的故障模式:工作負載中途額度耗盡。它無法管理您的預算,而每月上限的存在正是為了確保它不會失控。能從中獲得最大價值的團隊,會將實際的恢復金額與反映實際使用量的每月上限結合使用。他們還會將失敗郵件路由至人類真正會看到的地方,而不是被忽略的共用收件匣。
限制與考量:
- 費用結構: TokenLab 公布的帳務文件中,未確認自動加值發票是否包含額度金額以外的處理費。請直接檢查您的 Stripe 發票明細項目或帳務條款。
- 處理延遲: 觸發加值與新餘額反映在您的帳戶之間的時間,未在此進行基準測試。如果工作負載有嚴格截止期限,請先進行手動加值測試,並觀察儀表板的時間差,再依賴自動加值處理時間敏感的流量高峰。
- 程式化存取: 目前沒有記錄在案的公開 API 或 Webhook 用於自動加值設定或事件。如果 TokenLab 新增了此功能,請在進行開發前,先在官方 API 參考文件中驗證確切的端點與負載。
常見問題 (FAQ)
我可以使用 API 設定 TokenLab 自動加值嗎?
目前不行。自動加值由組織管理員或擁有者透過帳務儀表板進行設定。目前沒有記錄在案的公開 API 端點可用於程式化設定觸發、恢復或每月上限值。
預設的觸發與恢復金額是多少?
預設值為觸發 $5、恢復 $30、每月上限 $300。觸發、恢復及相關金額的最小值為 $1。每月最高加值上限為 $10,000。
如果我的信用卡在加值期間被拒絕會發生什麼事?
我們會將交易標記為失敗、停用自動加值、將狀態設為 payment_failed 或 requires_action、記錄失敗詳情,並發送付款失敗郵件。我們不會靜默重試。
TokenLab 自動加值在付款失敗後會重試嗎?
目前的實作中沒有內建自動重試機制。相反地,該功能會自行停用並透過郵件通知您,以便您修復付款方式並手動重新啟用。
TokenLab 自動加值是預設啟用的嗎?
不是。此功能需由各組織選擇啟用,且在啟用前必須先儲存付款方式。
來源
價格觀測於 2026-07-07
- TokenLab billing dashboard and auto recharge implementation觀測於 2026-07-09
- TokenLab model directory觀測於 2026-07-07



