Skip to main content
TICON AI
Sign up

How prepaid billing and holds work

What happens to your wallet when you send an API request: the hold placed first, how it is settled, and what happens when a request fails.

By [[PLACEHOLDER: author name]] · · 5 min read

TICON AI is prepaid, so before a request runs the gateway sets aside the largest amount it could cost from your wallet. This reserved amount is called a hold. When the request finishes, you are charged for the tokens actually used, and the unused part of the hold is released back to your available balance.

TICON AI is prepaid. You add money to a wallet in Bangladeshi taka, and every API request is paid for from that wallet. There is no invoice at the end of the month and no card on file that we can charge. This post explains what happens to your balance when you send a request, and why a part of it is briefly set aside before the request runs.

This describes how the system is designed to behave. The platform is currently running on a staging environment with placeholder prices and a mock upstream, so no real provider is behind any model yet. [[PLACEHOLDER: review this note and remove it when real providers are connected]]

Balance, held and available

Your wallet shows three numbers. The balance is the money you have added, minus what you have spent. Held is the part of the balance that is reserved for requests that are still running. Available is the balance minus held, and it is the number that decides whether a new request is allowed to start.

All amounts are stored as whole numbers of micro-taka, one millionth of a taka. Per-token prices are tiny, so counting in whole micro-taka means nothing is rounded away on small requests. We never use floating-point numbers for money. Amounts are only rounded at the edges, for example when a figure is displayed in taka.

Why a hold is placed before the request

A language model call has an unknown final cost until it finishes: you only learn how many tokens were produced at the end. If the gateway waited until then to check your balance, many requests running at once could together spend more than the wallet contains. To avoid that, the gateway reserves money first. This reservation is called a hold.

The size of the hold is an upper bound on what the request can cost:

  • the estimated number of input tokens, multiplied by a safety factor (1.2 by default), priced at the model's input price;
  • plus the largest number of output tokens the request may produce, which is the smaller of the max_tokens you sent (or the model's default) and the model's maximum output, priced at the output price.

The hold is taken in one atomic database statement that only succeeds if the available amount covers it. If it does not, the gateway answers HTTP 402 with the code insufficient_balance. In that case the upstream model is never called and nothing is charged.

What happens when the request finishes

When the response is complete, the gateway computes the real cost from the tokens that were actually used, at the prices that applied to your request, and settles the hold in a single transaction:

  1. the actual cost is debited from your balance (a billed request costs at least 1 micro-taka);
  2. the hold is removed, so the unused part of the reservation becomes available again immediately;
  3. a usage record is written with the model, token counts and cost, which is what you see on the usage page.

Because the hold is an upper bound, the charge should not exceed it. If an input estimate were ever too low, the charge is capped at what the wallet can cover; it never reaches into money reserved by your other running requests.

When something goes wrong

  • If the upstream provider fails before producing any output, the hold is released and nothing is charged. You receive an error with HTTP 502.
  • If you cancel a streaming response part-way, you are billed for the output that was already produced up to that point, and the rest of the hold is released.
  • If a hold is somehow left behind, for example because a server restarted, a background sweeper runs every minute, finds holds that have passed their expiry (15 minutes by default) and releases them. The sweeper only releases; it never charges. If a usage record already exists for that request, the hold is marked as settled instead.

Practical tips

  • Set max_tokens to what you actually need. A smaller maximum output means a smaller hold, so more of your wallet stays available for other requests.
  • Keep a buffer. If you run many requests in parallel, the holds add up, and the available amount can reach zero while the balance is still positive.
  • Watch the available amount rather than only the balance, and set a low-balance threshold in the organization settings, so a top-up does not arrive after requests have started failing with 402.
  • Use per-key monthly caps if several people or services share one wallet.

For the current per-token prices, see the pricing page. Prices shown during staging are samples. Questions about billing can go to support@ticonai.com.

All articles