[FEATURE] Expose usage-limit reporting and add hook points for graceful shutdown and resume
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
The model and hooks appear have no visibility into my session or weekly usage, and no way to act on it. When a session hits its limit and pauses mid-task, the model learns only after the fact, so long-running work is interrupted with no graceful shutdown and can be left half-applied. Nothing signals when a new session begins, so nothing can trigger a resume. I run multi-step work that often spans these boundaries.
Proposed Solution
Two platform primitives. Anthropic exposes the data and the extension points; users write their own shutdown and resume logic.
- Expose limit reporting: current usage percentage and reset time for both the session and weekly windows, available to the model and to hooks.
- Provide hook points: a usage-threshold hook that fires when a configurable threshold is crossed (for example 85 percent of the session limit), and a SessionStart signal that reports a prior session ended at a limit and which one. Thresholds and scripts live in settings.json.
Let each user decide what graceful shutdown and resume mean. A standard handoff-file resume could ship as an optional default, but the primitive is the ask.
Alternative Solutions
- One built-in behavior with no user control. Every workflow handles interruption differently, so a fixed behavior fits few; a signal plus an extension point is more durable.
- A manual handoff file the model maintains. My current workaround, but it only fires when I remember to trigger it and cannot tell a session limit from a weekly one.
- A UI-only usage warning. Tells me a limit is close but gives me nothing to attach shutdown or resume logic to.
Priority
High - Significant impact on productivity
Feature Category
Configuration and settings
Use Case Example
I write a threshold hook that fires at 90 percent of the session limit: finish the current file, write a checkpoint, stop new work. The session pauses. On the next session, the SessionStart signal reports it ended at the session limit, and my resume hook points the model at the checkpoint to continue from the next file. For the weekly limit I write a more conservative hook, since the reset can be days away. The platform exposes the state and the hook points; the behavior is mine.
Additional Context
My current handoff-file workaround only works when I remember to trigger it and does not distinguish session from weekly limits. The missing pieces are platform primitives: the limit reporting (usage percentage and reset time for both windows) and the hook points to attach my own shutdown and resume logic.
<img width="662" height="143" alt="Image" src="https://github.com/user-attachments/assets/f25b3404-36eb-4131-9f30-e4ba0770ce5a" />
3 Comments
This is very close to the workaround I ended up building while the native primitives are missing.
I maintain usage-guard. Its status-line shim snapshots Claude Code's own 5-hour/weekly
rate_limitslocally. Two opt-in helpers then expose that state to automation:The check exits 1 before new work starts when a threshold is crossed, and
usage-guard-sessionstart.mjsadds a short quota/pace line atSessionStart. Missing or stale data fails open; no dependencies and no network calls.Important limitation: it does not checkpoint or resume work automatically, and it cannot cancel work already in flight. The snapshot also needs a live status-line source. So the native reporting + threshold/resume hooks requested here are still the complete solution; this only covers the local pre-flight/session-start part today.
Disclosure: I maintain usage-guard.
+1 — this captures the exact shape of the problem. The two primitives here (expose session and weekly usage/reset to the model and hooks, plus a configurable usage-threshold hook) are the missing pieces.
The behavior I most want on top of them: let the session **pause proactively at a safe checkpoint before the cap**, not just shut down gracefully once it's already hit. If the model can see it's approaching the wall, it can reach a natural stopping point — commit in-progress work, finish the current step instead of starting a new fan-out, write a resume note — then stop, rather than getting interrupted mid-edit with half-applied state. A threshold hook that fires before the limit is what makes that possible.
This matters most for long multi-phase runs and subagent orchestration, where background agents draw down the same budget quickly and the interruption tends to land in the middle of a phase.
Part of this exists today: status line scripts receive a
rate_limitsobject withfive_hourandseven_daywindows, each withused_percentageandresets_at, so you can render usage or trigger your own logic from the status line script (Pro/Max only)./usageshows the same numbers interactively.Docs: https://code.claude.com/docs/en/statusline
What's not available yet is a usage-threshold hook event and a SessionStart signal saying the prior session ended at a limit. Leaving this open for those.
🤖 Generated with Claude Code