Flag values can be pinned for the life of the process, and a new pinned flag appears / Claude Code v2.1.248

Under the hood

Useful2 Signal3

Internals Notable

Some feature flags now stay fixed for the whole session, including a new one that is on.

Feature flag

tengu_slate_anchor Gate removed from the code

This release deleted the gate from the code while it was still reading on for the account this site reads, so the code path no longer asks a flag before running.

This account: on · anonymous baseline: on · compiled default in v2.1.248: not a boolean we can read

tengu_tab_read_sep Off in both readings

The flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.

This account: off · anonymous baseline: off · compiled default in v2.1.248: not a boolean we can read

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

What

Instead of one hand-written cache per flag, there is now a shared map that remembers the first value each flag returned and keeps it for the whole process, so a remote-config change mid-session cannot flip it. Three flags use it, including tengu_slate_anchor, new in this build and compiled on.

Details

Pinned flags: tengu_tab_read_sep (compiled off), tengu_tranquil_fern (compiled on) and tengu_slate_anchor (compiled on).
tengu_slate_anchor is read once inside the dynamic /loop tool's prompt, to ignore cache overage when working out the delay bounds shown to the model.
Compiled values are only the fallback; the live value comes from the server.

Evidence

tengu_slate_anchor

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