Wallet and Billing Troubleshooting
Understand wallet reservations, captured usage, failed deployments, refunds, and how to investigate unexpected charges.
By Hostnot GPU ·
Investigate a wallet discrepancy by reconstructing one operation's timeline. A lower available balance can be a reservation, a captured charge or a combination of active jobs. Do not top up repeatedly, relaunch work or infer a refund from an HTTP error before checking the authoritative records.
Read the wallet fields without double subtraction
GET /wallet requires wallet:read and returns currency, balance, reserved, available and held. Money values are decimal strings. Available funds equal balance minus reservations, with a minimum of zero. Held equals reserved: subtracting both counts the same commitment twice.
For arithmetic only, imagine a balance of 20 and reservations of 6 in the same currency. Available would be 14, not 8. This is not a platform price or a real account example. Use decimal arithmetic when reconciling actual values. A reservation limits what can be newly authorized but is not itself the completed usage charge.
Build a single-operation timeline
- Record the UTC time and wallet currency, plus balance, reserved and available at the observation point.
- Identify the public instance or logical inference operation involved, including the original idempotency key in your private records.
- For a GPU, compare quote/launch status, readiness, billable usage windows and termination state.
- For inference, compare response or error, request ID, any returned usage/billing and whether delivery is known or uncertain.
- Match resulting ledger entries to the operation instead of adding unrelated account activity into the same explanation.
Follow billing history for the dashboard record path. If a deposit appears missing, check its recorded payment state and reference under deposits before initiating another payment. A pending payment is not equivalent to spendable wallet credit.
Understand why a timeout can leave a reservation
Inference reserves an estimate before calling the model. The failure path before delivery attempts release. After delivery, a settlement error retains reconciliation state so delivered work can be accounted for. Client disconnection alone cannot distinguish these cases. Do not claim every failed HTTP response is free, or that every hold will disappear at a fixed time visible to the customer.
A large chat prompt or high output ceiling can require more authorization than its eventual measured usage. Character counts are used as an estimate input for chat authorization; they are not measured tokens. Reducing unnecessary input and output limits may reduce required authorization, but should not be used to conceal unresolved existing charges.
Check usage-window boundaries
GET /usage, with usage:read, returns GPU-instance records in a data array. Start defaults to 30 days before end; end defaults to now. The filter includes records whose start is on or after start and whose end is on or before end, not every record that overlaps the interval. Widen the window if a boundary-spanning record seems missing. This endpoint is not a serverless usage export.
Escalate an unexplained difference
Send support UTC times, public operation identifiers, currency, relevant amounts, request ID and a redacted status/error. Exclude private keys, bearer tokens, payment-card details and prompt content. Preserve the original records; do not edit wallet data, repeatedly terminate/relaunch resources or resubmit generation to “test” a billing discrepancy. See the billing guide for reservation terminology.