> ## Documentation Index
> Fetch the complete documentation index at: https://docs.veri.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Billing

> Deployment billing states, per-replica metering, and scale to zero.

Deployments consume GPU credit while their replicas are running. 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.

## Billing states

| Status           | Charging?                                                         |
| ---------------- | ----------------------------------------------------------------- |
| `queued`         | No                                                                |
| `provisioning`   | Replica warmup is billed retroactively once the deployment serves |
| `serving`        | **Yes** (per running replica, draining replicas included)         |
| `unhealthy`      | **Yes** (transient state during health failure)                   |
| `scaled_to_zero` | No                                                                |
| `waking`         | No (the new boxes bill once they launch)                          |
| `stopped`        | No                                                                |
| `failed`         | No                                                                |

## 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) 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:
   ```python theme={null}
   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 up the low-balance webhook** — Stripe will email at configurable balance thresholds

## 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 evaluate a trained model, consider running an eval (which uses an existing deployment briefly) and stopping the deployment immediately after.

## Where to go next

<CardGroup cols={2}>
  <Card title="Hosting & GPU sizing" icon="server" href="/deployments/hosting">
    Pick the right GPU before deploying.
  </Card>

  <Card title="OpenAI compatibility" icon="code" href="/deployments/openai-compat">
    What works, what doesn't.
  </Card>

  <Card title="Deployments API" icon="play" href="/api-reference/introduction">
    `create` / `stop` endpoints.
  </Card>

  <Card title="Deployment analytics demo" icon="book" href="/demos/deployment-analytics">
    Planned walkthrough for request, token, latency, and replica metrics.
  </Card>
</CardGroup>