Error messages

Lower-priority mode isn't available right now.

Lower-priority mode isn't available right now.

You hit your session limit, you reach for /low-priority, and Claude Code answers with one flat sentence and no reason:

Lower-priority mode isn't available right now.

There's no documentation page to check, because the command is hidden from the command list and doesn't appear in the published reference. So we went and read the strings in the shipped binary instead, version 2.1.269. What's in there turns out to answer the question fairly precisely, and the useful part is what the message rules out.

What the message rules out

Claude Code has separate sentences for the two reasons you'd guess first, and it prints them instead of this one when they apply.

If you've used up the week's allowance, you get a line that says so and tells you when it comes back:

You've used this week's lower-priority allowance. Lower-priority mode is offered again after your weekly limit resets.

If you're in the cool-off that follows a long wait for capacity, you get a line with a time on it:

Lower-priority mode is taking a break until 4:15 PM, after waiting too long for spare capacity. Try /low-priority again then.

The bare sentence is what's left when neither branch matched. In the code it's the final return after both of those checks, so seeing it means you haven't run out and you aren't in a cool-off. Which is worth knowing, because both of those would have been reasonable guesses and both are wrong.

What has to be true before the mode is offered

The check that decides whether Claude Code will offer lower-priority mode tests seven things at once, and every one of them has to pass. Renaming the minified variables, it comes to this:

• the rate-limit status the server sent back is one the client recognizes
• that status carries lowPriorityOffer: "treatment"
• there's a real reset time attached, and it's in the future
• the week's lower-priority allowance isn't spent
• you're not inside a cool-off
• lower-priority mode isn't already running
• the client-side config for the feature has enabled set to true

There's a second way in, for resuming a mode you stopped yourself, and it re-tests most of the same list plus one more: the stopped session's reset time has to still be in the future.

Two items there are yours to affect. You can stop the mode if it's already on, and you can be at a live limit rather than a stale one. The rest are decided by the server's answer and by a config blob the client fetches.

The likeliest reason, and it isn't your account doing anything wrong

lowPriorityOffer: "treatment" is the condition to look at. That value comes down from the server with the rate-limit status, and the telemetry around it records an arm and an in_experiment field. This is a staged rollout, and the client is told which side of it your account is on. If you're not on the treatment side, the offer never appears, and the fall-through sentence is what you get when you ask for it anyway.

The feature's client config is the other gate. Claude Code reads a remote config blob, keyed tengu_toasty_breeze, and the mode is live only when that blob says enabled is exactly true. A missing blob reads as off. Every user-visible line the mode prints can be overridden from that same blob, which is why the wording you see may not match the wording quoted here.

So the honest answer to "how do I fix it" is that mostly you don't. There's no setting to flip and no flag to pass. What you can do is make sure you're on a current version, since the gate and the copy both arrive with the client, and try again on a later limit, since the status is re-sent every time you hit one.

What lower-priority mode does when it is available

Worth knowing what you're missing. When the offer does appear and you take it, Claude Code prints:

Continuing now at lower priority until your limit resets at 6:00 PM. Your weekly limit still applies, and responses may pause while waiting for spare capacity. Run /low-priority to stop.

You keep working immediately. Requests wait for spare capacity instead of jumping the queue, so replies arrive when they arrive, and the status line reads Lower priority until {reset} with a percentage of your allowance left beside it. While a request is waiting you'll see Working at lower priority · waiting for capacity.

The waiting is bounded by two numbers the server can set per response. Claude Code retries every 20 seconds by default, and it won't accept a server-supplied value below 5 seconds or above 10 minutes. It gives up on a single request after 20 minutes by default, clamped to between one minute and six hours. Give up that way and you land in the cool-off, which defaults to 10 minutes and can be set as high as a day.

Every message this feature prints

Copied from the binary rather than retyped, so you can match yours against the list. The {} parts are filled in at runtime.

• /low-priority to continue now at lower priority · uses your weekly limit, the offer itself
• Continuing now at lower priority until your limit resets at {time}. Your weekly limit still applies, and responses may pause while waiting for spare capacity. Run /low-priority to stop.
• Lower-priority mode is back on until your limit resets at {time}. and the same tail, when you resume a mode you'd stopped
• Working at lower priority · waiting for capacity
• Lower priority until {reset}, in the status line, with {percent} allowance left
• You've used this week's lower-priority allowance. Lower-priority mode is offered again after your weekly limit resets.
• Lower-priority mode is taking a break until {time}, after waiting too long for spare capacity. Try /low-priority again then.
• Lower-priority mode isn't available right now.
• Lower-priority mode is off. New messages wait for your usage limit as usual; run /low-priority again to turn it back on.

The mode also ends on its own for reasons it doesn't always announce. The code enumerates them: your limit resetting, you stopping it, clearing the conversation, switching accounts, buying extra usage, hitting the weekly limit, spending the allowance, the feature being turned off, your account becoming ineligible, the limit moving, and waiting too long.

The neighboring command, which has its own version of this

/limit-reset clears the five-hour session limit outright, once a week, and it prints a near-identical refusal: A session-limit reset isn't available right now. Same shape, same kind of gate, and it means the same thing there: the reset wasn't offered, rather than used up or broken. We wrote that one up separately in what /limit-reset actually resets.

If the work can wait, the setting for continuing automatically when a limit resets costs nothing and is on by default. That's the one to lean on while the other two are gated.