[BUG] Claude Desktop 1.1.3189 severe UI lag and mouse stutter on Windows — performance regression after update

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22543
2. https://github.com/anthropics/claude-code/issues/22275
3. https://github.com/anthropics/claude-code/issues/18014

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate of any of the three listed issues.

• #22543 is macOS-only and focuses on the VM bundle size/cleanup. This issue is Windows-specific and covers three separate problems introduced by v1.1.3189: (1) the Cowork VM starting unconditionally even when Cowork is never used, (2) SkillsPlugin polling every 60s triggering unnecessary React state updates (2,177+ entries in a single session), and (3) the MSIX packaging ignoring all Electron GPU flag mechanisms (ELECTRON_EXTRA_LAUNCH_ARGS, electron-flags.conf), causing uncontrollable renderer/GPU CPU usage on high-refresh displays. The mouse stutter symptom when the window is focused is unique to this report.
• #22275 is about Claude Code CLI processes consuming 100% CPU at idle — not the Desktop Electron app.
• #18014 is also about Claude Code CLI idle CPU on Windows — again, not the Desktop renderer/GPU compositor.

The root cause here is the combination of the Cowork VM overhead, SkillsPlugin polling, React hydration errors (#418), EventEmitter memory leak warnings, and the inability to pass GPU flags through the MSIX package — all introduced or amplified by the v1.1.3189 update on Windows.

🤖 Generated with Claude Code

I have the same problem with Claude desktop. When I first started with chatty, I had the same problem there too and Claude says it might be because they both use Electron apps? Although it acknolwedged that the issue with Claude is more recent. Still, it's super annoying.

same here...

I have the same issue with a tripple monitor setup. My main monitor, an LG ultrawide WQHD monitor and on each side a 16:9 LG WQHD. It only starts to visible lag the mouse when using it on the ultrawide monitor

I'm experiencing a related issue on the latest version of Claude Desktop for Windows that I wanted to add here since it aligns with the Hyper-V VM auto-start problem described in this thread.

Symptoms:

• Mouse clicks stop registering after using the PC for a period of time
• Phantom mouse clicks occur when I'm not touching the mouse at all
• The issue persists across multiple different mice, ruling out hardware
• Problem occurs even when Cowork is not actively being used

What I've tried (did NOT fix the issue):

• Updated Windows
• Updated GPU drivers
• Restarted PC multiple times
• Uninstalled and reinstalled Claude Desktop (latest version)

What DID fix the issue:

• Ending the Hyper-V vmcompute task in Task Manager temporarily resolved it
• Running bcdedit /set hypervisorlaunchtype off and restarting fully resolved the phantom click and input issues
• Note: after uninstalling Claude Desktop, the Hyper-V services (vmcompute and others) were still running and the mouse problems persisted until I disabled the hypervisor via bcdedit

The problem returned immediately after reinstalling Claude Desktop, confirming the Hyper-V VM that Cowork spins up is the root cause. The VM still appears to start unconditionally on app launch regardless of whether Cowork is being used.

This is a significant usability issue — it effectively makes the PC unusable for normal work while Claude Desktop is installed. I'd love to keep using Cowork but can't until the VM is prevented from auto-starting when Cowork isn't active.

System: Windows 11, latest Claude Desktop version downloaded from claude.com/download (March 2026)

I'm having this issue too, and seemed to make progress by creating a batch file that runs Claude with a --disable-gpu flag to disable hardware acceleration. Claude itself suggested the fix, which seems to work. However, it's an obvious workaround. The right fix is probably to offer a disable hardware acceleration toggle in settings.

It has something to do with gpu hardware acceleration, or more simply frame scheduling.

One of my monitors is a normal gsync compatible panel, which suffer badly for <70hz displaying, and it seems that now claude desktop has dynamic frame generation based no UI or system updates. This causes electrop to constantly go from 0fps rendering upto the current monitor max one, causing a spike in desyncronization between cpu and gpu busy state and the other forced to a wait state

EDIT:

also, for those interested in disabling gpu acceleration you can simply click the burger menu top left -> help -> troubleshooting -> Disable Hardware Acceleration

Still remember when this was a vscode issue a few years ago...

I have the same issue on two separate computers. It's extremely annoying, mouse stutters and the dark background slightly flickers. I'm surprised this hasn't been fixed for more than half a month as it's a serious issue. (Not sure if that matters, but my setup is similar to what others described: Windows, ultrawide screens, RTX 3080/RTX 4080.)

EDIT: The workaround as suggested by sandros94 helped. When disabling hardware acceleration the issue disappears.

It's definitely VRR (e.g. G-Sync) related as @sandros94 mentioned. Turning off G-Sync fixes it.

You can use the Nvidia Control Panel or the Nvidia Profile Inspector to set Claude to use fixed refresh rate, but every time you switch between apps the monitor has the re-adjust so it's not a good solution.

ChatGPT Desktop, and many Electron apps, also suffer from this.

But it's definitely fixable, because some Electron apps like VS Code / Slack / Discord / Notion / etc don't suffer from this nowadays.

I'm able to reproduce the same issue. Ultrawide monitor, Win 11, GPU (RTX 5070), G-Sync enabled. Disabling GPU acceleration in "Help -> Troubleshooting -> Disable GPU Acceleration" was the viable workaround.

Update this morning broke my workaround. --disable-gpu seemed to make things usable yesterday, but now nothing works. Claude Desktop is completely unusable until this is resolved.

The MSIX packaging blocks every known GPU flag workaround
--disable-gpu was a working fix before the Cowork/MSIX migration
NVCP per-app profiles also can't reach MSIX executables
Anthropic should either restore a traditional EXE installer option or add a hardware acceleration toggle in Claude Desktop's settings

Disabling GPU acceleration fixed the lag for me!!.

_Windows 11, RTX 4090, dual monitor setup (primary 2560x1440 165Hz), Intel 13900k. Immediate improvement in mouse stutter and general responsiveness._

Just want to reiterate what has been said already. Disabling GPU acceleration did the trick.
Menu at the top left -> Help -> Troubleshooting -> Disable Hardware Acceleration. No need to edit shortcuts to add a flag.

Small update: I just tested Claude v1.1.8359 (64248d) everything seems to be working correctly with GPU acceleration enabled. Tho I recently updated nvidia studio drivers (595.79), which I didn't test before updating Claude 😅

Small update: I just tested Claude v1.1.8359 (64248d) everything seems to be working correctly with GPU acceleration enabled. Tho I recently updated nvidia studio drivers (595.79), which I didn't test before updating Claude 😅

Thanks for the update, unfortunately the v1.1.8359 didn't resolve it for me (Game Ready drive). Back to Disable Hardware Acceleration I go.

I came back to this thread and saw people saying they could turn hardware acceleration back on, so I tried it. It immediately started causing stuttering for me.

I then noticed some new NVIDIA drivers had just come out that same day, GeForce Game Ready Driver, Version 595.97, released Tue Mar 24, 2026. After installing them, everything's buttery smooth. In fact, it feels even smoother than before.

> Small update: I just tested Claude v1.1.8359 (64248d) everything seems to be working correctly with GPU acceleration enabled. Tho I recently updated nvidia studio drivers (595.79), which I didn't test before updating Claude 😅 Thanks for the update, unfortunately the v1.1.8359 didn't resolve it for me (Game Ready drive). Back to Disable Hardware Acceleration I go.

Try NVIDIA drivers Version 595.97, released Tue Mar 24, 2026.

> > Small update: I just tested Claude v1.1.8359 (64248d) everything seems to be working correctly with GPU acceleration enabled. Tho I recently updated nvidia studio drivers (595.79), which I didn't test before updating Claude 😅 > > > Thanks for the update, unfortunately the v1.1.8359 didn't resolve it for me (Game Ready drive). Back to Disable Hardware Acceleration I go. Try NVIDIA drivers Version 595.97, released Tue Mar 24, 2026.

That's it thanks. I thought I was on the latest driver because I only updated last night. Didn't realise there's a new one today. It's all working fine now!

Thank you both @pudDesign and @wywywywy for testing and reporting back.

This suggests that it might mainly be related to nvidia drivers themselves. Studio drivers are the same as game ready ones, but do go through many more test environment before being released (this is why their releases are slower). Once a studio driver has been validated then it lands as both studio and game ready.
Usually I exclusively use studio drivers because of this, the only exeption is that from time to time they do release a hot-fix for studio, but in a game ready driver, hence why I was on game ready one this time around.

Now I wonder if this is purely an upstream issue or claude desktop could intercept such bug

If I had to guess the issue is better than before, but not gone for me. Still a bit lagging on my Ultrawide and in full screen mode its also a bit worse but still better since my last comment

Just updated the desktop app from v1.1.8359 to v1.1.8629 five mins ago, it's broken again :(

v1.1.8629 five mins ago, it's broken again :(

lol Yep, same :( . So I have again disabled acceleration.

I disabled hardware acceleration and now it takes 100% of my cpu load attempting to open, it's completely bricked and i need to reinstall.

in case anyone bumps in the same situation, revert the setting here:
isHardwareAccelerationDisabled: true in ~/Library/Application Support/Claude/claude_desktop_config.json

I disabled hardware acceleration and now it takes 100% of my cpu load attempting to open, it's completely bricked and i need to reinstall.

I'm in the same boat here. High PC stats (96GB ram, 5080, 9950X3D), multiple ultrawide monitors. As soon as I open Claude desktop app the PC drags and cursor visibly lags unless I disable hardware acceleration. So far works with it disabled.

Corroborating report — complete system crash

On 2026-03-31 a Lenovo ThinkStation PX (Windows 11 Pro for Workstations) experienced a complete hard freeze requiring a power cycle, coinciding with a Claude Desktop update. Symptoms beforehand were intermittent mouse freezes and speaker beeps. A second incident with identical symptoms during a later update recovered without a power cycle.

Hardware is not a constraint (100+ cores, large RAM) — this seems to be purely a Claude Desktop issue.

Seconding the request for the Cowork VM to be opt-in only.

<html>
<body>
<hr>
<p><strong>Experiencing the same issue.</strong> Mouse cursor stutters/teleports when the Claude Desktop window is visible. Stops immediately when minimized.</p>
<h3>System Info</h3>

Component | Value
-- | --
Claude Desktop | 1.1062.0.0 (MSIX/Store)
OS | Windows 11 Pro Build 26200
CPU | AMD Ryzen 7 9800X3D
GPU | NVIDIA GeForce RTX 5090 (Driver 32.0.15.9597)
RAM | 128 GB
Monitor | LG 38GL950G — 3840×1600 @ 144Hz via DisplayPort
Mouse | Logitech G502 X PLUS (wireless, 1000Hz polling)

<h3>Observations</h3>
<ul>
<li><code>nvidia-smi pmon</code> shows Claude consuming <strong>2% GPU SM, 4% GPU memory</strong> while completely idle — all other apps (Discord, Steam, Explorer) show 0%</li>
<li>Window size does not matter — even a very small Claude window triggers it</li>
<li>Other Electron apps (Discord) do <strong>not</strong> cause this</li>
<li>Disabling Windows transparency effects had no effect</li>
<li>NVIDIA power management set to "Prefer Maximum Performance" had no effect</li>
<li>MSIX packaging prevents disabling hardware acceleration via Electron flags</li>
</ul>
<h3>Additional troubleshooting done</h3>
<ul>
<li>Disabled USB Selective Suspend — fixed a separate general mouse teleporting issue but not Claude-specific</li>
<li>Disabled integrated AMD Radeon iGPU — fixed a separate window drag stutter but not Claude-specific</li>
</ul>
<p>Confirms this affects AMD platforms (9800X3D) and latest-gen GPUs (RTX 5090) as well, not just Intel/RTX 4000 series.</p>
<hr>
</body>
</html>

I've also experienced this bug with the Claude Desktop app.
Claude 1.1617.0 (8d6345) 2026-04-09T16:10:15.000Z
Windows 26200.8037
NVidia Driver 595.97
I'm sure the mouse is not related but it is a wired 1000Hz Razer mouse.
CPU: 7600X
GPU: RTX4090
1440p GSYNC monitor with 120Hz target (framerate drops to the 30s when this bug triggers).
Task Manager shows no significant increase in CPU or GPU usage.

The bug triggers intermittently when Claude Desktop is open. Mousing over icons seems to trigger it?
For example: foreground the Claude Desktop app, mouseover the icons on the left strip (search/customize/chats/projects/artifacts). This alone drops the FPS to 25-90 Hz.

My whole experience with both Claude in the terminal and Cowork on Windows has been terrible. Months have passed and nothing seems to improve. It is the worst experience I have ever had with a Windows app. In the CLI, it would also affect the performance of the whole workstation. At least within the app, it does not freeze the entire system.

You could put your frontier model to work.

Claude Version 1.1617.0 (8d6345)
NVidia Driver 591.86 / RTX4090
Win11 PRO 26200.8117
i9-12900K
Multi monitor setup

Confirming @wywywywy's March 5 finding — additional diagnostic observations
Fully agree with the G-Sync / VRR root cause identified earlier in this thread. Adding a few observations that might help narrow down a fix:
The SteamVR clue: When SteamVR was running on my setup, Claude Desktop had zero lag. Closing SteamVR caused my GSync displayto briefly re-detect its DisplayPort source (signal renegotiation, no blackout), and lag returned instantly. SteamVR automatically disables G-Sync during VR sessions — that was the silent fix, and what eventually led me to the VRR connection.
Important nuance: Setting G-Sync to "Fullscreen only" in NVIDIA Control Panel does not fix the issue. G-Sync must be fully disabled for Claude Desktop to run without freezes.
Monitor isolation test: With only a secondary 16:9 1440p screen (no G-Sync), Claude runs perfectly at any refresh rate or resolution. Issue is 100% isolated to the G-Sync-enabled on my main display monitor (Alienware AW3423DW).
As @wywywywy noted, VS Code / Slack / Discord / Notion don't have this problem — so it's definitely fixable on Anthropic's end without users having to disable G-Sync globally.

I'm experiencing the same issue!

This is still an issue with the new version of Claude Desktop they announced today (Apr 17 2026).

As of today(April 19th 2026) this is also happening on my linux machine.

Adding a related-but-mechanistically-distinct sub-variant to this thread, plus quantitative trace data. The G-Sync/VRR frame-scheduling root cause that @sandros94, @wywywywy, @PoOlluX and others triangulated is real — but I'm seeing a separate bug in the same renderer that the existing workaround doesn't cover, and there's a real cost to the "disable hardware acceleration" remedy that I don't think has been flagged in this thread yet.

Different trigger, same underlying renderer

Long Opus 4.7 1M-context Claude Code session with many auto-compactions. Idle UI is fluid — scrolling, typing, mouse tracking all responsive (INP = 112 ms, "good"). Lag only appears during agent activity — streaming tokens, sub-agent spawns, expanding tool-use / thinking / editing bubbles — and only on the currently-focused session. Switching to another chat releases the lag instantly. On v1.3561.0.0 (MSIX).

Chrome DevTools Performance trace

171 s, 1.99M events; 42.9 MB .gz available on request.

• 91 main-thread long tasks > 50 ms (58 over 500 ms, 18 over 1 second)
• Worst single task: 5.01 s
• Time in GC: 71.8 s = 41.9% of trace
• Major concurrent marking rescheduled: 29,237 events — V8 cannot finish major marking before new allocations invalidate it
• jsEventListeners: 7,446 → 24,361 (+227 %) in 3 min of use — directly corroborates @J3-code's MaxListenersExceededWarning observation
• DOM nodes: 121,102 → 258,326 (+113 %)
• JS heap: 491 MB → 1,098 MB (+124 %)
• Layout + Paint + Raster total: ~9 s of 171 s — rendering pipeline is healthy, bottleneck is 100 % JS + GC on the main thread

Why this differs from the G-Sync story

Long tasks are dominated by RunMicrotasks (streaming-chunk Promise resolution cascades), not Layout / Paint. Listener bursts cluster around agent streaming activity, not SkillsPlugin's 60 s cadence — every streaming burst adds ~2,700 listeners in <300 ms (20 such bursts in the trace). Hardware is capable and fully utilized (RTX 5090 Laptop + Ryzen AI 9 HX 370, 64 GB, 240 Hz panel, hardware acceleration on); Chrome on the same machine is buttery smooth. Bottleneck is allocation churn in the renderer JS, not GPU/compositor frame scheduling.

Likely fix surface: batching streaming state updates (startTransition / rAF throttling), memoizing message / tool-use components, and fixing the cleanup-on-unmount path that's leaking ~2,700 listeners per streaming burst.

Heads-up on the "Disable Hardware Acceleration" workaround

It has a real cost on Windows MSIX that's worth knowing before following it. Setting isHardwareAccelerationDisabled: true (via Help → Troubleshooting, or directly in %APPDATA%\Claude\claude_desktop_config.json) causes Electron to fall back to --use-angle=d3d11-warp-webgl and --disable-gpu-compositing across all renderers — observable in the process command lines. That means CPU-side rasterization + compositing via Microsoft's WARP software rasterizer. On high-refresh-rate displays this produces a different app-wide animation stutter — empirically confirmed on this same machine before re-enabling HA today. On a 240 Hz panel, software compositing can't keep up even with non-trivial UI. So the workaround trades the G-Sync stutter for CPU-bound software-rendering stutter. Matches @jasonrdunne's "100% CPU load attempting to open, completely bricked" and @cambriel-cpu's observation that the MSIX migration broke GPU-flag workarounds generally.

Related, likely same pathology cluster

• #10881 (open): long-session + auto-compaction degradation — same trigger pattern
• #42045 (open): high-refresh + streaming output lag, no maintainer response
• #31666 (closed as invalid): renderer memory explosion on Windows MSIX, measurements match ours nearly exactly
• #31643, #4896 (closed): React render loops from SkillsPlugin, same listener-leak surface
• #48299 (closed as duplicate, canonical issue not traceable without auth)

Happy to share raw trace, per-second listener/GC time-series, pre- vs post-compaction scrollback size differential, or any other slicing that'd help the team reproduce.

Same here

I just downloaded the desktop app and right away had this issue. App was unusable due to strong flickering and stutters. Turning off Gsync or hardware acceleration both fixed it, but that should not be the solution.

I built a small Windows/NVIDIA telemetry tool called WTG for this kind of debugging: figuring out whether a workload is really using the NVIDIA GPU, or whether Windows Task Manager is just not showing the relevant activity clearly.

Project page:
https://ninja-neer.net/

GitHub:
https://github.com/novovictus/WTG

Basic test:

.\wtg.exe --watch 250

Run that side-by-side with the workload and compare Task Manager, VRAM movement, GPU utilization, and power draw.

If Task Manager is flat but WTG shows VRAM/power/utilization movement, the GPU may be active and Task Manager may be misleading. If WTG is also flat, the workload probably is not reaching the NVIDIA GPU.

Happy to help interpret output if anyone posts a sample or emails [wtg@ninja-neer.net](mailto:wtg@ninja-neer.net).

Re: Suggested Fix #3 — passing Electron GPU flags to the MSIX/Store build (and a less-drastic alternative to the built-in "Disable Hardware Acceleration" toggle)

⚠️ Unofficial, temporary workaround. It relies on undocumented launch behavior of the packaged build, so a future Claude / Electron update may change this and break the method (or, hopefully, make it unnecessary). Use at your own risk.

Same root cause several people here triangulated (NVIDIA dGPU + high-refresh / VRR display, DWM ↔ Electron GPU-compositing). I originally posted this in #56805, which was closed as not planned, so I'm moving it here where it's actually relevant. (cc @sigma4x — flagging this for the OP of #56805, since that thread was closed before any fix landed and this is the same problem.)

Two things this adds to the thread:

1. A more surgical flag than the in-app toggle. The built-in Help → Troubleshooting → Disable Hardware Acceleration works for most people here, but it disables the GPU entirely — which is likely why a few report 100% CPU on launch or worse painting afterward. --disable-gpu-compositing is narrower: it keeps GPU-accelerated rendering and only turns off the GPU compositing layer that fights DWM/VRR. That removes the mouse / view-switch stutter for me without giving up GPU rendering.

**2. How to pass any Electron flag to the MSIX/Store build** — exactly the gap called out in Suggested Fix #3. The Store/MSIX build ignores normal CLI args, and launching the exe directly fails (no package identity). Solution: launch the packaged app via IApplicationActivationManager::ActivateApplication, passing the flag as the activation arguments. Those arguments land on the process command line, so Chromium reads the switch and propagates it to the renderers. (--remote-debugging-port is separately blocked and makes the app exit, but --disable-gpu-compositing is accepted and persists.) Full disclosure: I worked this activation-manager path out with AI assistance, then confirmed it sticks with the verify command below.

$Aumid = 'Claude_pzs8sxrjxfjjc!Claude'   # confirm via:  Get-StartApps | ? Name -eq 'Claude'
Add-Type -TypeDefinition @'
using System; using System.Runtime.InteropServices;
[ComImport, Guid("2E941141-7F97-4756-BA1D-9DECDE894A3D"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IApplicationActivationManager {
    int ActivateApplication([In] string appUserModelId, [In] string arguments, [In] int options, [Out] out uint processId); }
[ComImport, Guid("45BA127D-10A8-46EA-8AB7-56EA9078943C")] public class ApplicationActivationManager { }
public static class L { public static uint Go(string a,string b){ var m=(IApplicationActivationManager)(new ApplicationActivationManager()); uint p; m.ActivateApplication(a,b,0,out p); return p; } }
'@
# Quit Claude first (single-instance lock), then:
[L]::Go($Aumid, '--disable-gpu-compositing')

Verify it stuck:

Get-CimInstance Win32_Process -Filter "Name='Claude.exe'" | ? CommandLine -match 'disable-gpu-compositing'

Update (re-confirmed after the Store auto-update on 2026-05-27, 08:00 JST / UTC+09:00): Still works on Claude 1.9255.0.0 (Electron 41.6.1), up from 1.8555.2.0. The package family name / AUMID (Claude_pzs8sxrjxfjjc!Claude) and the activation-argument injection are unchanged across the update, so the method survives Store updates. One caveat if you script the relaunch: the app now takes a bit longer to release its single-instance lock on quit, so add a short wait (or verify the flag landed and retry) before re-launching — otherwise the relaunch can attach to the still-dying instance and the flag gets dropped.

Wrap it in a .ps1 + a shortcut (pwsh -WindowStyle Hidden -File ...) and launch Claude from that instead of the Store tile (also disable launch-at-login so it doesn't start without the flag).

Env: RTX 3070, 3440×1440@120 Hz ultrawide, Win11, Claude 1.8555.2.0 (Store).

A built-in "disable GPU compositing" option — distinct from the existing full hardware-acceleration toggle — would remove the need for this and avoid the side effects of disabling the GPU outright.

_Note: English isn't my first language — I used AI to help translate and word this comment, so apologies for any awkward phrasing._

bump

Following up on my March comments with new data, since this issue is still unfixed and has had no staff response since February.

New data points from my system that rule out two recurring theories:

• It is not a multi-GPU / hybrid graphics problem. My machine is a desktop with a single RTX 4090 and the i9-13900K's iGPU disabled in BIOS, so there is no adapter ambiguity, and the stutter reproduces all the same.
• It is not fixed by driver updates. I'm now on 596.49, newer than the 595.97 that temporarily fixed it for me in March before app v1.1.8629 broke it again the next day. Driver updates are not a durable fix; something in the app keeps re-tripping this.

My setup matches the pattern in this thread: Windows 11 24H2, NVIDIA dGPU, native G-Sync primary display (PG279Q, 1440p 165Hz), Store/MSIX build. The trigger matches @HermiG's measurement exactly: the stutter only occurs when hovering the left sidebar (nav tabs and recent chats), never when moving the mouse over the conversation area. That's consistent with the mechanism several people have converged on here: sidebar hover highlights repaint over always-on backdrop-blur surfaces (the bundle ships dozens of backdrop-blur classes with no hover-scoped variants), producing bursty, irregular frame presents, and windowed G-Sync/VRR retimes the physical refresh to chase that cadence. The chat area has no hover targets, so nothing presents and the refresh stays pinned.

I can also confirm @iwata-1116's IApplicationActivationManager launch with --disable-gpu-compositing works on the current Store build (1.12603.1, Electron 42.4.0). Flag verified on the process command line, stutter completely gone, hardware acceleration otherwise still active. That a compositing-only change fully resolves it further confirms the problem lives in the present/compositing path, not rasterization, drivers, or input.

At this point the thread contains a complete diagnosis: the mechanism, a measured repro (refresh collapsing to 25-90Hz on sidebar hover), a minimal proven mitigation, and the standard solution. VS Code, Discord, and Slack all shipped occlusion-based frame throttling for exactly this class of Chromium-on-Windows issue years ago, which is why none of them stutter on the same machines. This is fixable at the app level without waiting on Chromium, NVIDIA, or Microsoft.

Four months, 40+ comments, multiple bot-closed duplicates, and no acknowledgment. Could someone from Anthropic please pick this up?

bump, I also have the same problem.
CPU: i5-12400F
GPU: NVIDIA GeForce RTX 3080 Ti
Monitor: GSYNC 165hz

This may be related to VRR, I disabled GSYNC on the nvidia control panel and the problem went away.

Edit: I see this has been discussed already, consider this additional confirmation.

Can confirm, having the same issue. I just upgraded to an NVIDIA RTX 5080 from an NVIDIA 3080 Ti, and didn't have this issue at all with the 3080 Ti. Can confirm disabling hardware acceleration fixes it, and, in addition, disabling G-Sync fixes it.

It's clear that Anthropics don't monitor Github issues. I've sent an email to feedback@anthropic.com and I hope someone will look at it.

Please send an email to feedback@anthropic.com too if anyone has time.