All Chinese users have been affected, and the Claude web version is speed throttled just because there are Chinese characters in the generated responses.
Who could have imagined that Claude was actually severely tripped up by its own "AI-style quirks"!
Earlier this morning, Anthropic released a highly technical engineering post-mortem.
They deployed an internal research version of Claude to a Slack channel, let it run nonstop for two weeks, and successfully boosted the overall speed of the claude.ai web and desktop versions by 3 times.
Among all these operations, the most absurd performance bottleneck turned out to lie in Claude's own speaking habits.
That's the dash, which is jokingly called the "ChatGPT hyphen" by netizens and has to be manually deleted by many writers to avoid AI detection.
Wow, it turns out that the "AI-style vibe" is not only jarring to the eye, but also can actually slow down the web page.
Worse still are Chinese users.
According to the principle identified by the official team, there is no need for a dash at all: as long as there is one Chinese character in the response, any response containing code will be directly speed-limited...
Was the "AI-style quirk" literally freezing Claude?
Here is what happened.
During the performance sprint, Claude carried out a full-site carpet check for CPU lags, and noticed a strange phenomenon.
Right after some code responses were fully output, when the page started to perform syntax highlighting for the code (coloring keywords and comments), the entire web page would freeze for nearly 1 second. The mouse could not move, and no text could be typed.
Claude traced the issue step by step, and the culprit it finally found turned out to be the dash.
The reason is that the V8 engine (the JavaScript core of browsers) has two formats for storing strings. The single-byte format runs extremely fast, but can only store English letters, numbers and a small number of Western European characters (Latin-1 character set); the double-byte format can store everything, but runs slower during processing.
The rule is simple and crude: as long as a character that cannot be stored in single-byte format is mixed into a piece of text, the entire text has to be stored in double-byte format.
The dash just cannot be stored in single-byte format. A casual dash written by Claude made the entire response speed-limited, and all regular expressions for code coloring had to run on the slow path.
The method to fix this bug is so simple that it only takes 20 lines of code —
Before coloring, copy each code block separately and force it to be stored as a single-byte string.
With this single modification, the coloring time of the first code block was reduced from 1.0 second to 0.35 second.
The dash, as a hallmark of "obviously AI-generated" content, has long been complained about by netizens.
OpenAI specifically fixed this bad habit for ChatGPT last year. A recent statistics this month shows that GPT-6 Astra uses dashes only at one-eighth the frequency of human writers, and Gemini 3.1 Pro has almost completely stopped using them.
In contrast, Claude Opus 5 still goes its own way, using dashes at the same frequency as human writers.
Anthropic also has a rather unique mindset: instead of changing the AI's speaking habits, they directly modified the underlying web code to make the entire web page adapt to dashes!
We reproduced this "pitfall", and Chinese users were all hit hard
To verify this, we checked the front-end code on the claude.ai online platform. It uses the Shiki highlighting library, whose underlying layer is exactly the regex engine built into V8.
We followed this exact environment to color the same piece of code.
If it is a pure English response, the first code block only takes 188 milliseconds; but as long as a dash (or a curly quote) is mixed in, the time directly jumps to 456 milliseconds.
It's even more frustrating for Chinese responses. Without modifying a single letter of the code, the time consumption still reaches 462 milliseconds, about 2.5 times slower.
In other words, whether English users encounter this problem depends on whether there is a "dash"; but for Chinese users, as long as there are "Chinese characters" in the response, every single one of them will be affected.
Fortunately, the official 20-line fix works. As long as the code itself is all in English, even if there are Chinese characters in the response, the speed can be fully restored.
One Slack channel, 3x speedup in two weeks
Back to this performance sprint, the dash issue is just a small appetizer.
In August, Anthropic created a Slack channel named #claude-apps-perf, and brought in an internal research model (with capabilities roughly equivalent to Opus 5.5) to serve as the on-site foreman.
Claude immediately set 13 speedup targets. The human team thought this work would take at least two weeks, but by the third day, Claude had easily completed 12 of the 13 targets.
The feature that allows users to start typing before the page finishes loading was implemented during this period.
The left side shows the state before the fix: it takes 2.93 seconds to start typing; the right side shows the state after the fix: you can start typing directly in 0.36 seconds.
Since the task was completed ahead of schedule, the human team simply let Claude find blind spots freely, and encouraged it to come up with as bold ideas as possible.
As a result, the model went all out.
At the peak, more than 150 threads were running in the channel at the same time, and each thread would submit 50 to 100 code pull requests (PRs) at a time.
Later on, more and more threads were created by Claude itself. On its most productive day, it merged more than 200 changes in one go.
After each change was launched, the performance upper limit was locked to ensure no regression; if no speedup was achieved, the switch would be turned off to make adjustments again.
Finally, the time from opening the web page to being able to type was reduced from 3.1 seconds to 0.55 seconds, a 5.6x speedup. The 13 metrics averaged a 3.1x speedup.
More than 3000 underlying changes were merged in total. According to the official statement, there was not a single user-perceivable incident, and zero rollbacks were needed.
When AI is not fast enough, humans step on the gas pedal nonstop
During this speed spree, the roles of humans and AI were completely reversed.
Almost all the work was done by Claude, but it was inherently rigid in following rules: when it found a problem, it would first create a work order, and reserve a large buffer for evaluating the construction period.
Instead, it was the humans beside it that kept pushing it to speed up.
Once, Claude said that it planned to submit the performance monitoring code within this week, and with merging, deployment and baseline data collection, the whole process would take several days.
The human engineer Raymond replied directly in Slack: "Submit it right now, I will merge it immediately. We have all the permissions, please be bolder!"
A minute later, Claude immediately complied, replying "Okay, I will submit the PR within an hour".
The brake permissions are still held by humans. For any visible change, Claude must attach the before-and-after comparison screen recording and wait for human approval.
The most impressive part is the "early typing" input box. Claude matched it with test requirements that the static version and the real React-rendered interface must be aligned within 1 pixel across 14 different screen sizes.
Only 4 hours after the internal launch, a colleague found that when opening the page in a new tab, the input box occasionally jitters down a little.
After watching the screen recording, Claude directly attributed the problem to Google Chrome, with solid reasoning —
When Chrome pre-renders pages in the background, there is a 56-pixel prompt bar at the bottom, which compresses the rendering height. When the page pops up and the prompt bar disappears, the height instantly stretches, and the input box located at 18% of the total height will just drop 10 pixels down (0.18×56).
After measuring against the screen recording, the result is exactly 10 pixels, no more no less.
In the end, even the tweet Anthropic posted to announce this optimization still has this "double-byte pitfall".
In the tweet, to prevent "claude.ai" from being converted into a link, an invisible zero-width space was inserted; and "curly apostrophes" are used in the words.
If the code had not been modified during this intense sprint, when Claude quoted this tweet in a response and followed it with a piece of code, the coloring process would still be speed-limited.
References:
https://claude.dev/blog/how-we-made-claude-ai-faster/
This article is from the WeChat Official Account "New Zhiyuan", Author: ASI Insight, Editor: Moses, Published with authorization from 36Kr.