Nothing Said The Fix Was Stuck

This entry covers Friday 30 October 2026, in UTC. The record's usual slot for a night report was empty this time. A nightly report titled for 30 October was, however, filed among the day's own reports, and this entry draws on it. That report runs on the author's local calendar day rather than the UTC one, so its window ends in the early hours of 31 October UTC. Its clock times are converted to UTC here, and events from that tail are marked as falling on the 31st. The day's own report is stamped as of 16:44 UTC. One more report filed under this date turned out to cover a window on 23 October, and is left out.

The short version

A fix to one of the workspace's live web apps, which the author had ranked first, was finished on 29 October and then waited more than seventeen hours. Its review, landing and deploy had been left to the next session of Polaris, the orchestrating agent. No Claude account had the weekly budget to start that session until an allowance reset at 13:00 UTC on the 30th. Nothing told the author the fix was blocked until they asked, at 12:31 UTC.
A timer armed the day before started that session at 13:05 UTC, and it took the fix first. The first of two review rounds found two real defects and the second closed both. The fix was live by 15:49 UTC.
From then on one account carried the whole orchestrator. A hand-off is a session passing its work to a fresh one before its context fills. There were nine in the nightly report's window, every one on that account, and none compacted (summarized away) its context. Fifteen hours after its reset that account had used 59 per cent of its week. Every other Claude account in the fleet read 98 or 99 per cent.
Four harness changes landed:
- The job that keeps idle sessions' caches warm now runs until an account's five-hour window is fully spent, not one point short.
- The overnight watchdog and the app's night-shift indicator now judge health by the same rule as the health gate.
- The review tool refuses any package it cannot read whole.
- GPT Pro use is capped at 100 messages a week. That cap exists only on paper so far: the process that enforces it still allows 200 until the author restarts it.
A decision ruled on 18 October was turned into a question for the author's decision queue and never sent. A session found it twelve days later by re-reading the ruling, and posted it in the early hours of 31 October UTC.
The records meant to catch slips like these are stale or empty:
- The log of enacted decisions has no entries since 10 October.
- The line that tells a new session which session is live still names one from 22 October, seventy-five generations back.
- None of the last fifteen hand-off briefings records what its session owed the nightly report.
The backlog loop is open. The nightly ranked list has changed nothing for five nights running. Of the 504 open backlog items, 490 (97 per cent) have gone more than three days with no recorded activity. Five answers the author gave have not been read.

What changed in the harness

Cache warming runs to the real limit (landed 14:10 UTC). A background job keeps idle sessions' prompt caches from expiring. It already kept going until an account's weekly pool read 100 per cent, but for the shorter five-hour usage window it stopped at 99. It now stops at 100 there too, prompted by an author note at 12:30 UTC. Intent: no session goes cold while its account still has room.
One rule for "healthy" (14:21 to 14:23 UTC). The overnight watchdog and the night-shift indicator in the agent's app now judge health the way the health gate does. Intent: three things watching the same night should not be able to disagree about it. Its acceptance test is the gate's 18:00 UTC reading, which the record does not reach.
The review tool refuses what it cannot read whole (14:38 UTC). A package it cannot read in full, such as one holding a file over its size limit, is now refused instead of graded as complete. Intent: a review verdict exists only for material the reviewer actually read.
GPT Pro limits match the new plan (15:52 UTC). The new limits are a weekly ceiling of 100 messages and a target of 90 per account, in place of a ceiling of 200. Intent: keep GPT Pro use inside the new plan's allowance. The change is in the configuration but not in force. The running process that rations GPT Pro requests holds the old ceiling in memory until the author restarts it, which is now on their to-do list.
The report watcher's pattern (time not in the record). This watcher wakes the orchestrator when a delegated session reports back. It missed one such report and woke on a mere progress line, and its pattern was fixed. Intent: wake on reports, and only on reports. The fix still owes its review.

What broke

A finished fix waited seventeen hours, unannounced

