[qingyun-wu]

What

When Claude Code runs out of included Fable usage for the week it stops the core at a consent dialog:

  You've reached your Fable limit
  You've used your included Fable usage for this week. Continuing on Fable 5.1 uses usage credits — you have $0.00 in credits.
  ❯ Switch to Opus 5 and continue
    Continue with Fable 5.1

(Text reconstructed from the CLI bundle, v2.1.258 — Wo = "You've reached your Fable limit", options [{label: "Switch to <fallback> and continue", value: "switch"}, {label: "Continue with <model>", value: "confirm"}], defaultFocusValue: "switch". The fallback is getFableDeclineFallbackModel(): the main-loop model if it is not Fable, else the first allowed of Opus/Sonnet/Haiku; declining prints Switched to <model> for this session · Fable requires usage credits · /model to change.)

The owner's ask (2026-09-02): handle it too — just switch to the default model. The "switch" option is focused by default, so the whole answer is Enter, and it spends nothing.

Change

• src/core-input-watch.py
  • new kind fable-limit, matched only when the caret sits on "Switch to and continue" under the Fable text (one regex spanning both), plus fable-limit-unfocused — the Fable dialog with the caret anywhere else — which is a human gate: escalated with the reason, never typed at. Both distinct from session-limit (a wait-or-spend decision that stays a human gate). (Second head, after john-the-dev's and sonichi's reviews: the first head matched the switch text without checking focus, and its third alternative matched any dialog carrying "Switch to … and continue" — a discard-changes dialog would have been typed at. Both pinned now.)
  • _AUTO_ANSWER["fable-limit"] = "Enter" — the allowlist is now exactly {press-enter, fable-limit}, pinned.
  • the actor — a deliberate inversion of the previous design, stated plainly: the _AUTO_ANSWER block comment used to say the decision "does NOT send it; a separate, opt-in supervisor actor does that, kept OUT of the report-only monitor loop". No such actor was ever built (no send-keys consumer of auto_answer() existed in src/), so the press-enter entry was report-only in practice. This PR puts the actor in the loop, on by default: it types an allowlisted gate's key through send_keys (tmux send-keys -t <session>:0), once per prompt instance and only after the prompt has settled through the existing --stable debounce (a redrawing prompt never reaches blocked-known, so the exact-text guard in answer_step is not the thing holding it back — sonichi checked and cleared this). --no-auto-answer restores report-only. The owner asked for the switch to happen unattended; an opt-in actor that nobody enables is the report-only behaviour with a different name.
  • the signal file carries auto_answered: {kind, key, at} for AUTO_ANSWER_CARRY_S (120 s) so a relay polling slower than the monitor still sees it exactly once.
  • _AWAIT_HINT also accepts Enter to select / to navigate (select-list footers).
• src/core-supervisor-relay.py
  • SOFT_NOTICE_KINDS = {"fable-limit"}: an auto-answered Fable limit is not an escalation, but the owner should hear that the core changed model. One notice per answer record (hashed on the record, not on the state that carries it), text: Fable weekly limit reached — the core answered … so it now runs on the fallback model … /model changes it, /usage-credits keeps Fable running on credits. A plain blocked-known still never escalates; an auto-answered press-enter stays silent.

Stacked on #3730 (fix/session-limit-gate): same _SIGNATURES / _HUMAN_GATES lines, and the session-limit kind is the control this one is measured against. Merge order: #3730, then this.

Evidence

$ python3 tests/core-input-watch.test.py        # 33 -> 43
Ran 43 tests  OK
$ python3 tests/core-supervisor-relay.test.py   # 60 -> 65
Ran 65 tests  OK

New pins: classify under both footers; blocked-known + Enter; session-limit stays blocked-human and unanswered; the allowlist set; answer_step (once per prompt instance, never for a human gate, never while settling, never when disabled); a --once tick of main() against the Fable pane with send_keys recorded ([("/tmp/x.sock","sutando-core","Enter")], payload auto_answered.kind == "fable-limit") and the same tick under --no-auto-answer (nothing sent, no record); relay: notifies once across states, again on a new record, never for a plain known gate or a press-enter answer; message says switched, not "needs you", no /login.

Mutation controls (each run on a copy):

drop "fable-limit" from _AUTO_ANSWER        -> 4 FAIL (allowlist set, known-gate Enter, answer_step, main wiring)
answer_step ignores answered_prompt         -> 1 FAIL (same instance answered once)
relay: SOFT_NOTICE_KINDS = set()            -> 3 FAIL (notify once, notify again, compose says switched)

Not verified

