Use Claude reset time to wait until quota reset instead of fixed --wait duration

[Labutin]

Summary

Currently, when ralphex detects a Claude/Codex rate limit and --wait / wait_on_limit is configured, it waits for the fixed user-provided duration and then retries.

This works, but Claude often prints a more precise reset time, for example:

You've hit your session limit · resets 8:20pm (America/Los_Angeles)

or messages like:

Resets in 1 hr 32 min

Since ralphex already captures the executor output and detects limit patterns, it could potentially use that reset information to wait until the actual reset time instead of always sleeping for the configured fixed duration.

Motivation

A fixed --wait duration is hard to choose correctly:

• If it is too short, ralphex wakes up too early, retries, hits the same limit again, and repeats.
• If it is too long, ralphex wastes time even though the limit may have already reset.
• For long unattended runs, this makes --wait less reliable than it could be.

Claude sometimes tells us exactly when the limit will reset, so ralphex could make a better decision automatically.

Proposed behavior

When a limit pattern is detected and --wait / wait_on_limit is enabled:

1. Inspect the executor output for reset information.
2. If a reset time/duration can be parsed, wait until that reset time, optionally with a small safety buffer.
3. If no reset information can be parsed, fall back to the current fixed --wait duration.

Example log message:

rate limit detected in claude output; reset at 8:20pm America/Los_Angeles, waiting 37m before retry...

For relative reset messages:

rate limit detected in claude output; resets in 1h32m, waiting 1h34m before retry...

Compatibility / fallback

This could preserve the current behavior:

• If --wait / wait_on_limit is not enabled, ralphex should continue to exit as it does today.
• If reset time parsing fails, ralphex should use the configured fixed wait duration.
• Existing configs using --wait 1h, --wait 30m, etc. would continue to work.

Related existing behavior

PR #168 added the current --wait / wait_on_limit retry behavior.

Issue #361 shows an example where Claude prints:

You've hit your session limit · resets 8:20pm (America/Los_Angeles)

but the expected behavior there is still based on waiting the configured duration. This proposal is a small extension: when the reset time is available, use it instead of guessing.

Discussion vs issue

I am opening this as a discussion first because I am not sure whether this fits the intended scope of --wait.

If this behavior makes sense, I can convert it into a proper issue with a more concrete implementation proposal.

[umputun]

i'm going to keep --wait as the coarse fixed-duration knob and pass on parsing the reset time. The reasoning, in case it's useful:

the retry loop already self-corrects when it wakes too early. On a limit hit with --wait set, ralphex sleeps the duration, retries, and if the limit is still active it re-detects and waits again. So an over-long --wait only costs idle minutes on a run you've already left unattended, and a too-short one costs one extra retry cycle. In practice a shorter --wait like 15-30m plus that self-healing loop gets you most of what precise parsing would, without a parser in the path.

i don't follow the "less reliable for long unattended runs" point in the writeup. The fixed wait always retries and eventually gets through, so there's no reliability gap to close here, just some wasted minutes or an extra cycle. That's an efficiency thing, not correctness.

the case that would actually benefit is the absolute form from #361, resets 8:20pm (Europe/Istanbul), and that's also the brittle one. It's undocumented CLI text that can be reworded anytime, parsing it needs timezone lookup (the binary doesn't bundle tzdata today), next-occurrence and DST/AM-PM handling, and a misparse to a past time would compute a zero wait and spin into a tight retry loop against the API. The safe half, the relative resets in 1h32m wording, is easy to parse but wouldn't have covered that #361 case at all. So the cheap part doesn't help and the helpful part isn't cheap.

it'd also be Claude-only. Under --codex the limit strings are generic API errors (429, quota exceeded) with no reset time to read.