Skip to main content

Billing

The Billing screen shows the current cycle, your rates and invoices. When API keys have their own terms, it shows each key's own billing instead. Keys that pay by card also see the card subscription here.

Billing by key​

When API keys have their own terms, Billing works per key. Use the API key filter at the top of the tab.

  • No key chosen: the tab shows Billing by key: one card per key with its own billing period and money, instead of the organisation cycle.
  • One key chosen: the tab shows that key's own billing:
    • the Key billing period, which follows how the key is paid: prepaid (from the top-up until the prepaid amount is used), an invoice period, or a monthly subscription counted from the first payment;
    • spending in real money; for a key bought below list prices, the same usage is also shown at list prices for reference;
    • a forecast: to the end of the period, or, for a prepaid amount, the date it runs out at the current pace;
    • cost by model;
    • the key's own rates; for a key bought below list prices, each rate shows your price with the list price under it;
    • the key's own statements, one per billing period; an open period shows spending so far.

A key without its own terms is shown in the organisation cycle described below.

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. The public list prices of every product are on Models and prices.

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.

Paying by card: deposit subscription​

A key can be paid by card like an automatic top-up. You pay a deposit once as a card subscription (about one week of usage: monthly spend divided by 4); after that the card is charged every week for 100% of the actual usage since the previous charge. The amount is fixed one day ahead and shown as Next charge. Each key may go below zero down to its own limit, you receive one e-mail with a pay button near the limit, and you can cancel at any time. Step-by-step guide with screenshots: Paying by card.

Reconciling with your own counter​

When your internal number and the cabinet number disagree, check in this order:

  1. Compare closed days only. The current day is still filling.
  2. Check the timezone. Days are closed in your organisation's timezone.
  3. Check what you are comparing. Requests, billable units and tokens are different counters. Use the rate card shown for your organisation.
  4. 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.