There is no /limit-reset — the hidden command is /rate-limit-options

You have just hit You've hit your session limit · resets 3:45pm, and somewhere in a search result you saw that /limit-reset clears it. Before you spend twenty minutes hunting for the magic keystroke: the official docs describe the limit-recovery surface in three separate places, and no reset command appears in any of them. What does exist — and is genuinely worth knowing, because it is deliberately hidden from the / menu — is /rate-limit-options.

What the docs actually say

The commands reference introduces its table as the list of "all the commands included in Claude Code." /limit-reset is not in it. That alone would be weak evidence, except for two details that make it strong:

• The docs do document commands hidden from the / menu. /heapdump and /rate-limit-options are both marked "Hidden from the command menu; type it in full." Being undiscoverable in the UI is not a reason a command would be missing from the reference.
• The docs do document plan-gated and platform-gated commands. A note says availability "depends on your platform, plan, and environment," and names /desktop and /upgrade as examples. Eligibility gating is not a reason either.

The two mechanisms the rumour leans on to explain its own absence — it is hidden, it is gated — are exactly the mechanisms the docs already handle in the open.

Meanwhile the errors page states the behaviour directly: Claude Code "blocks further requests until the reset time shown in the message," then enumerates what you can do about it. Nothing in that list resets anything.

The real menu at a usage limit

Wait-and-continue is the closest real thing

Check your version before you go looking for this one. The wait is recent: the interactive-mode page says "Requires Claude Code v2.1.234 or later," and the errors page is blunter — "Before v2.1.234, Claude Code didn't offer this wait." On an older build the menu is still there and the wait row is not, which is its own way of making you think a command is missing.

On v2.1.234 or later, on a claude.ai subscription in an interactive session, Claude Code holds the session open and resumes your task itself after the reset. That is on by default, and while it waits a line at the bottom of the session reads Usage limit reached · continuing automatically at 3:45pm · esc to cancel. It resumes early if you add credits with /usage-credits, sign back in after /upgrade, or switch models mid-wait and usage turns out to be available again.

Where it is off the table is worth memorising, because that is exactly where people go looking for a reset command:

• Background sessions and -p runs get no wait row at all.
• API keys and cloud providers have no reset to wait for — usage there is metered per request.
• Claude Code will not start a wait on its own when the reset is more than 24 hours out, which is normal for a weekly limit.
• Remote Control and agent-team teammate sessions do not start one automatically, but you can run /rate-limit-options yourself and pick the wait.

What is unverified here, and what would settle it

Nobody has typed /limit-reset at a limited account for this entry. It is a docs-based refutation, not an experiment. Two things would settle it:

1. Grep your installed CLI bundle for the literal string. If rate-limit-options is present and limit-reset is absent, the rumour is dead for your version.
2. Type it at a real session-limit wall and read what comes back. Unknown command is the expected answer.

The original claim traces to a single SEO-shaped outlet relaying screenshots — an outlet that reported the command declining on its own test accounts. A command that fails for the people reporting it, appears in no changelog, and contradicts a docs list that already documents both hidden and gated commands is best read as a garbled retelling of the hidden command that does exist. /rate-limit-options fits the description almost exactly: a limits command you cannot find in the menu, that you have to type in full, that offers a path around waiting out a reset.

If a future version adds one

Nothing here says such a command can never exist. If it ships, it will appear in the commands table the way /heapdump does, and /rate-limit-options is where its row would be linked from. Re-grep the docs before believing a second-hand report — that grep takes under a second and is the entire basis of this entry.

Checkpoint

1. You hit You've hit your Sonnet limit. Which command in the table restores your ability to work, and why does the same move fail against You've hit your weekly limit?

   ›Show answerAnswer

   /model. A family limit applies to that family only, so switching outside Sonnet gets you working again immediately.

   It fails on a weekly limit — and on a session limit — because those are shared across every model, leaving no family to switch to. Read the message to see which one you hit, then reach for /rate-limit-options, /usage-credits, or the wait instead.

2. /rate-limit-options does not appear when you type / and scan the menu. Is that evidence it is unavailable on your account? What does the docs' treatment of /heapdump tell you?

   ›Show answerAnswer

   No — it is hidden deliberately. The commands reference at code.claude.com/docs/en/commands marks both /rate-limit-options and /heapdump "Hidden from the command menu; type it in full," so absence from the menu says nothing about availability. Type it out and see.

   That is also what sinks the /limit-reset rumour. Since the docs list hidden commands and plan-gated ones openly, neither excuse explains why a real reset command would be missing from a table the reference presents as the complete set. What genuinely gates /rate-limit-options is a claude.ai subscription, and its wait-and-continue rows need v2.1.234 or later.

3. What would you run to check whether your installed version knows the string limit-reset at all?

   ›Show answerAnswer

   Grep your installed CLI bundle for the literal string. If rate-limit-options is present and limit-reset is absent, the rumour is dead for your version — read what your own grep returns rather than a second-hand retelling of it.

   The other check is typing /limit-reset at a real session-limit wall, where Unknown command is the expected answer. Keep in mind this entry is a docs-based refutation rather than an experiment, so a staged rollout that never reached the reference would slip past it.