A prepaid wallet in BDT
Your organization has a wallet in Bangladeshi taka (BDT). You add money to it with a top-up, paid through EPS, and every request spends from it. There is no invoice at the end of the month for API usage: the money is spent as you go, and when the wallet cannot cover a request, the request is refused with 402 insufficient_balance.
Amounts are exact. Internally the platform counts money in micro-taka (1 BDT = 1,000,000 micro-taka) with whole-number arithmetic, and rounds only when it calculates a request's cost.
What a request costs
Each model has a price per 1M tokens, in BDT, for three kinds of tokens:
- Input tokens: your prompt, excluding any cached tokens.
- Cached input tokens: prompt tokens the provider served from its cache, when the provider reports them. If a model has no cached price, they bill at the input price.
- Output tokens: what the model generates.
For each kind, the cost is tokens x price / 1,000,000, rounded up to the next micro-taka, and the three parts are added. If any token is billed, the minimum charge is 1 micro-taka. Your organization's tier can give a discount on the prices before this calculation.
Worked example with illustrative prices of 60 BDT per 1M input tokens and 120 BDT per 1M output tokens: 1,000 input tokens cost 0.06 BDT, 500 output tokens cost 0.06 BDT, so the request costs 0.12 BDT.
The authoritative token counts come from the model provider's usage report, and they are returned to you in the response usage field. The price used is a snapshot taken when the request starts, so a price change never affects a request that is already running.
Reserve, then settle or release
Because the real cost is only known after the model has answered, the gateway uses a hold:
- Reserve. Before calling the model, the gateway estimates the largest cost the request could have: the estimated input tokens (with a safety margin, 20% by default) plus the full
max_tokensof output, at the current prices. It sets that amount aside as a hold on the wallet. If the wallet cannot cover it, you get402 insufficient_balanceand the provider is never called. - Run. The request goes to the provider.
- Settle. When it ends, the hold is replaced by the real cost, and any unused part of the hold returns to your available balance.
- Release. If the request fails before any output was produced, the hold is released and you are not charged.
The hold is a reservation, not a charge. It reduces your available balance while the request runs and disappears when the request ends. A hold that is somehow left behind expires on its own (after 15 minutes by default, longer than the request itself can run), and expiry never charges you.
Practical consequences:
- Set
max_tokensto what you need. A largemax_tokensmakes a large hold, and a small wallet can fail a request that would have been cheap. - The hold estimate is deliberately pessimistic, so the check can refuse a request when the balance is only just enough.
Failures, cancellations and billing
| What happened | What you pay |
|---|---|
Rejected before the provider was called (4xx, 402, rate limit) | Nothing |
| Provider error or timeout before any output | Nothing |
| Request completes | The real cost from the usage report |
| Streaming request cancelled or cut after output started | The input plus the output generated so far (an estimate), billed |
| Streaming request cancelled before the first output | Nothing |
| Stream fails after output started | The input plus the output generated so far, billed |
See Streaming for the details of cancellation.
Monthly caps and unpaid usage
A key can have a monthly spending cap. The month is the calendar month in Asia/Dhaka time. See API keys.
If a request turns out to cost more than the balance can cover, only the available balance is charged and the rest is recorded as uncollected usage against the organization. When uncollected usage over a rolling 30 days passes a limit set by the operator, new requests are refused with 403 org_blocked until support clears it. Topping up does not clear it automatically.
Top-ups and refunds
Top up from the app. Payment methods are the local methods offered through EPS, and the amount is credited to the wallet when the payment is confirmed. The refund rules are in the refund policy, which is a draft pending legal review: see the refund policy.
Privacy of request content
The gateway meters tokens and does not write prompts or completions to its logs or database. What is recorded per request is metadata: the time, the model, token counts, cost, status and request id. The idempotency feature serves replays from memory for this reason: see Idempotency.