Getting More out of Codex - Maximising Usage with Subagents

The Arithmetic Test

You can answer 4 + 4 in your head. For 32 × 12, you might reach for paper. For 234 × 123, a calculator is the sensible choice. The change in method does not mean your brain became better or worse between questions. The problem changed, so the useful amount of external effort changed with it.

Coding work has the same shape. Renaming a component is not an architecture decision. Reading fifty configuration files is not the same kind of work as deciding where authentication belongs. Checking whether a page clips at 390 pixels is not the same as tracing a race condition. A single model can attempt all of these jobs, just as a person can multiply a large number by hand. Capability is not the question. Fit is.

OpenAI's current Codex guidance makes this explicit. It recommends more capable configurations for ambiguous, multi-step work and faster models for read-heavy scans or narrow, repeatable tasks. Reasoning effort follows the same logic: higher effort can improve complex work, but it also increases response time and token usage. Spend it where assumptions, consequences, or competing constraints make careful thought useful.

Context Has a Cost

A long Codex task accumulates useful decisions: the page is for a specific audience, the user has rejected a particular layout, a route must remain out of navigation, an existing API cannot change, and somebody else's uncommitted edits must be preserved. This is the expensive context. It should stay close to the agent making trade-offs and accepting the final result.

The same thread can also accumulate thousands of lines that matter briefly: search results, compiler output, browser snapshots, test logs, dependency trees, and dead-end experiments. Official OpenAI documentation describes this as context pollution and context rot. Important constraints become harder to find because temporary evidence surrounds them.

Changing the main model repeatedly can make the workflow worse when the new run has to be briefed again or rebuild its understanding from files and conversation history. This is a workflow cost, not a documented claim that every model switch mechanically retransmits the entire context in the same way. The practical rule is still firm: do not model-hop after every phase. Keep the main thread stable, and move noisy, bounded tasks into subagent threads that report back with a short result.

A Page Built by Roles

Planning the page takes serious reasoning. The planner has to understand the audience, existing design system, information hierarchy, routes, analytics, accessibility requirements, and what the page is meant to make easier. A weak plan produces a great deal of competent code in the wrong direction. This is where a capable model and higher reasoning effort can pay for themselves.

Execution is different. Once the structure is settled, implementation may require a lot of output but fewer open-ended decisions. A worker can add the route, compose existing components, wire metadata, and update tests from a precise plan. The job is large, but much of it is concrete. A faster model may be able to do it well if the boundaries and acceptance criteria are clear.

Visual checking is another discipline. The reviewer needs the running page, desktop and mobile views, readable DOM evidence, and an eye for overflow, hierarchy, awkward wrapping, missing states, and broken controls. It may read little code and still find the defect that matters most to the user. Give that subagent browser or vision tools and a narrow review brief. Ask for screenshots, affected selectors, and a severity-ranked report rather than a redesign from scratch.

Deployment often requires little reasoning and high caution. Build, check the working tree, verify the target, deploy, then confirm the live route. A narrow agent can handle the mechanical checks, but low cognitive effort does not mean low consequence. Production credentials, approvals, rollback, and the final publish action need explicit boundaries. This is a good place for deterministic automation around a tightly scoped agent, not broad autonomy.

The Honest Usage Model

Four agents reading the same repository are not a token-saving trick. They may duplicate setup, inspect overlapping files, and produce reports the main agent has to reconcile. OpenAI recommends starting with parallel agents for read-heavy work such as exploration, testing, triage, and summarisation. It advises more care with parallel write-heavy work because simultaneous edits create conflicts and coordination overhead.

The right measure is not the smallest token count in isolation. It is the cost of an accepted result: elapsed time, reviewer attention, retries, regressions, and how much irrelevant material remains in the main context. A specialist scan that spends extra tokens but catches a security problem before deployment is cheap. Three agents making overlapping edits to the same component are expensive even if each uses a lighter model.

This is why model choice belongs inside task design. A Workflow Automation Hub should not send every event through its most expensive reasoning path. It should route work according to ambiguity and consequence. Codex benefits from the same pattern. Use deeper reasoning for decisions that shape everything downstream. Use efficient agents for bounded searches, transformations, and evidence gathering. Keep human review where the result carries business or production consequence.

How to Delegate

“Help with the website” is not a useful subagent brief. The agent does not know whether to inspect, plan, edit, test, or publish. A bounded prompt states the question, the files or surface in scope, the evidence to return, whether changes are allowed, and when the agent should stop. If several agents are working, say which tasks can run independently and tell the main agent to wait for all results before deciding.

For example: ask one read-only explorer to map the current page architecture and cite the components involved. Ask a planner to propose the hierarchy and acceptance criteria using that evidence. Give the worker the approved plan and ownership of the new route. Ask a visual reviewer to inspect desktop and mobile without editing. Keep deployment with the main agent until the build, tests, diff, and approval state are known.

Do not delegate work merely to display activity. A task that takes the main agent one command and one clear check should stay in the main thread. Nor should several agents write to the same files unless the coordination benefit is obvious. Subagents are most useful when the boundary is real: different evidence, different tools, different expertise, or independent work that can proceed at the same time.

The main agent remains accountable for synthesis. It has to compare reports, resolve disagreement, protect the original constraints, and decide whether the result is ready. Delegation changes where work happens. It does not remove ownership.

There is also a real downside to doing this badly. Codex already handles much of the orchestration: spawning agents, routing follow-up instructions, waiting for results, and collecting the final response. Start by asking it to delegate a few independent tasks and inspect what happens. Do not keep raising concurrency, forcing model overrides, or building a cabinet of custom agents simply because the controls exist. A poor setup can burn usage on duplicated reading, send a light model into a hard decision, create conflicting edits, or give a worker more permission than its job requires.

Custom configuration is useful when you understand the repeated job well enough to set a stable boundary. Until then, let Codex manage the mechanics and keep your instructions about outcomes: what can run in parallel, what must remain read-only, what evidence should return, and which actions require approval. Experiment, but do it on work you can inspect and recover. Production is a bad place to learn that four agents misunderstood the same sentence in four different ways.