Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.246 ·

Cloud sessions can pull a server-built memory context into the system prompt, off in this build

Cloud sessions can fetch a server-built memory block into the system prompt, off in this build.

Nothing to try yet In Development
JSON All of v2.1.246
Nothing to try yetTier: how much it should matter to you
2Useful: my rating, 1 to 5
0Signal: worth watching, 1 to 5
MemoryArea: what it touches
In DevelopmentKind: in v2.1.246,
In DevelopmentSection of the release

Server-prepared memory context appended to the system prompt requires a remote entrypoint and tengu_misty_anchor, which falls back to false.

What

New machinery lets a cloud session fetch a block of text prepared by the session host and append it to the system prompt before the conversation starts. It is off here: it requires a remote entrypoint, an auth check, and the tengu_misty_anchor flag, whose in-source fallback is false. Nothing in a normal local run fetches anything or changes the prompt.

Details
  • Fetches GET /memory_context from the session host with session-JWT auth, ETag revalidation via If-None-Match, a 10 second timeout and a 256KiB cap on the returned content.
  • The payload must be {version, content}; malformed responses are rejected.
  • Prompt assembly waits up to 2000ms for the fetch before assembling, then appends the content as an extra system-prompt block.
  • Handles 204 (no context), 304 (unchanged) and 429/503 (not built yet) distinctly.
  • Restricted to the remote_cowork, remote_cowork_trigger, remote_api and remote_trigger entrypoints.
  • Emits cowork_memory_context_fetched, _none, _not_built, _gated and _malformed.
  • None of this existed in 2.1.245.
Evidence

cowork_memory_context_fetched, cowork_memory_context_gated

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

Read from
Feature flag
tengu_misty_anchor Not enough to say

Nothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.

This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.246: off

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

What has happened since
Flag reading moved The flag server now returns off for tengu_misty_anchor, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
Flag reading moved The flag server now returns nothing at all, having stopped carrying it for tengu_misty_anchor, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.

See this across every release →

How sure we are
One source agreesOne thing we can check says the same as this entry.
The name it cites is new in this buildNew in this build: tengu_misty_anchor

See this entry in the whole of v2.1.246 →

Feedback