kernel_task using high CPU on Apple Silicon

After this, kernel_task drops back to single digits and the fans spin down on their own.

Why this happens

On both Intel and Apple Silicon Macs, kernel_task is a placeholder process. When the SoC's temperature sensors approach a limit, macOS has kernel_task "occupy" CPU cycles on purpose — not because it needs them, but to keep other processes from scheduling onto hot cores and making things worse. That's Apple's own description of it (support.apple.com/en-us/102172), and it's worth reading literally: seeing several hundred percent CPU across cores is the throttle, not the cause. The actual cause is whatever pushed the chip toward that limit in the first place — most often a sustained heavy workload, blocked airflow, or a stuck fan. Less often, it's a third-party kernel extension pinning kernel time for no good reason; VPN clients, virtualization tools (Parallels, VMware), and some antivirus products show up repeatedly in user reports as the culprit, though none of this is something Apple documents or confirms — it's what people actually find when they go looking. This is the same underlying mechanism as thermal throttling with the fans stuck at max — kernel_task is the CPU-side symptom, throttled clock speed is the performance-side symptom, and they usually show up together.

Fix it

1. Open Activity Monitor (Applications → Utilities), sort the CPU tab by % CPU, and confirm kernel_task is actually the top consumer rather than a runaway app that merely looks like it. If you're already in Terminal, the equivalent one-liner is faster:

   ● Reads the system

   What it does: lists the eight processes using the most CPU right now.

   After: nothing changes, this only reads.

   ps -Ao pid,pcpu,comm | sort -k2 -rn | head -8

   Copy

   Output

     PID %CPU COMM
       0 612.0 /System/Library/Kernels/kernel
   88741  37.4 /Applications/Google Chrome.app/.../Google Chrome Helper (Renderer)
     606  17.1 /System/Library/PrivateFrameworks/SkyLight.framework/.../WindowServer
   89854  10.0 /Applications/Visual Studio Code.app/.../Code Helper (Renderer)
   30067   9.1 /Applications/Telegram.app/Contents/MacOS/Telegram
     610   9.0 /usr/sbin/coreaudiod

   On a healthy, idle machine the top line reads a few percent, not hundreds — the sample above is from a normal moment on the verification machine, shown so you can see the column format. When kernel_task is throttling, that top line is what climbs into the hundreds while the chip is under pressure.

2. Check whether macOS has actually recorded thermal pressure. This is the read that tells you if you're chasing a real throttle event or a red herring.

   ● Reads the system

   What it does: prints the current thermal and CPU speed/scheduler limits.

   After: nothing changes, this only reads.

   pmset -g therm

   Copy

   Output

   Note: No thermal warning level has been recorded
   Note: No performance warning level has been recorded
   Note: No CPU power status has been recorded

   That's the clean baseline captured on the verification machine — no warning recorded. One correction to older, Intel-era advice still floating around: the CPU_Speed_Limit / CPU_Scheduler_Limit percentage fields some guides mention don't exist on Apple Silicon at all — those are Intel-only fields. On an Apple Silicon Mac, this command only tells you whether a warning has been logged, not how severe it is.

   For a graded reading instead of a yes/no, sample the thermal pressure level directly — this is the same signal macOS exposes to apps through the public NSProcessInfo.thermalState API, reported as one of five internal levels (Nominal, Moderate, Heavy, Trapping, Sleeping):

   ● Reads the system

   What it does: samples the current thermal pressure level once.

   After: nothing changes, this only reads. Asks for your password since it needs root to read SMC sensors.

   sudo powermetrics --samplers thermal -i1000 -n1

   Copy

   A healthy machine reports Nominal. Anything past Moderate means the chip is actively managing heat right now — that's your confirmation, independent of whatever kernel_task's CPU percentage happens to read at that instant.

3. If thermal pressure is confirmed, buy the chip some headroom immediately by dropping into low power mode. This won't fix the root cause, but it lowers the ceiling the chip is trying to hit while you investigate.

   ▲ Changes settings

   What it does: enables Low Power Mode for all power sources.

   After: sustained CPU/GPU clocks drop, background activity is throttled, takes effect immediately.

   sudo pmset -a lowpowermode 1

   Copy

   Revert: sudo pmset -a lowpowermode 0

4. If the pressure keeps coming back under light, ordinary use (not sustained compiles or exports), a third-party kernel extension is a common cause — old VPN clients, some antivirus tools, and virtualization drivers are the usual suspects. List what's actually loaded outside of Apple's own set:

   ● Reads the system

   What it does: lists loaded kernel extensions, filtered down to non-Apple ones.

   After: nothing changes, this only reads.

   kmutil showloaded | grep -v com.apple

   Copy

   Output

   Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>

   That's the whole output on the verification machine — just the header line, meaning zero third-party kexts are loaded, which is the clean state you want. If your output has extra rows below the header, note the bundle name in the last column before continuing.

5. If step 4 turned up a third-party kext and its vendor confirms there's a known issue with no update available, removing the bundle stops it from loading on the next boot. Back up the .kext bundle first — copy it to an external drive or archive — since you may need to hand it to the vendor's support team or reinstall it once they ship a fix.

   ■ Irreversible

   What it does: deletes the named third-party kernel extension bundle.

   After: reboot required; the driver's functionality (VPN, virtualization, capture device, etc.) stops working until reinstalled.

   Back up first: copy the .kext folder somewhere safe before deleting it. There is no undo for this command — if you didn't back it up, you're reinstalling from the vendor's package.

   sudo rm -rf /Library/Extensions/VendorName.kext

   Copy

   Revert: not possible from this command alone — reinstall the driver from the vendor's official package.

Still broken?

If kernel_task keeps spiking with a clean kmutil showloaded and low power mode already on, look at these next:

• The fans are stuck at max and the case runs hot even at idle
• The Mac won't sleep because something is holding a power assertion — a process that's holding the machine awake is also usually the same one keeping it busy enough to trip the thermal limit.

When to take it to a shop

If pmset -g therm shows a warning level within minutes of an idle boot, with no heavy apps open and no third-party kexts loaded, that points at hardware: a fan not spinning up, a failed temperature sensor, or (rarely on Apple Silicon) a logic board issue. Run Apple Diagnostics (hold the power button at startup until options appear, then choose it) before booking a service visit — it will usually name the failing sensor or fan directly.

Verified on

The command syntax and read-only outputs above were captured live on the M3 / macOS 26.6 row.

Related problems

• Fans are stuck at max and performance drops under sustained load
• Mac won't go to sleep on its own even with the lid closed