delegation

name	delegation
description	Model routing for delegated work — use when spawning subagents or workflows, choosing a model for a task, or handing work to the Codex runtime. (Claude Code side; other agents rarely delegate.)

Delegation — Model Routing

General preferences

• If asked to do too much work at once, stop and state that clearly.
• If computer use is helpful for completing or verifying work, shell out to Codex for it using the configured model or profile.
• Keep model IDs out of this skill. codex exec without --model inherits the configured or recommended model. When a task needs a different cost/capability tradeoff, use a stable named profile and keep its model ID in Codex configuration.

Picking the right models for workflows and subagents

Choose by task characteristics, not release names. Intelligence is how hard a problem the worker can handle unsupervised. Taste covers UI/UX, code quality, API design, and copy. Cost reflects the user's effective usage limits, not list price.

How to apply:

• These are defaults, not limits. You have standing permission to override them: if a cheaper model's output doesn't meet the bar, rerun or redo the work with a smarter model without asking. Judge the output, not the price tag. Escalating costs less than shipping mediocre work.
• Don't let cost prevent you from using the right model for the job. Instead, take advantage of cheaper options to get more information and try things before moving the work to a more expensive option.
• Cost is a tie-breaker only; when axes conflict for anything that ships, intelligence > taste > cost.
• Bulk/mechanical work (clear-spec implementation, data analysis, migrations, convention mining, codebase sweeps): route through Codex using the configured workhorse or default profile.
• Difficult, ambiguous, or high-value work: use the strongest appropriate configured profile and increase reasoning effort before changing runtimes.
• Anything user-facing (UI, copy, API design) needs a runtime or profile demonstrated to meet the user's quality and taste bar.
• Reviews of plans or implementations should use a strong reviewer, with a different runtime or profile as an optional independent perspective.
• Do not use the smallest, lowest-capability Claude tier for delegated work.
• Claude stays for synthesis, judgment, and taste stages — the orchestrator, not the workhorse.

The habitual failure mode

The recurring violation is not picking the wrong model deliberately — it is running bulk work on Claude by default because Claude is the runtime you are already in. Spawning a Claude subagent for a codebase sweep, or running every Workflow stage on the session model, both feel natural and both misroute. Before ANY delegation (Agent call, Workflow stage, background task), classify first: is this bulk/mechanical? Then it goes through Codex using the configured workhorse or default profile, and staying on Claude requires a reason, not a habit. When launching multi-stage work, state the per-stage routing up front so it can be reviewed before tokens burn.

Codex mechanics

Codex work runs through the Codex CLI: codex exec for work, codex review for reviews. The claude-code plugin stays out of the agent's model of the world — its stop-time review gate runs as an ambient hook, and its slash commands are for the human to type. Route everything agent-initiated through the CLI:

• One self-contained prompt per run: codex exec -s read-only "..." for investigation/analysis, codex exec --sandbox workspace-write "..." for edits. Long-running goals: nohup codex exec ... > /tmp/<job>.log &, observed via that log and the rollout jsonl under ~/.codex/sessions/<y>/<m>/<d>/.
• One goal = one session. Parallel sessions sharing a state file (a PROGRESS.md, a scratch dir) stomp each other's checkpoints — kill the old session (pgrep -f "codex exec") before relaunching with a steering note.
• Codex runs can exceed Bash's 10-minute timeout: pass an explicit timeout, or run in the background and poll for the report file.
• Omit --model for the configured default. If routing requires a distinct capability or cost tier, use --profile <name> and let that profile own the current model ID.

Using Codex inside workflows and subagents (the model parameter only takes Claude models, so use a wrapper):

• Spawn a thin Claude wrapper agent (model: 'sonnet', effort: 'low') whose prompt instructs it to write a self-contained codex prompt, run codex exec via Bash, and return the report (use schema on the wrapper for structured output back).
• Always label these agents with a codex: prefix, e.g. {label: 'codex:review-auth'} — the workflow UI shows the wrapper's Claude model, so the label is the indication that the real worker is Codex.
• Parallel Codex implementation agents must use isolation: 'worktree' so codex edits don't collide in the shared checkout.
• Workflow token budgets only count Claude tokens; codex work is free and invisible to budget.spent().

Sandbox (workspace-write) — verified empirically 2026-07-09:

• Network is a config setting — check it, don't remember it: grep -A1 sandbox_workspace_write ~/.codex/config.toml on the machine you are on, or enable per-run with -c sandbox_workspace_write.network_access=true. The banner line of every run states the effective mode.
• GPU adapters, binding local sockets, and killing processes are NOT grantable in workspace-write; outbound localhost is allowed. For goals that need GPU, eval sweeps, or process control, front-load the access decision: ask the user for --sandbox danger-full-access at launch time. A relay — the sandboxed agent writing a script for the orchestrator to execute unsandboxed — is permission laundering; the permission classifier blocks it. Alternative when full access isn't warranted: a server split, where the orchestrator owns the long-lived GPU process unsandboxed and sandboxed codex connects to it over localhost.
• A network-enabled sandbox makes delegated prompts an injection surface. Never feed untrusted content (web pages, third-party code) into a codex run that can also reach the tailnet.