Source Intelligence

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 releases Home olderv2.1.248

Claude Code v2.1.250

15 entries read diff v2.1.248 → v2.1.250 Markdown
How it breaks down
You'll notice9Under the hood6

Five entries land the reconnection rework for live artifact watches without switching it on. Lease mode, the flag tengu_slate_lantern_ember, defaults to off, so a stock build always takes the long 120 to 240 second backoff tier once a stall repeats rather than the two-tier behaviour the code describes. Failed watch startups can now be classed as temporary outages, meaning a retryable server status or a request that hung at least 10 seconds with no reply, and routed to the slow retry schedule. Close reasons written as cf_mitigated_<status> or upgrade_rejected_<status> are decoded back into an HTTP status and a Cloudflare flag, where the previous build only wrote those strings. Two end-of-watch notices, one for giving up after repeated failures and one for live updates being turned off, are sent passively with their own advice text.

A disconnect classified as a load shed, meaning a Cloudflare-mitigated close or a 5xx, 429 or 408 upgrade rejection, now deletes the cached token lease instead of carrying it through up to three failed dials, and counts as a stall for backoff purposes. A watch judged to be stalling for a long time waits 120 to 240 seconds between attempts instead of 30 to 60, so a persistently broken watch stops hitting the server every half minute. Giving up is no longer fixed at 30 minutes: each stall run picks its own deadline of 30 minutes plus up to 15 more, so sessions caught in a single outage do not all abandon at once. The notice sent when reconnection is abandoned now says the watch will not reconnect on its own, and arrives passively rather than as an interrupting task notification.

An error handler in the path that arms a live subscription reported an outer captured value rather than the exception it had just caught, which lost the real error. It now passes the caught error through.

Find
Flag state
Pick an entry · j / k steps through
2 entries

What probably matters to you

Anything you can use today, anything that visibly changes, and anything worth poking at. One line each, open for detail.

You'll notice
Useful3 Signal4
Artifacts Notable not in their notes

Long-stall backoff band and randomised give-up window for live watches#

Stalled watches now wait 2-4 minutes between retries and give up at a random point between 30 and 45 minutes.

Feature flag
tengu_slate_lantern_ember On for this account, and not off by default

The flag server returned on for the one account this site reads, and nothing in this release compiles it off by default. The compiled default is shown below, and says which it is when we cannot read one: a fifth of gates compile in a string or a number rather than on or off, and most published releases have no gate table behind them at all. No client can see what the server returns for your account.

This account: on · anonymous baseline: on · compiled default in v2.1.250: on

Read once, for one account on one subscription tier, against v2.1.250. It isn't a statement about your account. What a flag value here can and cannot tell you

tengu_slate_lantern_ember
What

Repeated reconnect stalls now back off 2 to 4 minutes instead of 30 to 60 seconds, and a stalling watch gives up somewhere between 30 and 45 minutes rather than at exactly 30, so clients in one outage do not all abandon at the same moment. The long band is picked when a stall repeats and either the connection was closed by Cloudflare mitigation or lease mode is off, and lease mode (tengu_slate_lantern_ember) defaults to off, so a stock build takes the long band.

Details
  • New timing constants: longStallMinMs: 120000, longStallMaxMs: 240000, stallOutJitterMs: 900000.
  • Give-up deadline is now per run: maxStallMs plus a random amount up to the jitter.
  • A counter event fires once per stall run carrying a startup flag and, when known, http_status.
  • The numbers are compiled in and copied into state; nothing in this build overrides them remotely.
Evidence

stallOutJitterMs, stall_run_started

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

You'll notice
Useful2 Signal4
Artifacts Notable not in their notes

Which stall backoff tier is used depends on the lease-mode flag#

Repeat stalls take the long 2-4 minute retry tier because lease mode is off in a stock build.

A lease-aware short-retry tier exists but lease mode (tengu_slate_lantern_ember) falls back to off, so stock builds never use it.

Feature flag
tengu_slate_lantern_ember On for this account, and not off by default

The flag server returned on for the one account this site reads, and nothing in this release compiles it off by default. The compiled default is shown below, and says which it is when we cannot read one: a fifth of gates compile in a string or a number rather than on or off, and most published releases have no gate table behind them at all. No client can see what the server returns for your account.

This account: on · anonymous baseline: on · compiled default in v2.1.250: on

Read once, for one account on one subscription tier, against v2.1.250. It isn't a statement about your account. What a flag value here can and cannot tell you

tengu_slate_lantern_ember
What

The reconnect delay picker now has two tiers. The long one, 120 to 240 seconds, is used on the second and later attempts of a stall run when the close was Cloudflare-mitigated, lease mode is off, there is no lease, or the lease will not outlive the next attempt. Lease mode is tengu_slate_lantern_ember with fallback false, so without a remote value every repeat stall takes the long tier.

