Thermals & fans

Your Mac Is Hot. Is It Actually Throttling?

Heat, loud fans, and a slow benchmark are clues—not proof. The useful signature is sustained load while CPU power and P-core frequency fall together.

The short version

  • Thermal throttling is protection working: macOS reduces performance to keep heat under control, not because throttling itself has damaged the Mac.
  • The strongest observable signature is constant CPU demand while P-core frequency and CPU power fall together; Stanislas reported that pattern on his M2 MacBook Air in his December 27, 2025 MacThrottle write-up.
  • Apple’s powermetrics reports thermal pressure rather than degrees. Its current five-level vocabulary is Nominal, Moderate, Heavy, Trapping, and Sleeping.
  • ProcessInfo.thermalState uses a different four-state vocabulary—nominal, fair, serious, and critical—so screenshots from the two interfaces are not directly interchangeable.
  • Persistent Heavy pressure while the Mac is genuinely idle deserves investigation: first check for a runaway process, then airflow, visible vent obstruction, and a possible hardware or sensor problem.

What is thermal throttling on a Mac?

Thermal throttling is macOS deliberately reducing chip performance when heat or power pressure becomes too high. It is a protective response—not evidence that throttling itself has damaged your Mac.

That distinction matters. A hot chassis is not proof of throttling. Loud fans are not proof either. Fans may be holding the chip at full performance precisely because they are removing the heat successfully. A fanless MacBook Air can throttle without making a sound. The case can feel warm while the processor remains comfortably inside its managed operating state.

Apple does not publish one universal CPU temperature at which every Mac throttles. Different chips, cooling systems, workloads, room temperatures, and power modes reach equilibrium differently. I covered that problem in the companion guide to safe MacBook temperature: a degree reading without context is an excellent way to manufacture panic from a functioning control system.

What you can observe is the control system acting. Under a stable, sustained CPU workload, the demand stays high while the chip’s frequency and power consumption fall. macOS is doing less work per unit of time because continuing at the earlier frequency and power would produce more heat than the machine can shed.

That is the signature worth measuring.

PROCESSINFO.THERMALSTATE public Foundation API · four states nominalwithin normal limits fairslightly elevated serioushigh criticalperformance significantly affected POWERMETRICS PRESSURE OSThermalNotification.h · five levels 0Nominal 1Moderate 2Heavy 3Trappingnot reached in test 4Sleepingnot reached in test EMPIRICAL MAPPING reported by Stanislas M2 Air · Dec 27, 2025 Two interfaces. Two vocabularies. Do not mix the labels.
Apple’s public ProcessInfo.ThermalState has four documented states; powermetrics reports five pressure levels from OSThermalNotification.h. The dotted mapping is what Stanislas reported observing on one M2 MacBook Air (Dec 27, 2025) — empirical, not Apple documentation; he did not reach Trapping or Sleeping.

The signature: demand stays high while frequency and watts fall

Suppose a CPU workload begins with the performance cores running at a stable high frequency and the CPU drawing a corresponding amount of power. The Mac warms up. Fans rise if the model has them. Nothing unusual yet.

Now keep the workload constant.

If CPU demand remains pinned but P-core frequency falls, that is one clue. If reported CPU power falls at the same time, that is a second. If thermal pressure moves from Nominal or Moderate to Heavy, the three signals form a much stronger case:

  • The work still wants the CPU.
  • The CPU is being permitted to consume fewer watts.
  • The performance cores are running more slowly.
  • macOS reports elevated thermal pressure at the same time.

Stanislas described exactly this pattern on his M2 MacBook Air in a December 27, 2025 article: CPU usage remained at a reported 100% while power consumption and performance-core frequency fell. He also reported encountering throttling on a 14-inch M4 Max MacBook Pro, which is a useful reminder that “M4” is not a cooling system.

