# Interactive Cluster

> All-purpose Databricks clusters bill 2 meters simultaneously: DBUs at the all-purpose rate, which is priced above job compute, and cloud VM hours for the driver plus every worker. Auto-termination set to 0 minutes means the cluster never stops itself, so ZopNight terminates interactive clusters on schedule outside working hours.

Source: https://zop.dev/integrations/databricks/databricks-cluster
Updated: 2026-08-19

---

An interactive (all-purpose) cluster is a driver plus workers used for notebooks and ad-hoc analysis. While it runs it feeds both Databricks meters at once: DBUs at the all-purpose rate (priced above the job-compute rate for the same machines) and cloud VM hours for every node. A cluster left up overnight pays both meters to do nothing.

## What counts as interactive

Discovery keeps only clusters whose cluster source is UI or API: the ones humans created. Clusters materialized by the platform for job runs, pipelines, SQL warehouses, and model serving are system by-products, excluded from inventory and scheduling alike. Captured metadata includes node type, Spark version, runtime engine, availability, policy, any backing instance pool, and the auto-termination window.

## Pricing an autoscaling cluster honestly

For autoscale clusters the fixed worker count reads 0 and the truth lives in the min and max bounds. Billing at max assumes the cluster always runs flat out; billing at min assumes it never scales. ZopNight uses the midpoint of the autoscale range, clamped to at least 1 worker, plus 1 driver, multiplied by node rate and on-hours. That proxy avoids inflating either the cost or the projected savings.

## Auto-termination alone is not enough

An `autotermination_minutes` of 0 means the cluster never stops itself. Even a sane value only measures inactivity: a dashboard or notebook that pokes the cluster hourly resets the clock forever. Schedules exist on top of auto-termination, not instead of it. The schedule enforces working hours; the timeout catches gaps inside them.

## Stopping is a Terminate, and that is destructive

The scheduled stop issues a cluster Terminate, which discards running state; resume recreates the compute fresh. That trade is acceptable for interactive workloads precisely because their state is disposable, and it is why job, pipeline, SQL, and model-serving clusters are never scheduled.

## See who never stops

```bash
databricks clusters list --output json
```

Scan the output for `state`, `cluster_source`, and `autotermination_minutes`. A cluster in `RUNNING` state with source `UI` and a termination window of 0 is the first candidate for a schedule.