High Power Mode not applied by powerd after Migration Assistant (migrateenergyprefs related?)

High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs)

Summary

On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect.

Environment

  • Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM)
  • macOS version: macOS 26.5.1 (Build 25F80)
  • Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step
  • Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history

Symptom

  1. Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No.
  2. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly.
  3. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection.
  4. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced.

Investigation steps taken

1. Preference file inspection

Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number.

The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated.

2. Direct write test

Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state.

3. File deletion / regeneration test

Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause.

4. Binary-level investigation

Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found:

  • /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26)
  • /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630)
  • /System/Library/SystemProfiler/SPPowerReporter.spreporter/
  • /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/

The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does.

Reproducibility

  • Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely.
  • Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption.
  • Reproduced after a full reboot, ruling out a transient in-memory state issue alone.

Impact

Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration.

Questions for Apple

  • Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does?
  • Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes?
  • Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom?

Happy to provide a sysdiagnose or additional logs if useful.

So, let me start by clarifying a few details:

  1. Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No.

...

  1. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection.

What both of these actually show is the system’s current state. In the case of Low Power Mode, that means that switching to "Low Power" will change the state as you “force” the machine into low power; however, even in automatic or high power mode, you'll also see that idle machines show as "Low = Yes". The machine isn't doing anything, so it puts itself into low power mode.

  1. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly.

pmset is returning the kernel’s current configuration from IOKit, which means whatever it says is "true" at least as far as the broader system concerns.

That leads to here:

Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+).

A few questions:

  • Was this with the (paid) macOS app or the iOS App?

  • Were the fans running during your testing?

This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced.

No, not necessarily. There's another explanation, namely that you never actually reached "High Power" mode. I was curious enough about this that I actually gave this a try myself. My particular machine is a MacBook Pro M4 MAX with 48 GB of RAM and, running the iOS app, I consistently got a result of "7813" in 3D Mark without entering High Power Mode or the fans turning on.

That last point is critical— if the fans aren't turning on, then it's unlikely that you've pushed the machine hard enough. With a bit more experimentation, I was able to get the fan going, though I never actually got System Information to return "High Power Mode = Yes". As I'm writing this message, the machine is simultaneously running:

  • The iOS version of 3DMark Steel Nomad Stress Test from the App Store.

  • The iOS version of their older "Sling Extreme" benchmark from the App Store.

  • 4 copies of "Geekbench", all running the CPU test.

  • A variation of this code which has intentionally consumed ~71.08 GB of real memory, keeping it JUST below the threshold at which the kernel would have terminated it.

...none which have had ANY effect on the machines overall "feel" or seemed to change the results of the Steel benchmark. In other words, the problem here isn't that the machine won't enter High Power Mode, it's that the work being done simply isn't generating enough heat that the device will enter "High Power Mode". Note out description from this support article:

"High Power Mode allows the fans to run at higher speeds. The additional cooling capacity may allow the system to deliver higher performance in very intensive workloads. When High Power Mode is enabled, you may hear additional fan noise."

The key point here is that what triggers the transition here is "heat", not "work", so as long as the machine is staying "cool", we won't bother speeding up the fan.

Also, note this comment that follows:

"High Power Mode can improve performance in graphics-intensive workflows such as color grading 8K ProRes 4444 and 8K DNxHR video. In video editing and 3D applications, you may experience smoother playback and faster exports in High Power Mode."

The work being described there isn't just GPU/CPU bound, but also involves VERY heavy read/write I/O. I suspect that this issue here isn't just direct processor heat, but is actually the additional heat being generated by I/O to the flash. That's also why none of the benchmarks above triggered the crosshing, as none of them really "engaged" the I/O system.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

New observation: the "High Power" power state itself may have been changed/removed

Since my original post, I ran further tests and want to share a new data point that may reframe this issue.

Testing with another title (NTE), I observed a clear difference in total system power depending on the selected Power Mode:

  • Automatic: Total ~37–40W
  • High Power (selected via System Settings): Total ~55–57W

