Burning tokens very fast

What version of the IDE extension are you using?

26.311.21342

What subscription do you have?

Business

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

Am I the only one still seeing my tokens burning very fast following today's extension update? e.g. just by writing 1 or 2 prompts, usage drops by 1%, within 2 hours of working I managed to burn through ~20% of my tokens. Tried using GPT5.3 and 5.4, High reasoning effort. I know High reasoning effort will consume more quickly, but is it considered normal to consume one fifth of the tokens within 2 hours even for business accounts? Doesn't make sense to me, but please clarify

What steps can reproduce the bug?

just by writing reasonably simple prompts. GPT5.3 and 5.4, High reasoning effort.

What is the expected behavior?

Last week token usage was like 25% slower.

Additional information

No response

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

Rate Limits dropped 30% within a few hours of use? Teams account - not getting usage resets and still getting fast drops #14349
Regression around 0.111.0: usage drain spikes with Fast mode default + more aggressive multi-agent spawning #14116
one prompt consumes 11% of weekly limit #14441
"Weekly limit % left" dropping suddenly without any usage occurring. #14023
usage is very high on light usage #14112

Powered by Codex Action

Not a duplicate. I am aware about the separate reports that are now closed. But with my VS Code extension updated today, it seems the issue has not been resolved, at least for my account.

Please refer to my post here for reasons why you may be seeing increased usage.

Not a duplicate. I've reviewed etraut's post on the closed thread and none of the listed factors apply to my case.

I'm on a Pro account. Over the past couple of days, my weekly limit has been draining dramatically faster despite the same workload, regardless of model (GPT-5.3 or 5.4), reasoning effort, or channel (Codex App, CLI, VS Code). No sub-agents, no experimental features enabled. I've burned through ~70% of my weekly limit in a single day on what I'd consider normal, moderate usage. This is a clear regression from last week's consumption rates.

The regional sync fix mentioned in the closed thread doesn't appear to explain this. The drain is consistent and directional, not oscillating.

@nishikawa7863

Not a duplicate. I've reviewed etraut's post on the closed thread and none of the listed factors apply to my case.

I'm on a Pro account. Over the past couple of days, my weekly limit has been draining dramatically faster despite the same workload, regardless of model (GPT-5.3 or 5.4), reasoning effort, or channel (Codex App, CLI, VS Code). No sub-agents, no experimental features enabled. I've burned through ~70% of my weekly limit in a single day on what I'd consider normal, moderate usage. This is a clear regression from last week's consumption rates.

The regional sync fix mentioned in the closed thread doesn't appear to explain this. The drain is consistent and directional, not oscillating.

Thanks @nishikawa7863, exactly, this is what I am experiencing. I will do a little more evidence / data gathering & post here.

Same here never ever burned this much usage on CLI 5.3 codex med.... Lost arround 25% weekly within few prompt on only one project without using fast or anything else.. My 5hours usage goes under 20% which never hapened either.

If this is considered 2 times the normal usage it's straight unusable for any coding activites at least for plus member.

Edit : Just reached 5hours limit for the first time ever.
Token usage: total=742,555 input=697,188 (+ 9,077,504 cached) output=45,367 (reasoning 11,450)
Almost used half of my weekly session on this one.

Please refer to my post here for reasons why you may be seeing increased usage.

I don't really think this has been solved, with all due respect.

First the issue is being attributed to "network", when deflected by actual users the thread gets closed and now "its fixed and thread closed" but we still are experiencing a definitively more than 30% usage attributed to the new model.

That's our opinion based on usage. Thanks.

Not a duplicate. I've reviewed etraut's post on the closed thread and none of the listed factors apply to my case.

I'm on a Pro account. Over the past couple of days, my weekly limit has been draining dramatically faster despite the same workload, regardless of model (GPT-5.3 or 5.4), reasoning effort, or channel (Codex App, CLI, VS Code). No sub-agents, no experimental features enabled. I've burned through ~70% of my weekly limit in a single day on what I'd consider normal, moderate usage. This is a clear regression from last week's consumption rates.

