Skip to main content
The usage routes tell you what your organization ran and what it cost, from a monthly total down to a single model call. Use them to build dashboards, to reconcile your own records against your bill, and to size auto-recharge and quotas. The Usage page in the console shows the same figures without code.

Routes

All four routes need the usage_read scope and return data for the credential’s organization only. Every role holds usage_read; a key only has it if it was created with it. GET /v1/quota also needs usage_read; it is covered in Spend limits and quotas. Every amount is an integer in micro-USD: 1,000,000 micros is 1 US dollar. Timestamps are UTC in exactly YYYY-MM-DDTHH:MM:SSZ form, and daily dates are YYYY-MM-DD.

Windows

GET /v1/usage, GET /v1/usage/daily and GET /v1/usage/ledger take an optional window. Windows are half-open, [start_at, end_at). To read September 2026, send start_at=2026-09-01T00:00:00Z and end_at=2026-10-01T00:00:00Z. Offsets such as +02:00, fractional seconds and dates without a time are refused.

Totals for a window

In the example, two settled runs cost 38 micros and one run in flight holds its 20,000-micro ceiling.
A run that fails before any model call is made keeps state pending, so it stays counted in in_flight with no cost. See Polling.

Spend per day

GET /v1/usage/daily returns one row per UTC date, oldest first, with days that had no runs filled with zeros. It is the series to chart, and the one to use when you size auto-recharge.
  • The rows run from the date of start_at through the date of the last instant before end_at.
  • end_at - start_at must be at most 92 days.
A day’s figures follow the run’s creation time, so a run created at 23:59:59Z counts on the day it started. To cover more than 92 days, request consecutive windows and join the rows.

The ledger

GET /v1/usage/ledger lists one entry per model call, newest first. Use it to audit individual charges. There is no offset or cursor. To read further back, keep start_at at the start of the range you want and set end_at to one second after the created_at of the oldest entry you received and ask again. Because end_at is exclusive and timestamps have whole-second precision, that page repeats the entries from that last second, so skip entries you have already stored, keyed on run_id plus retry_ordinal.
A run that fails after the model answered is charged for what it consumed, so a failed entry can carry a cost.

One run

GET /v1/usage/runs/{run_id} returns one run’s accounting, with its calls in retry_ordinal order.
ceiling_micros is the most this run was allowed to spend, at most 20,000. attempts has the same fields as a ledger entry.

Two spellings of a run id

The runs API returns run_ plus 32 hex characters, such as run_a4314b6cc08f4bd8814099a613abeb44. The usage routes return the same id with hyphens, such as run_a4314b6c-c08f-4bd8-8140-99a613abeb44. Both name the same run, and every route accepts either form. To join usage rows to your own run records, normalize before comparing:

Errors

An unknown query parameter, such as from=, or a non-numeric limit is refused with a plain-text 400 that has no JSON envelope. Use only the parameters listed on this page.