Let a session resume itself when its usage limit lifts
Off by default and per session: it spends quota the moment quota exists,
with nobody watching, which is not a thing a default may decide. Switched
on from the session settings dialog, with the message it sends editable
("continue" unless something else is typed).
Running out of quota becomes a state rather than an error. The Claude
driver recognises its dialect's sentence -- `Claude AI usage limit
reached|1788546972` -- and reports `LimitReached` with the reset time it
gave; nothing above a driver matches on a string. The transcript draws it
as a divider, like a clear or a compaction.
The schedule is a plan to *ask*, never a plan to send. Both reset times
available are untrustworthy in the direction that matters -- the dialect's
is written when the turn fails, the endpoint's moves when the window does
-- so the wait ends in a question to the usage meter, and only `ok` with
no window at 100% sends anything. A window still spent reschedules to its
own reset time, which is what makes a limit that lifts late wait longer
and one that lifts early resume sooner. A meter that cannot be asked is a
longer wait too, never a send. A day after the limit was hit the wait
gives up and says so in the transcript, so a machine that can never be
asked is not retried for ever.
The schedule is persisted on the session: a five-hour window outlasts a
backend restart, and a wait forgotten across one never comes back.
Driven end to end with echo, never a real account: `/limit [minutes]`
reports the same event a real driver does and `/usage` sets what the meter
answers, deliberately separate so the two can disagree. The wait moved
from the dialect's two minutes to the meter's seven when the meter changed
its mind, and the message went out on the first check after the meter came
back under the limit.
Also makes the settings dialog scrollable, which these two controls made
necessary: at a 1.5x system font it clipped the last of them with nothing
on screen to say so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
4821a02bd3
commit
6bdec6e785
17 files changed
+1405
-20
No files matched your search
@@ -205,6 +205,25 @@ day to day:
|
||||
in `process.json`; removing either by hand while the session is live loses
|
||||
output or replays it.
|
||||
|
||||
## Auto-resume
|
||||
|
||||
**A session switched to it sends itself a message once the account's usage
|
||||
limit lifts** — off by default, per session, in the session settings dialog.
|
||||
PLAN.md's "Auto-resume" is the design; day to day:
|
||||
|
||||
- **The schedule is a plan to ask.** `resume.rs` wakes at the scheduled time,
|
||||
asks `GET /usage`'s meter for that machine and provider, and only sends when
|
||||
it answers `ok` with nothing at 100%. Anything else — still spent, logged
|
||||
out, unreachable — is a longer wait, and a still-spent window reschedules to
|
||||
the reset time the *meter* now gives.
|
||||
- **Test it with echo, never with a real account.** `/limit [minutes]` reports
|
||||
the same `limitReached` event a real driver does, and `/usage 100 5` sets
|
||||
what the meter answers. They are deliberately separate: the two disagreeing
|
||||
is the case the design exists for. `/usage 20` is the limit lifting.
|
||||
- The wait is on the session in `config.ron` (`resume`), so it survives a
|
||||
backend restart. A day after the limit was hit it gives up and says so in
|
||||
the transcript.
|
||||
|
||||
## Shared appearance
|
||||
|
||||
- **A row something is happening to is dimmed, drained of colour, and says
|
||||
|
||||
Reference in new issue
Block a user