Possibly related to #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:

1. plan usage may drain faster because Fast mode became enabled by default, and
2. 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:

• rust-v0.110.0...rust-v0.111.0
• 394e538

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.

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

Official commit:

• 932ff28

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: f8838fd
• subagent startup changes: c2e126f
• 0.111.0 release summary: 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.