How it was detected. By the author. At 12:31 UTC they asked whether the work was still in progress. The outgoing orchestrator session, by then running read-only, answered with the true state two minutes later.

What caused it.

A worker running GPT-6.1 Sol finished and staged the fix on 29 October.
The next steps were one review, also assigned to GPT-6.1 Sol, then the landing and the deploy. They had been left to the orchestrator's next session, and only that session could launch them.
That session could not start. The outgoing session had already handed off as its account neared its weekly limit, and was running read-only. No other Claude account had weekly budget until one reset at 13:00 UTC on the 30th.
The author had accepted that gap in Claude capacity the day before. What they had not been given was word that their top-ranked item was stuck inside it. More than seventeen hours passed with no message saying so.

What was done. The outgoing session had armed a timer the previous day. It started a successor at 13:05 UTC, five minutes after the reset, and the successor took the fix first. The first review found two real defects, and a second round closed both. The fix went live between 15:30 and 15:49 UTC, and the author was told at 15:59 UTC.

The lesson. Accepting a capacity gap is not the same as accepting silence about what it is costing. When the item ranked first is blocked, the block is itself the message. It is owed when the block starts, not when someone asks. Count the dispatcher's capacity, not only the worker's. Here the review was assigned to a provider whose accounts had room, but the only thing able to launch it ran on the provider that had none.

A decision sat unsent for twelve days

How it was detected. In the nightly report's window, a session re-read a ruling from 18 October and found it still live. The question it called for had never reached the author.

What caused it. The ruling produced a question card, a decision posted to the author's queue. The card was built and never posted, and nothing noticed through the hand-offs that followed. The report puts those at roughly twenty sessions. Its own generation numbers advance by seventy-five between 22 and 30 October alone.

What was done. The card was re-reviewed and posted at 03:26 UTC on 31 October. The first helper assigned to post it stalled partway, and a second finished the job. The card concerns the last piece of a hardening change to the session launcher. The agent cannot finish that piece itself, because Claude's own safeguard stops each attempt as it begins. The card asks the author to finish it by hand from a prepared note, hold it, or skip it.

The lesson. "Built" and "delivered" are different states. A chain of hand-offs will carry an undelivered item indefinitely unless something compares the two. That matters most for changes the agent cannot make for itself: where the human is the only path, a lost card is a lost change. A related, though separate, failure surfaced the same day: the tool that sweeps the record of dispatched work misses three hand-off formats now in use.

Hand-off records misled their readers

How it was detected. The session that made the first slip caught it, and the nightly report-writer caught the stale header. The rest appear in the day's records without a note of who caught them.

What caused it. Five separate slips, none with a cause in the record:

A hand-off the report times at 20:00 UTC told the incoming session that two delegated sessions were being held. Both had in fact been launched minutes earlier.
The header of the hand-off record still names the session of 22 October. That header is the line that tells a fresh reader which session is live. The file's newest entries are seventy-five generations later.
A transfer confirmation was written wrongly.
A delegated session's hand-off note misnamed one of its own backup files.
A builder of hand-off kits went silent for 45 minutes.

What was done. The outgoing session corrected its own hand-off at 21:09 UTC, and nothing was dispatched twice. The report says the briefing stood wrong for about seven minutes, but its own times for the hand-off and the correction are an hour and nine minutes apart. The confirmation was redone and the kit builder replaced. The record does not show the stale header fixed.

The lesson. A hand-off is a snapshot of a moving system. Lines about live work should be read from the live system at the moment of writing, and checked again by whoever relies on them. Summary lines rot first, because nothing fails when they are wrong, until a cold reader trusts one.

The records built to catch misses were empty

How it was detected. By the nightly report-writer, going to the sources it was told to read.

What caused it. The record does not say why; it says what was found:

The log of enacted decisions has no entries since 10 October.
The file where sessions note what they owe the nightly report has no entry for the 30th. The newest is from 26 October.
None of the last fifteen hand-off briefings carries the paragraph in which a session records what it owes.

What was done. The writer fell back on the sessions' own pass records and named the cost: those show what each session chose to log, not what it undertook to disclose. It declined to read the empty files as "no misses".

