/prun

name: prun
description: Parallel delegation fan-out on Agy. The coordinating session decomposes and integrates while task units run in parallel as Agy processes (Gemini through the Antigravity CLI), never on the coordinator and never on Claude-side workers such as Sonnet subagents. Each unit runs unattended in a scratch dir or throwaway clone and gets follow-up turns while slower units finish. A unit runs on Codex only when the user names Codex for it, or on Grok only when the user names Grok for it. Unit count follows the dependency graph rather than a small fixed cap. Units may read or write code; workers never commit or push, and the session plus the user are the final integration gate.

prun (parallel run)

Overview

`prun` fans a task out into independent units that run in parallel while the current session only coordinates. **Every unit runs on Agy by default**: an Agy process running Gemini through the Antigravity CLI, on the Google AI plan authenticated in `agy`. A unit runs on Codex only when the user names Codex for it, or on Grok only when the user names Grok for it (see Executors). The coordinator decomposes the task, dispatches the units, gathers their results, reviews their diffs, and integrates. It never runs a unit itself.

**No Claude-side workers.** A Sonnet subagent, a Workflow agent, or any other Agent-tool worker draws on the same Claude account as the coordinating session, so a fan-out of them spends the pool the session itself needs, and it drained fast once `prun` routed units to Sonnet. Exact plan buckets can change, so inspect current Agy quota before a large batch.

Relationship to the native Workflow tool

The native Workflow tool fans a task out across **Claude** subagents under a deterministic script, with structured output, judge panels, and resume. A Workflow run counts against the Anthropic plan's usage and rate limits.

`prun` is the fan-out that stays off that account. Its units run on Agy and use the Google AI plan; the session spends only the small Anthropic amount it needs to decompose, dispatch, read results, and integrate. `prun` never starts a Workflow or a Claude subagent, not as a unit, a fallback, or a second panel. A Claude panel the user explicitly asks for is a Workflow run outside `prun`. A cross-vendor read on staged work is what `/vet` is for.

When the Agy Gemini group cannot accommodate the next batch, queue or defer units instead of moving them onto the Claude account or Codex. Read the meter with `agent-quota`, including snapshot age and reset times, and do not silently shrink a genuinely parallel task to an arbitrary two or three workers. The dispatcher's own quota route already stops a unit from launching into an empty group.

When to use

Use `prun` when the task splits into **independent units that can run at once** (different modules, separate research questions, parallel analyses). Units may be heterogeneous, and there can be **many of them**: a dozen or twenty in parallel is normal when the task warrants it.

Do not use `prun` when the task is one sequential unit, or units depend on each other's output, or a unit's result cannot be checked without redoing it.

Executors

| Executor | Quota | Notes | |---|---|---| | Agy (`agy`) | Google AI plan authenticated in Antigravity | **The default worker.** Runs the registry's `prun-worker` model and effort for Agy; fast, separately funded, and dispatched with full unattended tool permission inside a scratch dir or throwaway clone. | | Codex (`codex`) | Codex plan, the pool `/vet` reviewers use | **Only when the user names Codex** for a unit or a batch. Runs the registry's `prun-worker` model and effort for Codex through `dispatch-task.sh` (`.ps1` on Windows). | | Grok (`grok`) | Grok plan authenticated in the Grok CLI | **Only when the user names Grok** for a unit or a batch. Runs the registry's `prun-worker` model and effort for Grok through `dispatch-task-grok.py`. | | Claude session (this session) | Current Claude account; check Settings > Usage for the applicable limits or credits | Coordinator and integrator only, on whatever model is selected. Never a unit. |

Rules:

• **Every unit runs on Agy by default.** Research, verification, extraction, cross-checks, and

code-writing units in a throwaway clone all go through `dispatch-task-agy`. The dispatcher gives a unit the same unattended capability as the `/vet` Agy reviewer, so it can verify numbers, run experiments, and fetch the web. The registry (`user/agent-models.json`, see the `agent-models` skill) decides the worker model and effort: its `prun-worker` row, Agy column. That row names a cheaper model than the `/vet` reviewer runs, on purpose: on 2026-10-13 a run on the reviewer's model cost about four times a run on the worker model of the same task on Agy's five-hour meter. A unit that needs another model names it in `ANTIGRAVITY_DISPATCH_MODEL`. An unreadable registry exits 2 and names the registry; the dispatcher never guesses a model.

• **Never a Claude-side worker.** Do not spawn an Agent-tool subagent (Sonnet or any other model)

or a Workflow agent for a unit, including as a fallback when the Agy pool is short. Those workers spend the coordinating session's own Claude account. When Agy cannot take a batch, queue it or tell the user.

• **Codex only when the user names it.** A unit goes to Codex only when the user's request names

Codex for that unit or for a batch ("a small /prun with codex for the hard problems"). The coordinator never picks Codex on its own, and never as a fallback when Agy is short: queue the units or tell the user. A Codex unit runs through `dispatch-task.sh` (`.ps1` on Windows), never a hand-typed `codex exec`, and its model and effort come from the registry's `prun-worker` row for Codex, not from the command line or the interactive Codex config.

• **Grok only when the user names it.** A unit goes to Grok only when the user's request names

Grok for