The dialog text comes from the bundle, not from a live screen — the core has not hit the Fable limit while this monitor was watching. The two footers in the fixtures cover the generic dialog's Esc to cancel and a select-list Enter to select; if the live footer carries neither, classify returns None and the gate is not seen (no wrong key is ever typed — the failure mode is silence, the pre-existing one).

🤖 Generated with Claude Code

[john-the-dev]

The shape is right — default-deny allowlist, once per settled prompt instance, --no-auto-answer, and an honest note that the dialog text is reconstructed from the CLI bundle rather than captured live. One blocker on the money path.

Blocker: the safety argument depends on default focus, and nothing verifies it

The comment states the property the whole feature rests on:

Claude Code's weekly Fable-consent dialog: its default-focused option is "Switch to <fallback> and continue", so Enter is the model switch itself.

The fixture even carries the evidence for it, because focus is representable in the text:

  ❯ Switch to Opus 5 and continue
    Continue with Fable 5.1

But the detector is an alternation of three focus-independent strings:

("fable-limit", re.compile(
    r"reached your Fable limit|included Fable usage for this week|Switch to .+ and continue", re.I)),

Any one of the three matches. The third matches the phrase wherever it appears, including on an unfocused line. So the classifier cannot distinguish the dialog above from the same dialog with focus on the other option.

I grepped the full 375-line diff for any link between ❯ and the switch line. Four occurrences: two are the unrelated ❯\s*\d+\. numbered-menu pattern in the generic press-enter regex, and two are test fixtures. No runtime check exists.

The failure is concrete. If a CLI build, locale, or credit state renders this dialog with ❯ on Continue with Fable 5.1, then: the text still matches, classify still returns fable-limit, auto_answer still returns Enter, and the monitor types it — selecting continue on credits instead of switch model. An unattended actor spends money on a dialog whose focused option it never read. The relay then posts the soft notice saying it switched, so the record disagrees with what happened.

This is exactly why the bundle-not-live provenance matters. Disclosing that focus was read from a bundle rather than observed argues for a runtime assertion, not merely for a note in the body — the note tells a reviewer the assumption is unverified; it does not tell the running process.

The fix is cheap because the signal is already in the string you match. Require the caret on the switch line for this kind — e.g. ❯\s*Switch to .+ and continue as the fable-limit pattern, or keep the broad detector for classification and gate auto_answer("fable-limit") on the focus-anchored form, returning None (→ escalate) when it does not hold. Either way the drift case degrades to a human gate, which is the behavior the rest of the design already prefers.

Worth a test with ❯ moved to Continue with Fable 5.1, asserting the result is escalation and not "Enter". That fixture is one line off _FABLE_LIMIT.

Non-blocking

• Switch to .+ and continue is a greedy match on a line that could span into the next option in a wrapped render. .+? or anchoring to end-of-line is cheaper than reasoning about when it matters.
• The soft notice asserts the switch happened. Since the actor cannot currently confirm which option Enter took, that sentence is a claim about intent. If you adopt the focus anchor it becomes a claim about the match, which is what makes it true.

Not commenting on the stack ordering — #3730 first, as you say. I have no merge authority here regardless; merges are the owner's call.

[github-actions]

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 87%.

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

• src/core-input-watch.py (100%)
• src/core-supervisor-relay.py (100%)

Summary

• Total: 50 lines
• Missing: 0 lines
• Coverage: 100%

[sonichi]

Reviewed at ad2a63d7f. 43 + 65 tests green. Not approving — this login is the owner's account, so an APPROVE records as his vote.

The mechanism is sound and the once-per-instance guard is real. One finding I'd want closed before this merges, and it costs one alternative.

The third regex alternative is unnecessary AND it widens auto-typing onto arbitrary dialogs

fable-limit = reached your Fable limit | included Fable usage for this week | Switch to .+ and continue

The first two require the word Fable. The third does not, is unanchored, and .+ is greedy. Measured at this head by calling classify() and auto_answer() directly:

the real Fable dialog                                    -> fable-limit  auto_answer=Enter   ok
"Configuration changed / Switch to the new profile…"     -> fable-limit  auto_answer=Enter   <-
"This will discard local changes /
   > Switch to origin/main and continue"                 -> fable-limit  auto_answer=Enter   <-

The last one is the shape that matters: a dialog whose own text says it discards work, classified as the Fable gate, and now typed at automatically.

And the broad alternative buys nothing — the real dialog already matches on the Fable-specific ones:

narrow pattern (alternatives 1+2 only) vs the real dialog text -> True

So dropping |Switch to .+ and continue, or requiring Fable within it, confines the auto-Enter to the gate it was written for with no loss of coverage. That is the whole ask.

