Billing
The Billing screen has three parts: the current cycle, your rates, and invoices.
The current cycle
Cycle start and end dates, consumption so far, and the amount accrued. This is the authoritative statement of where the cycle stands — the Usage screen shows the same numbers split by period and enabled breakdowns.
Rates
Rates are stated per million units and shown per model family, so the arithmetic behind any line is reproducible from the exports.
Three properties of the rate card matter when you check a number:
- Cached input is charged at a reduced rate. Repeated context inside a run is not billed as fresh input.
- Reasoning tokens are counted as output where your contract includes them.
- Long context can sit in a higher band. Above a threshold stated on your card, the rate per million changes. A single very long request therefore costs more per token than the same volume split into ordinary ones.
Your own rate card is on the screen; it belongs to your contract and is not the same for every account.
Invoices
Issued per cycle. Each invoice is backed by the same aggregates the screens use, so a line can be traced to the corresponding period and request data in the exports.
Reconciling with your own counter
When your internal number and the cabinet number disagree, check in this order:
- Compare closed days only. The current day is still filling.
- Check the timezone. Days are closed in your organisation's timezone.
- Check what you are comparing. Requests, billable units and tokens are different counters. Use the rate card shown for your organisation.
- Export the request-level dataset for the day in question and sum it yourself. If the sum matches the daily total but not your counter, the difference is on your side; if it does not match the daily total, send support the day and the key alias or mask. Never send the full API key.