claude-code - 💡(How to fix) Fix Feature Request: Token Limit UX — Configurable Threshold Alerts, State Preservation Before Cutoff, and Grace Period Buffer

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Summary

Three related UX improvements to make token limit handling significantly less disruptive, especially for long-running or near-complete tasks.

---

Problem

Currently when a session or usage limit is reached:

1. The only signal is a single warning notification — no configurable lead time
2. Work stops abruptly with no saved state
3. The next session has to re-analyze files from scratch, wasting tokens on context that was already established
4. Tasks that are 90% complete get blocked just as hard as tasks that are 10% complete

---

Proposed Improvements

1. Configurable Threshold Alerts

Allow users (or Claude) to set min/max warning thresholds for token usage — similar to how mobile data plans let you set alerts at 70% and 90%.

• User-configurable thresholds (e.g., warn me at 75% and 90%)
• Claude could proactively surface: "You're at 85% — I estimate 2 tasks remain. Want me to checkpoint now?"
• Applies to session, daily, and weekly limits

Value: Gives users agency and time to wrap up deliberately rather than being surprised by a hard cutoff.

---

2. Automatic State Preservation Before Blocking

Before hitting the hard limit, Claude should automatically write a structured checkpoint — a plan file with:

• Work completed (marked done)
• Work remaining (with enough context to resume without re-analysis)
• Current file state and relevant decisions made

This should be structured (not a raw conversation dump) so the next session can resume from the checkpoint token-efficiently, without re-reading files that were already analyzed.

Value: Eliminates the biggest current pain point — cold restarts that waste tokens re-establishing context that was already built up. Directly improves token efficiency and developer productivity.

---

3. Grace Period Buffer at End-of-Task + Carry-Forward

When a user is near task completion and approaches the limit:

• Allow an optional configurable grace buffer (e.g., 10% overage) with explicit user consent or a setting
• Claude already has a reasonable sense of how much work remains — this information should factor into whether to allow the overage
• If the grace period is used, the next session starts with that 10% already accounted for (rather than resetting to 0%), keeping the system fair while preventing mid-task cutoffs

Value: Avoids the frustrating scenario where a task that is 95% complete gets hard-blocked. A small, consent-gated overage for near-complete tasks dramatically improves the experience for power users doing long sessions.

---

Expected Impact

---

Notes

• Suggestions 1 and 2 are independent and low-risk — either can ship without the other
• Suggestion 3 requires billing/quota logic but the simpler form (just the grace buffer without carry-forward) is implementable standalone
• The state preservation (suggestion 2) is the highest-value change and would benefit all users regardless of their usage tier

---

Submitted by a Claude Code power user via feedback discussion.

Proposed Solution

Summary

Three related UX improvements to make token limit handling significantly less disruptive, especially for long-running or near-complete tasks.

---

Problem

Currently when a session or usage limit is reached:

1. The only signal is a single warning notification — no configurable lead time
2. Work stops abruptly with no saved state
3. The next session has to re-analyze files from scratch, wasting tokens on context that was already established
4. Tasks that are 90% complete get blocked just as hard as tasks that are 10% complete

---

Proposed Improvements

1. Configurable Threshold Alerts

Allow users (or Claude) to set min/max warning thresholds for token usage — similar to how mobile data plans let you set alerts at 70% and 90%.

• User-configurable thresholds (e.g., warn me at 75% and 90%)
• Claude could proactively surface: "You're at 85% — I estimate 2 tasks remain. Want me to checkpoint now?"
• Applies to session, daily, and weekly limits

Value: Gives users agency and time to wrap up deliberately rather than being surprised by a hard cutoff.

---

2. Automatic State Preservation Before Blocking

Before hitting the hard limit, Claude should automatically write a structured checkpoint — a plan file with:

• Work completed (marked done)
• Work remaining (with enough context to resume without re-analysis)
• Current file state and relevant decisions made

This should be structured (not a raw conversation dump) so the next session can resume from the checkpoint token-efficiently, without re-reading files that were already analyzed.

Value: Eliminates the biggest current pain point — cold restarts that waste tokens re-establishing context that was already built up. Directly improves token efficiency and developer productivity.

---

3. Grace Period Buffer at End-of-Task + Carry-Forward

When a user is near task completion and approaches the limit:

• Allow an optional configurable grace buffer (e.g., 10% overage) with explicit user consent or a setting
• Claude already has a reasonable sense of how much work remains — this information should factor into whether to allow the overage
• If the grace period is used, the next session starts with that 10% already accounted for (rather than resetting to 0%), keeping the system fair while preventing mid-task cutoffs

Value: Avoids the frustrating scenario where a task that is 95% complete gets hard-blocked. A small, consent-gated overage for near-complete tasks dramatically improves the experience for power users doing long sessions.

---

Expected Impact

---

Notes

• Suggestions 1 and 2 are independent and low-risk — either can ship without the other
• Suggestion 3 requires billing/quota logic but the simpler form (just the grace buffer without carry-forward) is implementable standalone
• The state preservation (suggestion 2) is the highest-value change and would benefit all users regardless of their usage tier

---

Submitted by a Claude Code power user via feedback discussion.

Alternative Solutions

No response

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

No response

Additional Context

No response