Stale-config detection and delayed refetch sit behind tengu_expressive_whistle, whose fallback is off.
New code compares a version marker the server returns on each API response against the one attached to the cached startup configuration, and if they differ it schedules a delayed refetch. It is gated on tengu_expressive_whistle, whose built-in fallback is off, so with no remote configuration nobody sees this.
- The marker arrives in an
x-cc-atis-currentresponse header; the caller in the API path already passes response headers in, so the feature is fully wired. - Outcomes are reported through the new
tengu_client_data_stale_refetchevent asskipped_converged,fetch_failed,fetched_convergedorfetched_pins_differ. - A second guard requires an internal eligibility check that lives in a chunk not shipped in this bundle.
- Refetches wait at least 300,000ms plus up to 180,000ms of random jitter.
[Bootstrap] Server ATIS pin differs from cached clientData; refetching
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
tengu_expressive_whistle Not enough to sayNothing 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
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.
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.
New in this build: tengu_expressive_whistle