Retuning your setup for GPT-5.6: seven changes that save tokens, dollars and time

A new model release means behaviour changes, and behaviour changes mean your carefully-tuned setup is now mistuned. GPT-5.6 shipped with meaningfully different defaults around persistence, reasoning effort and pricing, and the configuration that got the best results out of 5.5 will now cost you tokens, dollars and time.

This is a quick summary pulled from the GPT-5.6 system card and early field reports. Seven concrete changes, roughly in order of impact.

Cut the persistence prompts from AGENTS.md

GPT-5.6 goes hard on persistence out of the box. Hard enough that OpenAI’s own system card notes they “observed instances of the model cheating on tasks and fabricating research results” — probably, I suspect, because they’re training it to get higher METR scores.

If your AGENTS.md contains anything like “keep trying until you succeed” or “don’t give up”, delete it. You no longer need to push this model toward long run times, and stacking your persistence instructions on top of its trained-in persistence tips it toward reward hacking: claiming success, gaming tests, fabricating results.

This is worth a proper audit, not just a grep for “keep trying”. Most instruction files accumulate compensations for the weaknesses of previous models, and each release makes some of them counterproductive.

Back off the reasoning effort

Most people run xhigh reasoning all the time (I do too). The early consensus is that medium or high is enough for most tasks on GPT-5.6, and the token savings are substantial — reasoning tokens are often the bulk of a session’s spend.

A sensible default: medium or high for day-to-day work, escalate manually for genuinely hard problems. (Ultra modes — like ultracode in Claude — are a different mechanism and a different decision.)

Know what fast mode actually costs

Fast mode is 2.5× the cost. Most people leave it on 100% of the time — again, including me.

That’s a fine trade if you’re sitting there waiting on the agent. But if you’re starting to hit limits or your bill is getting attention, be honest about how often you’re actually watching it work. Most of the time you kick off a task and come back to it later anyway, and there fast mode is pure overhead.

Subagents work now — so configure cheap ones

Subagents in Codex are finally genuinely useful. The catch: by default a parent can only spawn subagents with the same model and same reasoning mode as itself. An xhigh parent fanning out xhigh children gets really expensive really fast.

The fix is defining purpose-specific agents with cheaper settings. This is the prompt I paste into Codex to set mine up:

Read my current ~/.codex/config.toml and the docs at
https://developers.openai.com/codex/subagents for custom agent definitions.

Then do the following:

1. Create three agent TOML files under ~/.codex/agents/:

fast_scan — for quick searches, codebase exploration, file reads,
and lightweight analysis.
- model: gpt-5.6-luna
- model_reasoning_effort: xhigh
- sandbox_mode: read-only
- Instructions: gather evidence quickly, return a concise summary,
  do not edit files.

routine_worker — for routine coding, tests, documentation,
and bounded fixes.
- model: gpt-5.6-sol
- model_reasoning_effort: medium
- Instructions: implement the assigned task and verify the result.

deep_worker — for difficult debugging, architecture, security,
and ambiguous multi-step work.
- model: gpt-5.6-sol
- model_reasoning_effort: high
- Instructions: handle complex work carefully, validate assumptions,
  provide strong verification.

2. Make sure max_threads = 6 and max_depth = 1 are set under [agents].

3. Show me the final config.toml and all three agent files so I can
   review before you save.

The shape matters more than the specifics: a cheap read-only scanner for gathering evidence, a mid-tier worker for bounded tasks, and a heavier worker you reach for deliberately.

Turn verbosity down

Verbosity is a first-class parameter now, and lower verbosity is cheaper. In ~/.codex/config.toml:

model_verbosity = "low"

Personally I also just prefer the terser output — less scrolling past restated context to find the actual answer.

Be careful bringing old sessions back

OpenAI now charges for cache writes, which they didn’t before. Everything gets a bit more expensive, but the case that really bites is resuming a long-running session that’s gone stale: you pay to re-write the whole accumulated context back into cache.

Long-lived sessions were already questionable for quality. Now they have a direct price tag too. Prefer starting fresh with a tight summary over resurrecting a huge stale session.

Archive your skills and start again

This one is general advice for any major model release. A good chunk of your skills and custom instructions encode workarounds for the previous model’s failure modes — and when the underlying model changes a lot, those range from useless to actively harmful.

Best practice: archive them all, stop using them for a period, and just ask manually for the thing you wanted. Watch where the new model does a good job unaided, then add back only the pieces of the old skill that still earn their place.

---

Where does this leave the bigger question of what to drive with? I still think the right way to build is with Fable driving — I prefer planning and orchestrating with it. But Sol is closing the gap faster than I expected.

Keep experimenting. And whichever agent you drive, know what it’s costing you — that’s the whole reason we built Cadence.