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.236 ·

Gzipped API request bodies, gated off, with a retry-and-latch kill switch

Requests to the API can be gzip compressed, but both switches default off so nothing compresses.

Nothing to try yet Notable In Development
JSON All of v2.1.236
Nothing to try yetTier: how much it should matter to you
2Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
InternalsArea: what it touches
In DevelopmentKind: in v2.1.236,
What probably matters to youSection of the release

Gzip request-body compression is built with per-request decline reasons and a fallback latch, gated by two remote flags that both default off.

What

Claude Code can now compress outgoing API request bodies with gzip, decided per request by a helper that records exactly why it declined. It only applies on the Bun runtime, only to string bodies of at least 4096 characters, and never over unix sockets, proxies, mTLS or custom CA setups. Both remote gates default to off, so nothing is compressed in this build without a server-side value, and a rejected compressed request falls back to sending uncompressed and stops compressing afterwards.

Details
  • Enabled by either of two remote flags, tengu_atomic_ocean or tengu_gzip_request_bodies, both falling back to false.
  • CLAUDE_CODE_GZIP_REQUEST_BODIES overrides the flags: set true it forces compression on unless the kill switch has already tripped, set false it forces it off.
  • Skip reasons recorded per request are env_off, not_bun_runtime, non_string_body, below_min_size, latched_off, flag_off, and the transport reasons unix_socket, proxy, mtls and custom_ca.
  • A compressed request answered with 400, 403 or 415 from what looks like an Anthropic or Cloudflare hop is resent uncompressed, and compression is switched off for the rest of the process.
  • When the rejection looks like it came from a non-Anthropic intermediary and the uncompressed retry succeeded, the off state is written to settings as gzipRequestBodiesLatchedOff so later sessions skip compression too.
  • The saved off state is honoured for about 7 days and then cleared, and per-session state tracks whether it is currently in effect.
  • Telemetry events are tengu_gzip_request_body_fallback for a rejected compressed request and tengu_gzip_request_body_latch_cleared when the saved switch expires, alongside per-request outcome reporting.
Evidence

tengu_atomic_ocean, return ((e.latchedOff = !0), (e.persistedLatchInEffect = !0), !0);

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

Read from
Feature flag
tengu_gzip_request_bodies 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.236: not a boolean we can read

Read once, for one account on one subscription tier, against v2.1.236. 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 on for tengu_atomic_ocean, 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_atomic_ocean, 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_atomic_ocean

See this entry in the whole of v2.1.236 →

Feedback