API Prepaid Credits Expire: Buy for the Next Workload, Not the Next Year

Prepaid API credit is a declining balance, not a savings account.

OpenAI and Anthropic both document a one-year expiration for purchased API credits. Both also say those purchases are non-refundable, and neither offers an extension for unused purchased credit. The safe buy is therefore the amount you expect to consume soon, backed by controlled auto-reload—not an annual budget transferred on day one.

This article covers API billing only. Claude Pro and Max subscriptions use a different billing system; their optional usage credits follow separate rules covered in Claude Pro limits, Max, and usage credits.

The official pages reviewed on 2026-08-28 were:

• OpenAI: Setting up and managing prepaid API billing and Service Credit Terms
• Anthropic: How do I pay for my Claude API usage?

Recheck them before a large purchase. Eligibility, trust-tier limits, and billing interfaces can change even when the expiration rule does not.

The two wallets look similar, but the controls differ

	OpenAI API	Anthropic API
Billing model	Prepaid credits, then usage deducts from the balance	Prepaid usage credits, then successful requests deduct from the balance
Purchased-credit expiration	One year after purchase	One year after purchase
Refund or extension	Non-refundable; expiration cannot be extended	Non-refundable; expiration cannot be extended
Auto-reload controls	Trigger balance, reload-to amount, monthly reload limit	Trigger balance, reload amount, monthly reload limit
Published starting purchase	$5 minimum; $10 default	Current help article does not publish a universal minimum
Other constraints	Purchase maximum depends on trust tier; rate limits remain separate	Account usage limits and rate limits remain separate

Do not transfer one vendor’s minimum, cap, or terminology to the other. The shared one-year deadline does not make the wallets interchangeable.

OpenAI: use the live prepaid billing page, not a guessed article ID

The current Help Center permalink is:

https://help.openai.com/en/articles/8264644-setting-up-and-managing-prepaid-api-billing

That page documents:

• a $5 minimum initial purchase and $10 default;
• a maximum purchase that varies with the account’s trust tier;
• auto-reload enabled by default during setup;
• three auto-reload settings: the balance that triggers a reload, the balance to restore to, and a monthly reload limit;
• expiration one year after purchase, with no refund or extension;
• possible delays before a newly purchased balance appears;
• removal of credits associated with a refunded or disputed payment; and
• separate API usage and rate limits that a larger balance does not raise.

OpenAI’s Service Credit Terms, updated 2026-01-01, independently state that service credits expire one year after purchase or issuance unless otherwise specified at purchase. They also say service credits are non-refundable and have no cash value.

Two practical consequences follow:

1. A large balance does not buy higher throughput. Trust-tier and rate-limit controls still apply.
2. Every purchase has its own age. Auto-reload keeps adding credit; it does not reset older credit’s expiration date.

OpenAI says purchased credits are used before granted credits. If your account also shows promotional or granted credit, use the expiration date and conditions displayed for that grant rather than assuming it follows the purchased-credit order or term.

Anthropic: successful API usage draws from prepaid credits

Anthropic’s current API billing article says API and Workbench usage is funded through prepaid usage credits. The balance is charged when a request completes successfully; failed requests are not billed as completed usage.

In Console → Settings → Billing, an organization can buy credit immediately or configure auto-reload. Anthropic describes:

• a balance threshold that triggers reload;
• a reload amount; and
• a monthly reload limit.

The same article states that purchased credits expire one year after purchase and cannot be extended or refunded.

Anthropic does not publish one universal minimum purchase or wallet cap on that page. Treat the amount and controls shown inside your own Console as the current offer for that organization. Do not copy OpenAI’s $5 minimum into an Anthropic purchasing policy.

Size the first purchase from measured burn

Let:

• B = average monthly API spend over a representative period;
• P = the next known workload, including a safety margin; and
• H = the number of months you can forecast with reasonable confidence.

A conservative initial purchase is the larger of the next workload and roughly one month of normal burn:

Initial balance = max(P, B)

If usage is stable and interruption would be costly, moving toward 2 × B may be reasonable. A full year’s theoretical spend is usually not.

Example: a service has averaged $80 per month and has a known $55 batch next week.

• A one-month starting balance is about $80.
• A two-month cushion is about $160.
• The mathematical twelve-month spend is $960, but buying $960 today converts a forecast into a non-refundable balance with a one-year clock.

The one-year ceiling is not a target. It is the last date the balance can remain useful.

Check the arithmetic on “bulk savings”

Neither reviewed API billing page offers a discount merely for parking more cash in the prepaid wallet. Unless a separate, account-specific agreement says otherwise, the financial trade is liquidity versus interruption risk.

At a steady $80 per month, a $500 purchase lasts about 6.25 months. If the project pauses after four months, roughly $320 has been consumed and $180 remains exposed to expiration. The problem is not the calendar alone; it is forecast error.

This gets worse for:

• prototypes with no production launch date;
• seasonal jobs;
• workloads that may switch models or vendors;
• clients who have not signed the next phase; and
• teams that prepay from a budget that expires internally sooner than the vendor balance.

Buy against committed usage, not optimistic backlog.

Configure auto-reload as a circuit breaker

Auto-reload should protect continuity without turning an incident into an unlimited series of charges.

Using the same $80 monthly burn example:

1. Set the trigger near one week of normal spend: about $20.
2. Restore the balance to about one month of normal spend: around $80.
3. Set a monthly reload limit aligned with an approved budget, for example $100, after allowing for known spikes.
4. Add separate provider-side project budgets, usage alerts, and rate limits where available.

Those numbers are an editorial example, not vendor defaults. Use your own burn rate and incident tolerance.

The monthly auto-reload limit matters because threshold-based reload can fire repeatedly during a runaway workload. It does not replace application controls:

• cap retries and concurrency;
• prevent untrusted users from selecting unbounded workloads;
• keep production and experiments in separate projects or workspaces where possible;
• alert on spend velocity, not only end-of-month totals; and
• investigate unexpected usage before raising the reload limit.

Renewal and exit checklist

Review the wallet monthly:

• current balance;
• oldest known purchase date;
• 30- and 90-day burn;
• auto-reload trigger, amount, and monthly cap;
• dormant projects and exposed keys; and
• any granted credit with a separately displayed expiration.

Before shutting down OpenAI pay-as-you-go, disable auto-reload. OpenAI’s cancellation article says remaining purchased credits stay on the account until used or expired and remain non-refundable. Canceling the payment plan does not cash them out.

For either provider, a clean exit means:

1. stop new deployments and scheduled jobs;
2. rotate or revoke unused API keys;
3. disable auto-reload;
4. consume only legitimate remaining workload—do not invent traffic merely to burn credit;
5. export invoices and usage records; and
6. record the oldest purchase date so the team knows when unused value disappears.

Buy-side rule

Treat API prepaid credit as short-horizon operating inventory:

• start around the next committed workload or one month of measured burn;
• use a bounded auto-reload for continuity;
• keep a monthly reload ceiling;
• do not assume a large balance increases rate limits; and
• never use the one-year expiration window as a reason to prepay one year’s forecast.

The goal is not to reach zero every week. It is to keep enough balance for real work without turning uncertainty into an expiring, non-refundable asset.