Source Intelligence
Follow Discord

DisclaimerUnofficial, and not affiliated with Anthropic. Nearly all of this is read straight out of what ships: npm bundles, captured prompts, published docs. Anthropic's own notes go in verbatim, marked as theirs. The rest is my reading, and every entry carries the strings behind it. If one looks wrong, vote it down and say why.

← All of v2.1.234 Home All releases ←olderv2.1.233 v2.1.235newer→
Claude Code v2.1.234

Sessions can wait out a claude.ai usage limit and continue on their own

Use it now
Useful5 Signal4
Usage & Limits Notable not in their notes

Your session can now wait out a usage limit and pick the task back up by itself.

autoContinueAtUsageLimit/rate-limit-options
What

When a claude.ai usage limit stops your session, Claude Code can now hold the session open, wait for the limit to reset, and resume the interrupted task by itself. It is controlled by a new autoContinueAtUsageLimit setting that defaults to on, is also offered as a choice in the /rate-limit-options dialog when the setting is off, and announces itself with notifications when it arms, fires, or gives up. A set of specific cancellation messages covers every way the wait can end, so you always know whether the task will restart on its own.

Details
  • On resume the session sends itself the prompt "Your claude.ai usage limit has reset. Continue the task you were working on when the limit was reached; do not repeat work that is already complete."
  • The /config row is labelled "Continue automatically at usage limit" and described as: when a claude.ai usage limit stops your session, wait for the limit to reset and continue the task automatically; when off, the limit dialog offers the wait as a choice instead.
  • That /config row is consent-gated and appears only when the setting is unset or came from your own user settings; the underlying schema entry is a boolean defaulting to true.
  • The /rate-limit-options menu gains an auto-resume choice plus a cancel choice to disarm it, with the wording varying by what is known: one label when a reset time is available, one when the limit has already passed, one when neither, including "Wait here, then continue automatically when the limit resets". The menu entry is built per render rather than behind its own named flag.
  • Confirmation text warns the wait may still pause for permission prompts, and the footer shows a cancellable notice with the reset time when known: Continuing automatically when your limit resets · esc to cancel.
  • Notifications include "Usage limit available — Claude is continuing your task" and "Automatic continue was turned off — the task will not resume on its own", added as three new entries in the shared notification type list that also drives hook events, so hooks see them too. No gate was found on the notification types themselves.
  • Stop cases cover exceeding the wait horizon, a dropped continuation, and hitting the limit repeatedly; there is a cap on re-arming, jitter before firing, and a "stale" state for when the machine slept through the reset time.
  • The wait cancels on Ctrl+C, escape, switching accounts, backgrounding, relaunch, plain exit, and handing off to Claude Desktop or to the cloud, each with wording naming that specific departure and stating you can send a prompt after the reset to continue, for example Automatic continue cancelled · Claude Code exited during the wait, so the task will not resume on its own when the usage limit resets (send a prompt after the reset to continue) and "Automatic continue cancelled · Claude Code relaunched during the wait…". A handoff message also explains that a handoff cancelled the automatic continue and points back at /rate-limit-options.
  • On exit the transcript runs through a handoff step before the session-end path (process_exit), and that handoff is also registered as a late-exit callback so it still runs on abrupt shutdowns.
  • Arming happens only in a normal interactive terminal session, not in print mode, and rate-limit responses from the server now carry the limit details the main loop uses to decide whether to arm; the internal usage-limit object gained a rejection event this machinery subscribes to.
  • The remote gate tengu_marble_heron can switch the whole feature off, but its fallback is an empty value and the enabled check treats an absent value as on, so it is live unless the server says otherwise.
  • Telemetry: tengu_quota_auto_resume_armed, _fired, _cancelled, _stale, _stale_resumed (recording how many times the wait was rearmed and how long it lasted), _offer_armed, tengu_quota_auto_resume_setting_changed, tengu_rate_limit_options_menu_select_auto_resume, and tengu_rate_limit_options_menu_cancel_auto_resume.
Evidence

Wait here, then continue automatically when the limit resets, Continuing automatically when your limit resets · esc to cancel, quota_auto_resume_disabled, label: "Continue automatically at usage limit", autoContinueAtUsageLimit, tengu_quota_auto_resume_armed, When a claude.ai usage limit stops your session, wait for the limit to reset and continue the task automatically. When off, the limit dialog offers the wait as a choice instead., Continue automatically at usage limit, Automatic continue cancelled \xB7 Claude Code exited during the wait, so the task will not resume on its own when the usage limit resets (send a prompt after the reset to continue)

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Related

Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.

See this entry in the whole of v2.1.234 →