One falling number is not enough. Frequency changes constantly during normal scheduling. Power falls when a workload reaches a lighter phase, waits for memory, blocks on disk, or moves work to another part of the chip. Utilization can remain visually high while the instructions being executed change.

I want correlation across repeated samples. Constant workload, sustained demand, falling frequency, falling power, rising pressure. Anything less is a clue, not a verdict.

Also mind Activity Monitor’s percentage convention: one process can exceed 100% because macOS adds usage across CPU cores. What matters here is not one magic percentage. It is that demand remains consistently high while delivered frequency and power decline.

How to run a Mac thermal throttling check with powermetrics

Use a workload that already exposes the problem: your normal compile, export, render, simulation, or other repeatable task. Do not manufacture a ten-minute furnace merely to prove that a thermal controller exists. Every modern processor will eventually negotiate with physics if you ask rudely enough.

Open Activity Monitor and watch the CPU tab so you can confirm that the workload remains active. Then open Terminal and run:

sudo powermetrics \
  --samplers cpu_power,thermal \
  --show-plimits \
  -i 1000 \
  -n 120

That requests one sample per reported 1,000 milliseconds for a reported 120 samples. It reads system metrics and exits; it does not change fan policy or disable any protection.

Exact field names vary by Mac and macOS build. On Apple Silicon, look for lines resembling:

P-Cluster HW active frequency: … MHz
CPU Power: … mW
Current pressure level: Nominal

Some machines expose additional cluster, residency, frequency-limit, or power-limit fields. Intel output differs. If --show-plimits produces nothing useful on your model, the frequency, CPU-power, and thermal-pressure lines still carry the main argument.

Start sampling before the workload reaches its hot plateau. The early samples become your same-machine baseline. Then compare three windows:

  1. The workload’s initial stable phase.
  2. The point where the chassis and cooling system have warmed.
  3. The later steady state, after frequency and fan behavior have settled.

Do not compare your watts with somebody else’s screenshot. Apple’s own powermetrics --help warns that its power values are estimated, may be inaccurate, and should not be used for comparisons between devices. They are still useful as a within-run trend on one Mac: I care that the reported CPU power fell while demand stayed constant, not whether the absolute reading deserves laboratory accreditation.

The units may be milliwatts. A reported 15000 mW, for example, is 15 W; that conversion is arithmetic, not an accuracy upgrade. Keep the native values if you prefer. The slope is the evidence.

If the output is overwhelming, run the thermal sampler alone in a second pass:

sudo powermetrics --samplers thermal -i 1000 -n 60

That shows pressure, not temperature. It cannot tell you which application created the load, so keep Activity Monitor visible beside it.

NOMINAL MODERATE HEAVY WORK DEMAND 100% pinned · constant workload P-CORE FREQUENCY baseline index = 100 falls under unchanged demand CPU POWER baseline index = 100 falls in parallel start warm-up steady state normalized indices — conceptual, not measured values pattern reported on an M2 MacBook Air — Stanislas, Dec 27 2025
Conceptual diagnostic pattern—not a universal threshold. Normalize the first stable samples from your own Mac to 100; confirm the fall with your captured MHz and mW values. Pattern reported on an M2 MacBook Air by Stanislas, December 27, 2025.

macOS thermal pressure levels, decoded carefully

macOS exposes two vocabularies that are routinely mashed together online.

The public Foundation API, ProcessInfo.thermalState, has four Apple-documented states:

  • nominal: within normal limits.
  • fair: slightly elevated.
  • serious: high.
  • critical: performance is significantly affected and the device needs to cool.

The lower-level pressure interface used by powermetrics has five labels. Apple’s OSThermalNotification.h header enumerates them as numeric states reported from 0 through 4:

  • 0 — Nominal
  • 1 — Moderate
  • 2 — Heavy
  • 3 — Trapping
  • 4 — Sleeping

Those names are real. Their precise user-facing semantics are not publicly documented with the same clarity as ProcessInfo.ThermalState.

