From ad3732a90880ea18c7c944a36d209363cc75a6fe Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Thu, 10 Sep 2026 08:46:21 +0700 Subject: [PATCH] Features: the two limits that bound any usage-limit recovery --- 11-Features.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/11-Features.md b/11-Features.md index 043d45b..91f434b 100644 --- a/11-Features.md +++ b/11-Features.md @@ -4826,4 +4826,23 @@ subscription is the thing that actually runs out. own behaviour is tested; that it is still *called* is not. Same shape as the six `FleetConfig.validateXxx()` startup calls — fleetd #398 owns closing it. +**Two limits of the detection this reports on.** Both bound what any recovery feature can do, so +read them before designing one. + +- **Detection needs a worker turn that finished.** `CompletionResolver` classifies a usage limit by + matching the member's own terminal output when its turn completes. There is no HTTP status or + header path into this. So fleetd cannot learn a limit has been hit until a member has run and + ended, and it cannot cheaply ask "is the limit lifted yet?" — any auto-resume has to spend real + backend work to find out. +- **No reset time is delivered, anywhere.** The captured live refusal is `The usage limit has been + reached. Try again later.` — there is no time in it, and nothing in the refusal path reads a + `Retry-After`. `BackendQuarantine` stores `now + cooldownNanos` and nothing else. Recovery can + therefore only ever be a fixed timer or a backoff probe, never a resume scheduled for the real + reset moment. +- **Every `subscription: true` profile shares one quarantine key.** With no explicit `credentialId`, + `effectiveCredentialId()` returns the `` sentinel, which is right for a single + Claude plan. The consequence is easy to miss: on this fleet the lead's own profile (`opus`) shares + that key with the worker fan-out profile (`sonnet`). Arm `exhaustedPattern` on `sonnet` alone and + worker exhaustion starts quarantining the lead's seat too. Arm them together, or not at all. + fleetd #395.