Skip to main content
Deactivation ends a Loops run and its paired sampler. Save the checkpoints you need first: an ended run can’t resume, but saved checkpoints remain available to download or deploy, or to start a new run from. Closing your Python client releases local connections and stops its keepalive. It doesn’t deactivate the run.

​
When to deactivate

  • Serverless: An idle run incurs no token charges, so deactivation isn’t required to avoid idle billing. Deactivate the run when you want to end it and its paired sampler.
  • Dedicated: Deactivate the run when you finish to shut down its trainer and paired sampler deployments and stop GPU billing. Otherwise, the run ends after a period of inactivity.

​
Deactivate and check the run

Use the run ID from TrainingClient.run_id or list your runs. Set BASETEN_API_KEY to your workspace API key.
To deactivate the run:Run the following command, replacing <run_id> with your run ID:
Confirm when prompted. Pass --yes to skip the prompt in scripts.Then check the run’s status:
Check that the described run has status.name set to INACTIVE.

​
Other resources

Standalone samplers have their own lifecycle. Use Deactivate a sampler when you finish with one. Deactivating a run doesn’t stop an inference deployment created from its checkpoint or release external sandboxes. Follow the example’s cleanup instructions for those resources.

​
When a run ends on its own

A dedicated run stays active, and bills for GPU time, while a training client keeps it alive, even between training calls. Once the client disconnects, the run ends after 15 minutes with no requests by default. Explicit deactivation ends it without waiting for that inactivity period. To change the inactivity period, configure the timeout when you create a dedicated run. Saved checkpoints remain available after the run ends.