The regional sync fix mentioned in the closed thread doesn't appear to explain this. The drain is consistent and directional, not oscillating.

I'm experiencing a similar issue on my PRO account and the usage spiked in the last few days despite no changes in my usual workflow

I'm using codex mainly via VSCode extension, current version is 26.311.21342

@etraut-openai

Yeah I was the original poster on that thread @etraut-openai and it's still not fixed. Still using 5.3 codex like I've always been, not particularly high usage compared to previously, but usage limits are still burning very fast.

It's insane how OpenAI insists everything is normal... there are people with Pro subscriptions that are hitting 70% of the weekly limit in 1 day... how is that even normal, specially considering the x2 promo?

Either...
a) the x2 promo is not being applied to everybody
b) there is a bug somewhere
c) the limits were significantly nerfed

And at this rate, Codex will be useless in April considering a lot of people will hit their weekly limits in 2/3 days.

On February/March, I've been often hitting my weekly limits and yet, there were weeks in October when I spent more or the same number of tokens.

I completely agree something’s not right. I’ve been using Codex for a few months, and I’ve had enabled subagents since they were released. I usually was ending my week with a 40% remaining usage and using it without worries.

For the past two weeks, I’ve been struggling on my 3rd day and using much less subagents.

I noticed that my quota decrease quite fast when I encounter compaction loop bug.
The compaction launch but the context window stay quite high (>75%), it compacts again and so on.

Just adding to this since it might be part of an explanation: I had noticed that my quota is getting used when the application is idle, e.g., after a fresh start of my system in the morning and opening Codex for macOS my 5h quota would go down from 99% to 0% without any interaction on my end.

I've disabled memory and prompt recommendations and it fixed my issue. But if this behavior is killing my 5 hour limit within 1 hour of being idle it explains at least a little bit of the 'high quota usage' feeling that people might have. If I would have been actually working at the same time my quota would have been done in 15 - 20 minutes I guess.

Last week I had one prompt in 26 hours use 40% of weekly limit of $200 Pro. I thought I went too hard there, but in the last 24 hours I burned about 20% of weekly limit without anything on note that I can find.

Interestingly I never saw the 5-hour limit getting low.

Feedback ID: 019eee35-4275-7591-bff5-5862839de07a

i stopped using openai. I use claude. And continue with local. openai is the backup to the backup. On the off chance it actually gets used, it still gets exhausted with one prompt. It's worthless.

…

