Plan with one Codex account, build with another, review in place

Your best model is the one you want reading the problem and writing the plan. It is often not the one you want burning quota on the fourth attempt at a test fix. CodexUse’s Work tab separates the two: a planner account plans in its own Codex window, a worker account builds in an isolated Git worktree, and you review and accept the result in your folder.

The run, end to end

1. Describe the work. Open Work and answer What should we do? in plain language.
2. Choose a folder. Pick the Git repository itself, not its parent. A worker needs Git; opening a folder in an account’s window does not.
3. Choose a planner. This account’s Codex window reads your request and writes the plan. Put your best model here.
4. Choose a worker. This account builds. The first time you pair it with a folder, CodexUse asks you to Allow worker access: let this account read this folder and receive the plan.
5. Add checks. Optional: under Checks and files, list Required checks, one command per line. They run before a result can be accepted.
6. Start. The planner window opens. When the planner hands off, the worker window opens and the job moves from Waiting to Starting to Building.
7. Review and accept. When the job is Ready to review, read the diff and the check output, then Accept.

Why the planner gets its own window

The planner is a normal Codex session in that account’s own Codex window, with your folder open. That has three consequences. The plan is written with full context of your code, not from a summary. You can watch it think, answer its questions, and keep talking to it after the hand-off. The planner’s requests use its account’s allowance; worker requests use the worker’s allowance. Actual usage depends on the task and the model.

A planner may also answer directly without handing off, for example when your request was a question. The run then ends as Planner finished without handing off, and the answer is in the planner window.

Why the worker builds in a worktree

The worker gets an isolated Git worktree of your folder under a workspace-write sandbox. It can edit every file in its copy and cannot touch your checkout, your uncommitted changes, or another worker’s copy. If it goes wrong, you remove the run and the worktree goes with it. If it goes right, Accept applies the changes to your working folder. Review and commit them yourself. Nothing is pushed.

Uncommitted files are not in the worker’s copy by default. Turn on Include uncommitted files to send them, and use Review uncommitted files to see what that means. If those files change after you reviewed them, CodexUse asks you to review them again before starting.

What the worker receives

The worker receives a brief from the planner: what to build, where, and what done looks like. It does not receive the planner’s transcript, your earlier conversation, or the planner’s scratch reasoning. That bound is deliberate. It keeps the worker’s context small, keeps the worker’s quota spend on building, and means a cheaper or third-party model sees only what it needs to do its job.

When the worker needs something outside the brief, the job turns to Needs you: it has a question, wants to run a command, or wants to read or change files outside its copy. You answer on the run card, or tell it something new with Tell the worker.

Review and accept

The review sheet lists every changed file with its diff, the output and exit code of each required check, and the worker’s summary. Accept is disabled until all changes have loaded and every check has passed; when one fails, the button says Fix the failing checks first. From the same sheet you can send Feedback for the worker, which continues in its copy, or hand the job to a Different worker. Once accepted, the run card shows Accepted into <folder>. The changes remain uncommitted until you commit them.

A custom-model account as the worker

A worker does not have to be an OpenAI account. A custom-model account, one that runs an OpenAI-compatible provider such as OpenRouter, DeepSeek, Groq, or a model on your own Mac, can be the worker when its verified provider route supports the coding tools a worker needs. CodexUse asks separately before it sends repository content to a third-party provider, and names the provider in the consent text. That choice is saved per folder.

This is the practical form of “plan with your best model, build with the right model”: an OpenAI account with a high-reasoning model plans, and a cheaper or local model does the typing. Each account’s requests count against that account only.

How this differs from codex agents

Codex supports subagents in the app, CLI, and IDE. Subagents handle delegated work and return results to the main conversation. The codex agents command browses local agent sessions; it is not the command that spawns subagents. CodexUse Work adds separate planner and worker accounts, per-account windows, Git worktrees, and a review step before applying changes to your folder. Read OpenAI’s subagent documentation for the native workflow.

What this does not claim

• Accept does not create a commit or push anything. It applies the changes to your working folder; you commit them yourself.
• Work does not create extra Codex quota. Splitting planning and building spreads quota across accounts; it does not add any.
• Work does not give the worker the planner’s transcript, and it does not let the worker reach outside its copy without asking you.
• A custom-model worker sends repository content to that provider. You are responsible for that provider’s terms.
• Work needs the Apple Silicon desktop app. The cross-platform CLI does not run planner and worker runs.