client.get_usage_stats() method.
Cost & Usage
get_usage_stats
Fetches time-series usage and cost data for a given plan type and time range.
get_usage_stats() returns a single dict, not a bare list of items:
total_cost (top-level) for the overall total, and each item’s event_name + total_cost for the breakdown by deployment (or by accelerator type with group_by="accelerator" — see below, including a plan_type="reserved"-specific breakdown that only shows up in that grouping).
UsageStatsParams
List parameters accept one or more values (for example
["a", "b"]). Passing a filter that is not valid for the selected plan_type raises a ValidationError.- You can find
workspace-idunder Settings > Workspaces. Select your workspace and copy the workspace ID.

- Go to Deployments and select a deployment to find the
deployment-idanddeployment-slug.

Plan Types
Examples
Dedicated Deployment usage (plan_type="private")
plan_type="shared"): hourly buckets for the last 48 hours, pin results to one workspace_id
deployment_ids (use deployment_slugs instead when you have slugs, not UUIDs)
model_names
plan_type="training"): weekly buckets for the last 90 days, narrow to training_job_names
plan_type="compilation"): daily cost for specific model_repo_names
include_all_statuses=True)
plan_type="reserved"): daily cost plus the pooled reservation commitment breakdown
plan_type="reserved", you always get this breakdown automatically — there’s no flag to set. total_cost reflects what your org is actually billed under the reservation, and items includes every deployment covered by it, even ones that predate the reservation. overage_amount is usage billed above what you’ve committed to for that window; true_up_amount is committed capacity you paid for but didn’t use that window.
With group_by="accelerator" instead, use items[].points[].computed_overage_amount / computed_true_up_amount per time bucket rather than reservation_commitment:
group_by="accelerator" pools items per GPU/CPU type instead of per deployment. Only valid for plan_type in private/reserved. Each pooled item gains a sources key (a list of every deployment source string folded into it) in place of the single source value the per-deployment grouping has; source itself is None on these pooled items.
Each point in a pooled item also carries computed_commitment_utilized_amount, computed_overage_amount, and computed_true_up_amount:
computed_commitment_utilized_amount— cost covered by capacity you’ve already committed to.computed_overage_amount— cost billed at on-demand rates because usage went above your committed quantity that window.computed_true_up_amount— committed capacity you paid for but didn’t use that window.
group_by just changes how items is organized — it’s available for both plan_type="private" and plan_type="reserved", with the same two values ("deployment" or "accelerator") either way. The reservation breakdown described above only ever comes with plan_type="reserved" — a plan_type="private" request, even with group_by="accelerator", never includes reservation_commitment. For plan_type="reserved", that breakdown is always included and always covers your whole account, regardless of which group_by you pick.Error Handling
The SDK raisesSimplismartError for API errors. Pydantic validates plan_type and window_size before the request is sent, so invalid values are caught locally.