Claude Code gzip requests (2.1.300): about 0.3 s faster on huge prompts, no difference on smaller ones

Claude Code now gzips the conversation it sends each turn, and Anthropic says that makes replies start sooner. In our 64 timed runs, the gain was real but small: on a very large request (about 340,000 tokens) the first token came back about 0.3 seconds sooner (median), and on a 140,000-token request we measured no difference at all.

The noise was much bigger than the gain: the same request took anywhere from 1.6 to 11 seconds to start answering.

Tested on 18 October 2026 with Claude Code 2.1.302, claude -p on a Windows 11 PC (WSL, Ubuntu 24.04) on home Wi-Fi, signed in with a Claude Max plan, model Claude Haiku 5.5, no tools. Prompts were made of Python standard-library source code.

At a glance

Key results

• Large request (~342,000 tokens): median time to first token 2.98 s with gzip, 3.17 s without (warm cache). Gzip was faster in 9 of 14 back-to-back pairs; median saving about 0.34 s.
• Smaller request (~140,000 tokens): 2.06 s with gzip, 2.14 s without; gzip was faster in only 4 of 13 pairs. No real difference.
• Total run time didn't change: the whole claude -p call took about 10 to 11 seconds either way; the saving disappears in start-up time.
• Spread beats the effect: single runs ranged from 1.6 to 11 seconds to the first token, with or without gzip.
• The text compresses well: our 557 KB prompt file gzips to 130 KB (about 4.3 times smaller), so the upload saving is real; it just isn't most of the wait.

What Anthropic changed

On 16 October the official @ClaudeDevs account posted: "Claude Code now gzips the conversation it sends on every turn, so it reaches the model faster." The post had about 2.3 million views and 16,000 likes by 18 October.

The change itself shipped earlier. The Claude Code changelog for 2.1.300 (released 14 October) says: "Changed large requests to api.anthropic.com to use gzip compression even when telemetry is disabled; set CLAUDE_CODE_GZIP_REQUEST_BODIES=0 to turn it off." So if you're on 2.1.300 or later and talk to Anthropic's API directly, it's already on. That off switch is what we used to compare.

Why it should help: every turn, Claude Code sends the whole conversation (system prompt, tool definitions, history, files it read) to the API. Prompt caching saves the model from re-reading it, but the bytes still travel. Text and code compress well, so the upload gets several times smaller.

Hands-on test

Setup

• Claude Code 2.1.302, claude -p --model haiku --tools "" --output-format json, run in a clean environment on a Windows 11 PC under WSL, home Wi-Fi.
• Two request sizes:
  • Large: 557 KB of Python 3.12 standard-library source pasted into the prompt, plus Claude Code's own context on that machine; the API reported about 342,000 input tokens.
  • Smaller: one small source file plus the same base context; about 140,000 input tokens. Most of that is Claude Code's system prompt and the plugins and skills installed on that PC, so it's not a "small" request in absolute terms.
• Question: a trivial count about the pasted text, answered in one number. We ignored whether the answer was right; we only timed it.
• Gzip on vs off: default (on) against CLAUDE_CODE_GZIP_REQUEST_BODIES=0, run as back-to-back pairs, order alternating each round, 16 rounds per size (64 runs).
• Measured: ttft_ms (time to first token) from Claude Code's JSON result, and wall time of the whole command. For the medians we dropped runs that wrote a fresh prompt cache (the first runs, and a few after the cache expired), since writing 300,000 tokens to the cache is much slower than reading them and would swamp the comparison.
• What we could not see: the compressed request itself. Claude Code's debug log doesn't mention gzip, and pointing it at a local proxy would change the endpoint the changelog talks about. The 4.3 times ratio is for our prompt text, not the exact request body.

The numbers

Paired comparison (each "on" run against the "off" run next to it, both on a warm cache):

What worked

What worked

• Big requests do start a little sooner. With about 342,000 tokens going up each turn, gzip won 9 of 14 head-to-head pairs and saved about a third of a second at the median.
• It costs you nothing. It's on by default from 2.1.300, needs no setting, and we saw no case where it made big requests clearly worse.
• The off switch works for testing, as documented.

Where it fell short

What didn't work

• No visible gain on smaller requests. At about 140,000 tokens, results were a coin flip.
• Network and server noise dwarf it. The slowest run of the same request was five to six times slower than the fastest. A third of a second is easy to miss next to that.
• It doesn't make a whole command faster. Start-up and everything else took about 8 seconds per claude -p call, so the end-to-end wall time didn't move.
• Our link was one home Wi-Fi line. On a slow or mobile upload, compressing a 1 MB-plus request should matter more; on a fast office line, probably less. We didn't test other connections.

Our verdict

The gzip change is a real, free improvement, but don't expect to feel it unless your sessions are huge or your upload is slow. Think of it as shaving a few hundred milliseconds off long sessions, not as the reason Claude Code feels faster this week. If you script claude -p and every second counts, keeping your base context lean (fewer plugins and skills loaded, smaller files pasted in) will do more: in our runs, the 140,000-token request started about a second sooner than the 342,000-token one, with or without gzip.

For other ways to cut cost and time when you script Claude Code, see our tests of fork subagents and Haiku workflows.

Frequently asked questions

Does Claude Code compress requests now?

Yes. Since version 2.1.300 (14 October 2026), Claude Code gzips large requests to api.anthropic.com, even with telemetry off. Anthropic announced it on 16 October.

How do I turn off gzip in Claude Code?

Set the environment variable CLAUDE_CODE_GZIP_REQUEST_BODIES=0 before starting Claude Code, as the 2.1.300 changelog describes. We used it to compare timings.

How much faster is Claude Code with gzip?

In our test, about 0.3 seconds to the first token on a 342,000-token request (median of warm-cache runs), and no measurable difference on a 140,000-token request. Run-to-run variation was 1.6 to 11 seconds.

Does gzip save tokens or usage?

No. It shrinks the bytes sent over the network, not the tokens the model reads. The input token counts in our runs were the same with and without gzip.