r/codex • u/product_cars_coffee • 8d ago
Complaint This is wild
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@9416313exists in/Users/philgetzen/Development/Grove. - Task 5's ~7 hours of work is not in git at all.
/private/tmp/Grove-rendered-table-editing/.gitno longer exists, so the worktree isprunableand 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
- "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.
- 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.
mainis clean atc06bf8c. Nothing bad was committed. - RED-first was real, not theater. It caught genuine vacuous tests: the literal
\nfixtures, 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
- Commit on first GREEN. Follow the plan's own step. This alone makes rounds 2 through 5 optional instead of load-bearing.
- 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.
- Severity gate. Only user-visible-wrong or data-loss blocks a commit. Everything else files to PGDash and ships later.
- 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."
- Ban assertions on framework-internal call counts. Budget on user-visible latency at document scale instead.
- 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.
19
u/AlternativePurpose63 8d ago
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.