What happened
The board's vendor-credit pane reported claude — logged out while the
operator was actively talking to Claude Code on that same machine, on a live
max subscription.
Evidence
The probe run by hand, immediately after, on the same box:
$ /Users/phil/.local/bin/claude auth status
exit code: 0
{
"loggedIn": true,
"authMethod": "claude.ai",
"apiProvider": "firstParty",
"subscriptionType": "max"
}
The pulse recorded 40 minutes earlier (fleet/workers/quotas.json):
{"agent":"claude","auth":"logged-out","ok":false,"note":"not logged in"}
Same command, same machine, opposite answers. It is intermittent, not wrong.
Cause
quotas.PROBE_TIMEOUT is 8s. Gaia runs at a load average of 4–7 on four
cores, so claude auth status overruns it under load. run() then returns
(1, "timeout"), and check_claude did:
try:
data = json.loads(out)
logged_in = bool(data.get("loggedIn"))
except ValueError:
logged_in = "loggedIn" in out and "true" in out.lower()
row["auth"] = "logged-in" if logged_in else "logged-out"
json.loads("timeout") raises, the fallback finds no loggedIn, and the row
is written as a definitive logged-out. A probe that did not answer was
recorded as an account that said no.
check_hermes already distinguished these two cases
(test_hermes_status_timeout_is_not_dry, 2026-08-26). check_claude never
got the same treatment, so the identical bug presented as a different one.
Fix
8374904 — an unreadable or timed-out probe now yields auth: "unknown",
ok: True (unproven is not down), and keeps probe_exit / probe_raw
locally in fleet/logs/probe-failures.jsonl. That file is deliberately
excluded from public_row, because claude auth status prints an email
address.
Tests: tests/test_a_silent_probe_is_not_a_verdict.py (5 cases — timeout,
genuine loggedIn: false, healthy answer, raw capture, and that the raw
output never reaches the public card).
Still open
The 8s timeout itself is unchanged. It is generous for an idle box and tight
for a saturated one, and every probe in quotas.py shares it. Worth deciding
whether the timeout should scale with load, or whether probes should be
skipped entirely above a load threshold the way pressure.too_hot() already
gates heavier work.
What happened
The board's vendor-credit pane reported
claude — logged outwhile theoperator was actively talking to Claude Code on that same machine, on a live
maxsubscription.Evidence
The probe run by hand, immediately after, on the same box:
The pulse recorded 40 minutes earlier (
fleet/workers/quotas.json):{"agent":"claude","auth":"logged-out","ok":false,"note":"not logged in"}Same command, same machine, opposite answers. It is intermittent, not wrong.
Cause
quotas.PROBE_TIMEOUTis 8s. Gaia runs at a load average of 4–7 on fourcores, so
claude auth statusoverruns it under load.run()then returns(1, "timeout"), andcheck_claudedid:json.loads("timeout")raises, the fallback finds nologgedIn, and the rowis written as a definitive
logged-out. A probe that did not answer wasrecorded as an account that said no.
check_hermesalready distinguished these two cases(
test_hermes_status_timeout_is_not_dry, 2026-08-26).check_claudenevergot the same treatment, so the identical bug presented as a different one.
Fix
8374904— an unreadable or timed-out probe now yieldsauth: "unknown",ok: True(unproven is not down), and keepsprobe_exit/probe_rawlocally in
fleet/logs/probe-failures.jsonl. That file is deliberatelyexcluded from
public_row, becauseclaude auth statusprints an emailaddress.
Tests:
tests/test_a_silent_probe_is_not_a_verdict.py(5 cases — timeout,genuine
loggedIn: false, healthy answer, raw capture, and that the rawoutput never reaches the public card).
Still open
The 8s timeout itself is unchanged. It is generous for an idle box and tight
for a saturated one, and every probe in
quotas.pyshares it. Worth decidingwhether the timeout should scale with load, or whether probes should be
skipped entirely above a load threshold the way
pressure.too_hot()alreadygates heavier work.