What you’ll learn
- Can I configure TokenLab auto recharge with an API?
- What are the default trigger and restore amounts?
- What happens if my card is declined during a recharge?
- Does TokenLab auto recharge retry after a failed payment?
- Is TokenLab auto recharge enabled by default?
A production agent can burn through a credit balance in minutes, and an empty balance turns every request into a hard stop. TokenLab auto recharge is the organization-level setting we built to prevent that failure mode: it buys more credit when your balance drops below a threshold you set. When configured well, an agent loop, a batch job, or a traffic spike keeps running instead of hitting an empty-balance wall. Here is how the trigger logic works, what happens when a card declines mid-recharge, the real minimum and maximum amounts, and how to turn it on from the billing dashboard.
Key Takeaways
- Auto recharge is opt-in and configured per organization from the billing dashboard by an admin or owner. It is not on by default.
- Default settings are trigger amount $5, restore amount $30, and monthly recharge limit $300. The minimum recharge-related amount is $1 and the maximum monthly limit is $10,000.
- On payment failure, we do not silently retry. We disable auto recharge, mark the transaction
payment_failedorrequires_action, and send a failure email. - There is no public API or webhook for configuring or monitoring auto recharge today. Configuration happens in the dashboard; monitoring happens through dashboard status, email, and transaction history.
- A saved Stripe payment method is required before you can enable auto recharge at all.
How to Turn On TokenLab Auto Recharge and Size Your Thresholds
- Sign in as an org admin or owner and open the billing dashboard.
- Add a payment method if you have not already. Auto recharge cannot be enabled without a saved Stripe payment method on file.
- Set
When balance drops below(the trigger amount). This is the balance level that fires a top-up. - Set
Restore balance to(the restore amount). It must be greater than the trigger amount; it is the balance you land on after a recharge. - Set a monthly recharge limit, or leave it enabled with enough headroom to cover at least one recharge cycle.
- Save and confirm auto recharge is active. The dashboard will show its current status (active, paused, or disabled).
If you do not customize these fields, TokenLab applies defaults: trigger $5, restore $30, monthly limit $300. Those defaults suit a low-volume workspace testing the API. They are almost certainly too low for a production agent or a customer-facing chatbot. Size them against your actual model mix, covered next.
The right trigger and restore amounts depend on which models you call, since per-token costs vary sharply across TokenLab's catalog. Set your restore amount too low relative to your burn rate, and you can hit the trigger again before the previous recharge has time to clear.
| Model | Provider | Input ($/MTok) | Output ($/MTok) | Context window | Source | Observed at |
|---|---|---|---|---|---|---|
| Claude Sonnet 5 | Anthropic | $2.00 | $10.00 | 1,000,000 | TokenLab live pricing snapshot | 2026-07-09 |
| GPT-5.5 | OpenAI | $5.00 | $30.00 | 1,050,000 | TokenLab live pricing snapshot | 2026-07-09 |
| Gemini 3.5 Flash | $1.50 | $9.00 | 1,048,576 | TokenLab live pricing snapshot | 2026-07-09 | |
| DeepSeek V4 Flash | DeepSeek | $0.09 | $0.18 | 1,048,576 | TokenLab live pricing snapshot | 2026-07-09 |
| GLM-5.2 | Z.ai | $0.70 | $2.20 | 1,048,576 | TokenLab live pricing snapshot | 2026-07-09 |
A pipeline running mostly on DeepSeek V4 Flash for drafting with GPT-5.5 for final output burns credit at a very different rate than one running entirely on GPT-5.5. For example, a GPT-5.5-heavy week will trigger recharges far more often than a DeepSeek V4 Flash-heavy week. Each recharge counts against your monthly limit. We recommend checking your actual usage mix before locking in a threshold. For a full rate comparison across the catalog, see the pricing comparison page.
How the Trigger Logic Actually Works
Auto recharge does not poll your balance on a fixed timer. We check balance after every settlement and compare it against your configured trigger amount. If the post-settlement balance is below the trigger, a recharge attempt starts.
A trigger is skipped (not fired) when any of the following is true:
- The current balance is already above the trigger amount.
- Another auto recharge for the organization is already pending.
- A trigger lock is active (prevents duplicate recharges firing on rapid consecutive settlements).
- No payment method is saved on the account.
- Firing this recharge would exceed the monthly recharge limit.
If the monthly limit would be exceeded, we pause auto recharge and record lastFailureCode: \"monthly_limit_reached\". This is a deliberate stop, not a bug. It protects you from runaway monthly spend if your monthly limit is set too low for your actual usage. If you see this status, raise your monthly limit up to the $10,000 cap or re-enable manually after reviewing why the limit was hit.
When a recharge does fire, we create a Stripe invoice in USD and charge it automatically against your saved payment method.
What Happens When Your Card Is Declined During TokenLab Auto Recharge?
This is the question that determines whether you trust auto recharge with production uptime. The billing implementation answers it directly.
On successful payment, we credit your organization balance once and mark the transaction completed. We store the invoice or receipt URL when available, increment your monthly spent total, keep auto recharge active for next time, and send a payment success email.
On payment failure or a required customer action (for example, 3D Secure verification), we mark the transaction failed. We disable auto recharge, set the status to payment_failed or requires_action, record the failure details, and send a payment failure email.
That last point matters more than a retry count would. We do not attempt to silently retry a declined card. We do not leave auto recharge quietly active while failing in the background. It fails closed: the feature turns itself off, and you get an email telling you why. Your requests still stop working once the balance hits zero, but you will not be left guessing whether auto recharge is covering you when it is not.
What this means for your operational setup:
- Treat the payment failure email as an actionable alert, not a notification to skim. It means auto recharge is now off until you fix the payment method and re-enable it from the dashboard.
- Keep your saved payment method current. An expiring card is the most likely cause of a
payment_failedstate, and there is no automatic fallback to a secondary card in this implementation. - If uptime is critical, do not rely solely on the email. Build an independent balance check below so a missed or filtered email does not turn into an undetected outage.
Is There an API or Webhook for TokenLab Auto Recharge?
Not currently. Auto recharge configuration (trigger amount, restore amount, monthly limit, payment method) is dashboard-only for org admins and owners. There is no documented public API endpoint for programmatically setting these thresholds, and no documented public webhook that fires on trigger, success, or failure events.
The customer-facing monitoring surfaces that do exist are:
- Dashboard status. Shows whether auto recharge is active, paused, or disabled, and the last failure code if applicable.
- Email notifications. Low-balance warnings and payment success or failure emails.
- Transaction history. A record of each recharge attempt, its outcome, and associated invoice or receipt links when available.
If you need programmatic monitoring for a production system, the practical workaround today is a scheduled job that checks your organization balance through whatever authenticated read access your dashboard session provides. Alert your team if the balance drops below a second, lower threshold than your auto recharge trigger. This gives you an independent signal even if auto recharge itself gets disabled after a card failure. Do not build integration code against an assumed endpoint or payload shape. If TokenLab documents a billing API or webhook, verify the exact contract in the API reference before wiring it into an alerting pipeline.
Minimum, Maximum, and Default Amounts
| Field | Minimum | Maximum | Default | Notes |
|---|---|---|---|---|
Trigger amount (balance drops below) |
$1 | Below restore amount | $5 | Must stay lower than the restore amount |
Restore amount (restore balance to) |
$1 | Bounded by monthly limit | $30 | Must be greater than the trigger amount |
| Monthly recharge limit | Must cover one recharge cycle | $10,000 | $300 | Recharges pause with monthly_limit_reached once this is hit |
Source: TokenLab billing dashboard and auto recharge implementation, /dashboard/billing, observed 2026-07-09.
If you are running a production workload with real burst risk, the $300 default monthly limit is often too conservative. A single afternoon of image or video generation, or a busy day of agent tool calls, can approach that ceiling fast. Raise it deliberately after estimating your model mix and typical daily spend, not after you get paused mid-workload.
Who Should Turn This On, and What to Check Before You Rely on It
Auto recharge is not necessary for every workspace. If usage is small and predictable, manual top-ups work fine. Configure it if any of the following apply:
- Autonomous or semi-autonomous agents. Agent loops running on models like Claude Sonnet 5 or Kimi K2.7 Code can consume credits unevenly. For example, a stuck loop burns through balance faster than a human is likely to notice.
- Customer-facing chatbots. Support and product chatbots see traffic that scales with your own product usage. A weekend spike should not become a Monday outage.
- Generation workloads run in bursts. Image and video jobs (Nano Banana Pro, Seedance, Veo 3) cluster around launches or content batches. A single rendering session can outspend a typical week.
- Scheduled batch jobs. Overnight or weekly pipelines are exactly where a mid-run balance failure is expensive to diagnose and rerun.
| Step | What to check | Why it matters |
|---|---|---|
| Confirm payment method is current | Card not expired, verified in dashboard | Recharge cannot fire without a valid saved payment method |
| Set trigger amount above your peak daily burn | Base it on your busiest day, not your average | Too low, and a spike can drain balance before the top-up lands |
| Set restore amount above weekly spend | Use the model pricing table above to estimate | A GPT-5.5-heavy week costs far more than a DeepSeek V4 Flash-heavy one |
| Set monthly limit with real headroom | Default $300 is often too low for production | Hitting the limit pauses auto recharge with monthly_limit_reached |
| Treat failure emails as alerts | Route payment failure emails to an on-call channel | Auto recharge disables itself on failure; nothing else will tell you |
| Add independent balance monitoring | Poll balance on a schedule outside auto recharge's own trigger | No public webhook exists yet; do not rely on dashboard-only visibility |
| Review usage weekly | Check consumption by model and by project | Auto recharge removes outage risk, not cost visibility |
For model cost comparisons to inform your thresholds, see the pricing comparison page. For shifting non-critical calls to cheaper models like DeepSeek V4 Flash or Gemini 3.5 Flash, see the model rankings page.
Auto recharge is a safety net, not a blank check. It solves one specific failure mode: running out of credit mid-workload. It does not manage your budget, and the monthly limit exists precisely so it does not. Teams that get the most value from it pair a realistic restore amount with a monthly limit that reflects actual usage. They also route failure emails somewhere a human will actually see them, not a shared inbox that gets ignored.
Limitations and considerations:
- Fee structure. Whether auto recharge invoices carry any processing fee beyond the credit amount is not confirmed in TokenLab's published billing documentation. Check your Stripe invoice line items or billing terms directly.
- Processing latency. The time between a triggered recharge and the new balance reflecting in your account has not been benchmarked here. If a workload has a hard deadline, test with a manual top-up first and observe dashboard timing before relying on auto recharge for a time-sensitive spike.
- Programmatic access. No public API or webhook for auto recharge configuration or events is documented today. If TokenLab adds one, verify the exact endpoint and payload in the official API reference before building against it.
FAQ
Can I configure TokenLab auto recharge with an API?
Not currently. Auto recharge is configured through the billing dashboard by an org admin or owner. There is no documented public API endpoint for setting trigger, restore, or monthly limit values programmatically.
What are the default trigger and restore amounts?
Defaults are trigger $5, restore $30, monthly limit $300. The minimum for trigger, restore, and related amounts is $1. The maximum monthly recharge limit is $10,000.
What happens if my card is declined during a recharge?
We mark the transaction failed, disable auto recharge, set status to payment_failed or requires_action, record the failure details, and send a payment failure email. We do not silently retry.
Does TokenLab auto recharge retry after a failed payment?
No automatic retry is built into the current implementation. Instead, the feature disables itself and notifies you by email so you can fix the payment method and re-enable it manually.
Is TokenLab auto recharge enabled by default?
No. It is opt-in per organization and requires a saved payment method before it can be enabled.
Configure auto recharge from the billing dashboard, or compare model pricing first on the models page to size your thresholds correctly.
Sources
Prices checked 2026-07-07
- TokenLab billing dashboard and auto recharge implementationSources checked 2026-07-09
- TokenLab model directorySources checked 2026-07-07



