GPT-6 Astra Medium depleted 100% of Plus 5-hour quota in two short turns (~minutes total)

What subscription do you have?

ChatGPT Plus

Which model were you using?

GPT-6 Astra, Medium reasoning effort, in Codex

Platform

Windows / Codex local repository workflow

What issue are you seeing?

GPT-6 Astra consumed essentially the entire 5-hour Codex allowance in two very short, ordinary coding turns.

Observed usage:

Start: 100% of the 5-hour allowance available.
First Astra Medium turn: 100% -> 42%. This turn took less than 5 minutes.
Second Astra Medium turn: 42% -> 0%. This turn took roughly 1–2 minutes and ended with You've hit your usage limit before the task was finished.

The conversation was not large or long-running. This was a normal repository task, not an hours-long session and not a context with many compactions.

What was Codex doing?

The task was a normal Unity repository fix:

Read a handful of project docs and relevant C# files.
Inspect procedural-world and player-controller code.
Make a small multi-file implementation change.
Add an editor test for character traversal.
Run Unity EditMode tests.
Inspect one failure (InvalidOperationException: Procedural door pool contains a destroyed object).
Apply a one-line follow-up fix.
Attempt to rerun the tests.
Codex hit the usage limit before completion.

The resulting diff at that point was only approximately:

4 files changed, 165 insertions(+), 7 deletions(-)

This is a routine agentic loop (edit -> test -> diagnose -> patch -> retest), not an unusually large workload.

Representative transcript excerpts

First short turn (the one that reduced the 5-hour quota from 100% to 42%):

› ok, faça

• Vou corrigir o piso externo, abrir saídas do prédio e substituir os blocos nas portas por passagens transitáveis. Também vou acrescentar testes
  com o collider do personagem para verificar a travessia das saídas e de cada cômodo.

• Ran Get-Content ... AGENTS.md; ... docs/SPEC.md ... docs/CODE_REVIEW.md ... docs/ROADMAP.md ... docs/DEPLOYMENT.md; git status --short

• Ran Get-Content ... GoProceduralWorldManager.cs ... GoProceduralRoomInstance.cs; rg -n 'CharacterController|radius|height|Move\(' ...

• Ran Get-Content ... GoProceduralWorldManager.cs ...; rg --files ...

• O Unity está aberto. Salve suas alterações e feche o Editor deste projeto para eu executar os testes automatizados; avise quando estiver fechado.

• Ran rg --files ...; Get-Content ... GoProceduralWorldManager.cs ...
• Ran Get-Content ... GoLocalPlayerMotor.cs ... GoOfflineDevBootstrap.cs ...

Second short turn, after closing Unity:

› fechei

• Edited 3 files (+35 -7)
...
• Edited Game/GatherV2/Assets/Tests/Editor/GoOfflineDevPlayModeTests.cs (+130 -0)
...
• Ran Unity.exe -batchmode ... -runTests ...
...
InvalidOperationException: Procedural door pool contains a destroyed object.
...
• Edited GoProceduralWorldManager.cs (+1 -0)
...
• Ran Unity.exe -batchmode ... -runTests ...

■ You've hit your usage limit. Upgrade to Pro, purchase more credits or try again later.

Steps to reproduce

Use a ChatGPT Plus account with a fresh 5-hour Codex allowance.
Start a relatively short Codex conversation in a normal non-trivial repository.
Select GPT-6 Astra with Medium reasoning effort.
Ask it to perform an ordinary coding task that requires a few file reads, a small implementation, and tests.
Check Codex usage after the first turn.
Continue once so it can test/fix/retest.
Check usage again.

In this case the two short turns consumed 58% + 42% = 100% of the 5-hour allowance.

Expected behavior

A normal coding workflow consisting of a few file reads, a small multi-file patch, one test creation, and one or two local test runs should not consume the entire Plus 5-hour quota in only a couple of minutes / two turns, especially at Medium effort.

At minimum, the quota accounting should be investigated for Astra and the product should expose enough usage telemetry to explain why a short ordinary task can consume nearly or literally the entire 5-hour allowance.

Actual impact

With this consumption rate, GPT-6 Astra is effectively unusable for real Codex development on Plus: there is not enough quota to complete even one ordinary implement -> test -> fix -> retest cycle, and it is difficult to benchmark or evaluate the model because the allowance can disappear after one or two turns.

