[Bug] Excessive initial context (~273k tokens) and 24M-token consumption in Codex Desktop with a custom Responses provider and subagents

Summary

On October 13, 2026, Codex Desktop for Windows consumed approximately 24 million tokens through a custom OpenAI-compatible Responses API provider (Xiaomi MiMo-v2.6-pro) during a multi-agent software-development workflow.

The local logs show:

1. Large initial input: the first recorded model response in four Desktop sessions had approximately 273,000 input tokens. The first CLI diagnostic response had 105,500 input tokens.
2. Full history inheritance: three subagents were spawned from one parent with fork_turns = all.
3. Low cache reuse: approximately 81.9% of the locally recorded input tokens were cache misses.

I am reporting this to understand whether the context size is expected, whether the Codex runtime can reduce it, and how to use multi-agent workflows with custom Responses providers without unexpectedly high usage. The provider-side caching behavior has not been independently diagnosed.

Environment

• OS: Windows 11, build 26200
• Codex CLI: 0.157.1; Codex Desktop for Windows
• Execution: native Windows / PowerShell
• Model: mimo-v2.6-pro
• Custom provider: Xiaomi MiMo Token Plan (Singapore), wire_api = "responses"
• Model configuration: model_context_window = 1048576, model_reasoning_effort = "high"
• Desktop: plugins enabled, including Browser, Computer Use, Chrome, Documents, PDF, Spreadsheets, and Presentations
• MCP servers configured: node_repl, rea

The provider was successfully authenticated and could call PowerShell tools from Codex CLI. No API keys or sensitive configuration values are included here.

Actual behavior

1. Large initial input

The first recorded last_token_usage.input_tokens for each session was:

The four Desktop sessions are within 476 tokens of each other (about 0.17% of their input size). This strongly suggests a common context component, but it does not establish which part came from system instructions, tool definitions, plugins, conversation history, or application state.

The simple CLI task, "Identify the operating system and current directory," eventually reported 620,765 tokens across its session (620,251 input, none cached; 514 output), despite returning just a short answer.

2. One parent spawned three subagents

Parent session ID: 01a13647-2344-7be0-9f52-8d192290972b

Each child session includes a parent_thread_id matching the parent, and the parent's spawn_agent tool-call arguments specify fork_turns = all for all three. Subagents were launched automatically as part of the parent workflow, rather than as three separately initiated top-level tasks.

3. Session token accounting

The following figures come from the last cumulative token_count entry per session in local Codex JSONL logs; they are not a request-by-request billing export:

Xiaomi's dashboard for October 13, 2026 reported:

The local total is approximately 99.0% of the dashboard total. The figures do not match exactly, potentially due to reporting windows or differences between client and server counters. I am not asserting a billing error based on that discrepancy.

4. Repeated large input and limited cache hits

Analysis found 73 positive changes in cumulative usage counters across the five sessions. These counter updates are not necessarily equivalent to 73 individual HTTP requests.

Examples of reported usage increments:

The largest recorded last_token_usage.input_tokens was 422,069. The high cache-miss fraction could reflect changes in the prompt prefix, behavior of the upstream caching implementation, or other factors; the available local logs do not isolate the cause.

Reproduction context

This is an incident report, not yet a minimal deterministic reproduction:

1. Install Codex Desktop and CLI 0.157.1 on Windows.
2. Configure a custom OpenAI-compatible Responses provider using a suitable model catalog.
3. Enable Desktop plugins and MCP integrations.
4. Run a multi-agent project task and allow the parent to spawn subagents with fork_turns = all.
5. Inspect the first token_count usage entry and subsequent usage increments in ~/.codex/sessions/**/rollout-*.jsonl.
6. Compare input sizes and cached-input ratios for parent and subagents.

Expected behavior / questions for maintainers

• Is a ~273k-token first input expected for Codex Desktop with these plugins and MCP servers enabled?
• Can the Codex runtime expose a breakdown of input context size (base instructions, tool schemas, plugins, conversation history, etc.)?
• Is the ~105k CLI vs ~273k Desktop first-input difference expected?
• Is fork_turns = all intended as the default for Multi-Agent V2? Can users configure a default inheritance policy while retaining functional task handoff?
• Are there known prompt caching limitations with custom Responses providers? Can Codex keep the reusable prefix stable where possible?
• Is there a supported per-session/per-agent token budget, warning threshold, or cancellation mechanism that can prevent unexpectedly large usage for third-party-billed APIs?

Impact

A single multi-agent development workflow consumed a substantial fraction of a paid monthly Token Plan subscription. Disabling subagents entirely is not a viable long-term workaround: they are central to this workflow. I am looking for a way to preserve useful multi-agent execution while controlling unnecessary context duplication and unexpected cost.

Diagnostics / privacy

I can provide a redacted session usage CSV, parent-child metadata, spawn_agent arguments, and a usage dashboard screenshot. I am not posting complete session JSONL files because they may contain private project content, local file paths, and sensitive prompts. No API credentials will be shared.