---
title: Heavy job pacing (retired)
---

# Heavy job pacing (retired)

## What it is

Omniscio no longer paces ordinary shell commands or automatically queues every background job. The
old **Pace heavy background jobs** system used filesystem/PID slots, fixed start delays, load holds,
and long fail-open waits. It is retired and off. A historic saved `on` value cannot reactivate it.

The Settings -> Performance control is retained temporarily for configuration compatibility. It is
now labeled experimental/reserved, defaults off, and does not enable the retired implementation or
the replacement broker.

Omniscio contains one authenticated local broker for explicitly classified heavy operations:

- recursive search
- heavy Git
- heavy process starts
- build/test work
- package installation

The broker sidecar starts with the app by default (since 2026-09-08 — a plain `npm run dev`; it
serves the Verdict broker's budget credential), but a running sidecar paces NOTHING until pacing is
switched on: every heavy CLASS stays dormant while its crash, latency, and long-soak evidence is
completed, and a session gets the broker variables only while pacing is on. It is not a general
shell gate. Idle agents, ordinary commands, cheap Git, and small searches perform zero broker I/O.

Switching pacing on, either way, on the app:

- the setting `admissionBrokerV2Enabled` — "pace agent git through the broker"; read per spawn, so
  a flip reaches the next session with no restart, and with no class list the session gets
  `git-heavy`, the one class that was sized and measured;
- or `AMC_ADMISSION_BROKER_V2_CLASSES=<comma-separated classes>` for an explicit list (the app
  injects `AMC_ENABLE_ADMISSION_BROKER_V2=1` into sessions for you either way).

`AMC_DISABLE_ADMISSION_BROKER_V2=1` is the master rollback and wins over enablement;
`AMC_ENABLE_ADMISSION_BROKER_V2=0` on the app turns the sidecar itself off. Classes are
independent; enabling `build-test` does not pace search, Git, installs, or ordinary commands.

### Those two variables are not sufficient everywhere — check reach first

A lease also needs an endpoint and a credential. The endpoint is derivable, but the credential is
signed with a secret minted fresh each time the app launches, held only in the main process and
never written to disk, and it is handed to a process at **session spawn** only. So a process that is
not a descendant of an Omniscio-spawned session — a gate `.cmd` running under the Windows Task
Scheduler, or the cloud dispatch daemon — cannot obtain one at any setting of those variables. There
the broker is unreachable by construction, and setting the flags changes nothing.

Confirm before you rely on it: a running broker means a live
`\\.\pipe\omniscio-agent-admission-*` (Windows). **Measured 2026-09-05 on the primary dev box:** no
such pipe existed and every one of 4,731 admission requests over ~25 hours returned a no-op
pass-through. Closing that gap is slice S5a in
[agent-load-governance-contract.md](../../.claude/memory/contracts/agent-load-governance-contract.md).

## Where to find it

The old control is still visible at Settings → Performance, relabeled experimental and reserved, and it defaults off. A saved `on` value from before cannot bring the retired implementation back, and turning it on does not enable the replacement either.

## How it behaves

### What happens if it is unavailable

Safe read operations degrade immediately. Heavy process starts and build/test work return no
verdict before starting a child. Package mutation refuses, while its separate kernel-owned
package-store integrity fence stays active. The broker does not hold work for minutes and then
release the whole queue unpaced.

### Large fleets

The protocol is designed for at least 250 concurrent authenticated heavy-operation clients from 200
callers. This is not a guarantee that one computer can keep 200 complete agent processes resident.
RAM/commit, process and handle limits, desktop heap, simultaneous Git metadata reads, and provider
limits still apply. Use remote execution or keep a smaller local active set when the host cannot
carry that footprint.

## Related

- [Agent action throttles](agent-action-throttles.md)
- [Computer feels slow?](slow-computer.md)
- **Testing regimes** — Omniscio’s internal, developer-only guide to which verification harness fits which job; it is not shipped to customers.