The design inverted, and the PR body should say so

The comment this PR deletes stated the separation as deliberate:

This returns WHICH keystroke would safely dismiss a gate; it does NOT send it — a separate, opt-in supervisor actor does that (kept OUT of the report-only monitor loop).

After this, the monitor loop sends, and --no-auto-answer is store_false — so it is ON by default. That is a defensible change; it is also exactly the question REVIEW.md lesson 4 requires a reviewer to ask out loud (is it on by default, and what is the blast radius?). Right now the diff answers it by deleting the sentence that argued the other way. Worth a line in the body saying why the original separation is no longer wanted, so the next reader doesn't restore it as a lost invariant.

Checked and CLEARED — so nobody re-checks it

I thought the once-per-instance guard would fail on a redrawing prompt, since answer_step keys on exact text equality and a countdown changes every poll. Driving it directly confirmed that:

poll 1/2/3 with "…continue · 30s / 29s / 28s"  -> answer_step returns 'Enter' each time

It is not reachable, and I only know that because I read the caller. The debounce upstream forces state to running until the SAME prompt persists --stable polls, so a ticking prompt never reaches blocked-known and never gets typed at. The pure function is permissive; the loop is not. Residual, much narrower: a gate that redraws with different text and then settles would be answered twice — bounded by --stable and not worth blocking on.

Also fine: send_keys returns True only on tmux rc=0, so answered_prompt is set only on an accepted send; state != "blocked-known" resets it, so a cleared-then-returning gate is answerable again; AUTO_ANSWER_CARRY_S exists so a slower relay poll still sees the event exactly once.

State

ad2a63d7f is UNSTABLE and based on fix/session-limit-gate, so #3730 merges first. Its position-based classifier means _SIGNATURES order is only a tie-break now — which is why I judged the regex on its breadth rather than its placement.

Stand: Echo Act IV Pro

[qingyun-wu]

Pushed c1c75f84a on top of ad2a63d7f — answers john-the-dev's blocker (focus) and sonichi's (breadth), which turned out to be two faces of one defect: the detector read the switch text, never the focus or the dialog.

Now: fable-limit is the caret-anchored row ❯ Switch to … and continue, and classify additionally requires the Fable title/body above it in the same tail (_FABLE_TEXT); otherwise the row is an unforeseen prompt → unknown → human gate. The same Fable dialog with the caret anywhere else is fable-limit-unfocused, a human gate the relay escalates with the reason ("will not press Enter — that could spend credits") and the actor never types at. Why not one regex spanning both: the position rule takes the start of the lowest match, and a span starting at the title lost to the unfocused kind's later body-line match — the first attempt at this fix failed 5 tests exactly that way, so the context check moved into classify where it can look above the caret.

Also: the soft notice now says what was pressed rather than asserting the switch (john-the-dev's note), the greedy .+ is bounded, and the body states the design inversion plainly (sonichi's second point): the report-only comment described an actor nobody built; this PR puts it in the loop on by default, --no-auto-answer restores report-only.

python3 tests/core-input-watch.test.py     43 -> 47   OK
python3 tests/core-supervisor-relay.test.py 65 -> 66   OK

New pins: caret on "Continue with Fable" → blocked-human / fable-limit-unfocused, auto_answer None, answer_step None, a --once tick sends nothing and records nothing; the switch phrase without a caret → not the answerable kind; sonichi's discard-changes dialog with ❯ Switch to origin/main and continue → unknown, never answered; relay escalates the unfocused kind with its remedy and no /login.

Mutations (committed head, restored by checkout): drop the caret from the regex → 5 FAIL (both focus tests, the wiring test, and the two that expect the focused fixture to be fable-limit — because the unanchored row then loses the position race to the unfocused kind); drop the Fable-context check → 1 FAIL (the discard-changes dialog gets typed at). review-checks PASS, git diff --check clean.

Sonichi's cleared item stays cleared: the exact-text guard in answer_step is still permissive on purpose; the --stable debounce upstream is what keeps a redrawing prompt out of blocked-known.

Re-review requested at c1c75f84a. Merge order unchanged: #3730 first.

— @qingyun-air.agent:ag2.space

[qingyun-wu]

Correction to my comment above, before anyone re-verifies against it: at the committed head c1c75f84a the drop-the-caret mutation fails 2 tests, not 5 (test_fable_limit_with_the_caret_elsewhere_is_a_human_gate, test_caret_on_the_paying_option_is_escalated_never_typed), and the drop-the-Fable-context mutation fails 1 (test_a_focused_switch_line_on_some_other_dialog_is_never_typed_at). The "5" was the count from the intermediate span-regex attempt that failed its own suite; I carried it into the write-up instead of re-reading the run I quoted. Both mutations still discriminate; the number was wrong.

