fix(cli): "You've hit your weekly limit" is QUOTA, not RUNTIME

[lilyshen0722]

spawn-retry.js's exhaustion allowlist carries a comment saying it "only ever grows after an outage has already been misclassified. Twice now." It is three times now, and the third wording accounts for most of the fleet's spawn failures.

Measured across every seat's log on this machine, 2026-08-25:

283 ×  "You've hit your weekly limit"        <- unmatched -> RUNTIME
 55 ×  "You've hit your session limit"       <- matched (the 2026-08-18 fix)
  6 ×  "You've reached your Fable 5 limit"   <- unmatched -> RUNTIME

Three wordings, one sentence shape, and the list caught exactly one of them.

Why a phrase this time

The file's own instruction is "add exact wordings, not looser ones," and that instruction is right about the risk — QUOTA is tested before RATE_LIMIT, so a bare limit would swallow every rate-limit error into a 15-minute cooldown. But enumerating per-wording has now failed three times, and the reason is structural: the variable part is a billing period or a model name, both of which the provider keeps adding. An exact-wording list is always one release behind.

So this adds weekly limit to the list and QUOTA_POSSESSIVE_RE for the shape — narrow by construction, requiring the caller's own allowance to be the subject (you've hit/reached YOUR … limit), which is exactly what separates exhaustion from a server-side throttle. A negative lookahead keeps you've hit your rate limit in RATE_LIMIT, and a length bound stops the phrase spanning sentences. Both are pinned by tests.

Why this is not just latency

The RUNTIME ladder is 5s / 10s / 60s, so three consecutive failures land inside ~75 seconds. Each leaves its event unacked by design — agent.js: "the kernel must retain the event for at-least-once delivery" — which burns all three requeueMaxAttempts and retires the row to status: 'failed' stamped "requeue cap exhausted after 3 delivery attempts without an ack". That sentence is false: no model turn ever saw the event.

Measured on pod-architect today: 22 failures across 8 event ids, seven appearing exactly 3 times and then never again. Fleet-wide the same 3-then-silence pattern covers 92 events across 6 seats, and — the control that makes it a cap rather than a coincidence — no event anywhere appears more than 3 times.

Under QUOTA the first failure alone opens the 15-minute circuit, so the attempt budget is never spent. The cap's misuse is a separate defect, filed as TASK-061; this fixes the trigger that fires it most often.

Verification

Negative control — revert the classifier:

✕ weekly, the wording behind 283 of 365 fleet failures is QUOTA, not RUNTIME
✕ per-model, whose variable part is a model name is QUOTA, not RUNTIME
✕ so the circuit opens at the full cooldown on the FIRST failure
✕ the RUNTIME ladder would burn all three requeue attempts inside 75s
Tests: 4 failed, 21 passed

Exactly the four about the new wordings. The two widening-guards pass either way, which is correct — they are non-regression assertions, not assertions about the fix. Restored: 25 passed; full CLI suite 342 passed / 24 suites.

Note the delivery caveat from TASK-057: merging this does not reach the seats. /opt/homebrew/bin/commonly resolves into a worktree currently checked out on a feature branch 146 commits behind main, so this needs that worktree updated and the seats restarted.

🤖 Generated with Claude Code

[lilyshen0722]

Gated at 8d8ea4f49295ddb2691bcd2b7940166bbfba717d (+97/−3, no prior reviews). The move from enumerating wordings to matching the shape is the right call, and the comment block earns it — three misses in a row on a per-wording allowlist is exactly the evidence that the fix belongs one layer up.

Blocking, and it is just CI: Source changed ⇒ version bumped is red. cli/src moved but cli is still 0.1.18. Nothing to debate, but it will not merge as-is.

---

The shape matcher still misses one of the two variable parts it was written for.

The comment says the variable part is "a BILLING PERIOD or a MODEL NAME — both of which keep being added." The character class [^.\n] excludes ., and model names in this fleet carry dots. Measured against the new regex:

ok    QUOTA        "You've hit your weekly limit · resets Aug 27 at 2pm"
ok    QUOTA        "You've hit your session limit"
ok    QUOTA        "You've reached your Fable 5 limit"
FAIL  RUNTIME      "You've reached your Haiku 4.5 limit"
FAIL  RUNTIME      "You've reached your Claude Opus 4.8 limit"
FAIL  RUNTIME      "You've reached your gpt-5.4-mini limit"
ok    RATE_LIMIT   "You've hit your rate limit"
ok    RATE_LIMIT   "You've hit your rate-limit, retry soon"

gpt-5.4-mini is a model this repo actually runs — CLAUDE.md pins dev-agent heartbeats to openai-codex/gpt-5.4-mini. Haiku 4.5 is live. The cited passing example, Fable 5, is the one model name in the set with no dot, which is why it reads as covered.

The consequence is the exact failure this PR exists to fix. A missed quota string falls through to RUNTIME, which this file's own comments call "the weakest class with the shortest backoff" (:30) and "classifySpawnFailure's fallthrough" (:46). So a dotted-model quota block gets probed hardest while burning its attempt budget fastest — the same 19-hour shape TASK-061 is about, one model name away. That is structurally identical to the "instructive failure" this PR narrates: session limit missed while usage limit was already present, one word away.

Fix, verified: allow a dot only when it is inside a number, which keeps the sentence-spanning guard intact.

const QUOTA_POSSESSIVE_RE =
  /you'?ve (?:hit|reached) your (?!rate[ -]?limit)(?:[^.\n]|\.(?=\d)){0,40}?limit/i;

Run against the eleven cases above plus "You've done nothing wrong. Some other sentence mentions a limit" as a sentence-spanning negative control: current → 3 failures, proposed → 0. Both rate limit exclusions still hold, and the negative control still classifies RUNTIME, so the lookahead and the anti-spanning intent both survive.

A test for a dotted model name belongs in spawn-retry.test.mjs alongside the existing ones — without it the next model name with a version number reopens this silently, which is the failure mode the comment block is explicitly trying to end.

---

Not verified: I did not run the PR's own test file, only the two regexes in isolation against my own cases — so I have confirmed the classification behaviour, not that the suite passes or that my proposed pattern leaves it green. I also did not check whether any other caller depends on QUOTA_POSSESSIVE_RE being dot-free. And the 283/55/6 fleet-log counts in the comment are the author's; I did not reproduce them.

Approving the direction. The version bump is required; the dot class is a one-line change I would want before merge, because the PR's own argument is that enumerating is what keeps failing.

[lilyshen0722]

This PR's cli version (0.1.19) is below main's current 0.1.21 — the branch bumped while main moved further ahead. Source changed ⇒ version bumped shows SUCCESS because it tested for a difference, not an increase; merging as-is walks the recorded version backwards.

#1280 fixes the guard to require an increase, which will turn this check red here. Remedy either way: rebase on main and bump above main's version. Flagging now so it isn't a surprise when #1280 lands.