Claude Desktop launches at login on my Mac. That is not a convenience, it is a requirement: the work I hand off from my phone runs on this machine, and the machine has to be awake with the app open. So I almost never watch it start. It is simply there when I open the lid. What I did notice was that the first half minute after logging in felt sticky, and I had filed that away long ago under “the laptop still needs a moment”.
On 19 August, Anthropic’s developer account said Claude Desktop now starts roughly twice as fast as it did a month ago. The reason they gave describes my exact setup: when the app started in the background, its timers got throttled and the JavaScript engine dropped into power-saving mode. They say it now boots at full speed even while the window is still hidden.
What sits underneath that sentence
Claude Desktop is an Electron app, so Chromium is doing the rendering. And Chromium deliberately treats a page nobody is looking at differently from a page someone is looking at. That is policy, not a bug, and it exists to protect your battery from the twenty tabs you left open.
| State | What the engine does | Meant for |
|---|---|---|
| Visible | Timers run normally, animation frames at screen rate | The tab you are looking at |
| Hidden | setTimeout and setInterval get coalesced to roughly once per second, animation frames stop | Background tabs |
| Hidden and quiet | Intensive throttling: down to roughly once per minute, and for a fully loaded page that can start after ten seconds of being hidden | Tabs you forgot about |
| Background process | The renderer process drops in priority, the JavaScript engine picks frugal over fast | Battery life |
For a tab holding a news article, that is fine. For an app that happens to be starting up at that moment, it is ruinous. Booting an Electron app is mostly JavaScript: loading modules, restoring the session, opening connections, waking up connectors. A lot of that work hangs off timers and promises that politely wait for each other. Put that chain on one tick per second and a fifty-step startup sequence turns into the better part of a minute, without anything slow actually happening.
Electron has a switch for this. You can set backgroundThrottling: false in the window preferences, which tells the engine to keep treating the page as visible. The existence of that switch does not mean it does what you hope everywhere. Electron’s issue tracker carries reports going back years where the switch works for a minimized or occluded window but not for a window that has genuinely been hidden with hide(). What Anthropic changed specifically is not documented anywhere.
The number you cannot check
“About twice as fast” is the only measurement in the announcement. There is no version number, no operating system, no sample size, no start and end time in milliseconds, and no definition of what “started” means. Is that the moment the window appears, or the moment you can type? In any app, that difference is worth a factor on its own.
I went looking for the backing. The official release notes for the Claude apps in Anthropic’s help center do not mention this change on 19 August, and the platform release notes point to that help center for app news. So there is no changelog line, no version number, and no second source. One post on X is the whole record.
The claim may well be right. You simply cannot check it. The only solid thing you can take from it is the cause, because that one is documented, in Chromium’s and Electron’s own material.
The replies underneath barely discussed startup time, incidentally. The most-read ones were about the app in general and about consumption, the sharpest being a joke asking whether this explains why someone’s usage burns twice as fast. That proves nothing, but it does show where the audience currently sits.
The caveat
A performance claim without a method becomes the norm. If “about twice as fast” with no version and no methodology is enough to announce, the bar for what counts as a measurement moves. For a startup time the damage is small. For a claim about a model’s accuracy or safety, the same packaging is considerably more dangerous, and the habit of accepting it gets built in posts like this one.
Verification lands on you, without the tools to do it. You cannot open a changelog to see which version carries the fix, so you cannot establish whether your install already has it. What is left is measuring it yourself, and most people will not. For a free speedup that is survivable. It is the same shape as an update that breaks something, where you only find out by walking into it.
Less power saving means more consumption while you are away. The throttling that got removed here was not there for no reason. An app that launches at login, stays hidden, and now runs at full speed does that at moments when you are asking nothing of it. On a laptop running on battery you will feel it, and it is exactly the kind of cost that never appears in an announcement, because it lands on your side rather than the vendor’s.
What I do about it
Two things. I measure it before I believe it: restart the laptop, run a stopwatch until I can actually type a prompt, repeat a few times. Without a before-number I cannot confirm any factor, but I will know whether the first minute is still sticky.
And I went back through my own setup looking for the same trap. Anything I leave running in a hidden browser tab, such as a long job that tracks its own progress on a timer, can stall in precisely this way with no error to show for it. That work belongs in a terminal, not in a tab that disappears behind my editor. I also use this laptop for spoken work where the app listens continuously, and the same rule applies there: hidden is not the same as off.
Frequently asked questions
Will my install pick this up on its own?
Yes. The change sits inside the app, so an update carries it along and there is nothing to switch on. Because the announcement names no version, you cannot check whether yours already has it.
Does it apply when I launch the app myself?
Probably not, or far less. The problem showed up when the window was hidden at startup, which mostly happens with launch-at-login. If you open the app yourself, the window is visible right away and the engine throttles nothing.
Can I prevent this in my own Electron app?
There is a setting for it, backgroundThrottling: false in the window preferences, but do not rely on it blindly. Open reports describe it working for a minimized window and not for a genuinely hidden one. Measuring is the only real answer here.
Sources
- @ClaudeDevs on X, post about Claude Desktop startup time, 19 August 2026.
- Chrome for Developers, “Heavy throttling of chained JS timers beginning in Chrome 88”, accessed 19 August 2026.
- Chromium blink-dev, “Intent to Ship: Quick intensive timer throttling of loaded background pages”, accessed 19 August 2026.
- Electron,
BrowserWindowandwebPreferences.backgroundThrottlingdocumentation, accessed 19 August 2026. - Electron, issues 20974, 31016 and 9567 on
backgroundThrottling, accessed 19 August 2026. - Anthropic Help Center, “Release notes” for the Claude apps, accessed 19 August 2026.
Checked on 19 August 2026. What I could not verify: the factor of two itself, because no methodology was published and I have no measurement from before the change. I also could not find the version number the fix shipped in. The sources do not contradict each other, but they do not cover each other either: Anthropic’s help center does not mention this change on 19 August, while the platform documentation names that help center as the place where app news belongs. The explanation of background throttling comes from Chromium and Electron material rather than from Anthropic, so the link between that mechanism and this specific fix rests on the wording of the post itself.