Pro 20x weekly usage rises 2% from 8 visible turns because long-context tool continuations generate 266 model responses #47045

What version of Codex CLI is running?

0.155.1

What subscription do you have?

ChatGPT Pro 20x

Which model were you using?

gpt-5.6-sol medium 872k window size non-fast mode

What platform is your computer?

Linux x86_64

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

No response

Codex doctor report

Not included publicly because the full report contains local paths and configuration details. Relevant sanitized runtime and configuration facts are included below. I can provide the redacted Doctor output privately if required.

What issue are you seeing?

I am repeatedly seeing unexpectedly rapid weekly Codex usage depletion on a ChatGPT Pro 20x subscription. This occurrence was
captured immediately after a weekly reset using local session telemetry.

Eight user-visible turns across two Codex CLI sessions produced 266 model responses and approximately 96.15 million processed
tokens, including 94.96 million cached input tokens. The weekly meter moved from 0% to 1% in about 11 minutes and to 2% in about 1
hour 47 minutes.

The concern is not merely that long context consumes usage. The client exposes a small number of user turns while performing
hundreds of internal inference continuations, each carrying retained context. There is no usable per-turn explanation of the
resulting weekly-limit charge, and the local rate-limit payload identifies the plan only as pro, not whether the 20x entitlement
was applied.

This behavior has occurred repeatedly. Support has previously granted allowance resets, but the underlying problem recurs.

Environment

• Product: Codex CLI with ChatGPT sign-in
• Subscription: ChatGPT Pro 20x
• Codex CLI: 0.155.1
• OS: Linux x86_64
• Model: gpt-5.6-sol
• Reasoning effort: medium
• Service tier: default; Fast mode was not selected
• Context window: 872,000 tokens
• Approval policy: on-request
• Sandbox: workspace-write
• Multi-agent: disabled
• Hooks: disabled
• Apps/plugins: disabled
• Background app-server: not running
• API-key billing: not in use
• Primary affected/uploaded thread ID: 01a0c1a4-2a90-7960-9647-e41a76b3e11a
• Second affected thread ID: 01a0b855-594a-7131-94e9-f543eca424b7

Observed timeline

Times are America/Toronto (EDT) on September 21, 2026.

• 07:45:24: server-reported seven-day usage window reset
• 07:45:40: server-reported weekly usage was 0%
• 07:56:24: weekly usage reached 1%
• 09:31:56: weekly usage reached 2%
• 10:03:12: end of the bounded telemetry sample

Bounded telemetry sample

These values sum the individual per-response usage fields in local token_usage_record events. They do not sum the cumulative
thread_token_usage field.

• User-visible turns: 8
• Threads: 2
• Model response records: 266
• Input tokens: 96,006,929
• Cached input tokens: 94,960,000
• Uncached input tokens: 1,046,929
• Output tokens: 141,728
• Reasoning output tokens: 43,336, reported as a subset of output tokens
• Total input plus output: 96,148,657

Tool activity in the same bounded period included approximately:

• 146 shell executions
• 70 patch operations
• 29 image inspections
• 15 running-process interactions
• 6 web operations
• 1 image generation
• No substantive external MCP-server calls

An input-level duplicate check did not reveal an identical retry storm. Almost all tool-call inputs were unique.

Actual behavior

• /status and token-count events report only an integer weekly percentage.
• The rate-limit payload reports plan_type: "pro" but does not expose the 5x versus 20x entitlement.
• A small number of visible turns can fan out into hundreds of model responses that repeatedly process hundreds of thousands of
  retained tokens.
• The user cannot reconcile the weekly charge with the visible work or verify that the 20x multiplier was applied.
• The issue has recurred after support-provided resets.

Requested investigation

Please determine:

1. Whether Codex CLI is sending or recording duplicate usage events.
2. Whether rate-limit accounting is correctly applying the Pro 20x entitlement.
3. Whether every tool-result continuation is expected to re-meter the retained cached context.
4. Whether the client can expose per-turn weighted usage and the actual plan multiplier returned by the service.
5. Whether long-context tool loops can be represented or batched more efficiently without reducing the selected model, reasoning
   effort, or supported context window.

What steps can reproduce the bug?

Uploaded thread: 01a0c1a4-2a90-7960-9647-e41a76b3e11a

1. Sign into Codex CLI using a ChatGPT Pro 20x account.
2. Use Codex CLI 0.155.1 with gpt-5.6-sol, medium reasoning, the default/non-Fast service tier, and the supported 872K context window.
3. Continue a long-running local chat that performs repeated shell, patch, and inspection operations.
4. Observe /status or the rate_limits.primary.used_percent value in local token_count events.
5. Compare the number of user-visible turns with the individual token_usage_record events in the session rollout.
6. In the captured occurrence, 8 visible turns generated 266 model responses and approximately 96.15 million processed tokens, while the weekly meter moved from 0% to 2%.
7. Inspect the rate-limit payload: it identifies the plan only as pro and does not expose whether the Pro 20x multiplier was applied.

What is the expected behavior?

Expected behavior

At minimum, the CLI should make the following observable:

1. Whether the authenticated rate-limit bucket has the Pro 20x multiplier.
2. The allowance cost attributable to each user-visible turn, including the number of internal model continuations.
3. Whether cached context is charged again after every tool result and at what rate.
4. Whether the weekly meter is based on raw tokens, weighted credits, model responses, or another calculation.

If repeated accounting of retained cached context across tool continuations is unintended, it should be corrected. If it is
intended, the CLI should expose the amplification before or during a turn instead of presenting only the final weekly percentage.

Additional information

Additional notes

• My primary and secondary ChatGPT accounts use separate CODEX_HOME directories and have distinct stored account IDs.
• No evidence was found of account crossover, a background Codex daemon, unintended Fast mode, automatic subagents, or external
  MCP activity causing this sample.
• Raw transcripts are not attached publicly because they contain private source code and command output.
• The relevant sanitized evidence is included above. A separate sanitized evidence file can be provided if requested.