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), and pacing ships ON with it: the app setting admissionBrokerV2Enabled defaults to true, so an app-spawned session is handed the broker variables and paces every class sized so far — git-heavy plus build-test, git-rebase and ready-mint. The remaining three classes (recursive-search, process-start-heavy, install) stay dormant until their own crash, latency, and long-soak evidence is completed, and a session gets the broker variables at all only while pacing is on and the sidecar is ready. It is not a general shell gate. Idle agents, ordinary commands, cheap Git, and small searches perform zero broker I/O.

Narrowing or widening that set, on the app — either is enough:

• 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 is handed git-heavy,build-test,git-rebase,ready-mint;
• or AMC_ADMISSION_BROKER_V2_CLASSES=<comma-separated classes> for an explicit list, which wins outright — including a list that names nothing (the app injects AMC_ENABLE_ADMISSION_BROKER_V2=1 into sessions for you either way);

The classes are recursive-search, git-heavy, process-start-heavy, build-test, git-rebase, ready-mint, and install. Three ship on by default — build-test, git-rebase (concurrent rebases on one object store) and ready-mint (concurrent ready-mints across the box, capped at 6) — each armed by a CODE default so a plain npm run dev needs nothing set, and each sized from a measurement of its own contention rather than a guess.

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.

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
• Computer feels slow?
• Testing regimes — Omniscio’s internal, developer-only guide to which verification harness fits which job; it is not shipped to customers.