Builders Are Already Patching Codex for Performance and Quota

GPT-5.6 raised expectations. Builders already knew Codex can still feel slow and burn quota for reasons that are not “the model is dumb.” I tested two structural problems and the fixes.

Why performance drops

The default system prompt is the main culprit, not the base model alone.

The stock prompt tells the model to report progress about every 30 seconds. That pushes it to shrink reasoning once it hits a length pattern. In usage logs, reasoning tokens often end at values shaped like 518*n−2. That is not noise. GPT-5.6 holds up better than weaker models, but the truncation pattern remains. On my unpatched test set the score was 4/5.

Fix performance by replacing the system prompt

I use a rewritten base instructions file (gist), saved as gpt-base-instructions.md, then wire it in config.toml:

disable_response_storage = true
model_instructions_file = 'path/gpt-base-instructions.md'

This is not a few deleted lines. The base instructions are redesigned:

• Remove the 30-second progress nag so the truncation trigger is gone.
• Prefer finishing the turn over mid-flight status theater.
• Put engineering judgment first: follow existing repo patterns, minimize blast radius, avoid useless abstractions.
• Keep strong search habits (rg first) and parallel tool use.

After the swap, the same tests used fewer reasoning tokens and scored 5/5.

Why quota evaporates

Subagent orchestration is the second issue.

spawn_agent does not let you pin a cheaper model or lower reasoning effort on children. If the parent is Sol Ultra, children are Sol Ultra. A main agent that spawns 8, each of which spawns 4, each of which spawns 5, can cross 200 agents on a “simple” research task. Every child pays context load, reasoning, and tools. The parent pays again to merge results. MultiAgentV2 defaults also allow several concurrent threads, which makes fan-out hard to contain.

Two cost controls (pick one)

Option A: V1 multi-agent with depth capped

[features]
multi_agent = true
multi_agent_v2 = false

[agents]
max_depth = 1
max_threads = 6

Children cannot spawn children. That is the structural stop for 200-agent trees. Best when quota is the primary pain.

Option B: keep V2, cut concurrent threads

[features.multi_agent_v2]
enabled = true
max_concurrent_threads_per_session = 2

You keep V2 behavior but slow the burn by dropping concurrent threads from 4 to 2. It does not ban spawning; it reduces how hard the session can spike.

Before you blame GPT-5.6, open config.toml. Harness defaults decide half of what people call model quality.