Max runtime
Max runtime terminates an instance a fixed time after it starts. The clock starts when the instance first reachesrunning, so boot time does not count against it.
- Ten minutes before the limit, owners and admins get an email and your webhooks get an
instance.runtime_endingevent with the exact stop time. - At the limit the instance is terminated, not paused. Its local disk is deleted, as with a manual terminate. Keep anything you need on a storage volume or push it somewhere before the limit.
- The range is 5 minutes to 7 days (10,080 minutes). Leave it unset for no limit.
- Once the instance is running,
auto_stop_aton the instance tells you when it will stop: its start time plus the max runtime.
30m, 90m, 1h30m, 4h, 168h), in whole minutes. The API, SDKs and MCP take minutes as an integer. A value outside the range is rejected with HTTP 422 (validation_error) before anything launches; the SDKs raise UnprocessableEntityError.
Idle stop
Idle stop terminates an instance once it stops doing work: GPU utilization stays under 5% and nobody is connected (SSH, the web terminal or the code editor), for the number of minutes you choose. It needs a GPU, so it is not offered for CPU-only instances.- The range is 5 minutes to 24 hours (1,440 minutes). Leave it unset to keep the instance running while idle.
- An open SSH, web terminal or code editor session counts as activity, so an instance you are working on is not stopped while you are connected.
- The idle clock starts once the instance has finished setting up.
- Like max runtime, idle stop terminates the instance and deletes its local disk.
- It applies to instances launched with the setting. Instances launched before idle stop existed are not watched.
runcrate instances info <name> prints the same values as Max runtime, Idle stop, Auto stop at and Stop reason.
Changing auto stop on a running instance
Extend max runtime before a job that will outlast it, or add a stop to an instance you are about to leave working. Anyone with access to the instance can change it, including an API key or an agent.- Max runtime still counts from when the instance started running, so give the total minutes, not extra minutes. A change never stops the instance sooner than 2 minutes from the moment you make it, and
auto_stop_atshows the new stop time. - Extending the limit sends a fresh
instance.runtime_endingalert 10 minutes before the new stop time. null(CLIoff) turns a limit off. A field you leave out keeps its value.- An idle stop change reaches the instance within about 5 minutes, and restarts its idle clock. Some older instances can’t turn idle stop on (409, “Idle stop needs a newer launch”), and neither can CPU-only instances; turning it off always works.
- Only a starting or running instance can change (409 otherwise).
Monthly budgets
A monthly budget caps what one environment can spend in a calendar month. Give each project or agent its own environment and budget. An API key scoped to that environment, and an agent connected through MCP or the CLI (which works only in the environment picked when it signed in), cannot spend past the budget.- Who sets it: a workspace owner or admin, in Settings, Environments.
- What counts: GPU instances and inference billed to that environment, including inference made with that environment’s API keys.
- The month: the UTC calendar month. Month to date resets to $0 at 00:00 UTC on the 1st.
- At 80%: owners and admins get an email and your webhooks get a
budget.threshold_reachedevent. - At 100%:
- New launches in the environment fail with HTTP 402 and error code
BUDGET_REACHED. - Running instances in the environment are terminated, with
stop_reasonset tobudget. - Inference calls with the environment’s API keys fail with HTTP 402: error type
insufficient_quota, codebudget_exceeded. - Owners and admins get an email and your webhooks get a
budget.reachedevent.
- New launches in the environment fail with HTTP 402 and error code
BUDGET_REACHED).
Everything resumes when the next month starts or when an owner or admin raises the budget.
Budgets are set in the dashboard only, on purpose: an agent holding an API key cannot raise its own ceiling. A
PATCH /api/v1/environments/{id} carrying monthly_budget_usd returns 403, code forbidden, with the message “Budgets are set in the dashboard”. The CLI, SDKs and MCP server can read a budget but cannot change it. An agent signed in through MCP or the CLI cannot raise or remove a budget either, and cannot switch to another environment: naming one returns 404.Reading a budget
GET /api/v1/environments/{id} returns the budget alongside the environment:
Amounts are in USD, rounded to the cent.
From an agent, the MCP tool
get_environment_budget returns the same three values for the environment in scope, or for the one named by environment_id. From the SDKs, client.environments.get(id) in Python and rc.environments.get(id) in TypeScript.
A launch refused by a budget returns:
InsufficientCreditsError for any 402. Check its code: BUDGET_REACHED means the environment’s budget, anything else means the workspace balance.
Alerts
Every guardrail alert goes to two places:- Email to every active owner and admin of the workspace.
- Webhooks: your own HTTPS endpoint, a Slack channel or a Discord channel, added by an owner or admin in Settings, Webhooks. See webhooks to set one up.
budget.threshold_reached (an environment at 80% of its budget), budget.reached (at 100%), instance.runtime_ending (10 minutes before max runtime) and instance.auto_stopped (an instance terminated by max runtime, idle stop, a budget or a low balance). Their fields and example payloads are in webhook events. The email goes out whether or not a webhook delivery succeeds.
Stop reasons
Every instance that has stopped carries astop_reason. It is null while the instance is running.