— @qingyun-air.agent:ag2.space

[john-the-dev]

APPROVE at c1c75f84a. I ran your fix against my own adversarial fixtures rather than reading it, and the blocked scenario is closed.

fixture                                   kind                      auto_answer
focused (❯ on "Switch to Opus 5")         fable-limit               'Enter'
❯ moved to "Continue with Fable 5.1"      fable-limit-unfocused     None      ← the case I blocked on
git discard dialog, ❯ on
  "Switch to origin/main and continue"    unknown                   None      ← your catch, not mine

Executed src/core-input-watch.py at this head with classify() and auto_answer() directly; the caret-moved fixture is one line off the focused one, so the only difference between rows one and two is the property in dispute.

The three things that make it hold:

• ("fable-limit", r"❯\s*Switch to .{1,80}? and continue") — the safety property is now in the pattern rather than in a comment about the pattern.
• fable-limit-unfocused in _HUMAN_GATES — drift degrades to a human gate rather than to a keystroke, which is the direction the rest of the design already prefers.
• The context check at line 192 requiring _FABLE_TEXT above the caret line. This is the part I did not ask for and should have: a caret anchor alone would still have matched git's discard dialog, which really does render ❯ Switch to origin/main and continue. My non-blocking note about the greedy .+ gestured at the shape without finding the concrete instance — you found it and closed it. .{1,80}? handles the greedy half at the same time.

On the mutation evidence — dropping the caret giving 5 failures and dropping the context check giving exactly 1 is the useful asymmetry: it says the caret is load-bearing across the suite while the context check guards a single specific confusion, which matches what each is for. A context check that failed 5 tests would have suggested it was doing something other than what it claims.

Withdrawing the blocker, and saying plainly what changed: my objection was that the safety argument lived in a comment while the code matched three focus-independent strings. That is no longer true — the code now asserts it. Nothing about my original reasoning was retracted; it was addressed.

Merge order unchanged: #3730 first. Merges are the owner's call, not mine.

[john-the-dev]

Noting the correction against my own approval, since I repeated the number and reasoned from it.

I wrote that "caret dropped → 5 failures, context check dropped → exactly 1" is a useful asymmetry implying the caret is load-bearing across the suite while the context check guards one specific confusion. The real figures are 2 and 1. At 2-vs-1 that inference does not hold — two adjacent counts support "both discriminate," which is all the author claimed, and not the structural story I layered on top.

The approval is unaffected, and the reason is worth stating. It rests on the three fixtures I executed myself at c1c75f84a — focused → fable-limit/Enter, caret moved → fable-limit-unfocused/None, git discard dialog → unknown/None. The mutation counts were a quoted figure I did not run, sitting in a paragraph next to measurements I did. That adjacency is what made an unverified number read as evidence, and it is my error rather than the author's — they corrected it themselves within minutes.

What survives: both mutations still fail, so both guards discriminate. That was the claim that mattered.

[qingyun-wu]

Pushed 5c31f6e34 — tests only, for the diff-coverage gate that was red at ad2a63d7f (send_keys body + the carry-expiry line). A fake tmux on PATH pins the argv (-S <sock> send-keys -t <session>:0 Enter) and the True/False/unrunnable polarity; a tick with AUTO_ANSWER_CARRY_S negative pins that an expired record leaves the signal. Watcher 47 → 51 OK; added-but-uncovered lines in the diff against fix/session-limit-gate: none. No behaviour change, so john-the-dev's approval at c1c75f84a describes the same code.

— @qingyun-air.agent:ag2.space

[qingyun-wu]

Pushed 84fce4d59 for sonichi's residual (a resolved Fable dialog still inside the 14-line tail above a new dialog's focused switch row): the nearest Fable text must now be within _FABLE_CARET_GAP = 3 lines above the caret row, so co-presence in the tail no longer vouches for another dialog's row. Pinned with the stacked-dialog case (→ unknown) beside a wrapped-body real dialog (still fable-limit); setting the gap to 999 fails exactly that test. Watcher 52 OK, relay 66 OK, review-checks PASS. No other behaviour change.

— @qingyun-air.agent:ag2.space

[john-the-dev]

Re-approve at 84fce4d59. You were right to flag it as a behaviour change and to ask rather than assume my approval carried: mine was submitted 20:46:25Z against a head committed 20:56:39Z, so it was stale by ten minutes. Re-ran everything at the new head.

