Regression around 0.111.0: usage drain spikes with Fast mode default + more aggressive multi-agent spawning

What version of Codex CLI is running?

0.112.0

What subscription do you have?

GPT-PRO

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

Possibly related to https://github.com/openai/codex/issues/13568, but this report narrows the behavior to a specific release boundary and a small set of likely causes.

Summary
Starting on 2026-03-05, my local Codex sessions began draining usage much faster than earlier days. After digging through local rollout archives, the cleanest boundary is the jump from 0.107.0 to 0.111.0.

This does not look like a simple one-turn accounting glitch. It looks more like a behavioral regression where:

plan usage may drain faster because Fast mode became enabled by default, and
token usage also jumps because Codex starts spawning many more long-lived explorer subagents, often with fork_context: true.
Local bisect boundary
From local session archives:

2026-03-01 to 2026-03-04: 0.106.0 / 0.107.0
2026-03-05 to 2026-03-07: 0.111.0
2026-03-08: mostly 0.112.0
The bad behavior starts exactly when sessions move to 0.111.0.

Local evidence of the behavior change
Representative parent sessions:

2026-03-03 parent on 0.107.0: 4 subagent spawns, 2 with fork_context: true
2026-03-05 parent on 0.111.0: 27 subagent spawns, 20 with fork_context: true
2026-03-08 parent on 0.112.0: 6 subagent spawns, all 6 with fork_context: true
Daily totals / subagent share from local rollout token counts:

2026-03-01: 30.3M total, subagents 18%
2026-03-02: 163.9M total, subagents 10%
2026-03-03: 182.9M total, subagents 55%
2026-03-04: 107.7M total, subagents 10%
2026-03-05: 915.0M total, subagents 64%
2026-03-06: 1.10B total, subagents 75%
2026-03-07: 305.2M total, subagents 86%
2026-03-08: 360.1M total, subagents 68%
Example worst case on 2026-03-07:

305,213,434 total tokens for the day
largest child explorer used 263,885,849 tokens by itself
The big child sessions were not just initialized with a giant prompt once; they kept running for hundreds to thousands of token-count events, so this feels like a long-lived subagent/orchestration regression more than a single counting bug.

Official changes that line up with this

1. 0.111.0 enables Fast mode by default

Official release / commit:

https://github.com/openai/codex/compare/rust-v0.110.0...rust-v0.111.0
https://github.com/openai/codex/commit/394e53864013a25dc60cc924c62a58385b0a4fe7
The 0.111.0 notes say:

"Fast mode is now enabled by default"
The code/UI for that release also describes Fast mode as:

"fastest inference at 2X plan usage"
This seems like the strongest explanation for why the visible usage bars started dropping much faster.

1. Multi-agent prompting became more aggressive in the same window

Official commit:

https://github.com/openai/codex/commit/932ff2818320e7c5181a28316db75e53620aeabc
That change expands the spawn_agent guidance to explicitly encourage spawning multiple explorers in parallel and reusing them. My local traces after the 0.111.0 boundary show exactly that sort of behavior increase.

Related changes in the same release window that may contribute:

/agent enablement: https://github.com/openai/codex/commit/f8838fd6f3a22f228a1ed551df67789b25c82b12
subagent startup changes: https://github.com/openai/codex/commit/c2e126f92ad560cfbda3a542db4e669680af9c25
0.111.0 release summary: https://github.com/openai/codex/compare/rust-v0.107.0...rust-v0.111.0
Current hypothesis
The most likely regression is a combination of:

Fast mode defaulting on in 0.111.0, increasing visible plan-usage burn, and
more aggressive multi-agent prompting / orchestration, increasing the number and duration of fork_context: true explorer subagents.
So this may be less of a raw token-meter bug and more of a regression in:

default usage policy,
subagent orchestration behavior,
and/or usage transparency for child threads.
What would help confirm/falsify this
whether 0.111.0 changed any hidden defaults around spawning explorers or fork_context
whether Fast mode was auto-enabled for existing users without a prominent notice
whether usage bars intentionally count child subagent threads at the same rate as the parent visible session
whether there was any guard/regression preventing runaway long-lived explorer swarms after 0.111.0
If helpful, I can add anonymized session IDs / exact local rollout examples in a comment.

What steps can reproduce the bug?

Use multi agebt

What is the expected behavior?

_No response_

Additional information

_No response_