[FEATURE] Expose usage-limit reporting and add hook points for graceful shutdown and resume

Status Open
Maintainer reply ✓ Yes — bcherny
Activity 3 comments · opened Jun 12, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

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.

  1. Expose limit reporting: current usage percentage and reset time for both the session and weekly windows, available to the model and to hooks.
  1. 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" />

View original on GitHub ↗

3 Comments

eltonylfgi-blip · 1 month ago

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_limits locally. Two opt-in helpers then expose that state to automation:

node hooks/usage-guard-check.mjs --max-5h 80 --max-weekly 85 && my-agent

The check exits 1 before new work starts when a threshold is crossed, and usage-guard-sessionstart.mjs adds a short quota/pace line at SessionStart. 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.

wshallwshall · 1 month ago

+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.

bcherny collaborator · 14 days ago

Part of this exists today: status line scripts receive a rate_limits object with five_hour and seven_day windows, each with used_percentage and resets_at, so you can render usage or trigger your own logic from the status line script (Pro/Max only). /usage shows 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