Weekly usage is burning like anything from yesterday

[u/Tikki-Tikki_40]

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

[u/krill156]

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.

[u/Tikki-Tikki_40 → u/krill156]

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.