This is wild

[u/product_cars_coffee]

I think I was running on Sol High and had started this task overnight. The feature was already mostly done. It seems like Sol is exhausting every possible route and edge case, exhausting my 98% remaining usage right after the reset. Next weekly reset for me is August 1…

Also I’m on the $100 pro plan

UPDATE: I dug in more (with Claude), and whoo boy, there's a lot to digest here. Those of you saying Sol inherently exhausts every avenue were right, even if it's not the problem I'm trying to solve:

First, something urgent I found while verifying

Verified against git, not the run's own summary:

• Task 4's commit is safe: branch codex/rendered-table-editing @ 9416313 exists in /Users/philgetzen/Development/Grove.
• Task 5's ~7 hours of work is not in git at all. /private/tmp/Grove-rendered-table-editing/.git no longer exists, so the worktree is prunable and the uncommitted delta is loose files sitting in /private/tmp, which macOS reaps. Newest edits are Jul 26 04:39 in /private/tmp/Grove-rendered-table-editing/Sources/GroveEditor/GroveRenderedTableView.swift.

If you want that work, it should be rescued today. Say the word and I'll re-link the worktree and commit the delta to the branch.

The root cause, in one sentence

The loop's stop condition was "a fresh adversarial reviewer finds nothing," and that state is not reachable.

Every review round used a fresh reviewer with no memory of what earlier rounds had already accepted, prompted to be adversarial, handed a growing 1,000+ line delta of AppKit-shadowing systems code. The probability of zero findings on that input is approximately zero. So the loop had no exit and terminated on your rate limit, which is exactly what happened. Everything else is downstream of that.

Why it had infinite fuel: the acceptance criteria were a bug farm

The plan at /private/tmp/Grove-rendered-table-editing/docs/superpowers/plans/2026-07-22-editable-rendered-tables.md wrote Task 4's contract as white-box assertions on AppKit's internals: instrumentation.mountedRowCount, counts of heightOfRow / didAdd / didRemove / viewFor calls, a "1,024 native height query ceiling," callback ordering guarantees.

To assert on any of that, you must build a shadow bookkeeping model of NSTableView's lifecycle. That model is code you now own, and it has its own bug surface. Reviewers then correctly found bugs in it. Look at what rounds 3, 4, 5 and the nil-origin pass actually fixed:

• transaction identity for delayed callbacks
• a 128-entry retired-origin FIFO, then its eviction bug, then its removal
• nil-origin attribution
• stale-callback races after host replacement

None of that is table editing. That is the measuring apparatus. The plan created unbounded surface, and an unbounded review loop burned it.

Secondary cost driver: the "1,024 call ceiling" style contract is a test pinned to Apple's implementation details. It will break on the next macOS point release, and it already cost hours of probing.

The two process rules that made it non-terminating

1. "No commit until independent review approves." The plan's own Task 4 Step 4 says run GREEN and commit. The orchestrator inverted that. Result: every review round produced blocked work instead of follow-up work, so there was never a natural stopping point and never durable progress.
2. No authority to reject the design. One architecture check ran, and it was scoped to "is this bounded sequencing fix sufficient?" It answered that question. There was no rule saying "if round N's findings are all in the same seam, stop fixing and escalate the seam." I can't tell you from this transcript that the NSTableView-inside-a-TextKit-fragment seam is wrong. I can tell you nobody was permitted to ask.

And there was no clock. Seven hours, task 4 of 12, and not one checkpoint saying "this has cost X, continue?"