Details
  • Short tier remains 30 to 60 seconds.
  • The timing table is a plain in-bundle constant, never reassigned, so the numbers are not server-tunable.
Evidence

longStallMaxMs: 240000,

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

Were these the right ones to put at the top? 0 answered
Below the fold

Everything else

Smaller changes and internals, grouped as the pipeline found them. Nothing is dropped, it is only further down.

4 entries

Improvementsopen

You'll notice
Useful3 Signal2
Artifacts

Load-shed disconnects drop the reused token lease#

Overload-related disconnects now back off and fetch a fresh token instead of reusing a stale one.

What

A disconnect classified as a load shed, meaning a Cloudflare-mitigated close or a 5xx/429/408 upgrade rejection, now both counts as a stall for backoff purposes and deletes the cached token lease instead of keeping it through up to three failed dials.

Details
  • The shed classification is computed before the stall check in the socket lifecycle handler.
Evidence

...(Ne && { shed: !0 }),

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

You'll notice
Useful2 Signal2
Artifacts

Persistently broken live watches back off to minutes#

A repeatedly failing live watch now retries every few minutes instead of every half minute.

What

When a stall is judged long-running, the retry delay is drawn from 120 to 240 seconds rather than 30 to 60, so a live artifact watch that keeps failing stops hammering the server every half minute.

Details
  • The long class is chosen on a Cloudflare-mitigated close, when lease mode is off, or when the lease is absent or about to expire.
Evidence

longStallMinMs: 120000,

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

You'll notice
Useful2 Signal2
Artifacts

Giving up on a stalled watch is spread across a 15-minute window#

Stalled watches now give up somewhere between 30 and 45 minutes, not all at once.

What

A stalled watch used to be abandoned at exactly 30 minutes. Each stall run now picks its own deadline of 30 minutes plus a random amount up to 15 more, so sessions caught in one outage do not all give up together.

Details
  • The new jitter constant is stallOutJitterMs: 900000.
  • The window deciding whether a fresh stall continues the previous run also widened, and now accounts for the long backoff band and twice the 15 second request timeout.
Evidence

stallOutJitterMs: 900000,

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

You'll notice
Useful2 Signal1
Artifacts

"Connection lost" notice reworded and made passive#

When a live watch gives up reconnecting, you get a quieter note instead of an interrupting alert.

What

When reconnection is abandoned, the notice the model receives now says the watch will not reconnect on its own and is delivered passively rather than as an interrupting task notification.

Details
  • The notifier helper takes an options object with advice text and a passive flag instead of a trailing string.
  • What the passive flag does further down the notification queue is not visible from this change.
Evidence

the live connection kept failing and reconnecting has stopped, it will not reconnect on its own

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

1 entry

Bug Fixesopen

You'll notice
Useful2 Signal1
Elsewhere

Wrong value reported when arming a live subscription failed#

When a live subscription fails to start, the error you see is now the actual failure.

What

An error handler in the live-subscription arming path reported an outer captured value instead of the exception it had just caught, so the real error was lost. It now passes the caught error.

Evidence

armLiveSubscription: late-park fall-through lost its park

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

3 entries

In Developmentopen

You'll notice
Useful3 Signal3
Artifacts

Failed live-watch startups are treated as temporary outages and retried on the slow schedule#

Live artifact watches that fail to start from a server hiccup now retry on the patient schedule instead of burning attempts.

Feature flag
tengu_slate_lantern On for this account, and not off by default

The flag server returned on for the one account this site reads, and nothing in this release compiles it off by default. The compiled default is shown below, and says which it is when we cannot read one: a fifth of gates compile in a string or a number rather than on or off, and most published releases have no gate table behind them at all. No client can see what the server returns for your account.

This account: on · anonymous baseline: on · compiled default in v2.1.250: on

Read once, for one account on one subscription tier, against v2.1.250. It isn't a statement about your account. What a flag value here can and cannot tell you

What

When a live artifact watch fails to start, Claude Code now decides whether the failure looks like a transient server problem rather than a permanent one, and routes it to the slow stall-style retry instead of the fast consecutive-failure backoff. A failure counts as a temporary outage if the server replied with a retryable status, or if the request produced no reply at all and hung for at least 10 seconds. Neither of these markers existed on this error path in 2.1.248.

Details
  • The retryable-status test returns true for HTTP status 500 or above, 429 and 408; such a status attaches an unavailable marker to the startup response.
  • A startup error code of boot_request_error attaches a noAnswer marker, meaning the request errored out with no reply.
  • The startup builder records the time just before the request is issued, so a hung startup can be measured; a noAnswer result plus elapsed time of at least stallThresholdMs, the reconnect timing default compiled at 10000 ms, counts as unavailable.
  • The failure helper gained unavailable and httpStatus options and passes a stalled flag plus the HTTP status into the reconnect scheduler.
  • All of this sits inside the live-watch feature, which is off unless the tengu_slate_lantern flag is switched on for your account.
