Billing at the micro: how runaii.cloud meters every token

When you run an inference platform, billing is not a feature — it is the product. A model that answers brilliantly but overcharges silently is a broken product. So we built our billing engine the way exchanges build clearing systems: append-only ledger first, balance as a projection, and a proof that the two always agree.

One request, three money events

Every /api/v1/chat/completions call moves through the same atomic path inside Postgres:

1. Authorize — we price your prompt (plus the worst case for max_tokens) and reserve that estimate atomically. Two concurrent requests cannot double-spend the same credits; the reservation is a row with a unique request id, enforced by the database, not by our application code.
2. Settle — when the stream finishes, we price the real usage: prompt tokens at the full rate, cached tokens at the subsidized cache rate, completion tokens at the output rate. The unused part of the reservation is refunded in the same transaction. If the request died mid-stream, the whole reservation is refunded instead — you never pay for a request that never delivered.
3. Reverse — any upstream failure triggers an explicit refund event, idempotent by request id.

Every event is an append-only row in credit_ledger with an idempotency key. Retries, duplicate webhooks, double settles — all of them collapse to a single effect because the database rejects the second write.

Cache hits are cheaper — and we pass it through 1:1

Open models like GLM and Kimi support prompt caching: repeated prefixes are served from cache at a fraction of the cost. Our price table carries a separate input_cache_read rate per model, and settle splits your prompt into cache-hit and cache-miss tokens. The pricing API at /api/v1/models exposes all three rates, and the terminal usage chunk in streaming responses includes a prompt_tokens_details object with the exact cached_tokens count — so you can verify your own bill, down to the token, on every request.

Proving the ledger honest

Balances live in current_balances, but they are only a projection. A parity view continuously asserts:

SELECT user_id, balance_micros - ledger_sum AS drift
FROM billing.parity WHERE drift <> 0;

That query must return zero rows. Always. It runs in CI against a real Postgres (the invariant suite covers concurrent double-spends, crash-between-reserve-and-settle recovery, duplicate webhook delivery, and DB-down fail-closed behavior), and it runs in production monitoring. If drift is ever non-zero, the banner on the admin panel turns red.

Try it

curl https://api.runaii.cloud/v1/chat/completions \
  -H "Authorization: Bearer sk-runaii-..." \
  -d '{"model":"glm-5.3-flash","messages":[{"role":"user","content":"hi"}]}'

The response's usage.cost field is exactly what your balance was charged. We think you should never have to take a billing system's word for anything — including ours.