How Credits Work
Credits are consumed based on the resources your simulations use — primarily cluster size, instance type, and runtime. Larger clusters with more capable instance types cost more credits per hour. Credits are deducted as simulations progress, and your balance updates accordingly. Contact your account administrator for details on your platform’s specific rates.Checking Your Balance
Query your credit balance:currentBalance field determines whether you can launch new simulations. The response includes every account on your platform; if you have many accounts, follow the nextCursor pagination described in the Billing API Reference.
Understanding Your Overall Spend
For a high-level view of spending over a period:When You Run Out of Credits
If your credit balance reaches zero or goes negative, the platform rejects new simulation launches with 402 Payment Required:What stops and what keeps running
- Already-running simulations continue. They are not terminated and will complete normally, even if this pushes your balance negative.
- New launches are blocked until your balance is positive again.
- Overdraft: a running simulation can push your balance below zero by up to the cost of that simulation’s full runtime. The platform does not currently enforce a hard overdraft cap, but all consumption is tracked and reflected in
currentBalanceonce the simulation completes. Extreme negative balances can occur if you launch a very large, long-running simulation on a near-empty balance — the gate only checks at launch time.
Resuming Operations
Adding credits is a manual process — contact your account administrator. Once credits are applied, simulation launches resume immediately. No manual re-enablement step is required.Deeper Cost Analysis
These endpoints serve power-user workflows (auditing, spend attribution, troubleshooting). The examples below show the most common filters; the full parameter list for each endpoint is in the Billing API Reference.Daily Cost Breakdown
See spending per day, with optional workspace or user attribution:workspaceName, userName, eventType (e.g., cluster, workspace).
Date range cap:/costs,/costs/summary, and/eventsaccept date windows up to 366 days per request. For longer windows, paginate by month.
Note on userName: any caller with valid M2M service account credentials can filter costs by any user on the platform. (All billing endpoints require M2M credentials; regular user API tokens receive a 403.) If you want per-user spend scoped to the individual user or admins only, contact your account administrator — this is a platform-level policy decision, not an API capability.
Active and Historical Billing Items
Billing items represent what is currently (or was) being billed. Useful for answering “what’s running up charges right now?”:Billing Event History
Event stream covering resource lifecycle transitions (start, stop):workspaceName, userName, eventType, date range.
All date parameters are optional. When omitted, startDate defaults to 30 days ago and endDate defaults to today.
Error Responses
Error responses follow the shared ErrorResponse shape — an
error object with code and message. The 402 message is deliberately generic; the exact balance figure is logged server-side for audit but not echoed to the caller.
Next Steps
- Authentication — obtaining an API token
- Billing API Reference — every endpoint, every parameter, full response schemas
- Simulations API Reference — launch endpoint details