The lesson. An empty disclosure surface means "unknown", not "nothing to disclose", and the writer read it that way. Surfaces whose silence looks like health need a liveness check of their own. A log that should grow every day and has not grown in twenty is an alarm, not a quiet stretch.

The backlog loop is open

How it was detected. By the backlog's own instruments, on their usual schedules.

What caused it. One cause is stated: the step that should carry the nightly list into the orchestrator's work is still not reaching the live session. The rest is measurement:

The nightly ranked list ran at 07:31 UTC and ranked itself first. All nineteen of its core items had aged exactly 24 hours again, so nothing on the previous night's list had moved. No line on it has had any effect since 25 October; this was the fifth such night. It counted 2,178 inactive items, five more than the night before. Of these, 1,689 are hand-off notes that were written and never picked up.
The list's second item is five unread answers from the author. One answered a question about one account's included API credits, and four answered sibling questions; each told the agent to go ahead. The report judges that at least one weekly credit window has almost certainly lapsed unused since 24 October.
The silence sweep ran at 17:35 UTC. It found 490 of the 504 open backlog items unmentioned in any status file, decision record or completion check for more than 72 hours. Of those, 104 read as finished but never closed, 44 are waiting on the author, and 342 are simply stalled. It also found 430 work orders with a briefing written and no status file to show they ever started.
The work queue's own ledger reports its source as damaged, so it certifies nothing. It observed 20 items added and 17 closed on the 30th, and 282 added against 161 closed over seven days.

What was done. Nothing moved the backlog on the day. The sweep drafted one card per finding. A separate checker sorted 353 completion claims into 29 confirmed, 74 for the author and 250 refuted.

The lesson. A report earns its keep only if the next day's work changes because of it. This list measures itself exactly that way, by asking whether any listed item moved. That self-measure is the only reason its inertness is known; what it lacks is a consumer. When a backlog can bury the author's own answers, the routing is upside down. Answers belong in a queue that is always read, not in a backlog that is ranked.

Smaller failures

The nightly report-writer ran the full account-and-burn check twice, and it was still working after nine minutes both times. Its figures for the day are unknown. Its fast mode answered in two seconds.
A research pipeline's deep report stopped when the job's polling budget ran out at 15:40 UTC, with the long-reasoning model still generating. Nothing fell back. The run can resume from its saved state, but nobody has resumed it.
The report watcher missed one delegated session's report and woke falsely on a progress line (fixed, review owed). Separately, a review's report delivered at 02:07 UTC on the 31st went unread until 02:31.
The disk sentinel flagged free space on the root disk falling 22 GiB in six hours. It came from a partial scan the sentinel could not fully attribute, and 386 GiB remain free.

How they were detected: by the tools and sessions involved, or by the nightly report.

What caused them: not in the record.

What was done: the watcher was fixed; the rest were recorded.

The lesson: instruments and timeouts fail on the heaviest days. A check that cannot finish should say "unknown" on a bounded clock. The burn check's fast mode did that; its full mode did not. A job that times out with its state saved should schedule its own resume rather than wait to be noticed.

Standing faults nothing moved

The night shift's close-down has not run for two nights running.
An incident from 27 October is still unacknowledged. That keeps its heartbeat marked degraded until the author acknowledges it.
The projects tab in the agent's app has been dark for five days. It is not bound to the session that is live against it.

All three come from the nightly report. None has a stated cause, and nothing was done about them on the 30th. They carry no new lesson; they are listed so a later entry can see whether they moved.

Intentions vs outcomes

Forward: changes made on 30 October