Additional note

The percentage values above are from the Codex usage indicator observed immediately around these turns. Even if usage reporting is delayed or batched internally, the practical outcome was the same: a fresh 5-hour allowance became unavailable after two very short Astra Medium interactions.

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

Powered by Codex Action

I have the same experience. Astra is destroying token usage and my Pro x5 required 2 token resets in 2 days. I never needed those token before.

My entire quota was depleted as well within 5 minutes and only had 25 insertions and stopped before it was finished because no credits left.

This is unacceptable and I want my money back. I am paying for a service not five minutes of unusable content.

I’m seeing the same issue on ChatGPT Plus.

After a usage reset, a single very short GPT-6 Astra interaction consumed approximately 6% of my 5-hour allowance. The prompt was only one sentence, and the response was a few hundred words, with no repository access, terminal commands, file reads, or other tool calls. As a comparison, after another reset, using GPT-5.6 for roughly 30 minutes consumed only about 25% of the same 5-hour allowance. With GPT-6 Astra, I can exhaust the entire 5-hour allowance in roughly 10–20 minutes of normal use, whereas GPT-5.6 behaves much closer to the historical usage rate I’ve experienced.

This looks disproportionately high and may indicate an Astra quota weighting / usage-accounting issue rather than simply higher model cost.

feedback id 01a07a0c-95f6-7da2-a6bf-113be168b169

I am seeing a very similar Astra quota-consumption pattern on ChatGPT Plus, and in my case the affected rollout provides fairly detailed telemetry about what the parent model was doing.

Environment:

Codex CLI 0.153.1
Windows 10 x64
Parent: gpt-6-astra / low
Workers: 2 × gpt-5.6-luna / xhigh

During one orchestration run lasting about 33 minutes, server-reported 5h usage increased from:

53% → 100%

The run then terminated on the usage limit before implementation/build completed.

What makes this case useful is that the parent rollout shows a concrete source of very large Astra-side overhead:

47 × wait_agent
all 47/47 used timeout_ms = 30000
all 47/47 returned only timed_out: true
each timeout re-entered the Astra parent with roughly 150k input tokens
those timeout-only polls alone consumed 7,130,181 parent input tokens
polling represented about 68% of the Astra parent's total raw input volume

I also measured a Luna Max control session on the same Plus account earlier the same day.

Over 127 minutes of active gpt-5.6-luna / max work:

input tokens:          9,538,330
cached input tokens:   8,998,400
output tokens:            86,771

server-reported 5h usage increased only:

2% → 10%  (+8 percentage points)

The two Luna X-High workers in the Astra run processed 19.51M input tokens combined. Even scaling the measured Luna Max consumption linearly by raw input volume gives roughly:

8 × (19.514M / 9.538M) ≈ 16.4 percentage points

So normal Luna-worker consumption alone does not plausibly explain most of the observed +47 percentage-point increase. The remaining workload was the Astra parent, which processed 10.46M input tokens, including the 7.13M timeout-only polling input above.

I submitted /feedback from the affected session with diagnostics attached.

Uploaded parent thread ID: 01a079cd-a44b-7ef2-8afb-45a3c5659a79

Full telemetry and the polling analysis are here:
#35259 (comment)

This may be useful for distinguishing normal Astra model cost from additional quota amplification caused by repeated parent-model re-entry during orchestration.

I’m seeing very similar behavior on ChatGPT Plus with gpt-6-astra in Codex Security.

I ran a security scan on a relatively small website repository using:

npx --yes @openai/codex-security scan . \
  --model gpt-6-astra \
  --effort high

After roughly 2.5 minutes, about 50% of my 5-hour Codex usage window had been consumed.

This makes Astra effectively unusable for regular Codex Security scans on the Plus plan, even for small repositories.

Environment:

Codex CLI: 0.153.4
Codex Security SDK: 0.1.25
Bundled plugin: 0.1.94
Model: gpt-6-astra
Reasoning effort: high
Auth: ChatGPT Plus

A dry run correctly reported:

model: gpt-6-astra
reasoningEffort: high

So this appears to be usage accounting / quota consumption rather than a model-selection issue.

