Billing & Top-ups
Reconciling usage and charges
How to reconcile Xisu AI call records: what each column means, why token counts are itemized, the difference between "—" and "0", why a successful call can cost zero, what to do when the balance doesn't match, and the four things to include in a report.
Usage details in the console is the only place you can reconcile call by call. It is also the only place a request_id is visible — and a support ticket needs one.
What each column means
| Column | Contents |
|---|---|
| Time | When the request happened (full timestamp in the tooltip) |
| Model / key | The model that actually ran, and which key called it |
| Token usage | Broken out: input, output, cached reads — not one total |
| Latency | How long this call took |
| Cost | What this call actually cost |
| Status | Success / failure |
The breakdown is deliberate: for the same 1,000 tokens, input and output differ in price by 3–5×. With only a total, a rising bill wouldn't tell you whether you sent more or the model wrote more.
⚠️ "—" is not "0"
0means genuinely zero — this call really produced no output, for example.—means we don't have that number (the upstream didn't report it and it couldn't be estimated).
We deliberately don't render — as 0: filling in a zero would be inventing a number on the upstream's behalf, and then you could no longer tell "really zero" from "no data". When you see —, trust the cost column, or bring the request_id to a ticket.
The call succeeded but cost is zero
There are five normal reasons, and the page states which one right under the cost:
| What the page says | Meaning |
|---|---|
| Covered by a prepaid pack | This call drew on your prepaid allowance, not the balance |
| No output this time | The model generated nothing (your client disconnected immediately, say) |
| This model is currently free | Its price is zero right now |
| Not charged | A case the system does not bill |
Failed requests also appear in the list, with a failure status — they are not billed, so rows with "a request but no cost" are correct.
Doesn't match the balance?
Start with the "data as of hh:mm:ss" line on the page. Balance and usage are owned by the gateway; the console shows a snapshot with the time it was taken:
- refresh immediately after a call and it may not be in the snapshot yet;
- two pages can carry different "as of" times — subtracting numbers only means something when they're from the same moment.
If a gap persists, open a ticket with: the time range, a few of the request_ids involved, and the number you calculated yourself. Don't just say "the bill is wrong" — that kind of ticket leaves support guessing what you compared.
The four things a report needs
The request_id, when it happened, which model, and the complete error body. Without the request_id we cannot locate that call.