# Databricks serverless cost controls: who can run, and how fast

> Remove All Users from Default Automated Compute only after the thirty-day jobs audit. Leave the serverless rate limit unenrolled.

By Ihor Seleznov, 3 November 2026. Databricks Field Guide, TechFabric. Canonical: https://databricks.techfabric.com/notes/smarter-cost-controls-for-serverless/

We would not follow the start list in [Smarter cost controls for serverless](https://www.databricks.com/blog/smarter-cost-controls-serverless), published 29 October 2026. Taking Can Use off Default Automated Compute fails every serverless job and pipeline of the user who loses it, AI Runtime jobs included, and the list puts that edit last ([manage serverless compute](https://docs.databricks.com/aws/en/compute/serverless/manage-serverless-compute)). We'd do it first. Access control on the two default objects has been generally available since 3 August 2026, and every workspace user still holds Can Use ([serverless compute release notes](https://docs.databricks.com/aws/en/release-notes/serverless/)). The tag the list asks for first can wait, since it leaves the failing job in place until Can Use actually comes off.

`automated_grant` has to return the clear line before the Serverless tab is opened. We'd build `job_ids` from the thirty-day `JOBS` and `DLT` rows for that user's `identity_metadata.run_as`, read the job and pipeline ids from `usage_metadata`, and put the system-initiated jobs in `background_ids`, because the access check skips those ([manage serverless compute](https://docs.databricks.com/aws/en/compute/serverless/manage-serverless-compute)). Any id left in `job_ids` alone keeps All Users on Default Automated Compute: the revocation would fail work that person already runs on serverless. System-initiated background compute does not count. It isn't that person's job, and the access check skips it anyway.

```python
def automated_grant(job_ids, background_ids):
    """job_ids come from the thirty-day JOBS and DLT query.
    background_ids are the system-initiated jobs the access check skips."""
    if job_ids - background_ids:
        return "leave All Users on Default Automated Compute"
    return "All Users can come off Default Automated Compute"

assert automated_grant({"job-1"}, set()).startswith("leave All Users")
assert automated_grant({"job-1"}, {"job-1"}) == "All Users can come off Default Automated Compute"
assert automated_grant(set(), set()) == "All Users can come off Default Automated Compute"
```

The rate limit stays off this change. The [manage page](https://docs.databricks.com/aws/en/compute/serverless/manage-serverless-compute), updated 18 October 2026, still says Private Preview and leaves notebooks and Databricks Connect outside the cap. [The post](https://www.databricks.com/blog/smarter-cost-controls-serverless) calls that control Beta and available now. We'd wait for one stage. A notebook stays uncapped on the page we'd enroll from, and a disruption can fail the access check open, so we would not describe the grant as a budget. Finance can have the usage policy in [Cost and performance](https://databricks.techfabric.com/guide/cost-and-performance/). The [tags page](https://docs.databricks.com/aws/en/admin/account-settings/usage-detail-tags), updated 9 October 2026, still puts serverless notebooks, jobs, pipelines and model serving on that policy, in Public Preview, and lists no serverless compute object, while the post's tag on one is Beta.

Default Interactive Compute waits until the owner expects the attached notebook to fail on its next cell ([manage serverless compute](https://docs.databricks.com/aws/en/compute/serverless/manage-serverless-compute)). We'd review a Genie Agent on the warehouse grant in [Genie](https://databricks.techfabric.com/guide/genie/), where Databricks SQL sits outside both of these objects, and we'd leave what the notebook can reach on the network policy in [Security](https://databricks.techfabric.com/guide/security/). Book the interactive edit with the person whose notebook will drop.

```mermaid When we would take All Users off automated serverless
flowchart TD
  Q["Thirty-day JOBS and DLT ids"] --> G{"An id outside the background set"}
  G -->|"yes"| H["Leave All Users in place"]
  G -->|"no"| R["Remove All Users"]
  R --> N["Notebooks stay a separate grant"]
  N --> P["Leave the rate limit unenrolled"]
```

> **Our position**: We'd run `automated_grant` on the thirty-day `JOBS` and `DLT` ids and remove All Users from Default Automated Compute only when every remaining id is background compute. The rate limit stays unenrolled while the manage page says Private Preview and the post says Beta. A notebook stays uncapped, and the bill stays on the usage policy.