Stanislas reported an empirical mapping on his M2 Air: Nominal aligned with .nominal; both Moderate and Heavy appeared while the public API still said .fair; his actual frequency-and-power drop appeared at Heavy. He did not personally reach Trapping or Sleeping, so assigning theatrical promises to those states would be fiction. The MacThrottle repository similarly describes Heavy as active throttling and combines the final two states into a critical presentation.

My practical reading is deliberately conservative:

  • Nominal: no pressure evidence supporting a throttling claim.
  • Moderate: elevated pressure; watch the trend, but do not declare throttling from the label alone.
  • Heavy: strong corroborating evidence when frequency and power are falling under constant demand.
  • Trapping or Sleeping: severe pressure states defined by the interface. Stop the test, allow the Mac to cool, and investigate why it got there rather than trying to reverse-engineer a precise promise from an undocumented label.

Then there is:

pmset -g therm

The installed pmset manual says this shows thermal conditions affecting CPU speed and warns that it is not available on every platform. On some Apple Silicon Macs it may report no recorded warning or no supported CPU power status. That absence does not prove the Mac never throttled. powermetrics is the more useful live observation here.

Does an M4 MacBook thermal throttle?

Yes, an M4 MacBook can thermal-throttle. That statement is almost boring: the thermal controller exists so the machine can reduce heat before reaching unsafe conditions.

The useful question is when a particular M4 model throttles under a particular sustained workload. A fanless MacBook Air and a fan-cooled MacBook Pro do not have the same thermal envelope merely because both carry an M4-family chip. A base chip, Pro, and Max also do not produce the same heat under full load.

Stanislas reported reaching throttling on his 14-inch M4 Max MacBook Pro. That is one machine and workload, not a verdict on every 14-inch M4 Max. It does show why a model name cannot replace measurement.

Expect short bursts to behave differently from long runs. A compile that finishes before the cooling system saturates may complete at high frequency. A long render can settle at a lower sustained frequency. The second result is not necessarily a defect; it may be the machine’s designed long-duration performance.

Compare the same task on the same Mac, in roughly the same room conditions and power mode. Cross-model screenshots are entertainment. Same-machine traces are evidence.

When Heavy pressure at idle means something real

A brief Heavy reading immediately after a workload is not mysterious. The workload stopped; the heat did not teleport out of the chassis. Give the cooling system time to recover.

Persistent Heavy pressure after the Mac has genuinely returned to idle is different. First verify the word “idle.” Open Activity Monitor, sort CPU by % CPU, and look for a browser process, virtual machine, sync client, Spotlight job, Photos analysis daemon, or other process still doing substantial work. Apple’s April 2, 2026 operating-temperature guidance specifically tells users to check Activity Monitor for malfunctioning processes when a Mac remains warm without an intensive task.

If CPU activity is low but pressure stays elevated, check the physical conditions:

  • Put the Mac on a hard, stable surface with ventilation.
  • Remove anything covering the keyboard or vents.
  • Disconnect a setup change temporarily—dock, display, or unusual power arrangement—and observe whether the state changes.
  • On fan-equipped Macs, inspect the external vents for visible dust or obstruction. Do not push debris farther inside.
  • Confirm that fans are actually reporting RPM and responding under load, if your model has fans.

Apple says Mac laptops contain internal temperature sensors and that fan-equipped models turn their fans on automatically. A fan, sensor, or other hardware fault is therefore a possible cause when software load and airflow do not explain persistent pressure, but pressure alone cannot identify the failed component.

Restart and repeat the observation once. If the Mac returns to Heavy at idle, run Apple Diagnostics. A passing result does not make the observation imaginary: Apple says Diagnostics checks internal hardware but does not detect software conflicts. Record the conditions and seek Apple or qualified service if the pressure remains reproducible.

On Intel Macs, a large rise in kernel_task is the classic visible companion. Apple says kernel_task makes CPU capacity less available to intensive processes when temperature rises, then reduces its activity as the CPU cools. That makes it the messenger, not the heat source; the full explanation is in our kernel_task high-CPU guide.