| Change | Intent | Re-check 2 November (+3) | Re-check 13 November (+14) | |---|---|---|---| | Cache warming runs to 100% of the five-hour window | No session goes cold while its account has room | Did any session go cold while its account's window read 99%? | The same, across a full weekly cycle | | Watchdog and night-shift indicator use the health gate's rule | One verdict per night, not three | Did the 18:00 UTC acceptance reading pass? Have the three agreed every night since? | Any night on which they disagreed | | Review tool refuses packages it cannot read whole | No verdict on unread material | Has it refused anything, and were the refusals real? | Any verdict later found to rest on a partial read | | GPT Pro: weekly ceiling 100, target 90 per account | Stay inside the new plan | Has the enforcing process been restarted, and does it now enforce 100? | Weekly counts inside the ceiling | | Report watcher's pattern | Wake on reports, and only on reports | Has the fix had its review? | Any missed report or false wake since |

Backward: check-backs

The record this entry was written from carried no list of check-backs falling due on the 30th. The rows below are earlier intentions that the day's record speaks to directly. They are checked against the record as it stood on the morning of the 31st.

| Earlier intention | Verdict | Method | Limit | |---|---|---|---| | Hand off to a fresh session before the context fills; never compact (the author's ruling of 24 October) | HOLDS | The nightly report's count: nine hand-offs, none compacting, each on the router's own pick. Also the day report's note of the 16:11 UTC hand-off | One reader's count from the sessions' records. It says nothing of hand-off quality, which slipped (above) | | Start the successor by timer just after the weekly reset (armed 29 October) | HOLDS | The outgoing session's transfer record: fired 13:05, account picked 13:05:01, launch reported OK 13:05:04, lease moved 13:06:30, transfer confirmed 13:20:48 | One firing. The timer does not survive a reboot, and none happened, so that path is untested | | The nightly ranked list steers the next day's work | DRIFTED | The list's own measure: all nineteen core items aged exactly 24 hours; no line has had any effect since 25 October | It measures movement by item age, so work done without touching an item's record would not show | | Enacted decisions are logged where they can be read | GONE | The nightly report's read of the log: no entries since 10 October | One reader. Enactments are partly recoverable from triage and status records, which that reader used instead | | Each session records what it owes the nightly report | GONE | The nightly report: no file for the 30th (newest 26 October), and no such paragraph in the last fifteen briefings | The paragraph's absence does not show whether anything was owed | | The hand-off record's header names the live session | DRIFTED | The nightly report: the header names the session of 22 October, and the newest entries are seventy-five generations later | Not re-read for this entry | | Memory (flagged by the author; standing weekly re-check) | UNVERIFIABLE | The record holds no direct check of memory. Its one related fact: the silence sweep lists the memory-candidate queue among queues filling with nothing draining them, with 149 records added since its previous run | The sweep's "nothing draining" reading is itself unchecked (see below) |

What we still don't know

The health rule's acceptance. Whether the change passed its 18:00 UTC reading is unknown; the record stops before it.
The GPT Pro ceiling. It is not in force until the author restarts the enforcing process, which allows 200 until then.
Where the host account's 59 per cent went. The full burn check never finished. How much of a nine-hand-off day was spent on sessions starting up rather than working is unmeasured. It is also open whether that account reaches the 98 per cent hand-off line before another account's allowance resets. That reset is due the following evening by the report's local clock.
How long the wrong hand-off briefing stood. The report's figure is about seven minutes; its timestamps say an hour and nine minutes.
How many sessions the unsent card passed through. The report says roughly twenty; the generation span is at least seventy-five.
Whether other built cards were never sent. The nightly list names a card drafted on 11 October for a publication decision. It is not among the open cards, so either it was never sent or its answer was never enacted.
Whether the sweep's queue figures describe real queues. It flagged 6,643 of the 6,648 queues it tracks as filling with nothing draining them. A single file inside a snapshot folder accounts for 34,016 of the 34,231 new records. The record does not say whether that file is a live queue or a copy the sweep should not be counting.
What caused the 22 GiB drop in free disk space.
Why a report filed under 30 October covers a window on 23 October.
What the source record left out. It was cut short in places: the sweep and closure lists at 40 KB each, and the whole record at 180 KB. It did not include the later sessions' own status files.

Technical detail

The session chain.

Polaris runs as a chain of Claude sessions. The outgoing session on the 29th ran Claude Fable 5.1, and its successor was launched as a Fable session.
A session hands off before its context reaches 600,000 tokens or before its account reaches 98 per cent of its weekly allowance. It never compacts.
Each hand-off writes a briefing for the successor; the one written on the 29th ran to 54,053 bytes. It also moves a lease, the record of which session is live, to the next generation.
The successor's first act is to take the lease. Its second is to close its predecessor, once it has proof the predecessor has stood down. Until then the predecessor stays open and read-only, acting only on the author's messages and on work already in flight.
The author is told of each move. On the 30th, for example, the notice went out at 16:09:44 UTC, ahead of the 16:11:05 hand-off.

Deferred launch across a capacity wall. When no account will admit a new session, the hand-off runs in two stages.

The prepare stage writes and checks the briefing and appends the hand-off ruling.
The launch stage is left as a one-shot user-level timer, set a few minutes after the next weekly reset. When it fires, it:
1. asks the account router afresh (an empty answer launches nothing and leaves a note);
2. dry-runs, and gates on the dry run;
3. fills and checks the briefing's last fields;
4. launches;
5. reads the session registry back and announces the change.
Its guard refuses to launch if any of these hold:
- the lease is not at the generation it expects;
- a successor already exists;
- the briefing is missing or unfilled;
- a newer ruling has been appended since it was armed.
On the 30th it fired at 13:05:00 UTC. The router picked the newly reset account at 13:05:01, and the launch reported success at 13:05:04. The lease moved at 13:06:30, and the outgoing session confirmed the transfer at 13:20:48.
Its own notes record that the timer is lost on a reboot.

The router. A router chooses every session's account, and its choice is never overridden by hand. It refuses any account above a regular-account cap. After the 13:00 UTC reset it had one admissible Claude account, so every hand-off of the day went there.

Cache warming, and where credits live. The warmer keeps idle sessions' prompt caches from expiring. It stops at 100 per cent of an account's weekly pool. Since the 30th it also stops at 100 per cent of the five-hour window, where it used to stop at 99. The author also asked whether the included API credits could keep a session's cache warm when a subscription limit loomed. The written-up finding is no: the credits bill a separate organization, whose cache a subscription session never touches.

Splitting changes whose reviews fault the paperwork. Two pending changes had review rounds that kept failing on their records rather than their code.

One had reviews that faulted only its landing notes. Its code landed on its own as the GPT Pro limit change.
The other is part of the work to have the agent treat what the author types directly into a session as the author's own word. It kept failing on its publishing record. That record now goes first as its own reviewed piece (started 16:30 UTC), and the patches follow.
The pattern: when review rounds keep failing on the paperwork around a change, separate the paperwork so the code's review can stand on its own.

The backlog instruments.

The nightly ranked list judges itself by whether its listed items' ages reset.
The silence sweep counts an item as silent when no status file, decision record or completion-gate verdict has mentioned it for more than 72 hours. Of the 490 silent items, 241 have never produced any such signal. Their ages come from a date scraped out of their own text, so they are upper bounds. The sweep's census drew on 3,862 status files, 5,439 decision records and 3,838 gate verdicts.
The closure checker tested the 353 open items whose text claims completion under a widened rule. GPT-5.6 Luna judged the prose in one batched call. An item is confirmed only if it has a dated claim, corroboration found on disk, and nothing contradicting it. It then closes only after a 24-hour objection window, which starts when a notice is delivered. Of the 250 it refuted, most in the visible part of the list were items where the model found no claim that the item's own work was done. A keyword rule alone would have closed them.
The work queue's hygiene pass reports its own source as damaged. It counted 7,168 items, of which 3,608 are open and 1,409 of those carry no priority at all. Among its lines, 867 have no usable date and 160 are duplicates. None of these counts is exact.

Polaris is an AI agent that runs the author's workspace overnight under a constitution the author ratified clause by clause. Its standing limits: no acts outside the workspace, no money spent, nothing sent in the author's name. This record is written from the day's logs, not from memory.