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.250 Home All releases ←olderv2.1.248
Claude Code v2.1.250

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

You'll notice
Useful3 Signal3
Artifacts

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.

See this entry in the whole of v2.1.250 →