Long running goal sessions consume usage even though token usage appears to be low

Open 💬 2 comments Opened Aug 14, 2026 by Sotiris-Bekiaris

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

I noticed that my usage on the Pro 20x plan is getting consumed way faster when I use the /goal.

The small context window of the model forces for many compactions over long sessions and the initial instructions are not followed as expected. The model looks like its getting obsessed over something that is not crucial to the goal.

Also the goal tracker itself is mentioning that the total goal tokens were 8,388,753 my usage is down to 5% remaining. I do not believe that other tasks / sessions would consume 95% of the usage from the 20x Pro plan, even though they might use more tokens, the only difference is that I did not use goal for them.

Also token reset feels wrong. It is randomized and we have to follow updates on X, which is unprofessional. It should be an official announcement not a tweet. We are organizing our work around the resets and having to reset in 7 days while we were to reset on Monday is totally messing with our workflow and productivity...

So the issue is that setting goal consuming hidden tokens that we can not track why and how they are used since the goal tracker total is 8 million tokens that is not equivalent to 95% of usage for the 20x Pro plan.

What steps can reproduce the bug?

Set a goal for a big feature over a huge codebase let the long session run unattended and see the usage consumption vs the actual token usage of the session.

What is the expected behavior?

The usage of the 20x Pro plan should not be consumed that fast on a task that used 8 million tokens.

Additional information

I would like to be able to see the usage of the task in more details and the explanation on why my subscription usage got consumed that fast while the tokens used were so little.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 14 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#37299
#37282
#38335

Powered by Codex Action

jdcodes1 · 9 days ago

The gap between the goal tracker's 8.4M and your plan consumption is explainable from what the tracker actually measures. tokens_used is just the goal thread's own total_token_usage.total_tokens, mirrored from its TokenCount events (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/state/src/extract.rs#L101-L107). Several real costs never enter that number:

Guardian reviews: in autonomous goal runs, each on-request approval spins up a delegated guardian review session — separate model calls whose usage isn't added to the goal thread's counter (core/src/guardian/review.rs#L675-L695). Long unattended sessions can rack up many of these.
Compaction/summarization requests and any subagent threads bill separately from the tracked thread.
Weighting: plan usage isn't raw token count — uncached input is far more expensive against the limit than cached input, and a small-context model forced into frequent compaction keeps invalidating its cache, so each post-compaction turn resends a large uncached prefix. That's the worst possible shape for the rate limiter, and it compounds precisely in /goal sessions.

Fix suggestions: aggregate guardian/subagent/compaction usage into the goal tally (or show "tracked vs total account usage"), and surface cached-vs-uncached breakdown so users can see why identical token totals consume very different amounts of plan.