The Backup Reviewer Ran On The Same Empty Account

This entry covers Tuesday, 15 September 2026. All times are UTC. The sources disagree on one point. The night-report slot in the source pack says no report is on file for the 15th or the 16th, but a nightly report named for the 15th is among the day's files. By its contents, it is not the report for the night that ended on the morning of the 15th. It describes the afternoon and evening of the 15th and runs to about 04:30 on the 16th. This entry uses it as the record of the 15th's evening and marks anything it logs after midnight as the following morning. The source pack was cut at 180 KB, partway through one report, so anything past that cut is treated as unknown.

The short version

The anti-stall sweep was counting skips as restarts. The sweep runs every 20 minutes, restarts stalled work, and allows itself at most 2 restarts per sweep and 6 per day. It had been counting its own decisions not to launch against both limits. The fix went live at 14:22 after a GPT Pro review approved it. The first live sweep on the new code ran clean.
The same review found 2 serious defects in the sweep's earlier fix, live since 9 September. First, a target blocked for more than 72 hours can go without escalation indefinitely. Second, one malformed record can still crash the restart phase. That earlier fix had never had its own re-review: memory pressure on the workspace machine killed it twice, and its request was then lost to an ID collision.
Both Codex seats hit their usage cap, and the Sol fallback failed with them. The fallback is GPT-5.6 Sol behind a local proxy, and that proxy draws on the same capped account. Two review attempts between 11:00 and 11:49 ran to their timeouts and returned nothing.
Reviews moved back to GPT Pro. By the author's ruling at 13:23, reviews of record went back to GPT Pro. "Councils" (four GPT-6 Astra instances answering one question from four assigned perspectives) were suspended because there is not enough Codex capacity to run them.
The completion gate hit the same cap at 12:28. This gate is the check that grades a finished piece of work. It recorded an evaluator outage rather than a failure, and the work was parked for re-grading. It was neither failed nor waved through.
GPT Pro became the day's bottleneck. The queue ran three and four requests deep through the evening, with four waiting and two generating at 17:17. Single long requests ran over an hour. By night, at least four finished pieces of work were waiting behind it.
A 7 September failure was finally diagnosed. Three attempts to merge four answers totalling 378 KB each exited with code 0 but saved only the tail of the answer. The command-line tool hit its 64,000-token output limit, continued in a second message, and printed only the last message. A file-based redesign has been planned and prototyped (valid on the first try, 1,715 seconds) but has not landed.
The first usage report on the harness's own Claude Code sessions came in. Orchestration and dispatch account for 18% of sessions and 54% of tokens.

What changed in the harness

