Claude Code now starts answering up to 3x sooner after Anthropic compresses every turn

What Anthropic announced

Anthropic says Claude now starts answering noticeably sooner, and Claude Code most of all. In a post from its ClaudeDevs account on 16 October 2026, the company said Claude Code now gzips the conversation it sends on every turn, "so it reaches the model faster," and that cloud sessions "start up as soon as you start typing." The post came with a table headlined "3x faster in Claude Code, 1.5x faster in Claude."

The change is not a new model or a new price. It is plumbing: less data on the wire and less time spent setting up a machine before the model sees the request. For people who run coding agents all day, that plumbing is where a surprising share of waiting happens, because an agent may make dozens of requests in a single task and every one of them pays the start-up cost again.

The numbers, and what they measure

Anthropic's table compares August with October 2026 and reports the 90th-percentile wait before the first token, excluding the time the model spends computing. On that measure, local Claude Code sessions went from 4.07 seconds to 1.33 seconds, about three times faster. Claude Code cloud sessions, which run on Anthropic's machines instead of the user's laptop, went from 16.99 seconds to 6.00 seconds, or 2.8 times faster. The Claude apps, listed as chat and Cowork, went from 3.36 to 2.17 seconds.

The last row is measured differently. For the Claude API, Anthropic reports the median time to first token including model time, which fell from 1.53 to 1.01 seconds. That makes the API figure the closest to what a developer would see with a stopwatch, while the other three isolate the overhead around the model. Using the 90th percentile for those rows also matters: it describes the slow end of normal experience, the waits people notice and complain about, rather than the typical request.

Why compressing every turn helps

The model behind the API keeps no memory between calls, so a client has to send the whole conversation each time: the system prompt, tool definitions, files Claude has read, command output and every earlier message. In a long coding session that payload grows turn after turn. Prompt caching spares the server from reprocessing the repeated part, but the bytes still have to travel from the user's machine to Anthropic before anything can happen.

That traffic is mostly text and JSON, which compresses well. Shrinking it before upload helps most on the connections where developers actually work: home broadband and office Wi-Fi, where upload speeds are often far lower than download speeds. Anthropic did not say how much smaller the requests get.

The Claude Code changelog shows when the switch became a default. Version 2.1.300, released on 14 October, "changed large requests to api.anthropic.com to use gzip compression even when telemetry is disabled." The wording suggests compression had earlier been tied to telemetry settings. The same entry gives an opt-out: setting CLAUDE_CODE_GZIP_REQUEST_BODIES=0 turns it off, which may matter for teams whose proxies or gateways inspect or rewrite request bodies.

Cloud sessions that start before you hit enter

Cloud sessions had the largest absolute wait, almost 17 seconds at the slow end in August. A cloud session needs a remote environment before Claude can do anything, and until recently that work began only after the user submitted a task. Anthropic now starts provisioning while the user is still typing, so part of the set-up overlaps with the time a person spends writing the prompt.

It is the same trick a browser uses when it preloads a page you are likely to open. The cost is some wasted work when a user types and then abandons the prompt, a trade-off Anthropic did not discuss.

The changelog for version 2.1.302, released on 16 October, shows the company is still smoothing cloud sessions: failed starts now say "Connection lost" or "Server error" instead of "Something went wrong," and a routine's page explains when its last run did not start because an organization hit its limit on concurrent cloud sessions.

The cache work around it

Several other recent changes aim at the same goal of not redoing work. Version 2.1.299, released on 14 October, added idle compaction in the terminal: a conversation of 200,000 tokens or more that sits idle for about 54 minutes is compacted before its one-hour prompt cache expires, "so your next message doesn't reprocess it all." The threshold can be changed with CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS, and "idleCompaction": false in settings.json turns it off.

Version 2.1.302 added a row in /config to switch idle compaction off or back on, moved the Claude in Chrome instructions so new conversations can read them from the shared prompt cache, and fixed a cache miss when a tool added mid-session was loaded again through tool search or after compaction. None of these is a headline feature, but each removes a case where Claude would have had to chew through a long prompt from scratch.

Speed has been a theme for Anthropic all week. On 15 October it took Opus 5.5 fast mode out of research preview, the same model at up to 2.5 times the output speed for $8 and $40 per million input and output tokens, and said most Code Review runs now finish about three times faster than in the preview. Its own engineers have also described how AI review let the Claude Code team ship more while reverting less.

OpenAI is chasing the same bottleneck

OpenAI is working on the same layer. A few hours after Anthropic's post, @thsottiaux wrote on X, in a post numbered "Day 12" of OpenAI's daily release run, that Codex and Work now give users more effective usage "by reusing context across subagents, keeping context cached longer, and improved request routing that allows us to increase cache hits."

The emphasis is different. OpenAI framed its change around how far a subscription stretches, since cached tokens are cheaper to serve, while Anthropic framed its change around waiting time. Both point to the same fact about agent products: once models are good enough, the cost and delay of moving and re-reading huge contexts becomes a competitive feature in its own right.

What developers need to do

For most people, nothing. The compression and the cloud pre-start happen inside Claude Code and Anthropic's service, so updating to a current version is enough. Anyone pinned to an older Claude Code release, or running it with telemetry disabled on a version before 2.1.300, will not get compressed requests until they update.

Teams that route Claude Code through their own gateway should check that it accepts gzip-encoded request bodies, or set the opt-out variable. Those who rely on long, idle terminal sessions may also want to decide whether automatic compaction suits them, since it summarises the conversation and can drop detail Claude would otherwise keep. Tools that shrink what an agent has to read, such as local code search like LightOn's ColGrep, attack the same problem from the other side: fewer tokens to send in the first place.

What the figures do not tell you

Every number here comes from Anthropic, and the company has not published how it measured them: which regions, which clients, how many sessions or which exact weeks in August and October. AI Lookout has not timed Claude Code itself. Because the main rows exclude model time, they also do not show whether answers finish sooner; a long response from a large model can still take far longer than the few seconds saved at the start.

Anthropic also did not say what produced the gains in the Claude apps and the API, which do not depend on Claude Code's compression. And August is a convenient baseline only if nothing else changed in between, such as traffic levels or server capacity. Independent latency trackers or user measurements over the coming weeks will show whether the faster start holds up under load.