operate-pi-dispatch

Operating pi-dispatch

pi-dispatch is a queue that runs paid autonomous agent jobs. The admin extension exposes tools to observe and operate a deployment. Some tools only read; some turn processing on and off; some change money-affecting configuration and are gated behind a human confirmation.

The tools

Observe (no approval needed):

• dispatch_status — queue/worker state, today's budget, settings overlay, schedulers.
• dispatch_runs — recent run records (PII-free). Raw job logs are never available to tools.
• dispatch_costs — cost analytics folded from the run history: window totals (window = 7d/30d/mtd), daily buckets, per-flow and per-model rollups, subscription plan verdicts, provenance (flow filters to one flow). Every dollar in the fold is typed { usd, class, ... }: quote the class with the number (metered is measured, estimated/seeded are not), and never present an estimate as an exact spend. When a dollar cap applies, a dollars block sits beside the fold: the dollar windows (each window's counter, spent and held, against its cap, and what settled) and each run's dollars. Those amounts are integer micro-dollars (1 USD = 1000000) with no class: they are the caps' own accounting. The operator sees the same fold drawn as charts on the operator console's insights page (/insights?range=7d|30d|mtd; /dispatch insights [7d|30d|mtd] prints its URL, and the console runs only when started with pi-dispatch-console serve). Its what-if form (/dispatch insights whatif <provider/model> --flow <flow> prints that URL) estimates what a flow would cost per run on another model's rates.
• dispatch_triggers — the configured triggers with their array index (needed to edit/delete one).
• dispatch_projects - the projects (projects.json): each id, display name, members, and the scoped-limits rows that cap it. dispatch_costs folds spend byProject by the id each run recorded, and its project filter (an id) scopes the whole fold to that project's runs. A run outside every project, or recorded before projects existed, is (no project): say so rather than guessing which project an old run "belongs to".
• dispatch_allocations - the allocation envelope (a dollar total per window and a floor per project) and the split applied inside it: each project's share and spend in micro-dollars, the applied plan's id and writer, and the last 20 outcomes. It never returns the reasons a plan gave; the operator reads those in the panel (b).
• dispatch_capacity: how busy each worker host was over window (24h, 7d or 30d, default 7d; host narrows to one): busy and idle share, jobs at once, memory and CPU promised against the budget, CPU used, the wait for a slot and the busiest projects, as text and as the report. It counts this deployment's jobs only (a machine busy with other work reads as idle), and history before its sources start is missingMs, never idle; a host that is new, or was down, inside history that is there reads as idle for that time. Say so when the coverage is cut, local only, or names running jobs not counted, rather than reading a quiet host into it. The operator sees the same 7 days per host, under its running jobs, in the panel (u).