---
title: Agent action throttles
---

# 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`, and
`install`. `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](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](heavy-job-pacing.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.