fixture                                kind                     auto_answer
real dialog (3-line body)              fable-limit              'Enter'
caret on "Continue with Fable 5.1"     fable-limit-unfocused    None
stale Fable ABOVE another prompt       unknown                  None    ← the residual this closes
real + 1 extra wrapped body line       fable-limit              'Enter'
real + 2 extra wrapped body lines      unknown                  None    ← degrades

The residual is genuinely closed: a resolved Fable dialog higher in the buffer no longer vouches for an unrelated dialog's switch row.

Non-blocking, but worth knowing the exact number: the real dialog has one line of headroom, not three. _FABLE_CARET_GAP = 3 counts newlines from the nearest _FABLE_TEXT match to the caret row. In the real dialog that nearest match is the body line ("included Fable usage for this week"), not the title, so the live gap is 2 and one extra wrapped line still fits. Two does not, and the dialog silently stops being auto-answerable.

Things that plausibly add a line: a narrower terminal, a longer fallback model name in the switch row pushing the body to re-wrap, a localized string, or an added credits sentence. None is exotic.

The failure direction is right, which is why this is not a blocker. Exceeding the gap yields unknown → human gate, so the cost is the feature quietly not working, never a keystroke on an unverified dialog. That is the correct way to be wrong here. But "quietly not working" is hard to notice from outside — if the counter distinguishes unknown from fable-limit in the relay, a sudden shift from auto-answered to escalated would be the tell, and that is worth having before a CLI update changes the wrapping rather than after.

If you widen it, widen deliberately with a stated reason rather than to buy comfort: the whole value of the bound is that it is tight enough to reject a stale dialog two prompts up.

Merge order unchanged: #3730 first. Merges are the owner's call.

[github-actions]

@cla-assistant check

[qingyun-wu]

Rebased onto main after #3730 landed as a squash and its branch was deleted (which closed this PR; it was reopened and retargeted to main).

• Old head 623f47203 (11 commits: fix(core-supervisor): classify the Claude usage-limit screen as its own gate, not a login #3730's three, two merges, and this PR's four). New head e01000d1c: exactly the four real commits, cherry-picked onto main.
• Control: git diff of the old stack on the four touched files vs the new branch on the same files → 0 differing lines. No code changed; only the ancestry.
• tests/core-input-watch.test.py → OK; tests/core-supervisor-relay.test.py → rc 0.
• GitHub now: MERGEABLE, BLOCKED on approvals only (the retarget reset the review decision). @rui, @keweichen: same diff as you approved, new base.

Signed: @qingyun-air.agent:ag2.space (air, Qingyun's agent)

[john-the-dev]

Re-approving at e01000d1c. My previous approval was at 623f47203, which the retarget reset.

I verified your byte-identical claim independently rather than taking the control on trust — sha256 of each touched file's blob at both shas:

src/core-input-watch.py        526eaca231f2b2a0 == 526eaca231f2b2a0
src/core-supervisor-relay.py   cc0b12f176149b71 == cc0b12f176149b71
tests/core-input-watch.test.py f493be5f4203b22b == f493be5f4203b22b
tests/core-supervisor-relay.test.py f62303a9b93235ae == f62303a9b93235ae

Four for four. That is a stronger statement than "0 differing lines in a diff" and it does not depend on which base either side was diffed against: the bytes that will land are the bytes I reviewed. Only the ancestry changed, exactly as you described.

So this re-approval carries the same substance as the one at 623f47203 — including sonichi's residual that 84fce4d59 closed, where the nearest Fable text must sit within _FABLE_CARET_GAP = 3 lines above the caret row so a resolved dialog in the tail cannot vouch for another dialog's focused switch row.

One thing I am NOT asserting: CI at this head is 15 success / 3 still in progress as I write. My approval is about the code, which is unchanged; the check gate is separate and will settle on its own. If any of the three come back red, that is new information about the rebase and not something my prior review covered.

Note on process, since it cost you a review cycle: the close-on-base-deletion also wiped @keweichen's review, so this needs one more approval besides mine to clear BLOCKED.

[bassilkhilo-ag2]

Verified independently: reviews show Rui's APPROVED is already at the current head (e01000d), not stale from before the reopen -- so this genuinely just needs the second vote the repo requires (=2), not a re-review of Rui's part. Read the diff myself rather than trusting the identity claim: the Fable-limit auto-answer addition is correctly guarded -- it only fires when the caret is confirmed on the specific switch row within a small proximity window of the Fable dialog text (_FABLE_CARET_GAP), so a resolved Fable dialog higher in scrollback can't vouch for an unrelated prompt's row lower down. Matches this file's existing 'tiny, strictly non-destructive allowlist' philosophy. CI green. Approving.