So the Power Mode selector does change something — switching to "High Power" measurably increases total system power draw in that workload. This means the setting itself is not entirely inert.

However, this is where it gets interesting. Comparing against third-party reviews (Notebookcheck) of this same model at launch:

  • Reviewed sustained power under Steel Nomad Stress Test: ~44W (powermetrics-equivalent Combined Power)
  • My sustained power under the same test, same conditions (fans pre-spun, GPU >95°C): ~27–30W

And on score:

  • Reviewed Steel Nomad Stress Test stabilized score: ~3600+
  • My stabilized score across 4 separate runs on the same day: 3142–3432

My current working theory is that the "High Power" flag/state itself is functioning correctly as a switch, but the power ceiling it switches to may have been lowered in a firmware/OS update since launch — possibly in response to the battery drain concerns raised in early reviews (Notebookcheck specifically noted High Power Mode could draw enough that the 97W input limit couldn't keep up, causing the battery to discharge under load).

One more data point that points in this direction: after the initial thermal throttling event (brief GPU spike to 100-101°C early in the run), the system settles into a stable state around 65-73°C for the rest of the 20-loop test, with fans still clearly running at high RPM. That's well short of the thermal ceiling, and there's visibly still cooling headroom being used — yet sustained power stays flat at 27-30W rather than climbing back up to use the available thermal margin. This makes me suspect the thermal/power policy itself became more conservative at some point after launch — i.e., the system is now choosing to settle at a lower power/temp point even though it has more thermal room than that to work with, rather than the previous behavior of pushing closer to the actual thermal limit.

If that's the case, what is currently labeled "High Power" may no longer correspond to the same power ceiling that reviewers measured at launch. The flag isn't broken — the table/policy it points to may have changed, and possibly become more conservative across the board (not just for High Power Mode specifically).

I don't have a way to verify this from the OS side, but the magnitude of the gap (44W → 27–30W, ~3600 → ~3150-3400 stabilized score) seems too large to attribute to environmental variance alone, especially given that fans were confirmed to be at full speed and GPU temps exceeded 95°C in my tests.

Curious if anyone else who reviewed/benchmarked this model at launch vs. now has noticed a similar drift.

Thank you for taking the time to dig into this and for the detailed explanation — I appreciate the effort, especially running your own test rig with concurrent workloads.

That said, I don't think the "insufficient heat" explanation accounts for what I'm actually observing, and I'd like to push back on a couple of points with data rather than supposition.

1. Sustained temps after thermal settling are well within headroom — not "too cool to trigger," and not "too hot either"

This isn't something I'm inferring — I have screenshots and powermetrics/Stats.app readings throughout the Steel Nomad Stress Test. Early in the run, GPU clusters did spike to 100-101°C during the initial burst. But after the first thermal throttling event, the system settles into a stable state around 65-73°C (GPU and CPU performance cores alike) for the remainder of the 20-loop test — and it stays there, fans still clearly audible at a sustained high RPM, not idling down.

That stable 65-73°C range is the part that doesn't fit the "not enough heat" explanation. It's well below thermal limits (nowhere near the 100°C+ seen briefly at the start), there's clearly still headroom, and the fans are still working hard to hold it there — yet powermetrics Combined Power stays flat in the 27-30W range for the entire stable period. If heat were the gating factor, I'd expect to see power increase to use the available thermal headroom, not plateau well below it while the fans keep working. In other words, the machine isn't "too cool to enter High Power Mode" (fans are maxed, it clearly already passed through a hot phase) — it's stabilizing itself at a power/temp point that's far short of both the historical 44W figure and the 100°C limit, despite available cooling capacity.

2. The "synthetic benchmarks don't generate enough heat/IO" theory doesn't hold up against third-party data

Notebookcheck's launch review of this exact model used the same benchmark (3DMark Steel Nomad Stress Test) and reported a sustained Combined Power of ~44W and a stabilized score of ~3600+. That's the same synthetic, GPU/CPU-bound, low-storage-IO workload you're describing as insufficient to trigger High Power Mode. If your theory (heat from storage I/O is the real trigger) were correct, Notebookcheck's environment running the identical test should also have failed to reach High Power Mode — yet they measured a sustained power level I cannot reach even with fans maxed out and GPU temps above 95°C.

3. The actual question

So the core issue isn't "the machine won't get hot enough to engage High Power Mode" — by the metrics available to me, it clearly passes through a hot phase and then settles into a stable, moderate temperature (65-73°C) with fans still running hard, well short of the thermal ceiling. The question is why a machine sitting comfortably below its thermal limit, with active cooling clearly still engaged, sustains only ~27–30W instead of the ~44W reported for the same model/test at launch. Separately, I also confirmed using a different title (NTE) that switching the Power Mode setting does change total system power (Automatic ~37–40W vs. High Power ~55–57W), so the setting clearly does something — it's just unclear whether what "High Power" maps to today is the same power ceiling that existed at launch.

I'm not trying to argue this is necessarily a bug rather than an intentional change (e.g., a response to the battery drain issues some reviewers flagged at launch) — but "the workload isn't generating enough heat" doesn't seem to fit the thermal data I'm seeing on my end. Happy to share the raw powermetrics logs and screenshots if that would help narrow this down further.

That said, I don't think the "insufficient heat" explanation accounts for what I'm actually observing, and I'd like to push back on a couple of points with data rather than supposition.

One more factor I should have mentioned. What power adapter are you using? From the same article I linked to in my previous email:

For 14-inch MacBook Pro with M4 Pro and M5 Pro chip, the 96W USB‑C Power Adapter is recommended for using high power mode while charging.

I'll note that our documentation phrasing tends to be more passive* than it could be and the word "recommended" is often better understood as "required".

*The realities of our world mean that we're forced to leave open the possibility of weird edge cases instead of closing them off entirely. Putting that in more concrete terms, I suspect it's POSSIBLE that the right combination of factors could still trigger high power mode, but under any kind of normal usage it will ONLY happen if you're using the 96W adapter.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for clarifying the "recommended = required" distinction — that's genuinely useful context I wasn't aware of, and I appreciate you flagging it.

That said, I've already tested both scenarios and the behavior is the same:

Apple's own 96W USB-C Power Adapter (system reports "Wattage (W): 98" via system_profiler SPPowerDataType — matching the rated wattage) A Thunderbolt dock rated at 140W (system reports the same 96W negotiated input)

In both cases: fans at high RPM, GPU/CPU temps peaking at 95-101°C in the early loops of the Steel Nomad Stress Test before settling at a sustained 65-73°C, and sustained Combined Power (powermetrics) staying flat in the 27-30W range throughout the stable phase.

If "96W is required," and my 96W Apple adapter is delivering exactly that, the adapter side of the equation should be satisfied. Yet system_profiler SPPowerDataType consistently reports the following regardless of adapter or load, even during active benchmarking with fans at full speed:

AC Charger Information: Connected: Yes Wattage (W): 98

AC Power: High Power Mode: No Low Power Mode: Yes

High Power Mode: No has persisted across multiple days, reboots, and both power sources tested. This is not a transient state — it appears to be a stable, persistent condition independent of adapter wattage.

I'm also curious how this explanation interacts with the launch-era Notebookcheck review, which reported ~44W sustained Combined Power and a stabilized Stress Test score of ~3600+ on this exact model. Were those results achieved with the 96W adapter? If so, what changed between then and now that would explain the ~27-30W I'm seeing with an equivalent power source?

I don't want to be dismissive of the adapter angle — it's a concrete and testable factor. But given that my adapter is already delivering 98W (per system_profiler), and the gap to launch-era results persists regardless of power source, I suspect there's still something else going on beyond just adapter wattage.

In both cases: fans at high RPM, GPU/CPU temps peaking at 95-101°C in the early loops of the Steel Nomad Stress Test before settling at a sustained 65-73°C, and sustained Combined Power (powermetrics) staying flat in the 27-30W range throughout the stable phase.

So, I was waiting to confirm some details with the power team, but now that they've gotten back to me, let me step back for a moment and clarify what "High Power Mode" actually is. High Power Mode is a thermal management feature, NOT a performance feature. That is, it has NO (direct) effect on your machine’s maximum performance or overall capability. Its primary purpose is simply to allow the machine to run the fan faster (meaning louder) than it otherwise would in "Automatic" mode, thereby allowing the machine to shed more heat and thus, in some conditions, "run faster" than it otherwise could at a lower fan speed.

The focus on heat, not performance, makes sense if you think about it, as there's no reason to simply have an "extra" reserve of "power" which we only engage when running in a special mode— this isn't some old 1980s PC with a "Turbo" button on the front[1].

[1] Yes, some PCs used to do this.

Here's the basic way to understand how this works:

  1. There's a temperature "band" the system is designed to run at, and it regulates its activity to try and stay inside that band, first slowing down and then eventually stopping entirely if it gets “too hot".

  2. There's a thermal window below which the machine will run at maximum power without any fan activity at all. If you're in a walk-in freezer, there's no point running the fan.

  3. There's a thermal window above which the machine CANNOT run at maximum power, no matter how fast the fans run. If you're in an oven, running the fans faster.

  4. Between 2 & 3, there's a window where the machine can run without any fan, followed by a window where running the fan allows it to dump more heat.

Within that framework, the point where you hit #3 is basically determined by how fast you run the fan. Our default behavior ("Automatic") caps the fan speed to limit how loud the machine will be. High Power Mode (HPM) then increases the fan speed limit, indirectly raising the thermal limit (#3).

The key here is that HPM ONLY matters IF the broader conditions actually mean that the machine can get hot enough that it's approaching the thermal limit. If that doesn't happen, then HPM simply will not engage because doing so would be pointless.

That then leads to here:

I'm also curious how this explanation interacts with the launch-era Notebookcheck review, which reported ~44W sustained Combined Power and a stabilized Stress Test score of ~3600+ on this exact model. Were those results achieved with the 96W adapter? If so, what changed between then and now that would explain the ~27-30W I'm seeing with an equivalent power source?

I have no idea and, more to the point, trying to reproduce an exact benchmark number like this is much harder than you think. Your assumption here is that running the "same benchmark" on the "same device" should always give you the "same result", but that isn't necessarily true. The benchmark doesn't have full control over the device, so its results will always be altered by the large environment.

If they're specifically trying to be rigorous about their testing, then they're carefully configuring the machine to a precise hardware and software configuration so that background activity and issues like display resolution don't distort the test results.

My biggest concern here would actually be what I asked about here:

Was this with the (paid) macOS app or the iOS App?

This question is critical because I don't think the iOS app is actually capable of determining the machine’s true capabilities. As the simplest point, if you're running an app in a window, then, by definition, NO test could actually determine the true limits of that hardware, as a significant portion of the machine’s resources will be dedicated to "the rest" of the screen.

A "window" benchmark might still be useful as a way to cross-compare between similar hardware; however, my other concern is that the Mac itself is different enough from iOS that I wouldn't expect the mobile benchmark to be capable of taking full advantage of the hardware. Indeed, I suspect that apps running in compatibility mode CANNOT take full advantage of the Mac’s capabilities, simply because macOS is intentionally lying to them about the environment they're running in (this provides the broadest compatibility).

Real world testing confirms this. The problem is that I'm getting the same result when running one of the test apps was when I run both of the test apps simultaneously, which obviously means that the test app isn't actually using "all" of the machine’s capabilities.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

To answer directly: this is the native macOS app , not the iOS app running in compatibility mode. I have never used the iOS version for any of this testing. The result files I've referenced throughout (.3dmark-result) are macOS-native output. So the entire "window benchmark / compatibility mode / iOS app can't access full hardware" line of reasoning doesn't apply to my testing — that's a different scenario than what I've been describing.

On the thermal framework you laid out: I follow the logic, but it still doesn't explain my data. By your own model, High Power Mode raises the fan speed ceiling, which raises the thermal ceiling (#3), which only matters if the machine is approaching that ceiling. My system does approach it — GPU briefly hits 95-101°C early in the run. After that, it settles at 65-73°C with fans still clearly at high RPM (not idling down), for the rest of a 20-loop test.

If "Automatic" mode's fan cap was insufficient to dissipate heat at a higher power level, I'd expect to see temps climb back toward the ceiling as the workload continues — not settle comfortably 25-35°C below where they peaked, with the fans still working hard. The fact that temps drop and stay down while fans stay up suggests the system has more thermal headroom than it's using, not that it's constrained by Automatic's fan-speed limit.

On the benchmark variance point — I understand run-to-run variance is real and that NotebookCheck's rigorous methodology and mine won't produce identical numbers. But the gap I'm describing isn't "3600 vs 3550." It's 44W sustained power vs. 27-30W — a ~35-40% reduction in steady-state power draw on the same chip, same test, same adapter wattage. I'm not asking why my score isn't identical to theirs; I'm asking why my sustained power ceiling is that much lower when my thermals indicate there's room to spare.

Two more pieces of data since my last post:

  1. The High Power Mode: No status isn't just something I'm reading off system_profiler interactively — it's also what's recorded in Apple's own sysdiagnose output (SystemProfiler/SPPowerDataType.spx), under both AC Power and Battery Power. So this isn't a one-off terminal query; it's the same value captured by Apple's own diagnostic collection tool.

  2. To rule out Migration Assistant history as a factor (since my original post mentioned the M2 Air → M4 Max → M5 Max migration chain), I did a full erase of my M4 Max via iBoot Recovery and a completely clean macOS install — no Migration Assistant, no data restore, Apple ID sign-in only. Selecting "High Power" on this fresh install still resulted in High Power Mode: No. This rules out migrated preference data as the cause entirely; the behavior is present on a machine with zero migration history.

To answer directly: this is the native macOS app, not the iOS app running in compatibility mode.

OK, thank you for clarifying. At this point, I don't think I have anything more to add about the benchmark side of this. This isn't an area I've spent a great deal of time looking at, and I don't think I have anything new to add.

On the thermal framework you laid out: I follow the logic, but it still doesn't explain my data. By your own model, High Power Mode raises the fan speed ceiling, which raises the thermal ceiling (#3), which only matters if the machine is approaching that ceiling.

First, just to clarify, what I mean by "thermal ceiling" is primarily about the larger environmental conditions the machine can run in, not the specifics of the device. That is, the system’s goal is to keep cool enough, and running the fans faster can allow the machine to continue "running faster" under a broader set of conditions.

My system does approach it — GPU briefly hits 95-101°C early in the run.

Yes, this spike is normal. Brief thermal "spikes" caused by sudden activity bursts are very common, so the fan intentionally delays its own activation so that it doesn't end up constantly spinning up/down to handle temporary spikes which the passive hardware can easily dissipate.

After that, it settles at 65-73°C with fans still clearly at high RPM (not idling down), for the rest of a 20-loop test.

Yes… this is the fans running at the RPM necessary to keep the machine within its thermal window. Putting that another way, imagine two variations of the state above:

  1. You turn on an air conditioner such that the air going into the fans is significantly colder -> The fan slows down... and the temperature stays at "65-73°C".

  2. You point an air dryer at the fan intakes, such that the air going into the fans is significantly hotter -> The fan speds up... and the temperature stays at "65-73°C".

In both cases, the machine’s performance won't change at all, unless the heat introduced by #2 means is more than the fans can vent. That leads to here:

I'm asking why my sustained power ceiling is that much lower when my thermals indicate there's room to spare.

What do you mean?

I think you're assuming that we'd actually let the machine run at a sustained "95-101°C", but that's not true. I talked about why the thermal spike happened above, but that doesn't mean the system itself will allow itself to continually run at that kind of temperature. Sustained over time, that's hot enough to be physically dangerous[1], not to mention the risk to the machine's physical components.

[1] Keep in mind that the nature of the passive heat system means that whatever temperature the fan stabilizes the system at is basically the temperature the bottom and other portions of the machine are eventually going to end up running at. A metal plate at +95°C is not something I want anywhere near my lap.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I follow the thermal model you're describing, and I'm not arguing the machine should be allowed to run at a sustained 95-101°C — I agree that would be unreasonable, and I wasn't asking for that.

The core issue is simpler than the thermal ceiling discussion: Notebookcheck measured ~44W sustained Combined Power on this exact model at launch, with reported temperatures settling in this kind of range (other reviews I've checked report sustained temps in the 78-82°C range for the 14" Max chassis under similar sustained load). My unit settles at 65-73°C and ~27-30W under the same benchmark.

I'm not asking why the machine doesn't run at 95-101°C. I'm asking why it settles at 65-73°C instead of something like 80°C — a temperature point that's still well within the range other reviewers report as normal sustained operation for this chassis, and that would correspond to meaningfully higher sustained power. Your fan/airflow analogy explains why temperature tracks fan speed under changing ambient conditions, but ambient conditions aren't what's different here — what's different is that my unit converges to a lower temperature/power point than other units of the same model reportedly do, under the same workload, same chassis, same cooling design.

If the thermal model is working as intended, I'd expect my unit to converge to roughly the same temperature/power point as the launch review units, not a meaningfully lower one. That gap (44W → 27-30W, ~80°C → 65-73°C) is what I don't have an explanation for yet.

One more data point to add to my last reply, since I think it makes the comparison clearer.

Notebookcheck's review of this exact model gives a specific number for the High Power mode stress test: it settles at 42W (~85°C). I've also seen other YouTube reviews of this model reporting sustained temperatures around 80°C under similar sustained load, which is roughly in the same range.

My unit, with High Power selected, settles at ~27-30W and 65-73°C instead. That's a meaningfully lower power point at a meaningfully lower temperature than what's been independently reported elsewhere for the same model, same benchmark, same mode.

So to put the question more precisely than I did before: I'm not asking why the machine doesn't run hotter than necessary. I'm asking why my unit's equilibrium point in High Power mode doesn't match the documented equilibrium point Notebookcheck reported for this exact model in the same mode.

My unit, with High Power selected, settles at ~27-30W

Ruling out something obvious, how exactly are you powering this? Are you using our highest capacity power charger through our MagSafe cable? I'd even go so far as to check the wall source just to rule out "everything". You might also take it to the Apple Store where you could test with a different charging block.

The simplest explanation for why it's not drawing more power would be that it can't, because either the wall, power brick, or wire is limiting what it can draw. Note that part of what the USB-C spec defines are mechanisms cables can use to declare their own capabilities, which mean visually identical cable can have totally different power transfer capabilities.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

To rule this out as thoroughly as I can: I've tested with the official 96W MagSafe charger (Apple's MagSafe cable, not USB-C), the 96W USB-C Power Adapter via USB-C, and a 140W-rated Thunderbolt dock via USB-C. All three give the same result — system_profiler reports the same wattage (~98W) in all cases, and sustained power/score during the benchmark is the same (~27-30W / ~3070-3430) regardless of which one is connected.

I've also swapped wall outlets/circuits during this testing, and confirmed other high-draw devices (other laptops, including ones that pull 100W+) charge normally on the same outlets and cables, so I don't think the wall or circuit is the limiting factor either.

I did this deliberately because I'd already considered the "something in the power delivery chain is bottlenecking it" possibility early on — it was actually the first alternative explanation I tried to rule out, before even getting to the thermal/firmware investigation. At this point I've cycled through charger, cable, and outlet combinations enough times that I'm fairly confident the limiting factor isn't anywhere in the power delivery chain. The constraint shows up the same way regardless of what's supplying the power.

High Power Mode not applied by powerd after Migration Assistant (migrateenergyprefs related?)
 
 
Q