It would be helpful to know whether this level of quota consumption is expected for Astra on Plus, or whether there is a rate-limit/accounting bug here.

I’ve noticed similar Astra usage behavior in my own engineering tasks.
Instead of treating this only as a quota problem, I started looking at how the workload was being assigned to the model. A significant part of the context and execution did not actually require premium reasoning.
I’ve been experimenting with splitting the workflow across specialized agents/models:
Router → Context Scout → Premium Reasoning → Implementer → Reviewer
Repository discovery and context filtering are handled before the expensive reasoning step. Routine implementation, tests, documentation and Git operations can then be delegated to smaller models, while Astra is reserved for architecture, security and difficult reasoning.
This obviously doesn’t change Astra’s underlying quota consumption, but it can reduce how much unnecessary work is sent to it.
I turned the experiment into a small open-source GitHub template in case it is useful for others testing similar approaches:
https://github.com/robert-lukowski/token-gourmand
Still early and I’m planning to benchmark the actual reduction rather than make assumptions about the savings.

I can reproduce the same excessive quota consumption with GPT-6 Astra at Medium effort in Codex Desktop on Windows.

Environment

Subscription: ChatGPT Plus
Platform: Windows / Codex Desktop local-repository workflow
Model: GPT-6 Astra
Reasoning effort: Medium
Bundled CLI reported at the time of writing: codex-cli 0.132.0

Observed usage

5-hour allowance before the task: 100% remaining
5-hour allowance immediately after the single task: 38% remaining
Consumption from one task: 62 percentage points
Task duration: approximately 13 minutes 24 seconds

The task was a normal, self-contained repository workflow involving code inspection, implementation, generated artifacts, visual verification, and automated checks.

The task completed successfully in one turn. There was no repetitive agent loop, no multi-agent delegation, and no repeated user follow-up cycle. Despite this, it consumed 62% of the entire five-hour allowance.

On the same account, comparable repository work with GPT-5.6 Sol at High effort has consumed far less of the allowance. I do not have a precise before/after percentage for a matched Sol run, so this comparison is qualitative, but the difference is large enough to make Astra Medium impractical for routine development work.

This corroborates the report in this issue and suggests the problem is not limited to very short tasks: a completed 13-minute workflow can still consume most of a fresh five-hour allowance.

It would help if Codex exposed a per-turn usage breakdown (input, cached input, cache writes, reasoning/output tokens, tool-call overhead, and the quota conversion applied) so users can distinguish genuinely expensive work from a metering or caching problem.

Adding a second reproducible Plus / GPT-6 Astra Medium case from Codex CLI 0.153.4 on a GitHub Codespace (Linux).

Observed behaviour:

ChatGPT Plus account.
Codex CLI 0.153.4.
Model: gpt-6-astra, reasoning medium.
The prior 5-hour window was exhausted, so I stopped work and waited for the stated reset.
After the reset, I resumed the same implementation session and sent one continuation prompt for a bounded repository security/CI task.
That single resumed turn ran the requested implementation/test loop and consumed essentially the entire fresh 5-hour allowance. At the end /status showed 1% left on the 5-hour limit, with the next reset at 17:45 local time; the next attempt was rate-limited.
Weekly allowance still showed 54% left, so the immediate blocker was the 5-hour bucket rather than the weekly bucket.

Codex's own end-of-turn token display for that resumed session showed:

Token usage: total=336,726
input=274,007
cached input=9,438,976
output=62,719
reasoning=22,101

The task was non-trivial (security-preservation mutations, local regression tests, database migration replay, concurrency/stress checks, typecheck/lint/build), so I am not claiming the model did negligible work. The problem is practical predictability: after waiting for the full reset, one Medium-effort prompt can consume ~99% of the 5-hour allowance, making it impossible to plan or complete an independent implementation/review cycle on Plus.

This also makes the current percentage meter difficult to interpret because users cannot see how model choice, cached-context replay, tool/test loops, reasoning, retries, or context size are weighted against the 5-hour allowance.

Request:

