Thermal throttling is the operating system deliberately reducing performance so a machine can shed heat faster than it makes it. It is a designed behaviour, not a fault. The practical questions are whether it is happening to you, how much it is costing, and which of the signals you can see actually answer that.
Most of them do not. Fan noise, chassis temperature, and the CPU temperature readings people usually reach for are all poor evidence, for reasons below. One signal answers the question directly.
The short answer
macOS publishes its own thermal state. Read that, not a thermometer.
pmset -g thermOn a machine with nothing recorded, this reports that no thermal warning level, performance warning level, or CPU power status has been noted. That is the clean result.
The programmatic equivalent is ProcessInfo's thermalState, which is available on every Mac, needs no sensor access, and reports what the system decided rather than what an observer inferred:
ProcessInfo.processInfo.thermalState
# .nominal | .fair | .serious | .criticalThe states, and what each costs
Apple documents four states and describes critical as the point at which thermal state is significantly affecting performance. It does not publish what the intermediate states cost, so the figures below are measured rather than quoted.
| State | What it means | Measured cost |
|---|---|---|
nominal | No thermal constraint | None. A 3B model held 115.05 tokens/second across 31 requests with a 1.2% spread. |
fair | Mildly elevated | Degradation begins. Two heavier workloads lost 26.3% and 32.9% of peak throughput here. |
serious | System reducing performance | Not reached in any run published here. Unmeasured rather than estimated. |
critical | Aggressive reduction | Not reached. Apple describes this as significantly affecting performance. |
The state most people treat as safe is where the cost starts. It is easy to read the four states as a switch that flips at serious. Measured across five models and 82 requests, that is not the shape. Throughput was flat at nominal and fell measurably at fair, with neither of the two heaviest workloads ever reaching serious. Waiting for serious before acting means acting after a quarter to a third of throughput has already gone.
The size of the loss tracked how hard the workload was. A small model that never left nominal did not decline at all across the same duration, which is what rules out elapsed time as the explanation.
Three signals that do not answer the question
Fan speed does not measure lost performance. Fans respond to accumulated heat, and they respond late. Measured on the machine above, both fans rose from 0 to roughly 5,000 RPM over about 100 seconds of sustained load, then stayed within about 2% of that plateau for at least 70 seconds after the work stopped and the GPU returned to idle. Loud fans mean the cooling system is working. They tell you nothing about whether you are being slowed down, and shortly after a run they are reporting a state that has already passed.
Temperature is the weakest signal available. Two things are wrong with it. Availability is inconsistent: readings come from best-effort SMC access, key names vary by Mac model and macOS release, and on the machine above, at Searoom 0.3.0, none of twelve candidate CPU and package keys returned a valid reading. The only readable sensor was the battery pack, which rose 7.5 °C, from 26.29 to 33.79, while the GPU ran above 97% for six minutes. A battery pack is not where the heat is made. A later build widened the probe with this generation's performance-core keys, Tp04, Tp08 and Tp0C, and on this same machine the package sensor now reads directly, labelled CPU PACKAGE: around 52 °C lightly loaded, past 70 °C under a twelve-core synthetic load, against the 100–105 °C region where M-series chips typically begin throttling. The figures in this page's measurements stay as they were recorded; only the sensor behind the newer readings changed.
Even a genuine core temperature is hard to act on, because the threshold at which any given machine reduces performance is not published, varies by chassis, and depends on ambient conditions. 95 °C means nothing without the limit it is being compared against.
Perceived slowness is not specific. Several unrelated causes produce it, and heat is only one. Rule the others out before blaming thermals.
Ruling out the cheaper explanations first
| Cause | Check | Signature |
|---|---|---|
| Growing workload | Restart the task from a clean state | Speed returns immediately |
| Low Power Mode | pmset -g | grep powermode | Slow from the first moment, machine stays cool |
| Memory pressure | vm_stat swap counters, twice, and subtract | Sustained swap traffic; everything else is slow too |
| Thermal throttling | pmset -g therm | Degrades over minutes, recovers after idle |
The shapes over time separate them without any tooling. Thermal throttling runs at full speed for a minute or two, declines as heat accumulates, plateaus, and recovers after the machine sits idle. Memory pressure does not recover on idle, because whatever is resident is still resident, and it degrades the whole machine rather than one workload. Low Power Mode is flat: slow from the first moment with no accumulation and no recovery. Apple documents Low Power Mode as reducing energy use to increase battery life and, on Macs with a fan, reducing fan noise; it publishes no figure for the effect on compute.
What actually helps
Give the machine a hard, ventilated surface. Apple's guidance is to use a Mac laptop on a stable work surface that allows for good ventilation, and specifically not in bed, on a pillow, or under bedding. Soft material against the chassis is the case that addresses. Apple does not publish where any given model draws its intake air, so be wary of advice that depends on a particular vent location.
Check the room. Thermal headroom is the gap between the chassis and the air around it. Apple specifies an ambient operating range of 10 to 35 degrees Celsius for Mac laptops, which is the envelope the cooling system is designed against.
Reduce the work per unit of output. For inference that means a smaller or more heavily quantised model. This trades quality for sustained rate, and it is the only lever here that changes the heat being produced rather than how it is removed.
Accept a lower sustained rate. Every machine has a sustained throughput below its peak, and a thin laptop has less headroom than a desktop enclosure. No configuration change removes that difference.
What will not help: closing applications, when the thermal state is the binding constraint. Freeing memory addresses a memory problem. If heat is the limit, memory headroom changes nothing.
Checking it yourself
Everything above uses tools already on the machine.
pmset -g therm # current recorded warning levels
pmset -g thermlog # streams until interrupted; start it before a long run
pmset -g | grep powermode # 0 is the default power mode
vm_stat | grep -E "Swapins|Swapouts" # run twice, subtractNote that pmset -g thermlog behaves differently from the others: it streams continuously and will not return on its own. Start it before a long run, leave it in a terminal, and read it afterwards.
Limits of the measured figures
The throughput costs on this page come from one machine, one chassis, one ambient temperature, and one class of workload. They show a direction and a rough magnitude, not a number to expect on a different Mac. The evidence is also correlational: heat and elapsed time rise together within a run and cannot be fully separated, though a model that never left nominal stayed flat across the same duration, which is the control that rules out time alone. Nothing measured here reached serious, so the cost of that state is unpublished rather than estimated.
Where these numbers come from
This page is a summary. The runs behind it, with full method and per-request figures, are in the field notes: five models under one sustained workload for the throughput costs by thermal state, why your Mac's fans spin up for the fan curve and the lag after load, diagnosing thermal throttling during long inference runs for the four-cause separation, and reading SMC sensors from Swift for why temperature is best-effort while thermal state is not.
To read these states without opening a terminal, five free Mac system monitors are compared side by side, licence and running cost included.
Definitions for every value named here are in the metric reference.