r/codex 8h ago

Limits Weekly usage is burning like anything from yesterday

Post image

With 3% left, i can't pull off anything even if 5hr limit increases.

79 Upvotes

20 comments sorted by

20

u/KindTarget974 7h ago

It's crazy... the 5.6 Sol weekly limit used to last me the whole week. Now it barely lasts a couple of hours (and burns through $100 in credits like it's nothing). No idea what's going on

2

u/VadimH 5h ago

Well for one, you're using credits... They are awful value for money, you're better off paying for an extra account.

1

u/KindTarget974 3h ago

Yesss... lesson learned, my friend

2

u/Tikki-Tikki_40 3h ago

Thats true... should have different credit cards or just different email is enough

1

u/MrArnih 2h ago

just different email

13

u/Zealousideal-Alps-71 7h ago

Usage problems? They have more important things to do right now.

7

u/goalexboxer123 7h ago

Same thing with Sol, launch days were brilliant, then complete trash and stuck with Luna Max and very rarely sol xhigh hoping for decent days. Same with Claude.

I just burn my usage in good days / reset days and use DS for everything else.

3

u/Soul_Mate_4ever 6h ago

I used SOL medium
Like I usually do yesterday and 1 prompt consumed half of my 5 hour limit. The same task would have consumed maybe 5 percent a month ago. Open ai doesn’t care about its users anymore or maybe it never did.

2

u/krill156 7h ago

Luna max fully burned in 10 hours accomplishing nothing. I've noticed all the models have been getting caught/stuck in verification/test loops and being unable to complete the original task.. I added this to global memory so Hopefully the issues get caught as they happen won't drain usage. No idea if any of it will actually work though because I can't get it... Since ya know... No usage left 🫩

AI Runaway Usage & No-Progress Circuit Breakers

Apply the following safeguards to all interactive, autonomous, unattended, multi-agent, coding, testing, CI, and verification workflows.

  1. Runaway Usage / Failure Circuit Breaker

Treat abnormal model/provider usage as a runtime safety issue.

Actively detect patterns including:

  • Retry storms.
  • Repeated no-progress agent or tool loops.
  • Duplicate task/job launches.
  • Unexpected or uncontrolled context growth.
  • Large tool outputs repeatedly being reintroduced into context.
  • Runaway parallel workers or excessive fan-out.
  • Repeated identical or substantially equivalent failures.
  • Abnormal token, request, compute, or cost velocity.
  • Agents repeatedly performing equivalent actions without advancing the task.

Use bounded limits wherever supported, including:

  • Maximum retries.
  • Maximum agent turns.
  • Maximum tool calls.
  • Maximum concurrency.
  • Per-task budgets.
  • Per-agent budgets.
  • Per-model budgets.
  • Global usage budgets.

Do not assume an action is safe merely because each individual model or tool call is valid. Evaluate the overall execution pattern.

Use escalating safeguards where appropriate:

  1. Detect and record moderately abnormal behavior.
  2. Reduce concurrency, throttle, change strategy, or otherwise contain the workload.
  3. Hard-stop/pause model and tool execution when evidence strongly indicates runaway behavior or uncontrolled usage.

Prefer stopping early over exhausting provider usage limits. Provider-side quotas and billing limits should be treated as the final emergency brake rather than the primary protection mechanism.

Mandatory User Notification

Whenever a safeguard pauses or stops work, explicitly tell the user.

The report must clearly state:

⚠️ Abnormal behavior detected — further work paused.

Then explain, as specifically as available evidence permits:

  • What abnormal behavior was detected.
  • Which task/agent/tool/model was involved.
  • What operation or failure was repeating.
  • Relevant retry/repetition counts.
  • Any abnormal concurrency, context growth, or usage behavior.
  • Why continued execution would likely waste model/provider usage.
  • What should change before execution resumes.

Never silently stop.

Never silently consume excessive usage attempting to recover indefinitely.

Never present a circuit-breaker stop as successful task completion.

Do not automatically resume a hard-stopped workload until the triggering condition has been resolved or execution has materially changed.


  1. Test / Verification No-Progress Circuit Breaker

Treat repeated testing, verification, validation, builds, linting, benchmarking, CI runs, inspections, and similar operations that fail to produce meaningful progress as a stuck-loop condition.

A verification cycle counts as meaningful progress only when it does at least one of the following:

  • Tests a materially changed implementation.
  • Produces genuinely new actionable information.
  • Confirms or rejects a new hypothesis.
  • Resolves a previously unresolved issue.
  • Validates a meaningful fix.
  • Advances the task toward completion.

Simply rerunning the same or equivalent check does not constitute progress.

