Anthropic has shared new speed numbers for Claude and a short explanation: "Claude Code now gzips the conversation it sends on every turn, so it reaches the model faster. Cloud sessions also start up as soon as you start typing." The headline is 3x faster in Claude Code and 1.5x faster in Claude. This post explains what gzip is, why compressing the conversation can shorten the wait, what the numbers actually measure, and what remains unproven.
TL;DR: the numbers and the two changes
| Surface | What was measured | Before | After | Change |
|---|---|---|---|---|
| Claude Code (local sessions) | p90 wait before first token, excluding model time | 4.07 s | 1.33 s | 3x faster |
| Claude Code (cloud sessions) | same | 16.99 s | 6.00 s | 2.8x faster |
| Claude (chat and Cowork) | same | 3.36 s | 2.17 s | 1.5x faster |
| Claude API | p50 time to first token, including model time | 1.53 s | 1.01 s | 1.5x faster |
The period is August to October 2026, per Anthropic's chart. The two changes it names are gzip on each turn's conversation and cloud sessions that start when you begin typing.
What is gzip?
Gzip is a lossless compression format. Lossless means the original bytes come back exactly after decompression, with no approximation, unlike a JPEG or MP3. It was designed in the early 1990s, and it is still one of the most common ways text is shrunk for storage and transfer. The gzip command, .gz files and the Content-Encoding: gzip header in HTTP all refer to the same family.
Inside, gzip uses the DEFLATE algorithm, which combines two ideas:
- LZ77. When a stretch of data repeats something seen a moment ago, store a short pointer ("copy 40 bytes from 900 bytes back") instead of the text. The lookback window is limited to 32 KB.
- Huffman coding. Give frequent symbols short bit codes and rare symbols long ones.
Text, JSON, source code and logs are full of repeated words, keys and indentation, so they compress well. Already-compressed data such as images and videos does not.
Why does the conversation get sent every turn?
A model call is stateless from the client's point of view: the model needs the whole conversation to answer the next message. In a long Claude Code session, that conversation includes your messages, the model's replies, file contents the agent read and command output. It grows with every turn, and each turn sends it again.
That payload can reach hundreds of kilobytes or more. Sending it uncompressed costs transfer time on every turn, and the model cannot start generating until the request arrives. That is the wait Anthropic's chart measures.
Why would gzip shrink the wait?
Time to send is roughly payload size divided by your upload speed, plus fixed delays such as connection setup. Compression shrinks the numerator. The benefit is largest when:
- the conversation is long,
- the uplink is slow, shared or high-latency (hotel Wi-Fi, VPN, mobile tethering, a busy office network),
- the content is text-like.
Compression adds a little CPU work on the client and the server, which is normally far smaller than the transfer time saved on text.
A small test we ran
To make this concrete, we compressed real text from this site's blog posts, wrapped in a chat-style JSON payload with each post as a tool result. This is an illustration of the principle, not a measurement of Claude Code, whose payloads and compression settings Anthropic has not published.
| Test payload | Raw size | Gzip size | Ratio |
|---|---|---|---|
| One blog post (prose and markdown) | 15.7 KB | 6.0 KB | 2.6x |
| Conversation with 5 distinct file reads | 81.5 KB | 28.2 KB | 2.9x |
| Conversation with 20 distinct file reads | 338.7 KB | 114.7 KB | 3.0x |
| 20 turns re-reading the same 3 files | 319.8 KB | 106.6 KB | 3.0x |
Two things stand out. First, ordinary English-and-code text compresses to roughly a third of its size at gzip's default level. Second, the last row is a reminder of the 32 KB window: even though the same files were repeated, gzip only found matches within a short lookback, so the ratio stayed near 3x. A very repetitive synthetic conversation, where the same snippet repeats every few hundred bytes, compressed far better in a separate test of ours (up to about 49x), but real sessions are less uniform. Your results will depend on what your agent reads.
What do the numbers measure, exactly?
The chart is careful about its definitions, and that matters for reading it.
- Claude Code, chat and Cowork: the p90 wait before the first token, excluding model time. P90 means 90 percent of requests were faster than that value, so it reflects the slower end of normal experience, not the average. "Excluding model time" means the number isolates everything around the model: sending the request, routing and setup. It does not include how long the model thinks.
- API: the p50 time to first token, including model time. P50 is the median. Here the model's own time is counted, so the 1.53 s to 1.01 s drop is a different kind of number.
So these are not one metric across four rows. The first three rows describe overhead around the model, and the API row describes median end-to-end time to the first token. Anthropic notes it keeps "improving performance across Claude," and the chart groups several changes.
Cloud sessions that start as you type
The second named change is separate from gzip. Cloud sessions run on a remote machine that has to be started. Starting it only after you press send puts the startup in your waiting time. Starting it when you begin typing hides some of that time behind the seconds you spend writing your message. The cloud row shows the largest absolute drop, from 16.99 s to 6.00 s at p90, which is consistent with startup being a large part of the wait.
This is a general latency technique called speculative or eager start: do likely-needed work early, accept that some of it is wasted if you do not send the message.
What we cannot say
- How much came from gzip. Anthropic lists gzip and eager cloud startup, but the chart shows combined results from August to October. It does not break out the gain from each change, and it implies other performance work. Do not read "3x" as "gzip makes things 3x faster."
- How it is configured. Compression level, minimum payload size and whether the server decompresses at an edge or at the service are not stated.
- Your result. Gains depend on your network and session length. Fast wired connections with short sessions may see little.
- Independent verification. These are Anthropic's own figures, and the chart does not describe sample sizes.
Should you compress your own requests?
If you build an app that sends large JSON to an API, the same reasoning applies, with conditions.
- Check support. Many servers compress responses by default, but accepting a compressed request body depends on the server. Look at the API documentation before adding
Content-Encoding: gzip. - Measure payload size. Under a few kilobytes, the saving is tiny. Compression pays off on large, text-heavy bodies.
- Measure the ratio on your real data. This takes seconds:
import gzip, json
payload = json.dumps(your_request_dict).encode()
compressed = gzip.compress(payload, compresslevel=6)
print(len(payload), len(compressed), round(len(payload) / len(compressed), 1))
- Mind the level. Higher levels shrink more but cost more CPU. The default of 6 is a common balance. Newer formats such as Brotli and Zstandard can compress better or faster in some cases, but they require support on both ends, and gzip's advantage is that it is supported nearly everywhere.
- Do not compress what is already compressed. Images, video and encrypted blobs gain almost nothing.
Other ways to make an agent feel faster
Compression is one lever. Others that appear in this series:
- Prompt caching reduces model-side cost and time for repeated prefixes. See our cache-read price cut and agentic cost math.
- Generation speed is a separate axis from wait-before-first-token. Our explainer on tokens per second covers it.
- Front-end and load-time work. Anthropic's earlier write-up on making claude.ai 3x faster in two weeks covers the method behind app speedups.
A good way to think about an agent's responsiveness is as a chain: your keystroke, the client, the network upload, routing, the model's first token, then streaming. Anthropic's chart is about the early links. Tokens per second is about the last one.
Bottom line
Gzip is an old, simple, lossless compression format, and applying it to a conversation that is re-sent every turn is a sensible way to cut upload time. Combined with starting cloud sessions as you type, Anthropic reports p90 waits in Claude Code dropping from 4.07 s to 1.33 s locally and from 16.99 s to 6.00 s in the cloud. Treat the headline multiples as the combined effect of several changes, and measure on your own network before drawing conclusions about any single one.
Related reading
- How Anthropic made claude.ai 3x faster in two weeks
- What is TPS? Tokens per second explained
- Claude Sonnet 5.5 cache read price cut and agentic cost math
- Claude Code weekly update: faster startup and token visibility
Figures come from Anthropic's chart and post, as shared on October 17 and 18, 2026. The compression test is our own and illustrative. We have not measured Claude Code's actual payloads.