Claude Code Added GZIP in 2026. Why Not Brotli?

A developer captured a Claude Code API request that was 594,750 bytes. After GZIP compression, the body was 289,145 bytes. That's about 51% less data to upload, without removing a word from the request.

Those numbers come from a community investigation, not an official Anthropic benchmark. But they help explain a small change that shipped on October 14, 2026: Claude Code v2.1.300 began compressing large requests to api.anthropic.com with GZIP, including when telemetry is disabled.

GZIP has been around since 1992. Brotli is newer and often produces smaller compressed files. So why pick GZIP for an AI coding tool in 2026? And what should we use in our own APIs?

A coding assistant's request can include conversation history, tool definitions, tool results, and other context. What gets included varies, but many requests contain a lot of repeated, structured text.

In August 2026, the author of Claude Code issue #90457 inspected requests from version 2.1.246 using a local proxy. They reported that the bodies were being sent without compression. Their measurements included:

The same report says their proxy avoided 185 MB of uploads over roughly three hours of use on one machine. Those results are specific to that person's workload and setup.

To put the single-request saving in perspective: transferring 305,605 fewer bytes on a 2 Mbps upload link saves approximately 1.2 seconds of raw transmission time. That's a calculation, not a measured improvement in Claude's response time. CPU work, protocol overhead, network conditions, and model inference all affect actual latency.

The official v2.1.300 notes confirm that large API requests now use GZIP. They also document an escape hatch for troubleshooting:

CLAUDE_CODE_GZIP_REQUEST_BODIES = 0 claude Enter fullscreen mode Exit fullscreen mode What GZIP actually does GZIP is a lossless compression format built around the DEFLATE algorithm. DEFLATE combines two ideas: refer back to repeated byte sequences instead of writing them again, and use shorter codes for frequently occurring symbols.

Think of a JSON document containing the key "category" a thousand times. A compressor can represent much of that repetition more efficiently. The receiver decompresses the bytes and gets the original JSON back.

Neither format makes your server execute application code faster. They reduce bytes transferred over the network, and compression itself costs CPU time.

Most web developers encounter compression when a browser downloads a response.

GET /api/products HTTP / 1.1 Accept-Encoding: br, gzip Enter fullscreen mode Exit fullscreen mode That means it can accept Brotli ( br ) or GZIP ( gzip ) responses. The server might reply:

HTTP / 1.1 200 OK Content-Type: application/json Content-Encoding: br Vary: Accept-Encoding <compressed response bytes> Enter fullscreen mode Exit fullscreen mode Vary: Accept-Encoding tells HTTP caches that clients accepting different encodings may need different response representations.

Claude Code's update is about the upload direction. The client compresses a request body before sending it:

POST /v1/messages HTTP / 1.1 Content-Type: application/json Content-Encoding: gzip <gzip-compressed JSON bytes> Enter fullscreen mode Exit fullscreen mode Here, the server must support decoding GZIP request bodies. Accept-Encoding describes what you want to receive; Content-Encoding describes how the body you're sending is encoded.

One more distinction matters for AI tools: compressing the HTTP request does not reduce the number of input tokens the model processes. The server restores the original body before interpreting it. Transport compression can save bandwidth without changing context-window usage or model billing.

In the August GitHub report, the author tested request encodings against Anthropic's API. GZIP worked. Brotli, Zstandard, and DEFLATE were rejected on the endpoint they tested. That describes the author's tests at that time, not a permanent compatibility guarantee for all Anthropic endpoints.

Given those results, GZIP was the compatible option. Saving a few more bytes with Brotli wouldn't help if the receiving API couldn't decode them.

For static website assets, you can compress once during a build and serve the same file many times. Spending extra CPU to achieve a smaller Brotli file can make sense there.

For dynamic API responses, measure both transfer size and compression time. Higher compression levels aren't automatically faster for users.

We can test both response compression and request decompression with built-in ASP.NET Core middleware. This example uses plain HTTP on localhost so we don't accidentally suggest enabling HTTPS compression without considering its security implications.

dotnet new web -n CompressionDemo cd CompressionDemo Enter fullscreen mode Exit fullscreen mode Replace Program.cs with:

using System.IO.Compression; using System.Text.Json; using Microsoft.AspNetCore.ResponseCompression; var builder = WebApplication. CreateBuilder ( args ); builder. Services.

AddResponseCompression ( options => { options. Providers. Add < BrotliCompressionProvider >(); options.

Providers. Add < GzipCompressionProvider >(); }); builder. Services.

Configure < BrotliCompressionProviderOptions >( options => { options. Level = CompressionLevel. Fastest; }); builder.

Services. AddRequestDecompression (); var app = builder. Build (); app.

UseResponseCompression (); app. UseRequestDecompression (); app. MapGet ( "/items", () => Enumerable.

Range ( 1, 1000 ). Select ( i => new { Id = i, Category = "accessory", Available = i % 2 == 0 })); app. MapPost ( "/echo", ( JsonElement body ) => Results.

Json ( body )); app. Run (); Enter fullscreen mode Exit fullscreen mode Start the app:

dotnet run --urls http://localhost:5073 Enter fullscreen mode Exit fullscreen mode Compare download sizes On macOS or Linux, run:

for encoding in identity gzip br; do bytes = $( curl -sS \ -H "Accept-Encoding: $encoding " \ -o /dev/null \ -w '%{size_download}' \ http://localhost:5073/items ) printf '%-8s %s bytes\n' " $encoding " " $bytes " done Enter fullscreen mode Exit fullscreen mode This counts the downloaded response-body bytes. It does not benchmark end-to-end latency, and Brotli at CompressionLevel.Fastest is not guaranteed to beat GZIP for every payload.

Inspect the response headers separately:

curl -sS -D - -o /dev/null \ -H 'Accept-Encoding: br' \ http://localhost:5073/items Enter fullscreen mode Exit fullscreen mode You should see Content-Encoding: br and Vary: Accept-Encoding when the middleware compresses the response.

printf '{"message":"hello from gzip"}' > body.json gzip -c body.json > body.json.gz curl -i http://localhost:5073/echo \ -H 'Content-Type: application/json' \ -H 'Content-Encoding: gzip' \ --data-binary @body.json.gz Enter fullscreen mode Exit fullscreen mode ASP.NET Core decompresses the body before the endpoint binds it as JSON. The endpoint returns the original content.

AddResponseCompression() and AddRequestDecompression() solve different problems. Enabling the first does not automatically enable the second.

I'd start by measuring actual requests and responses, rather than choosing an algorithm from a comparison table.

For a web API, Brotli with GZIP fallback is a reasonable response-compression setup to test. For compressed uploads, check which formats the receiving service accepts before deciding.

Claude Code's change started with a developer measuring real traffic and demonstrating that a server already accepted compressed requests. If your application uploads large JSON bodies repeatedly, inspecting Content-Encoding and the actual byte counts is a worthwhile first step.