On Fri, Jun 26, 2026 at 1:54 AM Eugeniusz Gilewski ***@***.***> wrote: *egilewski* left a comment (openai/codex#14593) <#14593 (comment)> Last week I had one prompt in 26 hours use 40% of weekly limit of $200 Pro. I thought I went too hard there, but in the last 24 hours I burned about 20% of weekly limit without anything on note that I can find. Interestingly I never saw the 5-hour limit getting low. Feedback ID: 019eee35-4275-7591-bff5-5862839de07a — Reply to this email directly, view it on GitHub <#14593?email_source=notifications&email_token=ACP3SDONDAW2ZEONUKQPAFT5BYMZFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBQG4YDONJWG432M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4807075677>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACP3SDN4UCNSTZV42KHFCTD5BYMZFAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIMBXGE2DKOJYGY42C5QC> . You are receiving this because you commented.Message ID: ***@***.***>

Actually it looks even worse to me now: in the last hour I had three fresh chats (with apparently no compaction and total reported context of 320k tokens) use 5% of $200 Pro plan. 5-hour limit was also reduced by 20-30% to 66%.

Maybe worth noting that I'm using an old 26.513.31313 Intel MacOS version. I'll try to resolve my updating problem ASAP.

Feedback ID: 019f02cd-8cc9-7d00-9790-8a05cdb4efd6 (includes IDs of all 3 sessions).

Token burn is a real problem. A few strategies that have helped:

Model routing by complexity — Don't use the most expensive model for everything. Route simple tasks (boilerplate, formatting, basic edits) to DeepSeek-V3 or Qwen (~5-10x cheaper) and reserve the frontier model for complex reasoning. Services like Vynex API give you one endpoint for 34+ models so you can switch by name without changing code.
Context caching — Cache repeated context (system prompts, project structure) instead of resending every turn.
Diff-only responses — Request only the diff/change, not a full file rewrite. Dramatically reduces output tokens.
Batch mode — Most providers offer 50% off for batch (non-real-time) API calls.

For high-volume coding workloads, the cost difference between using DeepSeek-V3 vs GPT-4o for routine tasks can be 10-20x. Worth evaluating if token burn is your main pain point.

Apparently the marketing team at https://thegrid.ai/ thought it would be a great idea to scrape the frustrated customer emails from this thread, to send them unsolicited campaign emails. Email has been archived for safe keeping.

Hey there,

I've been following your open source contributions on GitHub and wanted to reach out. If you're looking to cut your token costs, I'd invite you to start consuming inference with The Grid.

No you haven’t. This is the only place I’ve contributed on such topics. This thread.

Services like Vynex API

That’s a paid service, to which I see you’ve been contributing (per commit history).

Is your advice (#1 “strategies that have helped”) really to dress up an ad like a helpful comment in a room full of frustrated developers? Why no affiliation disclosure?

My list of services to avoid just grew.

As I mentioned on Reddit:

Me and several other people have got a strong feeling that Codex usage seems to deplete much faster recently, even when using the same model, reasoning level, and type of coding workflow - even after June 29th. I compared older and newer rollout logs to see whether this was only subjective.

The clearest difference is that older Codex versions often issued several independent shell commands from a single model response. Newer sessions appear to serialize almost everything as "model -> one exec call -> model -> one exec call". In the sessions I examined, older versions averaged roughly 1.4-1.8 tool calls per model cycle, with around 30-40% of cycles containing multiple tool calls. In newer 0.142.x sessions, there were effectively no multi-tool cycles and fewer than one tool call per model invocation on average.

This matters because every tool result requires another model invocation with the current conversation context. A recent task required 58 model invocations for 57 tool calls, whereas an older task used 84 model invocations for 151 tool calls.

The context carried by each invocation has also increased. In one comparison, the older session averaged about 54k input tokens per model call, while the newer one averaged about 102k. Recently, the overall context window was apparently increased from from ~245k to ~353k and a new "v2" compaction mechanism is applied, that not only means that longer contexts (with more cached input tokens) now become more likely, but also I noticed the compactions were less efficient than before, often by a factor of 2-3.

Combined, this resulted in roughly 30k input tokens per tool action in the older session versus about 104k in the newer one. That is approximately a 3.5x increase in input tokens for each practical tool action, which closely matches the subjective feeling that usage now disappears several times faster.

Prompt caching was working correctly, often above 95%, but cached input is discounted rather than free. Repeatedly sending 100k-200k cached tokens across dozens of model/tool cycles still consumes a large amount of the five-hour allowance. As said, compaction may also contribute. Older sessions often compacted down to relatively small contexts, while newer sessions sometimes retain 70k-170k tokens after compaction. Large IDE selections, web results, command output, and other user-context messages may survive compaction and then be included in every later call.

There is also some evidence that older usage reporting lagged behind actual consumption. Large turns sometimes appeared cheap when they completed, with the percentage jumping substantially only during later turns. Newer sessions seem to update the visible meter more promptly, which may amplify the perceived change. I even used to be able to run Codex a bit longer after I already saw 0%, I assume the "extra usage" as well as the delayed-reported usage just got eaten by OpenAI and that's no longer the case.

Even though it felt that way, I don't see strong evidence that the underlying allowance was reduced by a factor of 2-3 as I first assumed. (For me as a Plus subscriber, it seems to be around 450 credits in a 5h hour window, and it seems to have been the same a month ago.) The stronger explanation is that newer Codex versions perform fewer tool actions per model invocation while carrying more context on every invocation, resulting in significantly less useful coding work per unit of usage.

Right now I'm trying to figure out how to counteract these issues (other than downgrading, of course). The context window and compaction behavior can be changed in config.toml, but I don't know yet how we could get the more efficient tool calls back... let's see!

EDIT: This did help in AGENTS.md:

## Token-efficient execution

- Minimize model/tool round trips. Batch independent inspections, searches,
  and verification commands into as few tool calls as practical.
- Strongly prefer a single tool execution with `Promise.all` with several
  `tools.shell_command(...)` invocations or at least a single such call with
  multiple sequential shell commands over multiple overall tool calls.
- For a straightforward implementation, inspect the relevant files once,
  implement in one pass where possible, and perform one proportional
  verification pass.
- Do not run broad repository searches, dump complete files, or print complete
  diffs when targeted paths, symbols, ranges, or diff statistics are enough.
- Do not use web search when the answer can reasonably be determined from the
  repository, installed source code, or existing project documentation.
- Do not create ad-hoc verification scripts for small changes unless ordinary
  project checks cannot validate the behavior.
- After one failed environmental verification attempt, diagnose narrowly.
  Avoid repeated retries, polling, and alternative verification mechanisms
  unless they are necessary to establish correctness.
- Running an existing focused test or build is normally sufficient. Do not
  escalate into multiple test, editor, runtime, and debugger verification
  passes for a low-risk change unless a failure requires it.
- Keep command output narrow. Prefer targeted `rg`, bounded file ranges,
  path-specific diffs, and concise status output.
- Do not read workflow skills merely to perform routine completion checks.
- If in doubt, ask the user how to proceed.

Also, I set these configurations:

# Compact substantially earlier than the current ~316k-token behavior.
# Also, limit context window overall to mid-June-2026 values that worked well.
model_context_window = 258400
model_auto_compact_token_limit = 220000

# Prevent one enormous command result, file dump, or JSON document from
# remaining in the conversation history in full.
tool_output_token_limit = 12000

compact_prompt = """
Create a minimal continuation state for the current coding task, not a
transcript or retrospective.

Target at most 8,000 tokens. Do not exceed 12,000 tokens.

Retain only:
- the current repository, working directory, branch, and worktree state;
- the current requested outcome and acceptance criteria;
- explicit user decisions, constraints, and rejected approaches;
- incomplete work and the immediate next actions;
- modified files, relevant symbols, and a concise description of each change;
- unresolved errors, including only the essential error lines;
- commands or verification steps that still need to be run;
- commit hashes only when they remain relevant to continuing the task.

Discard:
- completed tasks and superseded implementation history;
- raw command output, build logs, test logs, and repeated polling output;
- complete diffs and complete file contents;
- large JSON, generated files, lockfiles, datasets, and dependency listings;
- IDE auto-context, active selections, open tabs, cursor position, and recently
  viewed files;
- content from unrelated repositories or earlier tasks;
- repeated user messages;
- brainstorming, planning, and design discussion that has already been
  resolved;
- temporary plans and files under docs/superpowers;
- skill text, plugin instructions, and AGENTS.md contents that Codex already
  receives separately;
- explanations of successful commands and already completed verification.

Never preserve a large source file or IDE selection verbatim. Refer to it by
path and relevant symbol, key, line range, or concise semantic description.

Do not retain information merely because it appeared recently. Retain it only
when it is necessary to continue the current unresolved task correctly.

When uncertain whether historical material is needed, omit it and record the
file path or command that can be used to retrieve it again.
"""

I also added this, as I have read that memories can also contribute to excessive token usage (even in the background), but I'm not sure how big of an issue this is for me (I don't need memories though, so no downside to disabling them):

[features]
chronicle = false
memories = false

[memories]
generate_memories = false
use_memories = false

Still working on improving the situation further.

@CherryDT

@CherryDT I suggest modifying your AGENTS.md prompt to avoid "Promise.all with several tools.shell_command(...) invocations" - the model-visible tool is called exec_command. shell_command is a legacy surface no longer visible by a model running in codex after the UnifiedExec refactor, so it just wastes reasoning tokens on figuring out that exec_command is what you meant.

Also default tool_output_token_limit is 10k tokens - 12k is higher than that.

model_auto_compact_token_limit is a fine change, the default is 90% of model context anyways so that would give you benefits at loss of long-horizon tasks. With model_context_window = 258400, the derived default would be 232,560 tokens. Setting 220,000 only compacts 12,560 tokens earlier, so the benefit is modest.

compact_prompt is a no-op since upstream codex has no override for re-enabling local compaction for OpenAI provider. remote_compaction_v2 is enabled by default

Completely out of quota again — when does the limit actually reset? For anyone else stuck waiting, I've been tracking observed reset timings here: https://codex-reset.com/timeline

For anyone trying to turn the “usage feels faster” reports into comparable local evidence, I built a small zero-dependency monitor around Codex's persisted rollout token_count events: https://github.com/tylerchen0123-sudo/CODEX-Inspection-Guidelines-for-Dosage

It keeps fresh input, cached input, output, and active-session activity separate instead of treating the cumulative total_token_usage snapshot as a per-turn value. That makes it easier to compare two CLI versions/workflows and answer questions like “did model-call count rise?” or “is most of the growth cached context replay?” without sharing prompt/tool content.

Important limitation: the local token counters are observability data, not a proof of the ChatGPT 5-hour/weekly subscription meter or billing. I would use them to compare workload shapes and regressions, not to claim a 1:1 quota conversion.

If people here can share only sanitized aggregates (calls, fresh/cache/output by time window, Codex version), I can keep the parser compatible with the current rollout shapes and add reproducible fixtures without needing private transcripts.

For anyone trying to turn the “usage feels faster” reports into comparable local evidence, I built a small zero-dependency monitor around Codex's persisted rollout token_count events: https://github.com/tylerchen0123-sudo/CODEX-Inspection-Guidelines-for-Dosage

Sol-pro advices against running it before some security and privacy hardening.

Right now I'm trying to figure out how to counteract these issues (other than downgrading, of course). The context window and compaction behavior can be changed in config.toml, but I don't know yet how we could get the more efficient tool calls back... let's see!

maybe try https://github.com/icoretech/codex-pooler and when setting up the Pool's models set them to Full instead of Lite, this enables parallel execution in codex

Navigation Menu

Repository navigation

Burning tokens very fast #14593

What version of the IDE extension are you using?

What subscription do you have?

Which IDE are you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

653 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Burning tokens very fast #14593

Description

What version of the IDE extension are you using?

What subscription do you have?

Which IDE are you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Mar 13, 2026

cy-ooi88 commented on Mar 13, 2026

etraut-openai commented on Mar 13, 2026

nishikawa7863 commented on Mar 13, 2026

cy-ooi88 commented on Mar 13, 2026

Xen0m commented on Mar 13, 2026

VannaGamma commented on Mar 13, 2026

bugduino commented on Mar 13, 2026

sibonyves commented on Mar 13, 2026

calves07 commented on Mar 13, 2026

dhpancor commented on Mar 13, 2026

neech commented on Mar 13, 2026

653 remaining items

fy-nn commented on Jun 24, 2026

egilewski commented on Jun 26, 2026

mploschiavo commented on Jun 26, 2026

egilewski commented on Jun 26, 2026

mabaojinbj commented on Jun 26, 2026

MrChadMWood commented on Jun 29, 2026

MrChadMWood commented on Jun 29, 2026

CherryDT commented on Jul 5, 2026

ignatremizov commented on Jul 23, 2026

taoyadev commented on Aug 4, 2026

tylerchen0123-sudo commented on Aug 12, 2026

egilewski commented on Aug 12, 2026

masterkain commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions