Agent action throttles

What it is

Settings → Performance

The former filesystem/PID throttles are retired and off. Historic saved on values do not turn them back on. In particular, Omniscio no longer delays every shell command, so an ordinary command does not wait for a slot, run a PowerShell process probe, or read a pacing file.

The switches for search, Git, installs, shell commands, new-session starts, and worktree creation remain visible temporarily for settings compatibility. They are labeled experimental/reserved and default off. They do not activate the retired implementation.

Where to find it

Every control on this page lives in Settings → Performance. The switches for search, Git, installs, shell commands, new-session starts, and worktree creation are kept visible there temporarily for settings compatibility — labeled experimental/reserved and default off — and pacing heavy work through the broker is switched on from the admissionBrokerV2Enabled setting, described as "pace agent git through the broker."

How it behaves

Protections that remain active

Removing pacing did not remove correctness or narrow safety controls:

• Git keeps bounded thread counts and no-lazy-fetch safeguards.
• Broad search keeps root rejection and junk-folder exclusions.
• find batching/pruning remains independently enabled by default because it prevents one command from creating a process per file.
• Worktree mutations still go through Dev Pipeline authority.
• Compiler/toolchain enforcement remains active.
• Critical automated recovery still respects the memory-cliff protection.
• Dependency writes still require the package-store integrity fence.

These controls do not queue ordinary commands.

Next-generation broker

Omniscio includes a new authenticated local broker for explicitly classified heavy work. Since 2026-09-08 the broker sidecar itself starts with the app by default (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 the reliability and scale proofs run, and a session gets the broker variables only while pacing is on. It is not a blanket shell gate.

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).

Available classes are recursive-search, git-heavy, process-start-heavy, build-test, git-rebase, ready-mint, and install; three of them (build-test, git-rebase, ready-mint) ship on by default. 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. Class enablement is independent; turning on one class does not pace the others.

Those two variables are necessary, not sufficient. A lease also needs an endpoint and a credential, and the credential is handed out only at session spawn, so a process that is not a descendant of an Omniscio-spawned session — a gate .cmd under the Windows Task Scheduler, the cloud dispatch daemon — cannot get one at any flag setting. Check for a live \\.\pipe\omniscio-agent-admission-* before assuming a class is active; measured 2026-09-05, none existed and 4,731 consecutive requests were no-ops. Detail: heavy-job-pacing.md.

If the broker is unavailable, safe read work degrades immediately, build/test or heavy process work returns no verdict, and package mutation refuses. It never waits to a ceiling and then releases the same queued cohort unpaced.

Large fleets

Idle agents and ordinary commands open no broker connection. The broker is designed to scale with concurrent heavy operations, not total session count. Keeping 200 local agent processes resident is a separate hardware question: RAM/commit, Windows process and desktop-heap limits, file handles, and simultaneous Git metadata reads still cost real resources. Use remote execution or a smaller active local set if the machine cannot carry that resident footprint.

Related

• Pace heavy background jobs
• Computer feels slow?
• Testing regimes — Omniscio’s internal, developer-only guide to which verification harness fits which job; it is not shipped to customers.