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 ·

The compression decision is rebuilt from a one-liner into a full decision path

The gzip decision now records exactly why it skipped, though compression stays off without a server value.

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

The compression check became a full decision path with named skip reasons, but both gates still default off.

What

In 2.1.235 this was a single expression checking one environment variable and one flag. It is now a function that returns a reason for every skip: not_bun_runtime, below_min_size for bodies under 4096 characters, non_string_body, and the transport reasons unix_socket, proxy, mtls, custom_ca. Both gates default to off, so absent a server value nothing is compressed.

Details
  • tengu_atomic_ocean and tengu_gzip_request_bodies are OR'd; CLAUDE_CODE_GZIP_REQUEST_BODIES overrides either way, and forcing it on still respects the in-process kill switch.
  • New this release: a 400, 403 or 415 rejection of a compressed body from an Anthropic response causes an uncompressed resend and turns compression off, optionally saved to the global config key gzipRequestBodiesLatchedOff with a timestamp and status, honoured for 7 days and then cleared with tengu_gzip_request_body_latch_cleared.
  • Request telemetry now carries requestBodyEncoding, gzipSkipReason and gzipFallbackStatus.
Evidence

not_bun_runtime

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