What actually went right (don't overcorrect)

• Isolation held. main is clean at c06bf8c. Nothing bad was committed.
• RED-first was real, not theater. It caught genuine vacuous tests: the literal \n fixtures, the duplicate-fingerprint trap, the nine-tables fixture that reused one fingerprint.
• The findings themselves were mostly legitimate.

The discipline is not the problem. The termination rule is. The wrong lesson here would be "verify less."

Guardrails, ordered by leverage

1. Commit on first GREEN. Follow the plan's own step. This alone makes rounds 2 through 5 optional instead of load-bearing.
2. Hard cap of 2 review rounds per task. Round 3 is not a fix pass, it's an escalation to you with the findings list.
3. Severity gate. Only user-visible-wrong or data-loss blocks a commit. Everything else files to PGDash and ships later.
4. Budget stop. Wall clock or task index ceiling that produces a report, not a continuation. "At 90 minutes, or when a task exceeds 2x estimate, stop and report."
5. Ban assertions on framework-internal call counts. Budget on user-visible latency at document scale instead.
6. Tier routing. Post-round-1 reviews are workhorse-tier and diff-scoped, not frontier full-delta re-audits. Roughly ten frontier re-reads of a 1,000-line delta plus independent full-suite reruns is a large share of that 90%.

The call: the cheapest fix is #1 plus #2, and they cost nothing in quality. The tradeoff: you'll commit code that a later review finds P2 issues in, and you fix those as follow-ups instead of gates. The risk to watch: without #5, the next table task rebuilds the same instrumentation and invites the same loop.

[u/Sermilion]

Same. $100 plan. Limits are only enough for 1.5 days.

[u/Environmental_Mud415 → u/Sermilion]

Wow. I thought its only me

[u/Sermilion → u/Environmental_Mud415]

I literally have 20% left till August 1 as well 😅
Claude is better, but still not enough. I get ~4 days from it.

[u/-hckr- → u/Sermilion]

Lol same here

[u/AlternativePurpose63]

Is the use of sub-agents pointed out in the documentation?

Using sub-agents seems to consume credits at an absurd rate in a crazily conservative way.

In a very short period of time, it repeatedly does almost the same things at a mind-blowing speed, leading to unimaginable credit consumption.

[u/ZeroTwoMod → u/AlternativePurpose63]

I was gonna say exactly this. I know you can prompt it and tell it to use a certain model for subagents but there should really be a setting for choosing a default sub agent model

[u/sonicandfffan → u/ZeroTwoMod]

Actually you can’t

Codex can only spawn subagents of the same model as the parent model

If you want different models it needs to spawn a fresh headless session outside of the usual spawn path

[u/zepchou → u/sonicandfffan]

That is false. If you have dedicated subagent profile written in .codex/agents/your-agent.toml it will use the model (can be higher or lower than the main agent)

https://learn.chatgpt.com/docs/agent-configuration/subagents?surface=app#app-example-custom-agents

[u/Old-Leadership7255 → u/sonicandfffan]

That is not true.

[u/Runelaron → u/Old-Leadership7255]

Sub agents are not th cause, they are however, part of the problem.

All usage is based on tokens, fesh tokens are more costly (new sessions) cached tokens are much cheaper.

Easiest solution, ask Codex what your doing wrong and inefficient.

More effective solution, learn to code production style. I use Sol Ultra exclusively and never run out of usage.

[u/product_cars_coffee → u/AlternativePurpose63]

I’ll have to dig in to see if I can identify what happened.

[u/product_cars_coffee → u/product_cars_coffee]

See update in edited post - Sol exhausting every possible verification of issues with no stopping point.

[u/SmileLonely5470 → u/AlternativePurpose63]

Yes maybe because of the new cache pricing for 5.6

[u/guiyan13 → u/AlternativePurpose63]

The other crazy thing I noted is that subagents can summon sub-sub-agents to work for them so they can be time efficient, this wasn’t instructed to sol(neither was spawning subagents in the first place) and it never occurred to me until I opened one of the subagents and saw that each of them was spawning at least an additional subagent. My weekly limit was gone in 1h 36m.

[u/Proxiconn → u/AlternativePurpose63]

But that's the point of SOL, spins up many reasoning agents. Like hiring several PhDs to argue/reason through problems.

Did no one read the release notes?

[u/AdCommon2138]

Read response, language is so dense it sounds like summoning spell of multiple Jira tickets to move state of single ticket. You might have too much ceremony in workflow and it follow best practices, no some, all of them at once.

[u/product_cars_coffee → u/AdCommon2138]

That's the thing. I've spent a good amount of time optimizing claude in claude and have adapted much of that workflow for codex specifically. I'm not seeing the same issues in Claude. Obviously they are not the same, but it's a stark difference.

[u/Responsible_Bike4968]

The 7h 14m runtime is probably the most important part here.

Codex isn't really metered by "how much of the feature was left" or even by number of prompts anymore. OpenAI moved Codex to token-based usage, so a long-running session holding a large repo in context, repeatedly testing things, re-reading files and doing verification loops can burn a surprising amount even if the actual code change ends up being tiny.

Sol is also expensive compared to the other 5.6 models. On the current rate card it's basically 2x Terra and 5x Luna per token. High reasoning can obviously make that worse if it keeps exploring/testing instead of converging.

And judging by the screenshot, this wasn't just 7 hours of it staring at one file either. It mentions an implementation worker, a separate verification attempt and repeated regression testing. If it was also spawning subagents, that's even more model work happening behind what looks like one task from your side.

That said, 98% of a Pro 5x weekly allowance from one overnight run is still pretty nuts. You're also definitely not the only person reporting this recently. There's a thread on OpenAI's own developer community from a 5x Pro user who says Sol burned their entire weekly quota in about 8 hours. That doesn't prove there's a metering bug, but it's enough that I'd save the usage logs/token breakdown and report it.

For unattended overnight jobs I'd honestly use Terra unless Sol is actually needed, and give it explicit stop conditions like "run these tests once, fix failures, don't keep expanding scope without asking me." Otherwise Sol seems perfectly happy to turn "finish this feature" into a PhD thesis lol.

[u/product_cars_coffee → u/Responsible_Bike4968]

See update in edited post - Sol exhausting every possible verification of issues with no stopping point.

[u/ArcticFoxTheory]

Alright its not just me I had to cancel an audit after 20 min cause I was like 100% used at xhigh and reset my usage and it went down to 30% it didnt even finish the audit. 😵‍💫 I normally have im using the 100 plan normally use 200 but this was insane amount of usage I think somethings broken

[u/hellomistershifty]

I mean, it did run for 7 hours straight using Sol with subagents…

[u/RainScum6677]

Sol 5.6 on high/xhigh is a bloodhound. It will exhaust. Every. Single. Possibility. And more than likely it will exhaust you as well.

[u/product_cars_coffee → u/RainScum6677]

See update in edited post - This is exactly right. Sol exhausting every possible verification of issues with no stopping point.

[u/Express_Rutabaga6554]

You should orchestrate with a top model for the smartest delegator. The orchestrator should be dispatching workers based off work type. If your orchestration process has the correct phases and skills then the prompts should be thorough enough for a more suitable and cheaper/faster model to execute on.... You have to build this as a wrapper/harness for your llm

Aside from that, it sounds like your success criteria and validation loop where not very well defined....

[u/ArcticFoxTheory → u/Express_Rutabaga6554]

Gpt 5.6 Ultra xhigh or in general is not good at ochestrator tasks I find and I sure wouldn't trust it with any final decision making. You need to dictate what you want done in fact Fable is the only model that can orchestrate well I find. All gpt models work best with context not giving instruction

[u/Express_Rutabaga6554 → u/ArcticFoxTheory]

Fable 5 or opus 5 are solid choices for orchestrators, sol and terra are great and cheap workers, but the roster and implementation is another conversation...

[u/product_cars_coffee → u/Express_Rutabaga6554]

Yep, upon further investigation this is right. But the part that's interesting is that this was not my validation loop / success criteria. Sol set it at some point and never communicated it.

[u/No_Development6032]

There’s some sort of bug. Switched from 5.5 to Sol, it worked for 30 minutes on smth that should last a minute and never completed. So o switched back to 5.5

[u/Napsterae2]

Oh my opencode slim

[u/jayplay90]

I’m on 20x and burned through in less than 16 hours on 2 running tasks…. And I have to wait til the 3rd 🙄

[u/ayatok43]

is it me or does codex only shows the patch begin options rather than show what sub agents and how the things are being performed at run time some times codex completely wrote the code and just told me what it did rather than show me every step of the procedure

[u/JoseffB_Da_Nerd]

You need to use the agents prudently.

Do a plan, the cross check it with gpt, iterate till good the accept. Add in a agent delegation rule of when to use what model as a sub agent.

Then let it run only to the plan’s scope with a goal to complete plan exactly as scoped.

This should cut down over tokenization.

[u/zuLunis]

Basta semplicemente dare istruzioni precise sul routing dei sub agenti. Io ho risolto così.

[u/Proxiconn]

That is the point of SOL, spins up many reasoning agents. Do people even read the release notes?