There is an issue with consumption as I do not really see a 4x (5 to 20) increased contingent and for the second time my weekly quota is gone in less than 1 day while using model Terra (Medium).
The model worked on a more or less simple code but run into a code verification loop without progressing with the actual code/project.
Since OpenAI closed the registration for new customers on the Pro (20x) plan due to processor capacity, I strongly think there are several issues in place and I have read complaints from many users with similar issues.
I hope OpenAI will be fair here with existing customers and seeks to resolve this in a timely manner and keeps an eye on this problem.
The code-verification loop detail may be more useful than it looks, because it gives you a way to separate “the task used a lot” from “the system spawned a lot of work without making proportional project progress.”
I have a separate current Codex case where a freshly reset weekly allowance went 0% → 100% in about 44 minutes during a security-scan task. The local rollout showed repeated worker/subagent fan-out. When OpenAI Analytics populated later, its feature attribution was:
Subagents: 47.6%
Security scan: 46.3%
Agent-created tasks: 6.1%
Those add to 100%.
The GitHub issue with the sanitized evidence is here:
I am not saying your Terra verification loop has the same root cause. But if your account exposes Analytics, I would check it after the data has had time to populate and preserve the feature breakdown for the affected period.
Useful existing evidence would be:
weekly reset timestamp;
meter before the task and after it;
task start/end time;
model + reasoning level;
whether subagents/agent-created tasks/security scan appear in Analytics;
whether the task was actually progressing or repeatedly re-verifying the same code.
No need to rerun or burn another weekly allowance for this. If your existing data shows the same fan-out shape, adding that independent specimen to #46819 would be genuinely useful.
Here’s a screenshot of the analytics, where one can clearly see there hasn’t been hardly any usage after the last reset on the 18th September, but the limit exceeded anyway after 3 days (while only starting today, Monday using it) or better one day.
Here’s the breakdown according to Codex when asked for the stats:
Question
What I can verify
Weekly reset
Next on September 26, 2026, 18:19:51 CEST. Codex usage is currently at 100%, with 0 credits available.
Meter before/after the task
Before: no snapshot was recorded, so it cannot be reconstructed. After: Codex usage is at 100%. The separate base_model_inference meter is currently at 7%; that is not the same Codex meter.
Task start/end
Task 01a0bb1c-99ef-7a62-949f-72e69111a9fb was created on September 19, 2026 at 21:20:08 CEST. It is still marked active in the system, so there is no formal end time. The internal runtime counter reported 68,749 seconds / 19:05:49.
Model
Terra was used according to the task context. The exact internal model ID is not visible in the task metadata available to me.
Reasoning level
Not visible in the available metadata. OpenAI Support would need to check this in the task/audit records.
Subagents/tasks
Yes. Three delegated reviewers were used: locate_candidate, quarantine_adversarial, and runtime_reproduction, plus the separate coordination task XXXXXXX – zentrale Fortsetzung (01a096b0-b899-75d2-b0cb-52a78f4122a8).
Security scan
I did not see a separate Codex Security scan or Codex Security plugin invocation in this task. There were source, XXXXX, hash, and runtime checks.
Progress or loop?
Both: there were genuine intermediate steps and one isolated runtime attempt, but the plugin’s functional state did not change. The same validation complex was then rechecked repeatedly. The final result remained a blocked test state, with no functional plugin progress.
This is much more useful than the original report because it gives us a different failure shape from #46819.
I would keep three facts separate:
Your weekly Codex meter is now at 100%.
The task is still marked active and reports about 68,749 seconds / 19h05m of runtime, with three delegated reviewers plus a coordinator.
You do not have a before-task weekly-meter snapshot, so we cannot honestly say how much of the 100% was charged to this one task.
The third point matters. “Still active for 19 hours” also does not by itself prove it was continuously consuming quota for 19 hours.
What is interesting is the execution pattern you recovered:
three delegated reviewers;
genuine intermediate work;
repeated re-checking of the same validation complex;
no functional plugin progress at the end;
no separate Security Scan invocation.
That means this is not the same specimen as #46819, where delayed OpenAI Analytics later attributed 47.6% to Subagents, 46.3% to Security scan and 6.1% to agent-created tasks.
If your Analytics page has the feature-level breakdown rather than only the daily bar, please preserve the breakdown for the affected UTC date once it has fully populated. In particular, whether Subagents or Agent-created tasks appear would tell us whether the delegated reviewers are also visible in OpenAI’s own accounting.
The other thing I would preserve is the mismatch you already have: apparently low visible daily Analytics activity after the reset versus a weekly Codex meter at 100%. Support can reconcile that server-side if you give them the existing task ID/timestamps privately.
If the task is no longer useful and is genuinely still running, I would stop it rather than leave it around. But I would not claim the “active” flag itself is the cause of the quota burn without accounting evidence.
No rerun needed. This current specimen is already useful.
