Sol for Sol Without Breaking the Bank: My Codex Subagent Setup for Production

I originally described this setup like a switchboard: choose Luna for this step, switch to Sol for that step, then send the result back.

That is not how I want to work.

I want to give Codex one goal. Codex should decide when a separate agent thread is useful, choose an allowed role, and bring the result back without asking me to play air-traffic controller.

The setup is not a collection of models I swap manually. It is a small menu of agents Codex can spawn, with rules that control what each one is allowed to do.

How Codex decides to delegate

Codex orchestrates subagents. It starts separate agent threads, routes work to them, waits for their results, and consolidates the useful evidence in the parent task.

In current local Codex releases, delegation starts after a direct request or an applicable project or skill instruction. Ultra can also delegate proactively when parallel work would materially help.

Once delegation is triggered, I do not need to pick a model for every child by hand. Codex can select a built-in or custom role whose description matches the job.

This matters because each child performs its own model and tool work. Subagents can protect the parent context and save time, but they also consume more tokens than a comparable single-agent run.

Automatic spawning is useful only when the available choices are sensible.

The default I wanted to control

Out of the box, spawned agents receive the task context they need. In custom agent definitions, settings I omit can inherit from the parent session.

Inheritance is convenient. It can also copy an expensive model and reasoning level into work that does not need them.

If the parent is solving a difficult Sol task, a child scanning ten files does not automatically deserve the same budget.

My goal is to control the spawn choices before the task begins:

• Clear execution work should route to Luna xHigh.
• Complex research should route to a read-only Sol xHigh agent with low verbosity.
• The parent should keep work that does not benefit from a separate context.

I configure those choices once. I do not manually change models halfway through the task.

The parent stays Sol Medium

My parent agent is Sol Medium. It is the control tower: it holds the goal, decides whether delegation helps, chooses an allowed role, and validates the returned result.

model = "gpt-5.6-sol"
model_reasoning_effort = "medium"
model_verbosity = "low"

[agents]
max_threads = 4
max_depth = 1

max_threads = 4 caps the team at four open agent threads. max_depth = 1 lets the parent spawn direct children while preventing those children from spawning another generation.

The parent is stable. The spawned role changes according to the work.

Define the spawn menu

Codex ships with general built-in agents. Custom agents let me add narrower roles with an explicit model, reasoning level, permissions, and job description.

I use two.

The description is the routing interface. It tells the parent when the role fits.

The developer instructions are the execution contract. They tell the child what to preserve, what proof to return, and where to stop.

That separation is the useful part. Codex chooses from a controlled menu instead of inventing a fresh team shape for every request.

Luna xHigh for clear production work

Luna is OpenAI’s fast, low-cost option for clear, repeatable work. At xHigh reasoning, it can handle substantial implementation when the scope and expected outcome are well defined.

Good Luna tasks include:

• Add one validation rule and its tests.
• Update a known endpoint without changing its contract.
• Scan a folder and return matching files with line references.
• Apply a mechanical refactor to a defined set of files.
• Run a focused test and explain the failure.

The task still needs a finish line. “Improve the backend” is not a cheaper prompt merely because it runs on a cheaper model.

Sol xHigh for complex research

Sol is the stronger choice when ambiguity, investigation, or cross-system judgment matters.

My research role uses Sol with xHigh reasoning and low verbosity. It gets the deep investigation budget without turning the result into a long monologue.

The researcher is read-only. It traces architecture, compares explanations, checks primary sources, states uncertainty, and recommends the smallest useful next test.

When the investigation makes the path clear, the parent can automatically route the bounded implementation back to Luna.

Sol does the detective work. Luna performs the now-obvious repair. I stay out of the costume change.

The copyable role definitions

These TOML blocks are examples inside the article. This article does not change anyone’s actual Codex configuration.

Luna task agent

name = "luna_task"
description = "Worker for clear implementation, tests, scans, and structured transformations with an exact finish line."
model = "gpt-5.6-luna"
model_reasoning_effort = "xhigh"
model_verbosity = "low"
developer_instructions = """
Handle one bounded task.
Preserve the stated public contract.
Run the smallest check that proves completion.
Return changed files, evidence, and remaining risk.
Do not spawn descendants.
"""

Sol research agent

name = "sol_researcher"
description = "Read-only researcher for ambiguous architecture, diagnosis, security, and multi-source synthesis."
model = "gpt-5.6-sol"
model_reasoning_effort = "xhigh"
model_verbosity = "low"
sandbox_mode = "read-only"
developer_instructions = """
Investigate the difficult question without modifying files.
Start with project context, ADRs, primary documentation, and upstream code.
Return evidence, competing explanations, uncertainty, and the smallest useful next test.
Do not spawn descendants.
"""

