Provisional and final
Usage settles 24 hours after it occurs. This is the settlement window.- Usage is provisional while it is less than 24 hours old. A provisional figure can still grow as late usage arrives.
- Usage is final once it is 24 hours old. The rare exceptions are counted for you; see Late arrivals.
A window that ends now, or anywhere in the last 24 hours, is never final. For figures you bill, charge back, or compare across reports, query a window that ended at least 24 hours ago and check that
final is true.
Read final and final_through from each response. Don’t compute them yourself, and don’t compare one service’s final_through with another’s: a service can hold final_through back, as Compute usage does while it is still recording usage.
Why 24 hours
Some usage reaches the reports after it occurs:- A background response is priced when it completes, which can be hours after it starts.
- Compute is metered minute by minute, and a delivery that fails is retried for several hours.
- LLM usage reports can be served from a cache; see Cached reports.
Which report to use
The platform cost report is the cost of record. It sums the stored cost of every billable unit by when the unit occurred, across all services. Use it whenever your figures must match total spend, for example for chargeback. Group it by
service to split the total into llm-gateway, compute, and sandbox.
The LLM cost report leaves out Compute and Sandbox spend. A Compute job’s cost appears in the platform cost report and in Compute usage, never in the LLM cost report.
Compute usage reports jobs and services for the team of the API key or session that calls it, and standalone volumes for the whole organization. It has no organization-wide view. For an organization’s total Compute spend, use the platform cost report grouped by service.
Organization admins read the platform cost report for their whole organization. Other members read their own spend only; see How spend is attributed.
The SDKs return the same fields in each language’s naming style, for example finalThrough in TypeScript.
Fields on each report
Platform cost report
GET /api/v1/budgeting/usage/costs carries the four settlement fields, as unix seconds, plus three counts over the same window and filter:
This report for November 7, 2026, grouped by
service, was computed on November 9 at 12:00 UTC, so its whole window is final:
LLM cost report
GET /api/v1/llm/usage/costs carries the four settlement fields, as unix seconds, plus unpriced_entries. It has no late-arrival counts. It sums LLM spend over the whole window and has no pages.
LLM usage reports
The bucketed LLM usage reports return pages of time buckets. Every page carries the four settlement fields, as unix seconds.final is judged on the requested window, not on the buckets of one page. The window ends at end_time, or at as_of when you omit end_time. Every page of one query reports the same final.
This Responses usage report covers November 1, 2026, in one daily bucket, computed on November 9 at 12:00 UTC:
has_more: true and a next_page cursor. Read a long window page by page covers bucket alignment, page sizes, and the cursor.
Compute usage
GET /api/v1/compute/usage carries the four settlement fields. as_of and final_through are RFC 3339 UTC timestamps in whole seconds, like the report’s window.from and window.to. settlement_window_seconds is the integer 86400.
This report for November 1 to 8, 2026, requested without resource_type so it includes volumes, was computed on November 9 at 12:00 UTC:
summary.total_usd is the calling team’s job and service cost plus every standalone volume in the organization. It is not the organization’s Compute spend.
final_through is at most as_of minus 24 hours. It is held back further while the meter has not yet recorded all the job and service usage in the report, because a meter that falls behind records the missed minutes later. When standalone volumes are in the report (resource_type omitted, or volume), final_through is also never later than volume_usage_complete_through, the point through which volume usage is recorded. Both points are capped to the requested window, so for a window that settled long ago final_through equals window.to, as in the example above.
Compute usage never cuts a window silently:
window.defaultedistruewhen you omittedfromortoand the report chose the bound.todefaults to the current UTC minute, andfromto 30 days beforeto. Usage before a defaultedfromis not counted, so a defaulted window is not an all-time total. Pass both bounds for a fixed window.summarycovers the whole requested window, whichever page ofdatayou read.datarows page withlimit(default 50, at most 200),next_cursor, andtotal.- A window longer than 90 days returns
400instead of a partial report.
accrued_usd is the resource’s lifetime cost so far: compute plus any volume billed to it. Where usage bills in whole minutes, it includes the current minute, charged in full as soon as the meter records it. It is provisional while the resource runs and until 24 hours after it stops. It is final after that, once the meter has recorded the resource’s usage through the time it stopped. In the usage report, data[].accrued_usd is the cost allocated to the requested window, not the lifetime figure.
Unpriced entries
unpriced_entries on both cost reports counts entries in the window that carry no cost. They add 0 to total_cost, so a total with unpriced entries under-reports what was used.
An entry has no cost when its model has no price, or when it could not be priced, for example during a pricing outage. A model priced at zero is not unpriced: its entries cost 0. Compute and Sandbox entries always carry a cost, so on the platform cost report unpriced entries come from LLM usage.
On the LLM cost report, a response still in progress is also unpriced. It counts in the window where it started. Once it completes and is priced, it moves to the window where it completed, so the count falls and the total rises. A response cancelled or failed before it used any tokens costs nothing and is not counted.
The LLM cost report also counts LLM usage recorded before the platform began pricing it. Those entries stay unpriced permanently, even in a final window, and their usage is not in the total.
If unpriced_entries stays above 0 for a final window, a model had no price or could not be priced when the usage occurred. Check the model’s price under Admin → Pricing. On the LLM cost report, a window that reaches back before the platform began pricing LLM usage keeps a count above 0 whatever the prices.
Late arrivals
The 24-hour window covers every delay that has a limit. Usage can still arrive later in rare cases: a delivery held up by an outage longer than the window, or an entry that was held for correction and delivered once fixed. The platform cost report counts these so a final figure never changes without a trace.late_entries is the number of entries in the window that arrived more than 24 hours after they occurred, and late_cost is their summed cost. late_cost is already included in total_cost.
If you recorded a final total for a window and a later report for the same window shows a higher late_cost, the difference between the two totals is late usage. Charge or credit it in your next period rather than reopening the closed one.
Cached reports
LLM usage reports and the LLM cost report can be served from a cache. A final report is cached for up to an hour. A provisional report is cached for up to a minute, so new usage reaches it quickly. A cached report keeps theas_of it was computed at, so as_of tells you how old the figures are. The platform cost report and Compute usage are not cached: their as_of is the time of your request.
Billing months
If your organization has billing enabled, billing uses calendar months in UTC. A month closes 24 hours after it ends, and its invoice is created then. Until it closes, the month’s figures are provisional. Usage that arrives for a month after its invoice exists is billed on a later invoice for that original month. An invoice that has been issued never changes. The invoice list (GET /api/v1/budgeting/billing/org/invoices) and the billing summary (GET /api/v1/budgeting/billing/org) return the newest 100 invoices. When older invoices exist, the invoice list sets has_more and the summary sets invoices_has_more, rather than dropping them silently.
In the console
The console marks figures the same way:- The Usage page shows usage and, under Spend, the platform cost report for the same window, split by service: LLM, Compute, and Sandbox. Each block names its window in UTC and carries a provisional or final badge, with a sentence saying from when its figures can still change. The page’s ranges end at the current time, so they show provisional.
- Usage figures cover the active team, and members see only their own. A line under Spend says which teams it covers: every team in the organization for an organization admin, or all of a member’s own teams for a member. If the spend block says LLM spend only, it covers the member’s LLM spend in the active team and leaves out Compute and Sandbox spend.
- If a usage report stops before the end of the window, the page says the usage is incomplete rather than presenting a partial figure as the total.
- Export on the Usage page downloads a CSV with three blocks: metadata, the usage table, and the spend rows the page shows. The metadata gives the window as
window_startandwindow_endin UTC,settlement_window_seconds,usage_as_of,usage_status(provisionalorfinal), andusage_final_throughfor the usage figures, andspend_as_of,spend_status, andspend_final_throughfor spend.usage_truncatedistrueif the usage report stopped before the end of the window.usage_team_idnames the team the usage covers, andspend_scopesays what the spend covers. Spend rows are written only when spend covers the same window as the usage. - On Compute, the Spend tiles show Jobs, Services, and Volumes, which add up to Total, with the same window note.
- On Admin → Billing, Not yet invoiced is usage from any month that is not on an invoice yet. It is always marked provisional.
Reconcile figures across reports
To make a dashboard, an export, and the raw responses agree:- Pick a window that ended at least 24 hours ago, with explicit start and end times on UTC boundaries.
- Read the platform cost report for that window and check that
finalistrue. - Keep
as_of,total_cost,unpriced_entries, andlate_costwith the figures you record. - For one service’s detail, query that service’s own report with the same window. Where a figure differs, the platform cost report is the cost of record. Reports that cover different scopes don’t match:
- Compute usage covers one team, while the platform cost report covers the whole organization for an organization admin and your own spend for anyone else. To check Compute as an organization admin, group the platform cost report by
service,task_type,team_idover the same window. For the team you queried Compute usage with, thecomputerows withtask_typejobandservicematch Compute usagesummary.job_usdandsummary.service_usd. Thecomputerows withtask_typevolume, summed across all teams, matchsummary.volume_usd. Members can’t make this comparison, because their cost report shows only their own spend. - For a member, the LLM cost report covers your own spend in the active team only, while the platform cost report covers all your teams. Group the platform cost report by
service,team_idand compare itsllm-gatewayrow for the active team.
- Compute usage covers one team, while the platform cost report covers the whole organization for an organization admin and your own spend for anyone else. To check Compute as an organization admin, group the platform cost report by
- Check
late_costagain on later reports for the same window, and carry any increase into your next period.