Evidence

boot_request_error, ...(i.errorCode === "boot_request_error" && { noAnswer: !0 }),

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

You'll notice
Useful3 Signal3
Artifacts

Watch-ended messages can be delivered without interrupting the model#

When a watch gives up or is switched off, you get a quieter notice that explains it instead of interrupting.

What

Two end-of-watch notices, one after repeated connection failures and one when live updates get switched off, are now sent passively and carry their own advice text rather than the default "watch it again if you still need that". The give-up notice tells the agent the watch will not reconnect on its own; the flag-off notice says there is nothing to re-watch. Ordinary stop and other-org notices are unchanged.

Details
  • The announcer's final argument changed from an advice string to an options object with advice and passive.
  • Both advice strings are new in this build.
Evidence

{ advice: Un, passive: !0 },, there is nothing to re-watch while live updates are switched off

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

Under the hood
Useful2 Signal3
Artifacts

Cloudflare and load-shed disconnects are recognised and reported#

Claude Code can now tell when a watch was cut off by traffic protection or server overload rather than a real error.

What

Connection close reasons of the form cf_mitigated_<status> or upgrade_rejected_<status> are now decoded back into an HTTP status and a Cloudflare flag. The previous build only wrote those strings. A close counts as a load shed when the status is 5xx, 429 or 408, or when Cloudflare mitigated it.

Details
  • Failure telemetry now carries shed, http_status and cf_mitigated fields; before it could only report a fixed stalled marker.
  • A shed close is folded into the stalled decision and no longer clears the cached token lease.
Evidence

cf_mitigated, /^(cf_mitigated|upgrade_rejected)_(\d{1,3})$/

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

5 entries

Internal Changesopen

Under the hood
Useful2 Signal2
Elsewhere

Shared test for transient HTTP statuses#

One rule now decides which server errors count as temporary, so retries behave consistently.

What

One predicate now decides what counts as a temporary outage: any status 500 or above, plus 429 and 408. It marks watch-token startup responses as unavailable and, with the close-code decoder, decides whether a failed live subscribe is a retryable stall.

Evidence

return e !== void 0 && (e >= 500 || e === 429 || e === 408);

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

Under the hood
Useful2 Signal1
Elsewhere

Version bump to 2.1.250#

The version stamp moves to 2.1.250.

What

The build stamp advances to 2.1.250 with a new build time and commit hash. It feeds the user agent and metric keys; nothing else changed alongside it.

Evidence

VERSION: "2.1.250", GIT_SHA: "2f71b9f41af67bfcea88aef7a9f8a0d406825b99", 2f71b9f41af67bfcea88aef7a9f8a0d406825b99

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.

Under the hood
Useful1 Signal0
Artifacts

Request timeout hoisted into a shared constant#

Two 15-second timeouts became one shared value; timing is unchanged.

What

The two hard-coded 15 second timeouts on the artifact read and the watch-token renew request became one named constant, which also feeds the stall-run window calculation. Same values, so nothing changes for users.

Evidence

handshakeDeadlineMs, Wxt = 15000;

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

Under the hood
Useful1 Signal0
Artifacts

Lease-renewal miss telemetry unchanged#

Lease-renewal failure reporting works the same; only variable names moved.

What

The renewal-miss event still reports the HTTP status or "no_response" and clears the renewable marker; only local variable names moved around it.

Evidence

` renew_miss_${ee.status ?? "no_response"} `

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

Under the hood
Useful1 Signal0
Elsewhere

Build stamp repeated across the bundle#

The build stamp is copied throughout the bundle and all copies updated together.

What

The same build-constants object is inlined at roughly 66 places, and all of them updated together. The two builds are stamped under two hours apart on the same day.

Evidence

BUILD_TIME: "2026-08-27T21:19:23Z"

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.

Verbatim
Official · Anthropic

Anthropic’s official release notes

Published verbatim by Anthropic for v2.1.250. Text is unmodified from the upstream changelog. Everything else on this page came out of the bundle instead, which is why the two lists don't match.

  • Bug fixes and reliability improvements
System prompt

No change to the system prompt since v2.1.248.

Claude Code, interactive mode

Documentation

What the docs did around this release

428 documentation changes were recorded within 24 hours either side of this release, nearest first. The closest 12 are below. They're here because they happened near this release in time. That's not a claim that this release caused the edit, or that the page documents anything in it.

Every time above is when this site's poller recorded the change, which is up to half an hour after the edit on an ordinary read and up to a day after it on a full sweep. Upstream's own edit time is used instead wherever a capture carries one. None of these do.

Switches

Every name in this release

The 1 literal strings found in the bundle, with the number of entries that name each one. Picking one searches for it. A name is here because this build's code mentions it, which is not the same as it working or being finished.

Settings and names in the code