Please investigate the server-side accounting for this session class on GPT-6 Astra Medium / Plus.
Expose per-turn allowance consumption or an auditable usage breakdown (foreground model calls, cached context, retries/compactions/tool-loop re-entry, reasoning, and the amount charged to the 5-hour bucket).
If consuming nearly a full 5-hour Plus bucket in one substantial Astra Medium turn is intended, surface a clear pre-run warning/estimate so users do not wait five hours only to get one turn before another lockout.

I have kept private repository names, account email, and session identifiers out of this public comment, but can provide a session identifier privately to OpenAI Support if maintainers need server-side correlation.

I am seeing similar Astra Medium quota behavior on ChatGPT Pro using Codex Desktop on Windows.

Environment

Codex Desktop package: 26.903.8094.0
Bundled Codex CLI recorded in the affected rollouts: 0.153.4
Model: gpt-6-astra
Shared weekly Codex allowance

I audited the local request-level token telemetry for Astra activity on September 8-9, deduplicating response_id and summing each request's usage. I excluded repository names, prompts, account identifiers, and session/turn IDs from this public summary.

Effort	Turns	Model responses	Input	Cached input	Non-cached input	Output	Reasoning output
Max	8	450	62,118,264	59,712,128	2,406,136	477,130	207,094
Medium	65	1,959	272,448,206	264,695,040	7,753,166	1,027,764	303,660

The Medium period processed about 4.35 times as many model responses as the Max period. Per response, Medium averaged about 3,958 non-cached input tokens, 525 output tokens, and 155 reasoning tokens; Max averaged about 5,347 non-cached input tokens, 1,060 output tokens, and 460 reasoning tokens. The local telemetry therefore does not by itself show Medium using more tokens per response. It shows that several long-running Medium tasks generated far more response/tool cycles, replaying roughly 135,000 cached input tokens per response on average.

The server-reported weekly meter still needs reconciliation. While several Medium tasks were active, the codex weekly used_percent snapshots progressed from the mid-40s to 74%. Multiple concurrent rollouts occasionally received stale snapshots that differed by one point. Separately, the UI was observed showing approximately 69% and later a value in the mid-20s. The local server snapshots reached 69% used and later 74% used, which corresponds to 26% remaining. That sequence is consistent with the client sometimes presenting used percentage and remaining percentage inconsistently, although I do not have screenshots proving the labels shown at each moment.

Please investigate:

The exact weekly allowance charged to each Astra Medium and Max response in this account window, including the weighting applied to cached input, output, reasoning, retries, compactions, tool-loop re-entry, and background work.
Whether concurrent Codex tasks can amplify usage through unnecessary model re-entry or repeated cached-context replay.
Whether the Windows client can alternate between displaying the backend's used_percent and a calculated remaining percentage.
Why concurrent sessions sometimes receive rate-limit snapshots that move backward by one point.
If any allowance was deducted incorrectly, restore the affected quota.

Related: #43222 and #41220.

I used my week limit + 2 resets within a couple of days. I have 11% left for te next 5 days :)

Astra has an insane token hunger. I have had much more agressive programming days before with Sol on high and I didn't reach the limit on pro x5

I developed on High then went to Medium now I am back on Sol.

I experience a raise in token cost for Astra. In the last 24 hours I have hit my 5h limit 4 times.

This whole week I had never reached the 5h and 7d limit. Since yesterday I can only ask 2 prompts and that's it.

This is not usable, predictable, trustworthy, transparant.

I can also confirm. 2 prompts and the whole 5H session is gone. I switched back to Sol and similar prompts only used 10%.

What subscription do you have?

ChatGPT Plus

Which model were you using?

GPT-6 Astra, Medium reasoning effort, in Codex

Platform

Windows / Codex local repository workflow

What issue are you seeing?

GPT-6 Astra consumed essentially the entire 5-hour Codex allowance in two very short, ordinary coding turns.

Observed usage:

Start: 100% of the 5-hour allowance available.

First Astra Medium turn: 100% -> 42%. This turn took less than 5 minutes.

Second Astra Medium turn: 42% -> 0%. This turn took roughly 1–2 minutes and ended with You've hit your usage limit before the task was finished.

The conversation was not large or long-running. This was a normal repository task, not an hours-long session and not a context with many compactions.

What was Codex doing?

The task was a normal Unity repository fix:

Read a handful of project docs and relevant C# files.

