An AI answer can stop halfway through a sentence. Some text may already have reached the reader, and the AI provider may already have done work that costs money. A broken connection alone does not tell us whether to charge or refund the customer.
Serverloka has implemented the accounting rules described here. That does not establish that the service is publicly live or proven in production. All credit balances below are examples, not measured costs or savings.
Set aside credits before asking the AI
Credits are the units used to pay for AI requests. A prepaid wallet is a balance funded in advance: each charge reduces the credits available for later requests.
Before asking the AI provider to work, the service estimates a maximum charge from the text being sent and the amount of output allowed. It then makes a reservation: credits become temporarily unavailable for other requests. This is a real debit from the wallet, not just a “pending” label.
The reserved credits move to an account used to fund the provider’s work. The service records that movement, creates a usage record, and adjusts the spending tracked against the customer’s AI access key, the credential used to make requests. These changes happen together or not at all. If the wallet lacks funds or the key’s spending limit would be exceeded, none of them is saved.
The aim is simple: every debit needs a record, and two requests must not spend the same credits.
How to read this illustration
- Left — blue token tray: stands for available credits. The image contains no wallet or cards.
- Center — token hopper, gears, and lock: stands for credits set aside before the final charge. This machinery is an illustration, not the service’s actual screen.
- Right — token housing and separate stack alcove: stands for credits set aside for a charge, not a receipt. The red route suggests movement; it does not show the exact accounting entries.
Takeaway: the objects explain the idea of a reservation. The next diagram shows the balance changes more precisely.
Replace the reservation with the final charge
Settlement means replacing the reserved estimate with the final charge. The service releases the whole reservation and applies the charge together, as one all-or-nothing change. It does not add a second charge on top of the reservation.
| Example step | Available credits | What happens |
|---|---|---|
| Start with a funded wallet | 10,000 | Nothing reserved yet |
| Reserve 3,000 | 7,000 | Set aside credits for this request |
| Settle a final charge of 2,200 | 7,800 | Release 3,000 and charge 2,200 together |
The saved balance is 7,800. There is no separately visible step where the full reservation has been returned but the final charge has not yet been applied. A full refund instead returns the wallet to 10,000 credits.
The accounting also has to balance. Every amount taken from one account has a matching amount recorded elsewhere. The final charge reduces the wallet and records the provider’s cost and the service’s share in their respective accounts. Adding all the signed entries must give zero. Returning the reservation removes the estimate; the final charge still pays for the response.
How to read the balance diagram
- Pink center station — reserved credits: the set-aside amount waits here before the final charge. Pink has this meaning in this diagram only.
- Arrow marked “Settle” — leaves the reservation, passes the intermediate coin stacks, and reaches the final-charge box. It replaces the reservation with a charge rather than adding another charge.
- Separate curved branch — leaves the reserved station and bends down to the refunded wallet. It returns the opening balance instead of continuing after settlement.
Takeaway: this charge leaves 7,800 available credits. Only the separate full-refund branch restores 10,000.
Do not charge twice for the same recorded work
The service tracks each reservation separately from each completed response reported by the provider. A conversation can contain several paid requests, so belonging to the same conversation does not make two requests the same charge.
If the service encounters the same reservation again, it recognizes the existing record. It also prevents two simultaneous attempts from creating duplicate records. Before applying a charge or refund, it checks that the reservation is still open. Repeating a completed charge or refund does not move credits again.
When the provider supplies an identifier for a completed response, the service records it with the usage. If that response is already recorded, the service releases the extra reservation, undoes its spending adjustment, and closes it without another charge. The database handles that duplicate within the larger update, so the refund and closure can still finish together.
This does not make every repeated request free. Each incoming request gets a fresh reservation identifier. Sending the same prompt again, or retrying a request as a new request, may ask the provider to do new work and may cost credits again.
Keep other wallet payments moving
A database lock briefly prevents another update from changing the same records at the same time. The service uses these locks while it checks and changes balances. It locks accounts in a consistent order, checks that their currencies match, and rejects changes that would make a balance negative. Before settling, it also locks the access-key and usage records it needs to change.
The provider’s work happens between the reservation and the final charge, outside those locked updates. The wallet is not locked for the whole network request or while the answer arrives. Otherwise, one slow answer could block unrelated spending until it finished.
Using the same lock order reduces the risk of two updates waiting on each other, though it cannot remove that risk entirely. Conflicting balance changes take turns; waiting for the provider does not hold up that turn.
Decide what to charge when an answer stops
A stream is an answer whose text arrives bit by bit rather than all at once. A usage report is the provider’s count of the input and output used for the request. Input is what the service sends to the AI; output is what the AI generates.
The service asks the provider to include usage information in the stream. An interruption can prevent the final report from arriving, even after text has reached the reader. A missing report does not prove that no work happened.
The implemented rules distinguish these cases:
| What happened | What happens to the credits |
|---|---|
| The provider returns an HTTP failure, an error response to the network request | Refund the reservation |
| Another stream error occurs, with zero captured usage | Refund the reservation |
| Another stream error occurs, but usage was captured | Work out the usage charge and settle it |
| The stream succeeds, but its usage report is missing | Work out the usage charge; if the resulting customer price is zero, use the reservation estimate |
How to read the interrupted ribbons
- Upper cream ribbon — answer text travelling from the generator on the left toward the reader’s screen on the right. Some text may arrive before the stream breaks.
- Lower red ribbon / warning tray — usage information stops short of collection. The warning means that information is missing, not that the work cost nothing.
- Colors and tiles — cream means text; red means usage information. The tiles and gaps are illustrative, not counts of AI text units or a measured failure rate.
Takeaway: delivering an answer and collecting the information needed to price it are separate events.
The service sends each piece of the answer onward before reading its usage information. If sending fails, that usage may not be captured, even though the provider did work. If an interrupted answer does have captured usage, the service still uses it to settle the charge.
Refunding an error with zero captured usage is a policy choice, not proof that the provider charged nothing. A successful answer with a missing report does not get that automatic refund. The service applies its usage-resolution rules to work out a charge, then uses the reservation estimate if the resulting price is zero. That gives a charging outcome, not necessarily a measured count of the AI’s text units.
How to read the refund and charge branches
- Top question / right arrows — an HTTP error from the provider refunds immediately. Otherwise, the second question refunds only for another error with zero captured usage. Pink marks the refund outcome in this diagram.
- Downward arrows / dark bottom box — every remaining outcome works out usage and settles the charge. This includes an interrupted answer with captured usage and a successful answer without a usage report.
- Right-hand note — when the resolved price is zero, settlement uses the reservation estimate. That estimate is not a measured count of input and output.
Takeaway: the error type and captured usage determine the branch. An incomplete answer alone does not guarantee a refund.
A wallet can stay above zero and still fall short
The final price can be higher than the reservation. When that happens, the service releases the reservation and checks the available balance. It charges more than the estimate if there are enough credits. Otherwise, it charges only what is available and records the unpaid difference as a shortage.
Here is a separate example, unrelated to the 3,000-credit reservation above. After releasing a reservation, a wallet has 6,600 credits available, but the final price is 8,000. The service charges 6,600 and records a 1,400-credit shortage. The wallet does not go below zero, but the service has not recovered the full bill.
Keeping balances valid, preventing duplicate charges, and recording missing usage or unpaid costs are different jobs. These accounting rules address those jobs; they do not establish lower costs or prove reliable public production operation.
Further reading
PostgreSQL’s row-locking documentation explains how database updates can briefly take turns. OpenAI’s Chat Completions reference describes streamed usage reports and why the final report may be missing after an interruption.