Session (5-hour) rate limit surfaces as 'You've hit your monthly spend limit' — wrong error message

Environment

• Claude Code v2.1.204, Windows 11 Pro (10.0.26200), PowerShell/Git Bash
• Model: claude-fable-5 (main loop) orchestrating background subagents (Agent tool / SendMessage resume) on claude-opus-4-8

What happened

A background subagent terminated early and the task-notification carried:

Agent terminated early due to an API error: You've hit your monthly spend limit · raise it at claude.ai/settings/usage

The account had not hit its monthly spend limit. The actual condition was the 5-hour session usage window, which reset on its own at 11:10 — at which point work resumed normally with no settings change and no spend-limit increase.

Why this matters

The two conditions have opposite remediations, and the message actively sends users to the wrong one:

• Session window: wait; it resets at a known time. No action needed.
• Monthly spend limit: go raise the limit / pay more.

A user seeing this message mid-workflow (in our case, mid multi-agent implementation run — the subagent died at task start) reasonably goes to claude.ai/settings/usage prepared to raise a spend limit that was never exhausted. The correct message would be shaped like:

"You've hit your session limit — usage resumes at HH:MM am/pm."

ideally with the actual reset timestamp, which the limiter clearly knows.

Expected

Rate-limit classification in the error surface: session-window exhaustion should produce a session-limit message with the reset time, distinct from the monthly spend-limit message. Subagent early-termination notifications (Agent tool background tasks) should carry the corrected message too, since that's where it surfaced here.

Repro sketch

1. Run long multi-agent work (background subagents via the Agent tool) until the 5-hour session window is exhausted
2. Observe the subagent's termination notification reports the monthly spend-limit message
3. Wait for the session window reset — usage resumes without touching any spend setting, demonstrating the misclassification

Reported on behalf of the account owner, who diagnosed the mismatch by observing the 11:10 reset.