Common parameters
Most routes accept a rolling-windowrange and, for the operational routes, an
environment filter.
range never returns a 400 for an unrecognized value. It silently falls back
to the endpoint’s default window. Invalid environment, date, start,
end, bucket_size, status, kind, or after values do return 400, as
does an unsupported sla on /tasks and /latency/timeseries. On GET /v2/usage, an unrecognized sla or model is not rejected. It is applied as
a filter that matches nothing.Monetary fields (
balance, period_spend, burn_rate, avg_cost_per_day,
product_spend, sailbox_spend, and breakdown total) are fractional USD
cents expressed as floats. For example 73795.09 is roughly $737.95. Token
fields on the public endpoints are raw inference token counts.Product accounting
Billing responses follow these guarantees:period_spendand each breakdown bucket’stotalinclude all positive Inference and Sailbox charges.product_spendalways contains exactly two product families,inferenceandsailboxes. It never emits anotherfamily, and the two values add up to the corresponding combined total.sailbox_spendreports the currently itemized Sailbox charges. Sailbox products without a line item still count towardproduct_spend.sailboxes, so the line-item fields may sum to less than it.- Token, model, completion-window, request, and latency metrics are inference-only. Sailbox quantities and identifiers are not represented as tokens, models, or completion windows.
- Only base input, output, and cached-input token products add token counts.
Surcharges add inference spend without duplicating token quantities. Cached
input is included in
input, sototal = input + outputand cached tokens must not be added tototalagain. - Model and completion-window breakdowns include only explicitly attributed
inference spend. Missing attribution stays unassigned instead of creating an
othermodel or completion window.
Billing & cost
GET /v2/usage/summary
Combined Inference and Sailbox spend, credit balance, burn rate, days remaining, inference token totals, inference SLA spend mix, and a prior-period comparison.Plan tier is not exposed via the API; it is shown only on the dashboard.
GET /v2/usage/breakdown
Combined spend and inference token breakdowns per time bucket, plus inference model cost rankings. Userange=day with date=YYYY-MM-DD to drill into a
single day at hourly granularity.
Inference spend without a completion-window attribution is the remainder
below. It is plain inference spend, not an
other product or completion
window.
GET /v2/usage/api-keys
Per-API-key usage, broken down by(api_key_id, model, sla), with a windowed
time series. display_name and display_prefix are populated for keys that
still exist; deleted keys return null for both (only the stable api_key_id
remains).
This endpoint reports inference usage only. Sailbox charges accrue over a
Sailbox’s lifetime and do not map reliably to a single API key, so Sailbox
usage is excluded from the per-key rows. Use
/v2/usage/summary or
/v2/usage/breakdown for product-aware spend.GET /v2/usage/tokens
Inference token counters (input/output/cached) over the range, as raw counts. Only base token products contribute quantities. Sailbox usage and inference surcharges do not add tokens. Cached input is already included ininput.
GET /v2/usage/tokens/timeseries
Raw inference token counts per time bucket, broken down by input/output/cached. The same base-product and cached-input rules as/tokens apply.
Operational activity & latency
These routes report request counts, task activity, and latency. They all accept theenvironment filter.
GET /v2/usage/activity
Consolidated completed-request counts and average latency over rolling windows.GET /v2/usage/activity/timeseries
Per-model completed-request counts over time.GET /v2/usage/recent
The most recent requests, including active and finished requests when available.sla is null when the request has no resolved completion window.
GET /v2/usage/tasks
Paginated task activity with per-task token breakdowns, spanning both active and finished requests.
Only
1h and 24h are valid for range; any other value resolves to 24h
(reported back as effective_range).
GET /v2/usage/latency/turn
Turn latency distribution for a single request-to-response time, with p50/p95/p99, aggregate and per-SLA.GET /v2/usage/latency/trajectory
Trajectory latency distribution for a multi-turn conversation, with the same shape as/latency/turn. Trajectory
responses additionally carry avg_turns_per_trajectory, and may set
approx: true when percentiles are sampled.
GET /v2/usage/latency/timeseries
Latency percentiles over time for turns or trajectories.model and sla filters are only supported for kind=turn. Passing either
with kind=trajectory returns a 400.approx and avg_turns_per_trajectory only when relevant
(both are omitted otherwise).
GET /v2/usage
Completed-request latency and counts in fixed time buckets, with one row per environment per bucket. Unlike the rolling-window routes above, this endpoint takes an explicitstart/end/bucket_size window, making it suited to
charting a specific time range at a fixed resolution.
A window that would produce more than 10,000 buckets for the chosen
bucket_size returns a 400. Widen bucket_size or shorten the window.Errors
Errors use the same envelope as the inference API. For usage-API errors,code
is set to the same string as type, and param is always null:
code (for example invalid_api_key) or null (a
missing Authorization header).
Endpoints return an empty/zeroed payload with HTTP 200 (not an error) when the
org has no billing account or no usage in the requested window.