Auto-reload and billing recovery
Keep a paid account funded with explicitly authorized extra-credit purchases. Auto-reload has its own money cap and does not raise API key limits.
Choose a pack, threshold and cap
Open Billing while signed in. Auto-reload requires an active, non-complimentary paid subscription within its paid period and a saved card. Choose a current pack, a credit-balance threshold and a monthly money cap, then explicitly authorize the displayed terms. Check that Billing shows the setting enabled. Availability depends on deployment readiness; accounts are never enabled automatically.
A paid subscription scheduled to cancel remains eligible until its paid period ends. Free, expired, past-due and complimentary accounts cannot initiate top-ups. Previously purchased credits do not expire when a subscription ends. A pending checkout is not a settled purchase.
Understand the separate spending controls
| Control | Meaning |
|---|---|
| Balance threshold | A balance below this value can trigger an authorized pack purchase. This differs from the low-balance alert preference. |
| Auto-reload cap | Includes tax and resets on the 1st at 00:00 UTC. Pending purchases reserve cap space. A purchase cannot exceed the remaining cap. |
| Extra-usage cap | Separate limit for enabled metered overage; does not authorize packs. |
| Key / connection cap | Cumulative spending through the credential. Buying credits does not raise it. |
| MCP max_credits / monitor cap | Separate per-call and monitor controls; auto-reload does not override them. |
Your allowance-reset date and the UTC cap month may differ. Use the current figures in Billing, including pending reservations. Invoice creation alone does not prove a credit grant.
Recover from payment problems
| State | Action |
|---|---|
| Saved card required | Save a card in Billing and explicitly enable auto-reload. Never paste payment secrets into chat. |
| Monthly cap reached | Check pending payments and tax. Wait for the UTC reset or deliberately change the cap. |
| Payment needs attention | Auto-reload pauses. Review the invoice/payment link and saved card in Billing; confirm the outcome before enabling again. |
| Purchase pending | Wait or use the pending-payment controls. Do not start a replacement solely because a response was lost. |
| Subscription changed | Refresh Billing and review eligibility. Authorization is bound to its subscription. |
| Still receiving 402 | Check the response reason, funds and credential cap. A funded account can have an exhausted key. |
Disabling prevents new authorized attempts; a payment already in flight can still settle. Cancelling a pending payment is separate and does not promise a refund for a settled purchase. Retain payment IDs and confirm the resulting balance.
Balance signals are not payment authorization
Payment configuration uses the signed-in dashboard, not public API-key endpoints. An agent can inspect permitted balance and receipt information but must not assume a retrieval tool can buy packs or enable auto-reload. Receiving a billing event does not authorize another purchase.