Inspect procedural-world and player-controller code.

Make a small multi-file implementation change.

Add an editor test for character traversal.

Run Unity EditMode tests.

Inspect one failure (InvalidOperationException: Procedural door pool contains a destroyed object).

Apply a one-line follow-up fix.

Attempt to rerun the tests.

Codex hit the usage limit before completion.

The resulting diff at that point was only approximately:
4 files changed, 165 insertions(+), 7 deletions(-)
This is a routine agentic loop (edit -> test -> diagnose -> patch -> retest), not an unusually large workload.

Representative transcript excerpts

First short turn (the one that reduced the 5-hour quota from 100% to 42%):
› ok, faça

• Vou corrigir o piso externo, abrir saídas do prédio e substituir os blocos nas portas por passagens transitáveis. Também vou acrescentar testes
  com o collider do personagem para verificar a travessia das saídas e de cada cômodo.

• Ran Get-Content ... AGENTS.md; ... docs/SPEC.md ... docs/CODE_REVIEW.md ... docs/ROADMAP.md ... docs/DEPLOYMENT.md; git status --short

• Ran Get-Content ... GoProceduralWorldManager.cs ... GoProceduralRoomInstance.cs; rg -n 'CharacterController|radius|height|Move\(' ...

• Ran Get-Content ... GoProceduralWorldManager.cs ...; rg --files ...

• O Unity está aberto. Salve suas alterações e feche o Editor deste projeto para eu executar os testes automatizados; avise quando estiver fechado.

• Ran rg --files ...; Get-Content ... GoProceduralWorldManager.cs ...
• Ran Get-Content ... GoLocalPlayerMotor.cs ... GoOfflineDevBootstrap.cs ...
Second short turn, after closing Unity:
› fechei

• Edited 3 files (+35 -7)
...
• Edited Game/GatherV2/Assets/Tests/Editor/GoOfflineDevPlayModeTests.cs (+130 -0)
...
• Ran Unity.exe -batchmode ... -runTests ...
...
InvalidOperationException: Procedural door pool contains a destroyed object.
...
• Edited GoProceduralWorldManager.cs (+1 -0)
...
• Ran Unity.exe -batchmode ... -runTests ...

■ You've hit your usage limit. Upgrade to Pro, purchase more credits or try again later.
Steps to reproduce

Use a ChatGPT Plus account with a fresh 5-hour Codex allowance.

Start a relatively short Codex conversation in a normal non-trivial repository.

Select GPT-6 Astra with Medium reasoning effort.

Ask it to perform an ordinary coding task that requires a few file reads, a small implementation, and tests.

Check Codex usage after the first turn.

Continue once so it can test/fix/retest.

Check usage again.

In this case the two short turns consumed 58% + 42% = 100% of the 5-hour allowance.

Expected behavior

A normal coding workflow consisting of a few file reads, a small multi-file patch, one test creation, and one or two local test runs should not consume the entire Plus 5-hour quota in only a couple of minutes / two turns, especially at Medium effort.

At minimum, the quota accounting should be investigated for Astra and the product should expose enough usage telemetry to explain why a short ordinary task can consume nearly or literally the entire 5-hour allowance.

Actual impact

With this consumption rate, GPT-6 Astra is effectively unusable for real Codex development on Plus: there is not enough quota to complete even one ordinary implement -> test -> fix -> retest cycle, and it is difficult to benchmark or evaluate the model because the allowance can disappear after one or two turns.

Additional note

The percentage values above are from the Codex usage indicator observed immediately around these turns. Even if usage reporting is delayed or batched internally, the practical outcome was the same: a fresh 5-hour allowance became unavailable after two very short Astra Medium interactions.

Good to see another game developer on here. Facing almost the same issue. Initially in ChatGPT app then even in CodexCLI. Whether its a simple JS task with Astra or Sol or even putting Astra on Ultra High with subagents or even with just using 5.6 Sol on medium, the usage gets burned through in a few turns. It wasnt like this before Astra release

Sharing a test config here for others to try and see percentage of improvement, if any

https://gist.github.com/TheLazyIndianTechie/d8052597c332d2faf4b80a7e3049d1b0

This is basically appending a guidance prompt in the projects ./codex/config.toml and asking Astra to delegate to subagents, not poll them and just wait.

