High token consumption during routine edits: context grows to 215k tokens per response

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.903.61454

What subscription do you have?

plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

I’m seeing unexpectedly rapid usage-limit depletion while making incremental Swift/macOS UI changes in Codex desktop using GPT-6 Astra, with low or medium reasoning.

An audit of the affected task’s two local session logs, deduplicated by response_id, found:

• 136 model responses
• 19,465,415 input tokens
• 18,648,064 cached input tokens (95.8%)
• 817,351 uncached input tokens
• 39,095 output tokens

Input context grew from approximately 27,000 to 215,000 tokens per response. No compaction events were found in the inspected logs.

Examples:

• Asking “since all of these are toggles can't we get rid of RESULT?” used 212,764 input tokens and produced 67 output tokens.
• The subsequent “go ahead” implementation used 1,284,407 input tokens across six responses, producing 1,014 output tokens.

The task also made eight 30-second sleep calls. At least one occurred before an edit without an apparent pending process, adding an avoidable model round trip.

I understand cached tokens are discounted rather than free. My concern is that routine follow-ups repeatedly process a very large context, making small changes unexpectedly expensive.

Historical usage-limit snapshots also showed changing reset timestamps, so I cannot reliably attribute a specific allowance percentage to this task. These observations do not establish a billing error; please investigate whether context management, unnecessary round trips, and usage accounting are behaving as intended.

Observed workflow (not yet independently reproduced):

1. Open a local Swift/macOS repository in Codex desktop.
2. Use GPT-6 Astra with low or medium reasoning.
3. Continue one task through incremental code edits and short design questions.
4. Observe input context increasing while subsequent requests remain small.
5. Inspect token_usage_record entries, deduplicating by response_id and summing usage rather than cumulative totals.

Expected: Routine follow-ups should consume a proportionate amount of usage, with effective context management as the task grows.

Actual: Later responses processed approximately 195k–215k input tokens each, including short conversational answers.

Affected task ID: 01a089c5-6d56-7bb0-8c10-fa9855c4e93f
Observed period: September 10, 2026, approximately 05:23–07:17 UTC
Feedback ID: 01a08a46-bd91-72e2-ada9-10d8ad2bc191

The feedback was initiated from a separate diagnostic task; the affected task ID above identifies the coding session being reported.

What steps can reproduce the bug?

Feedback ID: 01a08a46-bd91-72e2-ada9-10d8ad2bc191

What is the expected behavior?

Routine edits and short follow-up questions should consume a reasonable amount of usage, with effective context management as a task grows.

Codex should avoid unnecessary model round trips and manage accumulated history so small requests do not repeatedly require approximately 215k input tokens. If continuing a long task will substantially increase consumption, the app should make that clear and offer a way to reduce context while preserving essential task state.

Usage reporting should make it possible to understand how cached input, uncached input, and output contribute to allowance depletion.

Additional information

The figures above come from local token_usage_record entries, deduplicated by response_id across two session logs. They sum per-response usage, not cumulative counters. Cached input is included in total input, not added on top.

This is an observed case, not a confirmed minimal reproduction or proof of incorrect billing. Please investigate whether the consumption is expected for this workload and whether context management or usage accounting contributed.

Affected task ID: 01a089c5-6d56-7bb0-8c10-fa9855c4e93f
Feedback ID: 01a08a46-bd91-72e2-ada9-10d8ad2bc191

The feedback ID belongs to the separate diagnostic task used to investigate the affected coding task.

Start by reproducing the incremental Swift/macOS editing workflow with GPT-6 Astra at low or medium reasoning. Inspect token_usage_record entries across the two local session logs, deduplicating by response_id, and compare context growth, sleep calls, and cached versus uncached input. Done means determining whether context management, unnecessary round trips, or usage accounting explains the observed consumption.