use-codex: A Skill for Offloading Context-Heavy Work from Claude to Codex

What use-codex Actually Is

use-codex is a skill for Claude that lets the parent agent spawn one or more OpenAI Codex CLI subagents from bash. The idea is simple: coding, research, discovery, and other context-heavy work gets handed off to a separate Codex process, which burns its own tokens and returns only its final message. The parent Claude keeps its context window clean and focuses on planning and synthesis.

The skill is marked `builtIn: true` and, per the context around it, ships pre-built into the Chorus agent. The pitch attached to it is aggressive — the claim is that delegating implementation work this way can cut Fable token usage by around 90%. Treat that number as a marketing figure rather than a measured benchmark; your actual savings depend entirely on how much of your workload is genuinely context-heavy.

The mechanism, though, is concrete and easy to understand. There's a documented "Golden Rule": if a task plus its intermediate work would add 3,000 or more tokens to the parent context, spawn a subagent instead. That's a clear, checkable heuristic rather than a vague promise.

How It Works in Practice

Under the hood, the skill calls the Codex CLI directly. The canonical invocation pipes a prompt via stdin into `codex exec`, runs GPT 5.5 with a chosen reasoning effort, and writes the result to a file:

```bash

cat <<'EOF' | codex exec --yolo --skip-git-repo-check \

-m gpt-5.5 -c 'model_reasoning_effort="xhigh"' \

-o /tmp/codex-result.txt -

[TASK CONTEXT] ...

[OBJECTIVES] ...

[OUTPUT FORMAT] ...

EOF

result=$(cat /tmp/codex-result.txt)

```

Reasoning effort is a dial: `low` for simple searches and short lookups, `xhigh` for large refactors, deep research, or hard bugs. Output can be captured to a file with `-o` or, if you need machine-parsable results, streamed as `--json` and filtered with `jq`. The docs recommend `-o` by default to avoid JSON parsing and terminal truncation on long outputs.

The skill also documents a parallel pattern: fire off two subagents at once — each writing to its own output file — then `wait` for both and synthesize the results in the parent. The canonical use is comparing two approaches to the same problem under different framings, then having Claude pick the better answer. There's also a sequential mode for multi-step engagements where each step depends on the last.

A good chunk of the skill is really about prompting discipline. Subagents only see what you give them, so the guidance pushes structured prompts with five parts: context, numbered objectives, constraints (what to focus on and ignore), an exact output format, and success criteria. The good-versus-bad examples make the point plainly — "Research authentication" produces vague work, while a prompt naming the framework, the directories to check, and the exact output shape produces something usable. That advice generalizes well beyond this one skill.

Why It Matters for Building and Automation

The core problem here is real. Long agent sessions bloat context: every file read, every search result, every intermediate reasoning step accumulates and gets re-sent on subsequent turns. That drives up cost and, past a point, degrades the model's focus. Delegating the token-intensive parts to a subprocess that returns only its conclusion is a sensible architectural move, and use-codex packages it as a repeatable pattern rather than an ad-hoc habit.

The operational advice is worth calling out because it's the part people usually get wrong. The skill tells the parent to act autonomously while a subagent runs — don't pause for permission mid-flight, since the parent only sees the final result and mid-task pauses waste tokens. It pauses only for genuinely destructive operations. And it insists on synthesis over dumping: subagent output is *input* for the parent's answer, not the answer itself. That distinction is what separates a useful delegation layer from a firehose.

The honest caveats: `--yolo` and `--skip-git-repo-check` mean these subagents run with minimal guardrails, so you'll want to know what you're pointing them at. The model names and reasoning tiers referenced (GPT 5.5, `low`/`xhigh`) are what the skill hardcodes; whether those are available to you depends on your Codex CLI access. And the whole thing assumes you're already running Claude in an environment where it can execute bash and has the Codex CLI installed — this is a builder's tool, not a no-code integration.

Where does it fit versus alternatives? If your automations live in Zapier, Make, or n8n, this is a different layer entirely — it's about making a coding agent cheaper and cleaner, not about wiring apps together. It's closest in spirit to subagent and multi-agent orchestration patterns, but implemented as a thin bash wrapper around an existing CLI rather than a heavy framework. That minimalism is a strength: there's little to learn beyond the invocation and the prompting template.

If you want help building agent workflows that delegate work efficiently like this, browse the provider directory to find people who can put it to work.