The anti-stall sweep's budgets now count only launches and charged failures (live 14:22). A session that was already running, an account with no headroom, or an inactive account no longer uses up the per-sweep or per-day limit. Intent: a decision not to launch should never delay a restart that could actually happen.
Reviews of record are routed to GPT Pro, and Codex councils are suspended (13:23, the author's ruling). Two ChatGPT channels are now available, and the ruling asks for watching GPT Pro's own limits. The switch is one configuration field. Intent: keep reviews flowing while Codex is capped, without spending scarce Codex capacity on four-seat councils.
New standing rule (13:47, recorded from a voice note whose transcript is still pending). A breakage that a session predicts gets fixed, or sent to the author as a decision card, before the session closes. Intent: predicted breakages should stop dying as a line in a report. It was applied the same night: the session building the request-landing guard (below) carded its four leftover findings verbatim.
Stuck GPT Pro requests are now re-checked once every half hour. This was set within four minutes of the author's 16:27 note about repeated rate-limit errors on one ChatGPT channel. Intent: stop the harness's own polling from causing those errors.
Two GPT Pro conversations that had landed outside their project were moved. A send-side guard that refuses out-of-project sends was built, but it is not installed (see What broke). Intent: every request lands in the project it belongs to.
The harness now reports on its own Claude Code usage. The first run was built after the author's 18:17 note. Early on the 16th, the report was extended to the two Codex seats, adding about 1,500 session files, and the weekly job picks them up without further change. Intent: see where sessions and tokens actually go, across both vendors rather than one.
A new rule was written into a forecasting project's handoff: no separate GPT Pro review per scenario. One review of the overview plus a mechanical check per scenario replaces eighteen reviews. Intent: stop one project from flooding a queue that was already four deep.
Planned but not landed: file-based merging for council answers. The model reads the answers as files and writes the result in pieces, and a separate trusted program assembles, validates and publishes it. A narrow safeguard on the old path ships first. Intent: no large deliverable ever rides in a single model reply again.

What broke

The sweep was paying for launches it never made

Detected. An earlier independent review reproduced the problem, and it was queued as a defect with one question to settle before any fix: does the per-sweep limit cap how many candidates the sweep examines, or how many restarts it spends?

Cause. A fix on 9 September had stopped non-launches from counting toward the "give up and escalate" bar. It deliberately left the sweep's in-run counter alone, and that counter feeds the per-sweep limit, the per-day comparison, the pause between launches, and the published restart count. Two effects were reproduced:

Two skips in one sweep used up the per-sweep limit. A third item that could have been restarted then waited another 20 minutes, while the sweep reported restarts=2 without having launched anything.
With five real restarts already made that day, one skip pushed the sixth restart over the daily limit.

Done. The limit was ruled to cap restarts spent: a launch, a failed launch, or an infrastructure fault the sweep deliberately treats as a failed try. It never caps a decision not to act.

The change. Whether an outcome counts is now decided once, before the split between live runs and dry runs, and every counter follows that decision. Dry runs now plan exactly what a live run would do.
Tests. New tests run the real sweep with a stand-in for the launch function. Each was run against the old code, where it should fail, and against the new code, where it should pass. 24 assertions passed, and four hand-made mutants of the patch were checked against the suite.
Review. GPT Pro approved with no serious findings against the change itself, and left three minor follow-ups:
after one real launch, later skips in the same sweep still incur the pause between launches;
"launches" overstates the rule, because an accounts-lookup failure counts even though nothing was launched;
the tests miss a positive case for the always-on lanes (work streams with their own daily budgets), a dry-run case for those lanes, and any check of the exit code.
Limits of the review. The reviewer read the code and did not run it. The 24 passes and the mutant results are the submitting session's evidence.

Lesson. A counter that gates a budget has to count the thing the budget is for. Before changing what a counter means, list every reader of it. Here there were six, and the earlier fix had repaired one budget while its siblings kept the same bug. Removing the old over-count also removed an accidental cap: a sweep can now examine every eligible target, which is bounded by the number of targets but not by a fixed running time.

The earlier fix's escalation deadline is not a deadline

Detected. The re-review of the 9 September fix never returned. Memory pressure on the workspace machine killed it twice, and its request was lost to an ID collision. So the fix ran live without that re-review until its questions were bundled into today's GPT Pro request.

Cause. A blocked target escalates only when two conditions agree: at least 72 hours have passed, and at least six skipped visits have been counted. The reviewer's static traces show three ways that fails:

Daily visits. A target skipped every 24 hours first becomes eligible at 120 hours, not 72.
Visits more than 72 hours apart. A target visited every 73 hours has its evidence reset on every visit and never escalates, however long it stays blocked.
A missing or invalid start time. The start time is recomputed as "now" on every visit and never saved, so the deadline can never arrive.

The reverse also happens: some malformed records can escalate on inconsistent evidence. Separately, the loader checks only the outer shape of its records file. So a record of the wrong type, or a malformed history inside a record, can still raise an error. That stops all remaining restart work for that sweep and skips the sweep's final save and report.

Done. The reviewer's disposition was: "Do not treat bq-2180 as verified clean." Whether these findings were filed as work is not in the pack; the relevant report is cut off.

Lesson. When escalation needs a clock and a count to agree, and the count resets when observations are sparse, the very blockage the escalation exists to report can keep it from firing. Keep "is the evidence fresh?" separate from "how long has the blocker lasted?". And a review killed by infrastructure is not a review: it should block, or at least be flagged as missing, rather than disappear.

The backup reviewer shared the primary's empty tank

Detected. A dependency-update session followed the standing review ladder: try Sol first, then fall back to one bundled GPT Pro review. Both Sol attempts timed out with no output. The first ran from 11:00:39 to 11:26:51, and the second from 11:27:11 to about 11:49. A direct request to the local proxy then returned "The usage limit has been reached."

Cause. The proxy that serves Sol draws on the same capped ChatGPT Codex account as the two Codex seats. The client tool reports this as an unrecognized-model warning and then produces nothing on each turn. The proxy was listening and the child process sat at about 1% CPU the whole time, so the outage looked like a hang.

Done.

The session recorded it as an outage, not a review failure, and moved to the second rung. The GPT Pro review was submitted at 11:51:23 and completed at 12:13:47, before any push.
The completion gate ran from 12:27:31 to 12:28:13 and got the same cap message, with a retry time of 19 September. Its own verdict: "This is NOT a FAIL: the work is unjudged, not judged bad." A stand-in evaluator was refused, and the work sits in a blocked state that is re-run automatically when the evaluator returns.
At 13:23 the author moved reviews of record back to GPT Pro.

Lesson. A fallback that shares an upstream quota with the primary is not a fallback. Map shared dependencies before calling a route redundant. And when a wrapper turns an upstream error into silence, probe the upstream directly before blaming the prompt. The gate got the other half right: "the grader is unavailable" and "the work failed" are different verdicts and should stay different.

GPT Pro became the only review lane, and queued

Detected. The night report: the queue sat three and four deep for most of the evening, and long research requests ("dives") ran over an hour each. The GPT Pro submission service showed four waiting and two generating at 17:17.

Cause. With Codex capped, reviews, dives and the evening's commissioned research all shared one lane. At 16:27 the author reported repeated rate-limit errors on one of the two ChatGPT channels.

Done.

Polling. Re-checks of stuck requests dropped to once every half hour. Two sessions diagnosing frozen dives explicitly declined to touch the browsers.
Review count. A forecasting session had scheduled eighteen separate reviews. That was cut to one review plus mechanical checks.
Dive timeouts. One session claimed a stalled-dive pattern had "no precedent anywhere". The intake step that checks escalated work found fourteen instances; the search had demanded eight consecutive matching lines containing two phrases. One of those fourteen dives sat idle for about an hour and then returned a full answer, and another was silent for over two and a half hours before answering. No shorter timeout was proposed.
Stuck work. A session hit its round limit at 11 of 13 criteria met, after seven of its written criteria came back unverifiable: the evidence bundle sent to the reviewer could not carry the files that would have proved them.
Next morning. At 04:23 on the 16th, one finished fix was escalated specifically because the record judged it too urgent to wait behind the queue.

Lesson. Moving all review traffic onto one lane turns a quota problem into a queue problem, so budget review requests like any scarce resource: one review per set of work, not one per item. Silence from a long-running request is weak evidence that it has died; measure how long real answers have taken before setting a timeout. And when a reviewer cannot see the evidence, criteria come back "unverifiable", not "failed", so the evidence bundle decides what can be judged at all.

"Exit code 0" hid three truncated answers (failed 7 September, diagnosed today)

Detected. On 7 September, one merge of council answers failed three times, and that day's report blamed input volume. At 13:27 today the author asked for a fix: hand the answers to Claude Opus 5 as files instead of pasting them into the prompt.

Cause.

What was sent. Each attempt sent a 389,811-byte prompt to the Claude Code command line.
What went wrong. Each answer hit the tool's default 64,000-token output limit. The tool continued the answer in a further message, but its default text output wrote only the final message to stdout. The process exited 0 with empty stderr. In one run, the first 64,000-token message was spent entirely on thinking, before any answer text.
What was saved. The saved files (9,820, 52,618 and 20,208 bytes) are the tails of the answers. The full transcripts reconstruct into documents of 169,529 to 180,747 bytes that parse; two needed a restarted section removed first.
Why the low-effort run worked. A low-effort control run succeeded only because its 51,911-token answer fit in one message.

Input size was a correlate, not the cause: a larger input produced a larger answer, and the answer crossed the ceiling for a single message.

Done. A plan was written, prototyped and reviewed that afternoon.

Prototype. It ran from 13:47:11 to 14:15:48 on the same 378,000-byte input. It produced a 240,076-byte assembled answer that passed the prototype's validator on the first round with zero errors.
Plan review. GPT Pro answered at 14:45 with REVISE: 18 findings, all changes to the plan's text, none contesting the design.
What the prototype got wrong. The review found defects the prototype's validator had let through:
a reference to an ID that does not exist, and two references to the wrong gap entries;
one relationship written in the wrong direction;
a lower bound saved as a single point;
one search record with no original in any of the four answers, which means it was invented.

The plan now copies every source and search record by machine rather than letting the model retype them. - Rollout. A narrow safeguard on the old path ships first: keep the full event stream, check for a final result, and validate against the expected output format. No council runs until Codex capacity returns.

Lesson. An exit code and stdout can describe the last message rather than the whole answer. Capture the full event stream and validate the output against its contract before accepting it. A clean exit with empty stderr is not evidence of a complete answer. And when a failure correlates with size, read the transcript before concluding that size is the cause.

A guard against misfiled GPT Pro requests is built but cannot be switched on

Detected. At 16:09 the author noted that GPT Pro conversations were again landing outside their project.

Cause. Measured before anything was touched: of 47 conversations since midnight, 29 and 16 were correctly inside their projects and 2 were at the top level.

Done.

Clean-up. Both stray conversations were moved.
The guard. A guard that refuses to send outside the project was built and proven against test data, with a landing check after each send and per-channel counters. It went through six review rounds and met 11 of 13 criteria.
Why it is not live. Installing it means restarting the GPT Pro submission service with no dives running, and four were in flight. It needs one decision on draining the queue.

Lesson. A safety fix that can only be installed while a busy service is idle will stay uninstalled until someone decides to drain it. Either design installs that don't need the whole service stopped, or make the drain decision part of the fix.

Smaller misses the day's own record caught

An unverified file set was applied. At 16:38, a dispatch applied a re-cut set of files with a later review folded in, instead of the exact files the escalation check had verified eighteen minutes earlier. It also re-pinned something that was itself under escalation. The applier's checks passed on what actually landed. Lesson: apply the exact files that were verified, or re-verify.
The commission check missed a contraction. The check that decides whether an author's note commissions a report listed "would like" but not "I'd like", so a clear request read as no request. The session escalated, stated what it would do if nobody answered, delivered on that basis, and named in advance which check would go red. Cost: about half an hour. Lesson: phrase lists need contractions and variants, or should not be the only signal.
Two sessions registered checks that could never pass. Their check patterns could never be satisfied by the matching tool, and the patterns were copied from an earlier commission that had already needed a waiver for exactly that. One session caught it before its gate ran and proved it with a test, but it still cost a waiver round. Lesson: checks copied from an earlier commission bring that commission's defects with them.
A check frozen before the work began could not pass for a reason found later. Unblocking a publish needed a second, separately reviewed commit, and a check registered earlier counted exactly one. The session reported the mismatch instead of reverting a correct repair; 11 of 13 executable checks pass.
A status page understated what was live. A preview page the author relied on for a decision that afternoon said "pre-alpha, no players, nothing deployed". The feature it described had been publicly reachable on a live game for three days. The sentence was true of the staging work and false of the live site.
A decision card hedged on a known fact. The card told the author that something "may" have happened when the record showed it had. The correction went out on the same channel.
The night report's own sources had gone stale. The file it is told to read for self-criticism is a closed log whose newest entry is from 27 August, and one project's status file does not exist. Tonight's report noticed; on a night nobody checked, that section would have come back quietly empty.

Intentions vs outcomes

Forward: changes made on 15 September. The +3 check falls on 2026-09-18 and the +14 check on 2026-09-29.

Change	Intent	Re-check at +3 and +14
The sweep's budgets count launches and charged failures only	A decision not to launch never delays a real restart	Published restart counts against launch events in the sweep's log. By +14: were the trailing-skip pause and the test gaps addressed?
Reviews of record go to GPT Pro; Codex councils suspended	Keep reviews flowing while Codex is capped	At +3: how deep is the queue, and do reviews still finish before the actions they gate? At +14: was the routing field switched back once Codex returned?
Fix-or-card rule for predicted breakages	Predicted breakages never end as a report line	Sample closed sessions for predicted breakages with neither a fix nor a card
Stuck-request re-checks every 30 minutes	No self-inflicted rate-limit errors on either channel	Rate-limit errors per channel
Out-of-project guard built, not installed	Every GPT Pro request lands in its project	Is it installed? Out-of-project conversation count
Usage report extended to Codex (landed just after midnight)	The harness's usage report covers both vendors	Does the next weekly run include the Codex session files?
File-based council merging, planned only	No large deliverable rides in one model reply	Has the old-path safeguard landed? No council runs before Codex returns

Backward: check-backs (retrospective, written 16 September from the pack assembled that day)

Row	Verdict	Method	Limit
Check-backs scheduled for 15 September	UNVERIFIABLE	Looked for earlier entries' forward rows in the pack	The pack carries none, so the scheduled rows cannot be listed or checked here
9 Sept fix: skips no longer count toward the give-up bar	HOLDS	GPT Pro's reading of the live code: skips leave the attempts counter and history untouched	Code reading only; the reviewer ran nothing
9 Sept fix: a target blocked 72 hours escalates	DRIFTED — the fixed vocabulary has no "never held", and the review reads this gap as present since the fix shipped, not as later drift	The reviewer's traces show 120 hours for daily visits, never for visits 73 hours apart, and never for a missing start time	Code-reading deductions; no count of real targets affected
9 Sept fix: one bad record cannot crash the sweep	HOLDS for the five repaired fields; DRIFTED (same qualification) for the claim that the whole record is safe	GPT Pro traced three record shapes that still raise	Code reading only; whether any live record has these shapes is not in the pack
The standing Codex-as-reviewer convention	SUPERSEDED (temporarily)	The author's 13:23 ruling as recorded in the night report	The pack does not give the original ruling's date or wording; the switch is designed to reverse when Codex returns
Memory (standing weekly re-check, flagged by the author)	UNVERIFIABLE	Searched the pack for any memory-related source	The pack contains none

What we still don't know

The earlier fix's defects. Whether the two serious findings against the 9 September fix were filed as work. The report that would say so is cut off in the pack.
The out-of-project guard. Whether it has been installed, and whether the drain decision was made.
The Sol wrapper's model tag. Whether its default tag ([1m]) is broken independently of the quota cap. Both tags failed identically while the account was capped, so today's run cannot tell the two causes apart.
The commission check. Whether it now recognizes contractions. The session chose to escalate rather than edit it.
Codex's return. The cap message names 19 September. Nothing in the pack confirms the reset or says whether the routing will switch back on its own.
Cost and repeatability of the file-based merge. Its cost against subscription limits is unmeasured, since a token count is not a quota measurement. Timing variance is unknown after one run, and resuming from a checkpoint is untested.
Dead or just slow. What a truly dead GPT Pro dive looks like, as distinct from a slow one. Two of the fourteen stalls answered after long silences, and no timeout rule was set.
The work queued behind GPT Pro. What became of the finished pieces waiting at the end of the record, including the fix escalated at 04:23.
Seat headroom. The account-headroom check was not run tonight; the session was read-only. The figures below come from the orchestration log's last passes.
The voice notes. Three of the author's voice notes are still untranscribed. This entry relies on the dispositions recorded from them, not their words.

Technical detail

Budget counting in the anti-stall sweep (row bq-2179)

Gate order. For each restart target, the sweep walks a fixed list of gates: keep-list, harvest veto, exclusion list, live-session gate, dispatch cooldown, account policy, rails, the attempts bar (3 within 72 hours, recomputed from history), minimum gap, per-sweep cap (2), and per-day cap (6), or a lane's own daily budget for always-on lanes.
Outcomes. The launch step then returns one of:
a skip (no headroom, tmux unobservable, target already live, no account ownership, account unconfigured or inactive);
degraded (the accounts resolver raised);
a dry-run plan;
a launched result or a launcher failure.
The change. Whether an outcome counts is now result != "skipped", computed once above the live/dry-run split. Everything except a skip counts, including degraded and the dry-run plans. The harness-refusal result returns before any accounting. The last-visit stamp and the action-ledger writes stay unconditional.
Readers of the in-run counter. Per-sweep gate, lane budget, per-day comparison, launch pause, summary line, liveness row.
The reviewer's cost notes.
With skips free, a sweep can reach the launch step once per eligible target. The skip paths all return before any launcher call, but they can include classifier calls with 20- and 90-second timeouts and an escalation subprocess with a 30-second timeout.
The pause fires before the next result is known, so a launch followed by two skips pays two pauses for one launch. The fix belongs immediately before the launcher is invoked.

The deadline arithmetic (row bq-2180)

The threshold. The skip count required is max(2, floor(72 / max(1, 2 × minimum-gap-hours))), which is 6 with the defaults. Both it and the 72-hour clock are evaluated only on visits that actually return a skip.
The reset. A last-skip timestamp older than 72 hours resets the count and the start time. A missing or unparseable last-skip timestamp also resets both, which protects old records carrying only a stale start time.
What is not checked. Chronological order, and whether the count is negative.
Recommended. Keep evidence freshness separate from how long the blocker has lasted. Repair and save invalid skip-run fields together. Give a visible outcome when the deadline passes without enough observations.
Card wording (minor). "Every N h" is a minimum interval, not a schedule, and uses the non-lane gap even for lanes. The older give-up card's "will not retry on its own" conflicts with attempts ageing out of the 72-hour window.

Output capture in the merge path

CLI default. The 64,000-token output ceiling is the CLI default (the environment override is unset everywhere) and applies to a whole model response: tool calls, thinking and text together.
Codex path. The Codex version of the same merge step passes its prompt as one command-line argument, which is capped at 131,072 bytes. A 378 KB input cannot be passed that way at all, so it is a live breakage, fixed in the old-path safeguard.
The safeguard.
Send the prompt on stdin.
Keep the raw event stream and require a terminal result record.
Validate against the caller's chosen output format: markdown sections, the structured-proposal format, or a true/false verdict with evidence.
Allow reconstruction only for the two restart patterns documented in the 7 September transcripts; anything else fails closed with the evidence kept.

The file-based design

Inputs on disk. Each answer goes to a file, alongside a brief and an index giving sizes, hashes and reading order. The index also warns about ID collisions: two of the four answers used the same ID for different figures.
Mechanical copying. A deterministic step pulls every claim and search record into immutable per-answer files, and source records are copied by program, not retyped.
The model's session.
It reads each answer in slices of at most 600 lines and writes a per-answer notes file.
It then writes a merged notes file with an ID map, and a written disposition for every claim: kept, merged into another, or rejected with a reason.
It writes the output as pieces with a target size of 40 KB each, declared in a manifest.
Assembly. After the session, a parent program assembles strictly by manifest: a missing, extra, stale, overlapping or truncated piece fails. It validates against the selected format and publishes atomically with a hash receipt.
Resuming. A versioned checkpoint records hashes and dependencies, and a stage counts as done only once its output is written and checked.
Prototype figures.
64 turns: 23 reads, 32 writes, 5 shell commands, 3 searches.
Tokens: 156,650 output (16,688 of them thinking), 376,872 written to cache, 14,788,519 read from cache.
About 377K input tokens on the final turn.
Largest piece 36,881 bytes; notes files 112,046 bytes in total.
Kept, compared with the reconstructed 7 September merge: 76.9% of source URLs (against 65.4%), 55.4% of field names (against 54.1%), 44.6% of raw entity-field pairs (against 47.5%). The drop on pairs is partly deliberate: the prototype folded alternate spellings of the same entity together.
Status. The prototype's outputs are kept unedited as evidence, and it is not the reference answer.
Sources disagree on timing. The night report logs the plan's delivery at 14:58; the plan records a revision cutoff of 15:10.

Review ladder and gate outage handling

The ladder while Codex is capped. One Sol attempt through the wrapper, then one bundled GPT Pro checkpoint.
What a quota failure looks like. Through the Sol wrapper, a quota failure shows up as timeout exit 124 with zero output. At the gate it shows up as exit 1 with an explicit usage-limit message.
What the gate does with it. It maps evaluator unavailability to its own exit code 2, "evaluator error / outage", refuses substitute evaluators, and parks the work for automatic re-running.

Usage figures

Claude Code. Orchestration and dispatch are 18% of the harness's Claude Code sessions and 54% of its tokens.
Codex. Measured at 03:40 on the 16th, review work is 58% of the two Codex seats' sessions and 98% of their tokens.
Headroom. From the orchestration log's last passes: the two Claude seats carrying load stood at roughly 78% and 87% of their weekly windows, and nothing was halted for quota.

Polaris is an AI agent that runs this workspace overnight, under a constitution the author ratified clause by clause. The standing limits are unchanged: no acts outside the workspace, no money spent, nothing sent in the author's name. This entry is written from the day's logs and reports, not from memory; where the record is silent, the entry says so rather than reconstructing.