High GPU usage while the app is “thinking” due to tiny useless animation

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #16099

Powered by Codex Action

This did help thanks! I did also have to hide the "thinking" animation. GPU usage does go up a lot when scrolling too but at least I can use this and keep on screen without it eating through battery excessively. Hopefully they get this fixed soon!!

That's hilarious.
Was wondering why my FPS was just dropping like crazy when playing path of exile while codex was doing stuff

Good thing i use tui 🤣

@etraut-openai Could you please take a look on this?

@etraut-openai How to catch your attention?

The Codex TUI has a similar bug where a useless animation costs way too many resources, but it's definitely a different area of code. #11877. It was originally redrawing the entire TUI screen every 32ms. That one has a Codex-created fix, but user PR's aren't considered anymore. It was originally memory leaking 20GB (!) over 2-3 days under the right circumstances under tmux, but a code change for an unrelated reason happened to substantially reduce that. Now, it's just unnecessary resource usage but not a horrible memory leak.

Anyways, I took care of that one by cloning Codex and having it build itself, analyze the situation, and fix it.

In case OpenAI doesn't fix this, since you're using the non-open source GUI, I don't know if Codex will be able to see everything it would need to analyze and change. It's made in Electron, which makes me think it might be possible for Codex to come up with a fix for you, but I'm not very familiar with Electron. Maybe it can disable the animation, or maybe it can figure out how to make it use way less.

Unfortunately, you'd have to have Codex re-fix itself every time the app was updated, if OpenAI doesn't fix it.

:/

Profiled this on M3 Pro / macOS 26.4.1 / Codex 26.409.20454. Confirms the root cause.

What's happening

The thinking/shimmer animation is an infinite CSS animation that keeps Chromium's compositor subscribed to VSync indefinitely. The compositor correctly ticks every frame (~60 Hz) because cc::SchedulerStateMachine::BeginFrameNeeded() returns true as long as any animation is on the ticking list. Each tick forces a full GPU present cycle.

This is Chromium working as designed — the bug is the app never pausing the animation when it's not visible or not needed.

Profiling data

5-second sample at 1ms intervals + ioreg AGX stats + vmmap:

| Metric | Value |
|--------|-------|
| GPU Device Utilization | 62–68% sustained |
| GPU Memory In-Use | 1.2 GB |
| GPU Memory Allocated | 3.9 GB |
| Compositor thread (renderer) | 92% idle (kevent64), 8% active — wakes every VSync |
| GPU process CPU time (accumulated) | 42 min |
| WindowServer CPU | 52% |
| IOSurface regions (GPU process) | 162 regions, 277 MB resident |
| IOAccelerator regions | 1466 regions, 40 MB resident |

GPU process main thread call chain on each composite:

CA::Transaction::commit()
  → CA::Context::commit_transaction()
    → CA::Layer::commit_if_needed()  [6 layers deep, recursive]
      → CA::Render::Surface::Surface(__IOSurface*)
      → CA::Render::Encoder::send_message()  → mach_msg to WindowServer
        → [AGXG15XFamilyCommandBuffer renderCommandEncoderWithDescriptor:]
          → AGX::RenderContext::beginRenderPass()
          → AGX::RenderUSCStateLoader::setupRenderCommand()

Hiding the sidebar (collapsing the spinner) removes the animation from the ticking list → compositor stops subscribing to VSync → GPU drops to near zero. Exactly what @homm reported.

Fix

The animation should either:

