Closing data point for this thread: the mechanism is now confirmed by remediation, on both power modes. I steepened my third-party fan curve so it reaches 100% by ~73-74°C instead of ~97°C — i.e., full cooling arrives before the die temperature at which the clock reduction engages. Result, 3DMark Steel Nomad Stress Test: 98.05% stability under High Power and 97.96% under Automatic (both PASS), sustained scores within 0.5-1.5% of the Notebookcheck launch reference and best loops exceeding it (4453/4402 vs 4392) — flat loop times for 17 minutes, zero manual intervention, in the exact configuration that previously produced monotonic degradation and a 0.54 GHz collapse. Telemetry: die crosses 73°C within 3-5 s of load, fans auto-ramp to max within ~10 s, die holds 79-81°C, GPU sustains ~1.52 GHz / 60 W throughout. Notably, under this curve Automatic and High Power become indistinguishable again (~1%), restoring the documented cooling-only distinction between the modes. This also resolves the residual gap I flagged earlier: with proper cooling timing there is no measurable sustained regression left on my 16" — the earlier ~5-6% was ambient and accumulated-state, not OS capability. To be clear, this is a bypass, not a fix: the policy that reduces clock below a temperature threshold without consulting available fan headroom is still in the OS (and per-domain power attribution is still broken on 26A5388g). But it narrows the defect precisely: any fan curve, stock included, whose active region sits above ~74°C can never receive the temperature signal — the regulation acts first. Everything, including dual-channel telemetry for both runs, is in FB23754032. @BETA15: worth testing on your 14" — if a steepened curve doesn't help there, it further confirms your ceiling is the HPM engagement failure rather than this thermal-priority inversion. For reference, the fan curve I used: And the original iStatMenus fan curve:

Two things to correct/add to my previous post: Correction on my score conversions: calibrating against the actual displayed score of a new run (loop 1: 44.35 fps shown as 4434), the factor is fps×100, not ×96.6 as I used. Revised figures: my fans-auto run = ~4122 first loop / ~3583 sustained (same regime as your 3983/3432, ~3.5-4% higher on the larger chassis — not the digit-for-digit match I claimed); my fans-100% sustained = ~4121, i.e. ~6% below Notebookcheck's 4392 launch figure rather than ~9% (with ~27°C ambient here vs typical lab conditions likely explaining part of that). A fresh run tonight sustained ~4169 (-5.1%). The qualitative picture is unchanged: both machines sit far below launch behavior in sustained load, and the residual after correcting the fan/clock issue is real but smaller than I first stated. Worth adding: my two fans-100% runs now bracket the same equilibrium from opposite sides. The morning run started with residual regulator "charge" (26 min after the fans-auto run) and climbed monotonically toward ~41.5 fps; tonight's run started fully rested (and ~3-4°C warmer) at a full 44.35 fps burst and declined gently toward ~41 fps, flattening at the end. Opposite initial conditions, opposite trajectories, same attractor: ~41-41.5 fps (~4100-4150 score) is this machine's true sustained capability under the current OS policy at 27°C ambient, max cooling. The remaining ~5-6% gap to the 4392 launch figure is therefore a stable measurement, not run noise — part ambient, part residual OS regression; separating those two awaits either cooler ambient or the 27.0 stable release.

Hi @BETA15, I'm the one who replied on Reddit with the long messages about my own experience and testing. @DTS Engineer, I can corroborate and extend BETA15's findings from a different chassis and OS train, with mechanism-level instrumentation. MacBook Pro 16-inch, M5 Max (40-core GPU), 128 GB, on AC (original 140W power block and MagSafe cable). Reproduced across macOS 27.0 Developer Beta 3 (26A5378n) and Beta 4 (26A5388g). Filed as FB23754032 (currently showing 10+ similar reports), with three follow-ups and full raw telemetry attached. Why my data point matters for this thread specifically: the 16-inch M5 Max was independently measured as completely stable under sustained GPU load at launch (Notebookcheck: stable in Automatic mode, no throttling). Whatever both of us are now measuring is therefore not a chassis limitation. What I measured, using a native Metal/MLX video-inference pipeline (not a windowed or iOS-compatibility benchmark) with two independent telemetry channels recorded simultaneously (sudo powermetrics at 1 Hz + the SMC/IOReport channel): Back-to-back identical runs degrade monotonically: 513 s -> 642 s -> 627 s on Beta 4 (497 -> 565 -> 570 s on Beta 3). Output hashes are bit-identical across all runs, so the computation is constant; only the regulator state changes. During the degraded runs, the GPU sits at 100% utilization while collapsed to 840 MHz / 16 W, with fans held at ~2,900 rpm of 5,800 available and the die pinned at 68.7 C. Deepest live sample: 534 MHz / 8.6 W. A fourth run launched after ~50 min of idle (die verified at ~50 C beforehand) came back fully healthy: 457 s, ~1,230 MHz / 30 W, fans allowed to reach ~4,000 rpm, die allowed to rise to 78 C. Same binary, same input, bit-identical output. The accumulated state fully resets with idle time. 3DMark Steel Nomad Stress Test (native macOS app), 20 loops, run twice ~30 min apart with a single variable changed - fan policy. High Power was selected in both runs. Fans on an auto curve: monotonic decline on all 20 loops (41.2 -> 32.7 fps, 79.3% stability) while the GPU die temperature FELL from 79 C to 72 C and system power decayed from ~103 W to ~93 W. Fans manually forced to 100%: 91.6% stability, sustained 41.2 fps at a stable ~73 C / ~114 W, with loop times improving monotonically from loop 2 onward. Converted to scores, my fans-auto run (3982 first loop / ~3460 sustained) matches BETA15's 14-inch results (3983 / 3432) nearly digit-for-digit. Performance falling together with temperature, at power levels far below the launch-review equilibria, with fan headroom unused, is the inverse of thermal throttling. The consistent mechanism across all our data: the regulator reduces clock first, at die temperatures below any fan curve's ramp thresholds, instead of using the available cooling capacity - and the constraint tightens with sustained load (integrator-like) and relaxes with idle time. Note that the fans-auto decline above happened with High Power selected: the mode whose sole documented function is to raise the fan-speed ceiling presided over a run where the fans never ramped and the clock was progressively reduced instead. On the High Power Mode engagement question discussed above: accepting the definition given in this thread - engagement is heat-triggered, not work-triggered - our data shows why "High Power Mode: No" is permanent on these machines under this policy. The clock-reduction loop suppresses the die temperature below any plausible engagement threshold before it can be reached. Under the current regulation, the documented engagement condition for High Power Mode is unreachable by construction. The status readout is not cosmetic; it is the observable of the clock-before-fans priority order. One change worth noting between Beta 3 and Beta 4: on 26A5378n, powermetrics reported a constant 1620 MHz / 100% residency / Nominal pressure throughout degraded episodes (verified against 3,082 and 3,629 raw samples), while the IOReport channel showed the true collapsed frequencies. On 26A5388g, powermetrics now reports the real frequency during collapse (543 MHz, "1620 MHz: 0%") and agrees with IOReport. The observability defect appears fixed; the regulation itself is unchanged or slightly worse. Happy to provide the dual-channel telemetry, the .3dmark-result files, or a sysdiagnose captured during a degraded episode - everything is already attached to FB23754032, and I would welcome that report being related to the FBs referenced in this thread.