Billing

Deployments consume the workspace’s GPU credit while their replicas are running (how balances, funding, and the $0 rule work: Billing). Billing is metered per replica: each GPU box charges from its launch (warmup included) until it’s terminated, so a deployment that scales from 1 to 3 replicas and back pays for exactly the box-minutes that ran.

​

Billing cadence

Charges accrue per minute while any replica is up. When you call stop (or a min_replicas: 0 deployment parks itself), Veri settles each replica up to the moment its GPU was freed. Each replica’s cost is computed exactly over its lifetime (the final partial minute is prorated) and rounded once at settlement, not rounded minute by minute.

​

Billing states

A replica swap (drain?replace=true) runs one extra box for its overlap: the replacement bills from its launch while the old replica keeps serving, and the old replica bills until its drain ends. A replacement that fails is billed only for the time it ran. Balance enforcement follows the same rule: when a parked deployment wakes, its spend counts from the new boot. Time spent parked is never charged and never counted against your balance.

​

Cost and uptime you see

The dashboard and the metrics API use the same per-replica windows billing charges:

• total_cost_usd on the deployment is what has been settled to your balance so far.
• GET /v1/deployments/{id}/metrics returns total_cost_usd accrued over the deployment’s whole life (every replica of every boot, up to now, before rounding to the cent) and uptime_seconds, the time at least one box was up. Both count every boot and leave out time spent parked.
• GET /v1/deployments/{id}/metrics/timeseries reports cost_usd per bucket: the billed time of each replica that fell in that bucket. An hour in which nothing ran costs $0, and the buckets add up to the window’s cost_efficiency.cost_usd.

​

Avoiding idle bills

A deployment with min_replicas of 1 or more (the default) keeps its warm floor running until you stop it — that’s what you asked for, so there’s no idle auto-stop on those. Options, from most to least automatic:

1. Create with min_replicas: 0 — the deployment parks itself (scaled_to_zero, $0) after its idle window (scale_to_zero_window_seconds, default 1 hour, counted from when it starts serving or from its last request) and wakes on the next request. Expect a multi-minute cold start on the first request after parking.
2. Add idle_delete_after_days — a parked deployment with no traffic for that many days is auto-stopped for good.
3. Wrap deployments in try/finally — guarantees stop even if your code errors:
   dep = client.deployments.create(...)
   try:
       dep.wait()
       # ...do work...
   finally:
       dep.stop()
   
4. Monitor active deployments — regularly list deployments and stop anything no longer in use.
5. Set a spend alert or auto-reload: a spend alert emails you at 75% and 100% of a monthly threshold, and auto-reload tops up the balance from your saved card when it drops below a threshold. There is no low-balance webhook.

​

Comparison vs training jobs

Training jobs run for a fixed duration and stop themselves. Deployments run until you stop them. If you only need to spot-check a trained model, run a short batch of requests against the deployment and stop it immediately after.

​

Where to go next