I created 3-4 project specific subagents with limitations. Initial tests that I ran - from about 3-5 prompts where Astra (High) would consume 90% of the 5-hour limit, its come now for about 13m and 24s run. Values below

gpt-6-astra high · gpt-6-astra · high · ue6-mac · 5h 39% left · weekly 58% left · Context 79% left · 258K window · 67.1K used · 1.61M in · 9.15K out · Main [default]

I still think it's way worse than it pre-astra release. But its definitely an improvement from over an hour ago.

Note: weekly went from ~64% to 58% during this time. I'm on Plus not on Pro

This is unacceptable, if plus users cannot even use it for 10 minutes, why did you even make it available in plus plans? We need our money back, OpenAI!!

With GPT-6 Astra the token usage seems to have exponentially increased. Understand this model utilizes more resources but what is the point of having frontier models if users cant use them for their use cases responsibly. I don't have a huge codebase but still codex exhausts usage within a day.

Additional GPT-6 Astra Light usage test

This test was performed in Codex Desktop on Windows 11 using GPT-6 Astra Light and Computer Use.

The account is a paid ChatGPT Business workspace with a paid seat.

Task performed

I asked Codex to use the already-open Windows Notepad application, type a short message, save the file to Downloads, and leave Notepad open.

The task completed successfully in 1 minute and 52 seconds. Codex moved the mouse, entered the text, saved the file, and left Notepad open.

Usage before the task

Immediately before starting the task, the five-hour Codex/Work usage balance showed 72% remaining.

Usage after the task

Immediately after this single task, the five-hour balance showed 57% remaining.

That is a 15-percentage-point decrease for one successful task that lasted less than two minutes.

Practical impact

This consumption rate makes GPT-6 Astra difficult to use for normal development work. A short Notepad test consumed 15 percentage points of the five-hour allowance. When I use Astra for a development task, a single prompt can consume most or all of the five-hour allowance before the work is completed, leaving insufficient capacity to continue testing, correcting, or finishing the task.

This is a paid ChatGPT Business workspace, not a free trial or a small promotional allowance. The concern is not simply that Astra costs more than other models. The concern is that the consumption rate makes Astra impractical for ordinary development work, even on a paid Business subscription.

Please investigate whether this level of consumption is expected, whether Computer Use creates excessive tool or context overhead, and whether the usage meter is correctly accounting for the work performed.

A per-task breakdown showing model processing, screenshots, Computer Use actions, retries, context processing, and the exact allowance deduction would make this behavior auditable.

I think this may be related to context compaction.

I experienced very similar extreme usage while using OpenCode. After switching to the latest Codex app, however, the problem disappeared for me. The Codex app automatically compacts the context as it grows, and I can now run much longer agentic sessions without rapidly exhausting the 5-hour allowance.

Since this issue is occurring in Codex CLI, while I experienced similar behavior through OpenCode, I wonder if context is not being compacted properly in these cases. If the full/growing context is repeatedly being sent, that could potentially explain the unexpectedly high usage.

I can't confirm this is the root cause, but the difference in behavior after switching to the latest Codex app was significant.

I was at 100% of my 5-hour usage limit, GPT plus account. I asked Astra, with Medium effort, to convert two simple web pages into PowerPoint presentations. Each page contained a table with some text and a small image in each row, and I mainly wanted to be able to edit the text afterward.

It completed both tasks successfully and did a great job. However, when I checked my usage afterward, I only had 11% left, after just two prompts, one for each web page.

That seems a bit excessive for what were relatively simple tasks.

Thank you to the Codex team for listening.

After today’s GPT-6 Sol and Luna release, credit usage feels dramatically better. In my testing, GPT-6 Luna is now comparable to, and sometimes even more efficient than, GPT-5.6 Luna.

This is a huge improvement over the earlier GPT-6 Astra Light usage I reported above. The new models feel much more practical for normal development work.

my 5 hour usages limit on plus plan gone in 2 minute of astra high model thinking .

astra high burned the 5h usage limit in 10 minutes and did not even start editing my code 🤣

two short turns and the whole five hour quota gone. that is not a big task, that is the context tax, and the money-back rage is earned.

