Skip to main content
Usage reaches the MKA1 API’s reports after it occurs, sometimes hours after. A figure for the last 24 hours can still grow. A figure for usage older than that is final. Every usage and cost report that covers a time window says when its figures were computed and which part of the window is final. Use those fields to tell a settled number from one that is still filling in, and to make the console, your exports, and the raw API responses agree.

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.
Each report applies this rule to its own window with four fields: 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.
24 hours covers all of these with margin. It is also the delay before a billing month closes, so a closed month and a final report count the same usage; see Billing months.

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:
The report is a grouped sum over the whole window. It has no pages and never leaves rows out.

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:
A window larger than one page always comes back with 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.defaulted is true when you omitted from or to and the report chose the bound. to defaults to the current UTC minute, and from to 30 days before to. Usage before a defaulted from is not counted, so a defaulted window is not an all-time total. Pass both bounds for a fixed window.
  • summary covers the whole requested window, whichever page of data you read. data rows page with limit (default 50, at most 200), next_cursor, and total.
  • A window longer than 90 days returns 400 instead of a partial report.
On a job or service, 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 the as_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_start and window_end in UTC, settlement_window_seconds, usage_as_of, usage_status (provisional or final), and usage_final_through for the usage figures, and spend_as_of, spend_status, and spend_final_through for spend. usage_truncated is true if the usage report stopped before the end of the window. usage_team_id names the team the usage covers, and spend_scope says 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:
  1. Pick a window that ended at least 24 hours ago, with explicit start and end times on UTC boundaries.
  2. Read the platform cost report for that window and check that final is true.
  3. Keep as_of, total_cost, unpriced_entries, and late_cost with the figures you record.
  4. 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_id over the same window. For the team you queried Compute usage with, the compute rows with task_type job and service match Compute usage summary.job_usd and summary.service_usd. The compute rows with task_type volume, summed across all teams, match summary.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_id and compare its llm-gateway row for the active team.
  5. Check late_cost again on later reports for the same window, and carry any increase into your next period.