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

# Automated Rebalance

> How nOps moves unused seat limit to the seats about to hit their cap — the workflow modes, the trust scorecard it has to pass before it can write, and the safeguards that hold it back.

**Automated Rebalance** watches pooled seat spend and moves unused limit to the seats about to hit their cap, so nobody gets blocked mid-period.

Because it writes to your provider, the default posture is that it *cannot*. It has to earn write access against a published scorecard you can watch in the product, and it loses that access the moment a write cannot be verified. This page documents exactly how that works, so you can decide whether to trust it before turning it on.

<Note>
  Automated Rebalance is an admin-only tab inside seat tracking, not a sidebar entry. It unlocks once your budget is ready. Unattended limit changes are supported for **Claude Enterprise** only — Cursor and ChatGPT / Codex seat limits are read-only in nOps.
</Note>

## Get started

1. Sign in to [nOps](https://clara.nops.io/dashboard).
2. Open your seat tracking project and go to the **Automated Rebalance** tab.
3. Open the **Automation** card and read the **Trust scorecard** before changing anything.
4. Leave the workflow on **Observe** until the scorecard says **Eligible**.

If you have no provider that supports limit writes, the tab tells you so: *Enable an AI seat tracking provider with limit writes to configure automation.* Seat recommendations still show; nothing can be applied.

## Key features

### The Automation card

A collapsible card with two tabs, **Settings** and **Activity**, plus two controls in its header:

* **Enable** turns detection on and off.
* **Run now** triggers a check immediately instead of waiting for the schedule.

The card's status reads **Detection off**, **Observing pool**, **Approve before apply**, or **Auto-rebalancing**, depending on how it is configured.

### Workflow modes

Under **Settings**, three tiles decide what a run is allowed to do. Checks happen about hourly; if raise or lower recommendations exist, the run honors whichever mode you picked.

| Mode        | What a run does                           |
| ----------- | ----------------------------------------- |
| **Observe** | Detect only, never write to the provider. |
| **Approve** | Propose changes for a human to confirm.   |
| **Auto**    | Apply limit changes immediately.          |

Click **Save settings** to apply. Email and chat notifications for rebalance runs are configured in project settings.

<Warning>
  The workflow mode is a preference, not a permission. A policy still cannot write unattended until it has passed the trust scorecard, regardless of which tile is selected.
</Warning>

### Triggers

By default every check runs on the schedule. Turn on **Only run when pool is tight** to skip the hourly check unless something actually warrants it:

| Setting                                | What it does                                               |
| -------------------------------------- | ---------------------------------------------------------- |
| **Run when remaining pool hits**       | Fire when the remaining pool falls to a dollar figure.     |
| **Run when pool spend reaches**        | The same trigger expressed as a percentage of the pool.    |
| **Min spend before checks**            | A floor, so early-period noise does not trigger runs.      |
| **Forecast breach** and **Days ahead** | Fire when the forecast says you will breach within N days. |

Under **Advanced**:

* **Custom pool cap** overrides the pool size. Leave it blank to use the budget target.
* **Open requests before graduation** lets runs open seat requests and wait for a human while the trust score is still building. Automation still never writes on its own — someone has to approve the run. This is unavailable in Observe, which never opens requests.

### The trust scorecard

The **Trust scorecard** card shows the evidence required to graduate out of the current autonomy state, with a pill reading **Eligible** or **Building trust**. Every criterion must pass.

| Criterion                       | Requirement                                    | Why it exists                                                                              |
| ------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Observation window**          | 7 days by default                              | Enough calendar time to cover a full weekly spend cycle.                                   |
| **Qualifying hours observed**   | 50 distinct hours by default                   | Confirms the controller has seen this budget repeatedly over real elapsed time.            |
| **Settled forecast samples**    | At least 1                                     | Graduation cannot rest on forecasts that were never checked against reality.               |
| **Forecast error**              | Mean absolute percentage error at or below 25% | The controller must be able to predict this budget before acting on it.                    |
| **Simulated budget violations** | Exactly 0                                      | If any recommendation *would have* pushed allocations past the pool, that disqualifies it. |
| **Recommendation samples**      | At least 5 recommendation transitions          | Churn cannot be judged from an empty sample.                                               |
| **Recommendation churn**        | Below 10%                                      | A controller that keeps reversing itself is unstable, whatever its average accuracy.       |

The card shows your live figures next to these: elapsed versus required days, qualifying hours, forecast error with its settled sample count, churn with its reversal count, and **Budget adherence**, which reads **No violations** when clean.

#### What counts as evidence

Only outcomes that reflect an actual decision count toward graduation. Runs that errored out, found nothing worth deciding on (no pool to work with, no managed seats, or a conflicting policy already holds write access), or were held back before they got that far (rate-limit backoff, another run still in progress) don't count.

A policy cannot graduate because its runs kept failing or getting skipped. A run that looked at a healthy pool and correctly did nothing *does* count.

Evidence accrues by the distinct UTC hour, not by the number of runs — several runs inside the same hour count once, and you can bank at most 24 hours of credit per day. The floor always implies real elapsed time.

### Rebalance History

The **Activity** tab and the **Rebalance History** panel record every run.

| Run status            | Meaning                                             |
| --------------------- | --------------------------------------------------- |
| **Proposed**          | A recommendation was recorded; nothing was written. |
| **Awaiting approval** | The run is parked waiting for a human.              |
| **Applied**           | Limit changes were written and verified.            |
| **Failed**            | The run errored.                                    |
| **Skipped**           | The run was suppressed before deciding.             |

Each run also records what triggered it: **Manual**, **Threshold**, **Forecast**, or **Scheduled**.

A run **Awaiting approval** offers **Approve** and **Undo**. A **Proposed** run offers **Undo**. Pending runs also point out that you can review each seat change individually as an open request on the [Requests](/ai/requests) tab, if you would rather decide seat by seat than approve the whole run.

## How often it runs

Every tracked budget is checked on a fixed hourly schedule. There is no faster path, and there is no way for a check to decide it should run more often.

That is a deliberate constraint rather than a limitation. A check that can decide to run itself more often can drift into checking far more frequently than anyone intended, with no setting you could point to that explains why. Keeping the schedule as the only trigger means the frequency you see in **Settings** is the frequency you get — it can't quietly speed up on its own.

Raising a seat's limit sooner is still possible: open a seat request and approve it, or use **Run now**.

## Safeguards

**Every write is verified.** After changing a seat limit, nOps re-reads that user's effective limit from the provider and confirms it matches the intended value. A write that cannot be verified — wrong value, unreadable, or the provider identity no longer matches — is recorded as a failure, not a success.

**Failed verification revokes autonomy.** A policy that fails reconciliation is demoted back to Observe. It stops writing immediately and has to earn write access back through the scorecard.

**One unattended writer per provider.** Only one policy per organization may hold write autonomy for a given provider. If a second policy would otherwise graduate, graduation is refused and the conflict is logged. Claude Enterprise spend limits are organization-wide, so two controllers writing to the same roster would fight each other with no audit trail explaining the result.

**Rate limits are respected.** Provider calls back off and retry rather than hammering your provider organization's shared request budget.

## What it will never do

* Write to your provider while in Observe.
* Graduate itself without every scorecard criterion passing.
* Raise a seat's allocation past the budget pool.
* Change Cursor or ChatGPT / Codex seat limits.
* Keep writing after a write failed to verify.

## FAQs

<AccordionGroup>
  <Accordion title="Can I skip the observation period?">
    No. There is no setting that grants write access immediately. The scorecard is the only path.
  </Accordion>

  <Accordion title="Why isn't my policy graduating even though it has run hundreds of times?">
    Check which criterion is unmet on the scorecard. The two most common causes are **Qualifying hours observed** — runs that were skipped, backed off, or failed do not count, and multiple runs in the same hour count once — and **Recommendation samples**, because a policy that has never changed its recommendation has no churn sample to judge.
  </Accordion>

  <Accordion title="How do I revoke autonomy manually?">
    Set the workflow back to **Observe**, or turn off **Enable**. It stops writing on the next run.
  </Accordion>

  <Accordion title="Can I let automation open requests before it has graduated?">
    Yes. Turn on **Open requests before graduation** under **Advanced**. Runs will open seat requests and wait for a human. Automation still never writes on its own.
  </Accordion>

  <Accordion title="Why is the tab missing for me?">
    It is admin-only, it lives inside seat tracking rather than the sidebar, and it unlocks only once the project's budget is ready.
  </Accordion>
</AccordionGroup>

## Related

* [Requests](/ai/requests)
* [Budgets](/ai/budgets)
* [Wallets](/ai/wallets)
* [Claude Enterprise integration](/integrations/claude-enterprise)