this is the exact failure that got me to put a small gate between the agent and the shell. honest scope, nothing outside the model can stop it from re-reading its own context. what a local gate gives you is the receipt trail. every command the session ran on your machine is recorded with a verdict, so a two-turn burn shows exactly what the session was doing while the quota drained, instead of a number and a shrug.

it is free, it runs on your machine, and this project has been helping me out for a while now.

npx operator-lite

it starts in shadow mode and only records, so nothing changes at first.

npx operator-lite mode enforce

run that once from your own terminal and the destructive-command blocking is on too.

For everyone here asking for a reset or a refund: a "same here" with a percentage is easy to dismiss. A table from your own logs is not. Codex already records the evidence locally. Each call in ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl logs its tokens (input, cached, output, reasoning) next to the server's rate_limits.used_percent for the 5-hour and weekly windows.

From that you can show, per window, quota points used per million tokens. If Astra Medium costs, say, 10× more points per million tokens than Sol did for the same kind of task on the same plan, that is a model weighting or metering issue, not your workload. You can also list the exact UTC minutes when the meter jumped (for example 100% → 42%) next to the few hundred thousand tokens behind each jump. Several comments above (e.g. "read the same file over and over") also point at workload amplification. The same logs show that as context replay and repeated tool output, so you can tell which case you are in.

Free script that builds those tables locally (disclosure: I made it): npx github:lowkey-studio/quotatrace --since 14d. No dependencies, nothing uploaded, report is counts only. https://github.com/lowkey-studio/quotatrace. If you'd rather have someone read your report and draft the support message for you, there's an optional paid review on the site, but the script is all you need to get the numbers.

Navigation Menu

Repository navigation

GPT-6 Astra Medium depleted 100% of Plus 5-hour quota in two short turns (~minutes total) #42987

What subscription do you have?

Which model were you using?

Platform

What issue are you seeing?

What was Codex doing?

Representative transcript excerpts

Steps to reproduce

Expected behavior

Actual impact

Additional note

Environment

Observed usage

5 remaining items

What subscription do you have?

Which model were you using?

Platform

What issue are you seeing?

What was Codex doing?

Representative transcript excerpts

Steps to reproduce

Expected behavior

Actual impact

Additional note

Additional GPT-6 Astra Light usage test

Task performed

Usage before the task

Usage after the task

Practical impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

GPT-6 Astra Medium depleted 100% of Plus 5-hour quota in two short turns (~minutes total) #42987

Description

What subscription do you have?

Which model were you using?

Platform

What issue are you seeing?

What was Codex doing?

Representative transcript excerpts

Steps to reproduce

Expected behavior

Actual impact

Additional note

Activity

github-actions commented on Sep 5, 2026

CamilleHbp commented on Sep 6, 2026

gbsr commented on Sep 6, 2026

NUS-Tim commented on Sep 7, 2026

bompus commented on Sep 7, 2026

tagorr commented on Sep 8, 2026

iamspido commented on Sep 8, 2026

robert-lukowski commented on Sep 8, 2026

duanra-a16a commented on Sep 9, 2026

Environment

Observed usage

kamo-k commented on Sep 9, 2026

ppgnox commented on Sep 9, 2026

5 remaining items

swisswebxperts commented on Sep 11, 2026

m4t5k4 commented on Sep 12, 2026

EnigmaCEO commented on Sep 12, 2026

TheLazyIndianTechie commented on Sep 12, 2026

What subscription do you have?

Which model were you using?

Platform

What issue are you seeing?

What was Codex doing?

Representative transcript excerpts

Steps to reproduce

Expected behavior

Actual impact

Additional note

TheLazyIndianTechie commented on Sep 12, 2026

TanbirRamim commented on Sep 15, 2026

surakshith-suvarna commented on Sep 16, 2026

pirolid commented on Sep 20, 2026

Additional GPT-6 Astra Light usage test

Task performed

Usage before the task

Usage after the task

Practical impact

Davidtrassu commented on Sep 20, 2026

raidolo commented on Sep 22, 2026

pirolid commented on Sep 23, 2026

l33tx0 commented on Sep 27, 2026

erw-1 commented on Oct 3, 2026

entity-0-0-2 commented on Oct 8, 2026

lowkeybuilds commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions