DEV Community

Cover image for Claude Code Added GZIP in 2026. Why Not Brotli?
Bargan Constantin
Bargan Constantin

Posted on

Claude Code Added GZIP in 2026. Why Not Brotli?

#performance #dotnet #webdev #ai

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?

Why an AI coding assistant uploads so much text

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:

Request body Bytes
Before compression 594,750
After GZIP 289,145
Saved 305,605 (about 51%)

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.

Brotli is also lossless. It uses a different encoding design and a built-in dictionary that can help with common text patterns. It often compresses HTML, CSS, JavaScript, and JSON better, especially at stronger compression settings. The trade-off can be more CPU time spent compressing.

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

Request compression and response compression are different

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

The browser sends:

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.

So why didn't Claude Code choose Brotli?

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.

Consideration GZIP Brotli
Typical text compression Good Often produces smaller output
Compression CPU cost Generally modest at normal settings Can cost more at stronger settings
Modern browser response support Broad Broad
Precompressed static assets Useful Often a strong choice
Compressed request uploads Server must support it Server must support it

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.

Try it in ASP.NET Core

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.

Create a minimal app:

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.

Send a GZIP-compressed upload

Now send compressed JSON to /echo:

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.

Before turning this on in production

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

  • Measure realistic payloads. Compare bytes, compression CPU time, and p95 latency under load. A tiny JSON response won't behave like a 500 KB response.
  • Check the hosting layer. IIS, a reverse proxy, or a CDN might already compress responses. Inspect the bytes reaching the client.
  • Don't recompress everything. JPEGs, videos, and ZIP files usually have little room left for savings.
  • Review HTTPS compression security. ASP.NET Core response compression middleware disables HTTPS compression by default. Compressing secrets alongside attacker-controlled content can expose side channels such as BREACH.
  • Limit decompressed request sizes. A very small compressed upload can expand into a huge body. Keep request size limits in place to reduce decompression-bomb risk.
  • Test caching and streaming. Check Vary: Accept-Encoding, streamed responses, and any proxy that transforms bodies.

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.

References

Top comments (0)