Expose session usage-limit state to the model and hooks, with a configurable threshold and automatic post-pause resume

Problem Statement

Today the model and the hook system have no visibility into how much of my plan or session usage has been consumed. When a session reaches its usage limit and pauses mid-task, the model only learns about it indirectly, after the fact. There is no signal at any percentage before the limit is reached, and no signal when the pause lifts and a new session begins. Long-running work gets interrupted with no graceful wind-down, which can leave partial implementations, and picking the work back up afterward means I have to re-orient the model by hand.

Proposed Solution

Two related mechanics:

1. Usage-threshold awareness with a user preference

• Surface the current session or plan usage percentage to the model and to hooks, for example through a dedicated usage hook or an added field on an existing hook.
• Let me configure a threshold and a preferred behavior at that threshold. For example, "at 85 percent, stop starting new work, finish and checkpoint the current step, and summarize what remains."
• The preference would live in settings.json so it can apply per project or globally.

2. Post-pause resume signal

• When a usage pause is lifted and a new session starts, provide a signal, for example a field on the SessionStart hook, telling the model that the prior session ended at a usage limit and that it should resume the previous task.
• Ideally this ships with a standard resume process: at the threshold the harness, or the model on instruction, writes a temporary memory or handoff file describing how to resume and what work remains, and on the next session the resume signal points the model at that file so it continues automatically instead of waiting for me to re-explain.

Alternative Solutions

• Manual handoff file maintained by the model at each milestone. This is what I do today, but it depends on me noticing the limit is near and prompting the model to checkpoint, so it fails exactly when an interruption is unexpected.
• A user-facing usage warning in the UI only, with no signal to the model or hooks. This tells me the limit is close but cannot drive an automated graceful wind-down or an automatic resume.
• Exposing usage to hooks only, without a configurable preference. A hook could inject static guidance, but a configurable threshold and behavior gives me control over the tradeoff between finishing work and conserving budget.

Priority

High for my workflow. Multi-step work that crosses a usage boundary is common for me, and the current abrupt interruption risks partial, unverified changes. Please adjust to your own triage scale as you see fit.

Feature Category

Session and usage management, spanning Hooks (a new usage signal and a SessionStart resume field) and Settings (the threshold and behavior preference in settings.json).

Use Case Example

I am partway through a multi-file refactor that will not finish inside one session. At 85 percent usage the model finishes the file it is on, writes a checkpoint or handoff describing the remaining files and the verification steps, and stops launching new work. The session then pauses at the limit. When the limit resets and I open a new session, the resume signal tells the model the prior session ended at the limit, it reads the checkpoint, and it continues from the next unfinished file without me re-explaining the task. The result is a graceful checkpoint-and-continue instead of a hard stop and a manual restart.

Additional Context

Without a pre-limit signal the work stops abruptly and can leave partial implementations; without a resume signal I pay a re-orientation cost every time a new session starts. A configurable threshold plus a resume flag, ideally backed by the standard temporary-memory-file process described above, would turn a hard interruption into a graceful checkpoint-and-continue. I currently approximate this with a handoff file the model rewrites at each milestone, but that workaround only works when I remember to trigger it. The missing piece is the platform signal itself, both the pre-limit percentage and the post-pause new-session indicator.