/prun

name: prun
description: Parallel delegation fan-out. The Claude session coordinates (on whatever Claude model is currently selected, e.g. Opus or Fable) while task units run in parallel on workers (never on the coordinator). Codex (`codex exec`, a separate abundant account) is the prioritized default; Sonnet is reserved for units needing Claude-session-internal capabilities (MCP/email tools, Artifacts, cross-vendor web verification), with the orchestrator deciding per unit. 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 on separate-quota or in-session workers, while the Claude session only coordinates. Workers are **Codex** (`codex exec`, a separate abundant account, frontier model) and **Sonnet** subagents (inside the Claude session). **Codex is the prioritized default**: its quota is separate from the Claude plan and its current model (gpt-5.6 tier) is strong on hard reasoning and code, so most units go to Codex. **Sonnet is reserved** for units that need something the Claude session uniquely provides (see the Executors rule). The coordinator decomposes the task, dispatches the units, gathers their results, reviews their diffs, and integrates. It never runs a unit itself.

The orchestrator picks the executor per unit; when in doubt, Codex. A Codex unit runs through the separately authenticated Codex/OpenAI account, so the worker run does not draw on the Claude plan at all. A Sonnet unit and the Claude coordinator both consume the current Claude account's quota; the exact split across models and weekly buckets depends on the plan and on active promotions and shifts over time, so check Settings > Usage before relying on any model-specific split. Codex is the default because its worker run is outside the Claude plan; keep Sonnet units targeted because they draw Claude-side quota.

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, and its agents use the session model unless the script routes a stage to a different Claude model.

`prun` has a different quota shape. A **Codex** unit is dispatched by a shell call to `codex exec`, so the worker run uses the separate Codex/OpenAI account. A **Sonnet** unit and the coordinating session both draw the current Claude account's quota, so reserve Sonnet for units that need the Claude session's own tools. The coordinating session also spends a small Anthropic amount while it decomposes, dispatches, reads results, and integrates.

The two relate in two ways, both with the current session as the orchestrator:

• **Substitute (quota).** When the Anthropic pool is too constrained to run a Workflow, use prun

with Codex-only units, or keep any Sonnet units small and targeted. This shifts the heavy fan-out to Codex while leaving only the coordinator and any chosen Sonnet work in the Anthropic pool.

• **Complement (diversity).** When a Workflow is affordable and you want cross-vendor perspectives,

run a Claude panel through the Workflow and a Codex panel through prun. Use the same structured contract and the same question on both sides, then cross-check. Agreement across vendors is usually a stronger signal than agreement inside one model family, because shared model lineage and tools can share blind spots. Invoke them together in one natural-language request; no special mode is needed. Reserve this for high-stakes work (a review, an audit, a hard design call), since it spends both pools and the coordinator must merge two result sets.

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 | |---|---|---| | Codex (`codex exec`) | Separately authenticated Codex/OpenAI account; abundant | **Prioritized default.** Frontier model (gpt-5.6 tier), strong on hard reasoning and code, and the worker run spends no Claude-plan quota. Run many in parallel. | | Sonnet subagent | Current Claude account; check Settings > Usage for the applicable limits or credits | Reserved, not a default. Runs in the Claude session, so it alone can reach session-internal tools (MCP / email / Artifacts) that Codex cannot. | | 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. |

Rule: **units never run on the coordinator (the Claude session itself).** The orchestrator picks the executor per unit, with a strong default toward Codex:

• **Codex is the default for almost every unit** (code, research, analysis, web fetch). Its quota is

separate and abundant and its frontier model (gpt-5.6 tier) is capability-competitive with the top Claude models, so there is rarely a reason to prefer another worker. Start here.

• **Sonnet is the reserved exception, chosen only when a unit needs a tool the Claude session has but

the isolated Codex worker does not.** Codex is an external process, so route to Sonnet when a unit needs a session-internal MCP / email connector (Gmail, Calendar, Drive, Slack), the Artifact tool, or a **cross-vendor web-search verification** where you want a Claude-side `WebSearch` result to cross-check the Codex one. A normal Sonnet subagent inherits the session's available tools but **s