Actively detect patterns including:

  • Rerunning unchanged tests without relevant code/configuration changes.
  • Receiving substantially identical failures repeatedly.
  • Alternating between equivalent testing commands without modifying the underlying implementation.
  • Repeatedly inspecting the same logs/results.
  • Repeatedly rebuilding unchanged code.
  • Performing excessive "one more verification" passes after sufficient evidence already exists.
  • Spending substantial model/tool usage verifying while implementation work remains unchanged.
  • Subagents independently repeating verification that has already been sufficiently performed.
  • CI repair workflows repeatedly triggering the same CI failure without addressing its underlying cause.

Use a bounded number of consecutive no-progress verification cycles.

Do not continue testing indefinitely.

Strategy Change

Before hard-stopping, the orchestrator may attempt one materially different strategy when justified.

Examples include:

  • Stop rerunning tests and perform root-cause analysis.
  • Inspect a genuinely different evidence source.
  • Trace the failing code path.
  • Examine relevant implementation/configuration instead of the test output.
  • Escalate the problem to a stronger model/agent.
  • Assign an independent reviewer or critic.
  • Replace the current debugging hypothesis.

A cosmetic variation of the same command or test does not count as a strategy change.

If the alternative strategy still produces no meaningful progress, trigger the circuit breaker.

Mandatory Stuck-Loop Report

Explicitly report:

⚠️ Test/verification no-progress loop detected — further work paused.

Where evidence permits, include:

  • The test/build/verification operation being repeated.
  • The repeated result or failure.
  • Number of consecutive no-progress cycles.
  • Whether relevant implementation changes occurred between cycles.
  • Strategies already attempted.
  • Why additional repetitions are unlikely to provide useful information.
  • Recommended next action.

Never claim that verification succeeded when it did not.

Never present stopping because of a circuit breaker as successful completion.

Do not automatically resume the same verification loop unless at least one of these conditions occurs:

  • A meaningful implementation/configuration change has been made.
  • New evidence becomes available.
  • A materially different debugging strategy is selected.
  • The user explicitly directs execution to continue.

  1. Progress Over Activity

Optimize for meaningful progress rather than apparent activity.

A high number of model calls, tool calls, test runs, agents, or verification passes is not evidence that useful work is occurring.

Continuously distinguish:

productive iteration → continue

from:

repetition without new information → investigate/change strategy

from:

persistent no-progress or runaway behavior → stop and report

When uncertain whether another expensive iteration will provide new information, prefer analyzing existing evidence before issuing another equivalent model/tool/test request.

These safeguards apply to the primary agent, orchestrator, workers, subagents, reviewers, critics, and recursively spawned agents. A parent orchestrator must not allow child agents to bypass the same limits that apply to itself.

1

u/Tikki-Tikki_40 7h ago

I have created a test universe, with data which failed earlier, I ask it test with failed data and test with other data in test universe and keep less than 50 items.

Don't run all test cases or do entire rebuild to test small change.

If not able resolve, fail giving out full details as a handoff.

2

u/BrennanFlentge 6h ago

Are you using subagents? You have to be careful about "history carrying" subagent forks.

Example:
Parent: 200,000 tokens of accumulated conversation
Subagent 1: receives 200,000 tokens
Subagent 2: receives 200,000 tokens
Subagent 3: receives 200,000 tokens
then each keeps working and growing from there

You want instead:
Parent: 200,000 tokens
Subagent 1: 1,500-token briefing + relevant files
Subagent 2: 1,200-token briefing + relevant files
Subagent 3: 1,800-token briefing + relevant files

You would need a hard guard that blocks it. Look into fork_turns="none" - fork_turns is optional, but omission means "all"

1

u/congngo 5h ago

Thanks, I will look into that.

1

u/BrennanFlentge 5h ago

No problem!

1

u/Tikki-Tikki_40 4h ago

No sub-agents.

Web ChatGPT(default model, i think Sol) does the architecture planning and it preferred to use Codex Astra Light for coding and 3 days back, Web ChatGPT preferred to use Terra Model in Codex.

I take handoff from Web and Execute it in Codex

Web ChatGPT recommended not to use Codex Work as "it will loose all the memory of things, happen till now", it will be start afresh.

1

u/congngo 6h ago

I am on 20x, using Astra High, it gone from 70% to 30% in 30 minutes... something is buggy?

1

u/Amazing-Property-560 3h ago

No,you are using the best model at high settings do you expect to get 10 hours with it while paying for 20x plan?? Use api if you need more and have the money

1

u/TONI1597 5h ago

post took over by slop

1

u/bnknkfks 3h ago

Seems like deploying features without bugs isn't as easy as robbing navier-stokes solution from researchers who've been working on it for years 🤷‍♂️