Session quality: unverified claim about rate-limit status caused avoidable back-and-forth

Summary

During a multi-agent orchestration session (Fable model, background agents via the Agent tool), a review task hit a session rate limit with a stated reset time ("resets 6am Europe/Budapest"). Later in the same conversation, when asked to relaunch the same task specifically on the Fable model, the assistant asserted the relaunch "would just fail again" without checking whether the reset time had actually passed. It had — by about 13 minutes. The assistant only discovered this after the user pushed back twice (including sending direct negative feedback about wasted time), then ran a date check and found the limit was no longer active.

Why this matters

Stating a stale fact as current, when a single command could have settled it, reads to the user as excuse-making/bullshitting rather than an honest technical constraint. This eroded trust in an already long, high-stakes session (finalizing academic manuscripts under time pressure).

Suggested improvement

When an agent orchestration layer reports a time-gated constraint (rate limit reset, embargo, scheduled window) with an explicit reset time, the harness/model should proactively re-check current time before re-asserting the constraint is still active in a later turn, rather than relying on a stale earlier report. This could be a lightweight built-in nudge (e.g., surfacing current time alongside rate-limit-related task notifications) so the model isn't relying on memory of a time-gated fact across turns.

Context

• Platform: Windows 11, Claude Code CLI
• Model: Sonnet 5 orchestrating background Fable-model agents via the Agent tool
• This was reported as explicit user feedback within the session; filing per the user's request to log it on the issue tracker.