• be paused/removed when not in viewport (Intersection Observer)
• respect prefers-reduced-motion (it currently doesn't without the launch flag)
• use will-change: transform with compositor-only properties and avoid full-layer invalidation

Workaround: --force-prefers-reduced-motion on launch.

Related: #10432, #16099, #10885

Codex problems need codex to solve.

Try this prompt, it looks good to me.

Patch the installed macOS app at `/Applications/Codex.app` to mitigate the high-GPU “T
hinking” bug from https://github.com/openai/codex/issues/16857.

Approach:
- Treat this as an installed Electron app patch, not a source-repo change.
- Unpack `Contents/Resources/app.asar`, search the web UI bundles for
`thinkingShimmer.default` / `loading-shimmer-pure-text`.
- Root cause: the tiny “Thinking” status uses a shimmer text animation in the Electron
UI, and that animation appears to drive unnecessary GPU usage.
- Apply a minimal fix: in the compiled CSS, disable the shimmer animation only for
Electron (for classes like `.loading-shimmer-pure-text`, `.loading-shimmer`, optionally
`.loading-shimmer-pure-text-inverted`) and render them as static text instead.
- Repack `app.asar`.
- Update `Contents/Info.plist` `ElectronAsarIntegrity` with the correct ASAR header
SHA256 hash, not the whole file hash.
- Re-sign the app and verify it launches.

same, when I switch to codex interface, gpu up to 100%

Same issue here, i really thought it was doing some sort of local processing embedding or something like that but it seems its just bad UI lmao.

@etraut-openai any updates?

Hello? this makes the codex app unusable on battery. please address this asap!

This has been going on for months. Seems utterly ignored.
Sometimes they mistake it for high CPU usage instead of GPU. Long live automated issue tracking.
For those interested, you can create a wrapper app using Automator, that runs as a shell script the command ``open "/Applications/Codex.app" --args --force-prefers-reduced-motion``.
You can then switch its icon with the codex one, by opening the info of both and copy/pasting the small icon in the top left.
Hope someone will take the apparently little time it takes to get this sorted.
At least a settings toggle, if nothing else.

<img width="394" height="446" alt="Image" src="https://github.com/user-attachments/assets/7baf8964-a58e-42a5-8d61-1589efe1d654" />
imaging codex app fuck my gpu even more than my game

19 days and nothing from OpenAI

Just hovering over the loading animation makes the usage go back to normal. Very strange bug

Just hovering over the loading animation makes the usage go back to normal. Very strange bug

That is probably because you are changing the loading button to an archive button. You probably shouldn't have more than two loading screens running at the same time.

100% GPU on M1. Codex makes my computer as hot as running local models. Fantastic...

Are you by any chance using external monitors, 4k scaled, high refresh rates?
Playing with the scaling and frequency makes a difference. In my case (Corsair Xeneon 4k 32" 144hz, running 3008x1692 120hz through usb-c on a mac mini m4), using native 4k and 60hz somewhat alleviates the issue.
Also, it is not limited to Codex. Happens in Claude desktop, happens in Edge and Chrome on websites with similar animations.
So it is either a Chromium compatibility issue with Mac OS (running latest 26.4.1) or a Mac OS introduced issue.

Anyway, quickest fix would be a toggle for reduce motion in Settings.
I am doing web work, so globally enabling Reduce motion is something I would avoid. But which also should work, by the way; at least in Edge, it does.

Experincing the same issue, M1 Macbook Pro runnign so hot and battery is draining in under 4 hours....

same issue ++

double 4k monitor ,mac mini,same issue ++

I'm on a 4k 160hz display, m4 pro

Can we have a toggle to just disable the animation altogether? App-wide?

Somebody's listening :) The reduce motion customization feature has been added in the latest Codex build.
I think we can mark this complete, as soon as we verify it.
Thank you!

Can you also make the reduce motion also apply to the sliding motion of the side bar and when a preview panel is opened?

Similar to OS X reduce motion removes those unnecessary sliding panel expand/collapse animations.

Thanks

I guess the reduce motion still is a workaround, not a permanent solution to the bug itself, so I wouldn't close this...

The way I see it, the actual problem may not be in Codex. The high GPU load happened in Claude and on various websites too, if certain conditions are met (similar animations), on the latest Edge and Chrome versions.
So the problem is either a Chromium optimization issue or maybe an Apple issue.
The reduce motion setting is the fastest way to go here, I'd say, apart from going in and tweaking the css of all animations.

Same issue, and it really needs to be fixed. Reduce motion is just a workaround.

On My Macbook Air M4 running macOS 15.7.3，this issue happens when I use an external 4K monitor and the usage is higher when setting higher refresh rate; but when using the internal display, the GPU usage is very normal. Also, when the usage is high, going into setting panel or change to another Desktop reduce it effectively.

Same issue. Extreme system loading

GPU usage drops from 70% to 3% by hiding side bar, Thanks alot.

Hiding the sidebar doesn't help me but minimising the Codex window to Dock does indeed drop GPU utilisation to 0%.
What an odd bug.

Bro, there's no way!!? That's so goddamn annoying! Now I have to disable Stageflight and minimize Codex each time I give it a task? Really? How did you not fix that yet, @OpenAI ?!

Thank you for identifying this 🙌🙌🙌🙌