Follow Discord
Sweep 28 Sep 2026 · 18:16Z Build v2.1.284 505 read Stable v2.1.277 Latest v2.1.284 Next v2.1.284 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.284 ·

Usage checks stop retrying after a rejected token or a rate limit

After a rejected token or a rate limit, Claude Code now stops re-asking the usage endpoint for a while, and retries once after a token refresh

You'll notice Improvements
JSON All of v2.1.284
You'll noticeTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
Usage & LimitsArea: what it touches
ImprovementsKind: in v2.1.284,
ImprovementsSection of the release
What

Claude Code asks a server how much of your usage allowance you have used. It now remembers two kinds of refusal for each credential (the sign-in token it sent):

  • rejected credentials: a 401 answer, or a 403 answer carrying an Anthropic error
  • rate limits: a 429 answer, or a 403 answer, which means too many requests in a short time

While a refusal is remembered, later usage checks fail straight away without contacting the server. The error says how long ago the server answered and how long before Claude Code asks again. The wait follows the server's Retry-After value, up to a maximum. This remembering is controlled by a server-side setting that is on unless it is switched off remotely.

Separately, a 401 answer that arrives while another request is refreshing your sign-in token now waits for that refresh and is sent once more with the new token. Failures are now sorted into network errors, 401, 403, 429 and other HTTP errors.

Why

Once the server has refused a token or rate-limited Claude Code, repeated requests would only fail again. Waiting avoids hammering the endpoint and cuts down on bursts of failed retries around a token refresh.

How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtIt looks like the re-send after a token refresh runs even when the server-side setting is off, but this is not confirmed.

See this entry in the whole of v2.1.284 →

Feedback