Fields omitted from a custom agent can inherit from the parent. I pin the model and effort here because controlling that inheritance is the point of this setup.

Teach the parent how to route

Agent files define the choices. A project instruction or reusable skill tells Codex when delegation is appropriate and which description belongs to each lane.

An article-only example looks like this:

### Automatic subagent routing

- When a separate context materially helps, choose `luna_task` for clear implementation, tests, scans, and transformations.
- Choose `sol_researcher` for ambiguous architecture, diagnosis, security, or multi-source research.
- Keep research read-only. When the path becomes clear, return implementation to `luna_task`.
- Do not spawn a child for work the parent can complete more cheaply in the current context.
- Wait for requested children and consolidate their evidence.

The parent now has a policy, not a sequence of manual switches.

At ordinary intelligence levels, that instruction or my prompt triggers delegation. With Ultra, Codex can decide proactively that the extra lanes are worth using.

Give Codex a clear finish line

I no longer need to say, “Use Luna now, then switch to Sol.” I describe the work and allow the routing policy to choose.

Add validation to the upload request schema.
Keep the public API shape unchanged.
Use a subagent only when a separate research, implementation,
or test context would materially help.
Run the focused test file.
Return changed files, evidence, and remaining risk.

If the path is clear, Codex can spawn luna_task. If it discovers an ambiguous dependency, it can use sol_researcher, return the evidence, and then route implementation to Luna.

That is automatic orchestration inside a controlled boundary.

Write prompts like recipes

The best prompt gives Codex direction, not an itinerary.

A useful recipe has four parts:

• Goal: the outcome and who it must work for.
• Context: useful code, docs, issues, or other starting points.
• Output and boundaries: what to produce and what must stay untouched.
• Finish line: the checks or evidence that make the result ready.

Prescribe what must be true. Suggest what often works. Validate what was achieved.

The routing policy decides who should do each lane. The prompt defines what success means for the whole mission.

One request, three possible routes

The same request can take different shapes without me changing agents manually.

• If it is small and local, the parent completes it without spawning anyone.
• If it is clear but benefits from isolation, the parent spawns luna_task.
• If it is ambiguous, the parent spawns sol_researcher, then sends the clarified implementation to Luna.

The parent remains responsible for judgment and validation. A child result is evidence, not an automatic merge approval.

Budget guardrails

I use one child before I use three. More lanes are justified only when they are independent and the time or context saved is worth the extra model work.

I keep the default nesting depth at one. Children do not create grandchildren and discover a surprise family plan on my token bill.

I avoid parallel writers in the same files. Coordination overhead can erase both the speed and cost advantage.

I keep research read-only until the problem is understood. Then the parent routes a smaller implementation task to Luna.

OpenAI recommends Sol Medium when someone is unsure where to start. This article is more opinionated: it defines a repeatable spawn policy for work I already understand.

If Luna high or medium passes the same checks, lowering effort is the next optimization. Use the lowest reasoning effort that reliably crosses the finish line.

If you bought the $200 fuel tank

Some people optimize every token. Others have a high-allowance account and would like their agents to stop flying economy.

If that is you, the same automatic routing can use a Sol-for-both menu:

The worker gets Sol’s stronger model with the reasoning tap barely open. The researcher gets the full detective board, red string, and permission to stare thoughtfully at the architecture.

Keep low verbosity for both. Expensive thinking does not need to become an expensive monologue.

Is this the cheapest route? No. Neither is ordering dessert. With a large allowance and valuable work, it is a sensible quality-first spawn policy.

OpenAI describes Pro capacity in higher-rate-limit tiers rather than one permanent price promise. Treat “$200 account” as shorthand for enough headroom, and recheck the current plan before budgeting.

What I keep from this setup

Codex handles orchestration. My configuration controls the choices available to it.

Luna xHigh handles clear spawned work. Sol xHigh investigates ambiguity. The Sol Medium parent keeps small work in the current context and validates every returned result.

I do not manually swap agents. I define roles, routing signals, permissions, and finish lines, then let Codex choose the cheapest suitable lane.

That is how I use Sol for Sol without paying for Sol everywhere.

Sources

• OpenAI: GPT-5.6 model guidance
• OpenAI: Codex Subagents
• OpenAI: Codex pricing
• OpenAI: Codex configuration
• Eric Provencher on X