Docs / Budget caps and auto-destroy

Budget caps and auto-destroy

GPU instances are expensive and easy to forget. LLM Hangar treats runaway spend as a failure mode to engineer against, not a support ticket to apologize for.

Budget caps

Every deployment can carry a spend cap. When the estimated infrastructure spend reaches the cap, the deployment is destroyed automatically and you get an email naming the deployment and the amount. Caps can be raised while a deployment runs; they cannot be quietly lowered around a running workload.

Self-destruct timers

A deployment can be given a time to live, for example 24 hours. When the timer expires the deployment is destroyed, whether or not anyone remembers it exists. Trial deployments always carry one.

Stop and resume

Stopping a deployment shuts the instance down without destroying it, which stops the largest part of the bill while keeping the deployment ready to resume. A wake/sleep schedule automates this, for example running only during working hours.

Verified teardown

When a deployment is destroyed, for any reason, we do not just fire a delete call and hope. The teardown checks with your cloud provider that the resources are actually gone before the deployment is reported destroyed, and keeps re-checking until that is confirmed. If your provider keeps billing after a failure, that gap is visible, not silent.

One honest limit: your cloud provider bills you directly, and their meter, not our estimate, is the invoice. Caps and timers bound the window in which spend can accumulate; they are estimates from catalog prices, not a guarantee of the exact invoice amount. The consent step at deploy time states exactly this.

Warm stages and storage cost

If a prepared stage is kept after a destroy so the next boot is fast, its storage keeps a small cost in your account. Stages are listed with that cost in the dashboard and can be deleted at any time.