--- title: "Claude's long responses now render about 4x smoother on web and desktop" url: https://daily.dev/posts/claude-s-long-responses-now-render-about-4x-smoother-on-web-and-desktop-w7kea5mrr source_url: https://daily.dev/posts/claude-s-long-responses-now-render-about-4x-smoother-on-web-and-desktop-w7kea5mrr type: collection source: "Collections" published: 2026-08-25T21:38:59.585Z updated: 2026-08-26T07:24:59.454Z tags: ["claude", "anthropic"] reading_time: 1 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Claude's long responses now render about 4x smoother on web and desktop **[Collections](https://daily.dev/sources/collections)** · 1 min read · 0 upvotes · 0 comments ## Summary Anthropic rebuilt the streaming text renderer in Claude's web and desktop apps so that only the parts of a response still changing get redrawn, instead of the whole message. On slower laptops, long replies now stall 9 times less often and the worst freeze is 4.5 times shorter, while on a 120Hz MacBook the app sustains a full 120fps throughout streaming. ## Content Anthropic rebuilt the streaming renderer behind Claude's web and desktop apps, and the difference shows up specifically when you're reading a long answer. The core fix: instead of redrawing the whole response as new text arrives, the renderer now only touches the parts that are actually still changing. That sounds like a small technical detail, but the numbers are pretty striking. On a slower laptop, long replies now stall 9 times less often, and the worst freeze you'll hit is 4.5 times shorter than before. On a 120Hz MacBook, the app holds a full 120fps from the first token to the last. I'll admit this is the kind of update that's easy to shrug off until you've actually felt the old version stutter through a 2,000-word answer. Nobody's going to write a think piece about renderer performance, but if you spend hours a day reading Claude's output, this is the kind of change you notice in your hands before you notice it in a changelog. ## Questions this post answers ### Why did Claude's web and desktop app used to stutter on long responses? The old streaming renderer redrew the entire response every time new text arrived, instead of updating only the parts still changing. Anthropic rebuilt the renderer to touch only the actively changing portions, which cut stalls on slower laptops by 9 times and shortened the worst freeze by 4.5 times, while letting 120Hz MacBooks hold a full 120fps throughout a response. _Developers relying on Claude for long outputs can follow performance changes like this on daily.dev._ ### How much faster does Claude's app render long responses after the streaming renderer rebuild? Long replies stall 9 times less often on slower laptops, and the longest freeze is 4.5 times shorter than before the rebuild. On a 120Hz MacBook, the app now maintains a full 120fps from the first token to the last, a change owed to redrawing only the actively updating text rather than the entire response. _Anyone tracking AI assistant performance improvements can follow updates like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 124 comments across x (as of 2026-08-26). **TL;DR:** Reception to the renderer fix itself is generally positive as a technical win, but the thread is dominated by unrelated complaints about verbose responses, usage limits, Opus 5 quality, and pricing that overshadow the rendering announcement. **Sentiment:** 35% positive · 25% mixed · 40% skeptical **The case for** - Several people say the smoother streaming meaningfully reduces freezes and fan noise on lower-end/older laptops during long generations. - Some appreciate the technical approach of only re-rendering changed portions instead of the whole message, calling it the right fix for perceived jank. - One commenter highlighted a specific CPU usage drop (45% to 14%) as evidence the fix addresses real wasted client-side compute. **The pushback** - Many argue the real problem is response verbosity, not rendering speed, and want shorter/more concise answers instead. - Several complain that usage limits and token consumption have gotten worse or feel like they're being 'stolen', overshadowing the UI fix. - Some note that smoother streaming doesn't reduce actual generation time, so the perceived benefit is purely cosmetic while waiting. - A few report Opus 5 has felt buggy, 'dumb', or slower recently, unrelated to but coexisting with this update. - One commenter pushed back that calling it a '4x' win overstates things since the freeze duration is still nonzero and it's a renderer change, not a model improvement. **By community** - x (mixed): Technical appreciation for the renderer fix is present but largely drowned out by complaints about verbosity, usage limits, and model quality unrelated to the announcement. **Hottest debate:** Whether this renderer fix actually matters when many feel the bigger issue is that responses are too long and usage limits feel increasingly restrictive. **Open questions** - Was the original slowdown caused by rendering or by token parsing, since some still see jank on long code outputs? - Do the smoothness gains hold on ordinary office laptops with multiple tabs open, not just high-end or low-end test devices? - If a long reply still takes 40-60 seconds to generate, does smoother streaming change actual usage patterns or just the waiting experience? **Highlights** > @ClaudeDevs CPU down from 45% to 14% is the number that actually matters here — a third of the client-side compute was being spent re-rendering text that hadn't changed. Everyone benchmarks tokens per second and then loses the win in the DOM. > — [ricci\_nov on x](https://x.com/ricci_nov/status/2092223295143772161) > @samet_ai @ClaudeDevs Sure, start treating power users like they don't know what they are talking about, that has worked perfectly for companies in the past. The overall feeling is not "great its faster", it is "I don't want an essay long answer on a yes/no question" > — [jpheymans on x](https://x.com/jpheymans/status/2092233087316885648) > @ClaudeDevs The interesting question is whether generation is still the actual bottleneck. If a long Opus reply still takes 40–60s to finish, does 4x smoother streaming change how people use it, or just how it feels while waiting? > — [freesouleth on x](https://x.com/freesouleth/status/2092355435844006301) > @ClaudeDevs Renderer work sounds boring until a long answer starts freezing. Model quality and interface quality land as one experience for the user. It would be useful to see whether the gains hold on ordinary office laptops with several tabs open. > — [Liam2307 on x](https://x.com/Liam2307/status/2092228443672830421) > @ClaudeDevs 120fps streaming is nice. I’d still trade it for shorter answers. > — [rh\_fardin on x](https://x.com/rh_fardin/status/2092329476294312261) **Source threads** - [x](https://x.com/nusagain/status/2092299580536914374) · 1 points · 0 comments - [x](https://x.com/ClaudeDevs/status/2092006814804214163) · 0 points · 124 comments --- Tags: [#claude](https://daily.dev/tags/claude), [#anthropic](https://daily.dev/tags/anthropic) [View this post on daily.dev](https://daily.dev/posts/claude-s-long-responses-now-render-about-4x-smoother-on-web-and-desktop-w7kea5mrr)