Apple Silicon usually makes frequency and power changes less theatrically. Do not require an Intel-era kernel_task spike before believing the measurements in front of you.

1 · WAIT FOR RECOVERY workload just ended — pressure lags the work 2 · VERIFY IDLE Activity Monitor → CPU → sort by % CPU BUSY PROCESS FOUND identify that workload first CPU actually idle 3 · CHECK AIRFLOW hard surface · vents clear · fans reporting RPM RETURNS TO NOMINAL/MODERATE cooling recovered — stop here Heavy persists at idle 4 · RESTART + RUN APPLE DIAGNOSTICS persistent Heavy may indicate hardware or sensor trouble one label is a clue — the sequence is the evidence
Heavy at idle, worked in order: let the pressure lag clear, verify “idle” in Activity Monitor, check airflow and fans, and only then treat a persistent Heavy as a hardware or sensor question for Apple Diagnostics. No thresholds invented along the way.

What this test cannot prove

powermetrics is evidence, not a hardware diagnosis.

It cannot prove why thermal pressure rose. It cannot distinguish a dust-obstructed airflow path from a failing fan merely by printing Heavy. It cannot tell whether a workload changed phases unless you understand that workload. Its power figures are estimates, and labels or fields can differ across macOS versions and hardware.

A benchmark score by itself is weaker still. Scores change with background work, power mode, room conditions, compiler versions, test versions, and run-to-run noise. If a second run is slower, inspect the frequency, power, workload, and pressure traces before declaring heat the cause.

Nor is every throttle event undesirable. A fanless Air trading sustained frequency for silence is performing its design bargain. A Pro reducing frequency during an extreme long-duration load is using its protection. The problem worth pursuing is persistent, unexpected throttling during work the machine previously sustained—or high pressure while no meaningful work is happening.

Where CoreGuard fits—and where it does not

The command-line test above remains useful even if CoreGuard never existed. I am not going to pretend a friendly dashboard turns an estimated power reading into laboratory instrumentation.

CoreGuard’s job is to make the surrounding evidence easier to keep. The free version shows live temperatures, fan RPM, CPU, GPU, and RAM readings; a menu-bar readout; basic history with threshold alerts; and plain-English naming of the top app or process consuming resources. Every danger warning stays free. If the Mac is hot because a process is running away, knowing the process name is not a paid revelation.

Free history is basic history. I am stating that plainly because “history” is an easy word to stretch until it implies the paid product by accident.

Pro is a one-time $29 purchase for the deeper tools: longer trend history, per-app energy, CSV/JSON sensor-log export, and the PDF/JSON Condition Report. Those are useful when the event is intermittent or you need portable evidence rather than a recollection that “it got slow on Tuesday.” Pro also includes opt-in fan control, but it is off by default, clamped to the hardware’s supported range, watched by thermal safeguards, and returns control to macOS if CoreGuard exits. It does not disable throttling or overrule the Mac’s protection.

CoreGuard also does not invent a health score, predict a failure date, or pronounce a warm M4 defective. It observes and explains. The app is local-only, makes zero network connections, supports macOS 13 and later on Apple Silicon and Intel, and ships as a Developer-ID-signed, Apple-notarized app.

CoreGuard is pre-launch. You can get notified when it is available or see exactly what Free and Pro include.

Until then, the useful rule fits in one line: if the work remains, but frequency and watts leave, check thermal pressure. Heat is a sensation. Throttling is a pattern.

See what your Mac is actually doing.

CoreGuard is a local-only Mac health monitor: live CPU, temperatures, fan RPM, and the top process named in plain English — with history, so a spike you missed is still there when you look. It observes and explains; it never touches, deletes, or “fixes” your files.

launching soon · one-time purchase, not a subscription · 30-day money-back · local-only, zero telemetry

Sources & further reading

All insights