CPU Undervolting 2026: -155 mV in 13 Steps, 45 Min

Somewhere in the last five years, undervolting stopped being a quiet efficiency trick and became a marketing genre. You have seen the thumbnails: a screaming-red arrow, a shocked face, the promise of 20-30% MORE PERFORMANCE FOR FREE. The Machine is here to tell you that this number is real, and also that it is a lie, and that both of those statements are true at the same time depending on what is sitting on your desk. This is a tutorial, not a sermon, so we will spend most of our time on the how. But you do not get to skip the physics, because the people who skip the physics are the ones who post my PC won't boot anymore at 2 a.m.

Undervolting is the practice of asking your CPU to do the same work at a lower voltage. Less voltage means less heat, less power draw, less fan noise, and, on a thermally strangled machine, more sustained clock speed because the chip stops slamming its face into the thermal ceiling. It is the polite inverse of overclocking, and unlike overclocking it will not shorten the life of your silicon. It is, in the strict legal sense, still a warranty-voiding modification on some platforms. Read the fine print, then do it anyway, carefully.

Why Undervolt: The Honest Case

Before you touch a single millivolt, understand what you are buying with your 45 minutes, because the answer depends entirely on your thermal situation. The gap between the honest case and the clickbait case is the difference between a happy afternoon and a corrupted Windows install.

The 30% Number Is a Lie (Except When It Isn't)

Here is the technically precise version, and it is the one nobody puts in a thumbnail. On a desktop with a competent cooler that is not thermally throttling, undervolting adds close to zero multithreaded score. Your Cinebench number moves by a rounding error. What you gain instead is 20 to 40 watts of package power and 8 to 15°C off your load temperatures. That is the real prize, and it is a good prize.

The 20-30% more performance figure quoted for a conservative -80 mV offset on the CPU Core and CPU Cache of a 2026 Intel Core Ultra chip is not fabricated, but it is conditional. It applies to a thin-and-light laptop or a small-form-factor box that was already throttling, dumping clock speed the instant it hit 95 or 100°C. Remove 80 mV, and the chip runs cool enough to hold its boost clocks instead of sawtoothing between them. The 20-30% is performance you already paid for and were losing to heat, recovered. It is not new performance conjured from a voltage slider. TechPowerUp's own ThrottleStop notes put it plainly: undervolting lowers temperatures and extends battery life without significantly affecting performance. On AMD, SkatterBencher measured roughly a 6% Cinebench R23 uplift from an aggressive per-CCD Curve Optimizer setting, and that 6% comes entirely from Precision Boost 2 sustaining higher clocks on a cooler die. Same mechanism. No magic.

What You Actually Gain: Watts, Degrees, Decibels

Reframe the goal and the whole exercise makes sense. You are not chasing a benchmark record; you are moving your operating point down the voltage-frequency curve to a quieter, cooler place that happens to also stop your laptop from throttling. On a desktop you get a fan curve that never spins up under gaming load. On a handheld you get an extra hour of battery, which is why undervolting is a rite of passage for the Steam Deck and its rivals; we got into that trade-off in the Switch 2 versus Steam Deck battery breakdown. On a mini-ITX build you get to keep the small cooler you wanted without cooking the VRMs.

Who Should Not Bother

If you own a 360 mm AIO strapped to a mid-range chip that never crosses 70°C, the honest answer is that undervolting will win you lower power and marginally quieter fans and nothing else. That is still worth 45 minutes to some people and worth nothing to others. If you are the kind of person who reboots into BIOS to reset a single Windows update, you have the temperament for it. If instability makes you want to throw the tower out a window, stay stock. There is no shame in stock.

How Undervolting Actually Works

You cannot tune what you do not understand, and the single biggest source of failed undervolts is people copying a number off a forum without knowing which voltage rail that number touches. Ten minutes of theory saves you an hour of crashes.

The Voltage-Frequency Curve

Every CPU ships with a factory voltage-frequency curve: for a given clock speed, the manufacturer fuses in a voltage that guarantees stability across every chip that passes binning, at every temperature, for the whole warranty period. That guarantee is expensive. It means your specific chip, which is almost certainly better than the worst chip the fuse map has to cover, is being fed more voltage than it needs. Undervolting shifts the entire curve down: less voltage at every frequency point. AMD's Curve Optimizer does this literally, per core, along the frequency axis. Intel's offset does it as a flat millivolt subtraction. The silicon lottery decides how far down you can shift before the chip starts making arithmetic mistakes.

FIVR, DLVR, and Where the Voltage Actually Lives

On modern Intel the core voltage is generated by a Fully Integrated Voltage Regulator (FIVR) inside the package, and on Raptor Lake and Core Ultra parts there is an additional Digital Linear Voltage Regulator (DLVR) stage layered on top. This matters because the knobs you turn address different rails. The two that pay the rent are CPU Core and CPU Cache (also called the ring or LLC). You undervolt both, usually by the same amount, because if the cache stays high while the core drops you gain little and risk odd instability. Some 2026 boards expose a separate DLVR voltage or an efficiency profile in BIOS; leave those conservative until the core and cache offsets are dialed, because stacking two aggressive rails at once makes it impossible to know which one crashed you.

Offset vs Adaptive vs Fixed

Three modes, and choosing wrong is a classic beginner trap. Offset subtracts a fixed millivolt value from the entire stock curve; this is what you want, because it preserves the factory's frequency-dependent shaping. Adaptive lets you set a target voltage at a target frequency and applies an offset on top; useful on some platforms, but you must select the adaptive radio button before the offset field does anything, a step ThrottleStop makes explicit. Fixed (also called override) pins one voltage for all clocks and is a trap for undervolters, because a voltage that survives your idle desktop will not survive a 5.5 GHz all-core boost, and a voltage that survives the boost wastes power at idle. Use offset. Almost always, use offset.

Prerequisites: Hardware and Software

The failure mode of a rushed undervolt is discovering, three hours in, that your CPU was locked all along or that your monitoring tool was reporting a value the chip silently ignored. Front-load the boring checks.

Hardware: What Can and Can't Be Undervolted

Not every chip cooperates, and Intel spent 2020 through 2022 actively fighting this via the Plundervolt microcode mitigation, which disabled the undervolting MSR on a swathe of locked mobile parts. In 2026 the landscape is:

• Intel desktop, K/KF/KS and HX: unlocked, undervolt in BIOS or ThrottleStop. Easiest case.
• Intel Core Ultra (LGA 1851, Arrow Lake) desktop: unlocked, BIOS offset on Core and Cache, conservative start at -80 mV.
• Intel locked mobile (non-HX U/P series): may or may not permit the offset MSR depending on the OEM's microcode; ThrottleStop will tell you within a minute whether the FIVR sliders take.
• AMD AM5 (Ryzen 7000 / 9000, e.g. 9700X, 9900X3D, 9950X3D): undervolt via Curve Optimizer in BIOS or Ryzen Master, not via a millivolt offset.
• AMD laptop (e.g. Ryzen 5 7640HS): per-core Curve Optimizer, often exposed as a Custom P-state or CO menu in vendor tools.
• Older AMD (K10 through Zen 3, roughly 2007-2021): the Linux tool amdctl, driving P-state CpuVid fields directly.

Software and Versions

Pin these exact tools; version drift is a real source of confusion because the FIVR interface changed across ThrottleStop releases.

• ThrottleStop 9.7 stable, with the 9.7.3 beta released April 2025, from the official TechPowerUp download page. Do not grab it from a random mirror; the mirrors lag and some bundle junk.
• HWiNFO64 (latest) for sensor logging, or lm_sensors on Linux.
• intel-undervolt (kitsunyan) from the GitHub repo or your distro's package, for Linux Intel.
• amdctl-git from the AUR (Feb 2025 build) for older AMD on Linux.
• Prime95 30.x / mprime and Linpack Xtreme for stability testing with numerical verification.
• Cinebench 2024 or R23 for a repeatable score baseline.
• A current BIOS/UEFI. Flash it first; microcode updates change voltage behavior and there is no point tuning against firmware you are about to replace.

Back Up Everything First

This is not filler. An unstable undervolt can corrupt data silently before it ever crashes, because a CPU that computes 2+2=5 under load will happily write that 5 to disk. Back up anything you cannot lose before the first stress test, not after the first crash. Note where your motherboard's Clear CMOS jumper or button is. On a laptop, know that pulling the battery or a forced power-off resets a BIOS offset, and that ThrottleStop offsets evaporate on reboot unless you tell them not to. The undervolt that cannot be undone in 30 seconds is the undervolt that ruins your weekend.

Intel: BIOS Offset and ThrottleStop

Two roads lead to the same rail. BIOS is persistent and applies before the OS loads; ThrottleStop is live, reversible in one click, and the only option on many locked mobile chips. Unlocked desktop owners should prefer BIOS. Laptop owners usually live in ThrottleStop.

The BIOS Route: Offset and Adaptive

Enter your UEFI and get into advanced mode; on most 2026 boards that is F6 on ASRock and F7 on MSI to toggle out of the simplified EZ view, with ASUS and Gigabyte using their own toggles. Find the CPU voltage section (names vary: CPU Core Voltage, CPU Core/Cache Voltage Offset, Actual VRM Core Voltage). Set the mode to Offset, the sign to minus, and enter your value. Do the same for the CPU Cache/Ring offset. A representative starting sheet looks like this:

# UEFI / BIOS - Intel Core Ultra offset undervolt (example values)
# Tweaker / OC menu

CPU Core Voltage Mode ............ Offset
CPU Core Voltage Offset Sign ..... -  (minus)
CPU Core Voltage Offset .......... 0.080 V     # start conservative: -80 mV

CPU Cache Voltage Mode ........... Offset
CPU Cache Voltage Offset Sign .... -  (minus)
CPU Cache Voltage Offset ......... 0.080 V     # match the core

# Optional companion (see All-Core Ratio below)
CPU DLVR Voltage ................. Auto        # leave until core/cache dialed
XMP / EXPO Profile ............... Profile 1   # memory stable FIRST

Save, boot, and prove it took before you trust it. Many boards accept an offset in the menu and then quietly ignore it because a conflicting auto rule overrode it. Read the applied VID back in HWiNFO under load.

The ThrottleStop Route (Windows)

Install ThrottleStop 9.7, launch it, and click the FIVR button (Turbo FIVR Control). In the FIVR window, select CPU Core Voltage, tick Unlock Adjustable Voltage, choose the Adaptive radio button, and drag the Offset Voltage slider negative. For a modern mobile chip the effective range runs roughly -125 mV to -165 mV; our worked target lands near -155 mV. Then select CPU Cache and apply the same offset, because the FIVR interface treats them as separate domains and forgetting the cache is the number-one ThrottleStop mistake. Click OK - Save Voltages Immediately. A dialed-in readout looks like this:

ThrottleStop 9.7 - FIVR - expected readout after apply

CPU Core        Unlock Adjustable Voltage [x]   Adaptive
  Offset Voltage ................ -155.3 mV
CPU Cache       Unlock Adjustable Voltage [x]   Adaptive
  Offset Voltage ................ -155.3 mV
Intel GPU       Offset Voltage ...  0.0 mV
System Agent    Offset Voltage ...  0.0 mV

Monitoring (FID/VID under load):
  CORE  #0  4.90 GHz   1.081 V   78 C
  CORE  #4  4.60 GHz   1.075 V   76 C
  PKG POWER  38.7 W  (was 54.2 W at stock)

To make a ThrottleStop offset survive reboot, enable Start ThrottleStop minimized on Windows startup in Options and add its task to the Task Scheduler with highest privileges, or it will reapply too late and you will boot at stock every morning wondering why your temps crept back up.

All-Core Ratio and DLVR

Two optional companions for the thermally desperate. First, a mild underclock: set the all-core ratio 100 MHz below stock, e.g. multiplier 54 instead of 55 for P-cores and 46 for E-cores. This is not undervolting, but on a hard-throttling chip the small clock give-back buys a disproportionate voltage and heat reduction, and net performance can rise because the chip stops throttling. Second, DLVR: some boards expose the Digital Linear Voltage Regulator with its own voltage and an extreme efficiency mode. It can squeeze further, but it stacks a second variable on top of your core offset, so leave it on Auto until the core and cache are locked, then tune it in isolation. Do not enable XMP tuning and CPU offset and DLVR all in the same sitting; when it crashes you will not know which one to blame.

Intel on Linux: intel-undervolt

On Linux the canonical tool for Haswell and newer is kitsunyan's intel-undervolt, which pokes the same MSR and MCHBAR registers ThrottleStop uses on Windows. It is a config-file tool, which makes it clean, scriptable, and easy to version.

Installing intel-undervolt

Most distributions package it; on Arch it is in the repos, elsewhere you build from the repo. It needs the msr kernel module and root, because writing model-specific registers is a privileged operation for good reason.

# Arch
sudo pacman -S intel-undervolt

# From source (any distro)
git clone https://github.com/kitsunyan/intel-undervolt
cd intel-undervolt
./configure && make && sudo make install

# Ensure the MSR interface is available
sudo modprobe msr
echo msr | sudo tee /etc/modules-load.d/msr.conf

Writing /etc/intel-undervolt.conf

The config uses one line per voltage domain: undervolt ${index} ${display_name} ${value_in_mV}. Index 0 is the CPU core, 2 is the CPU Cache; match them. The ArchWiki's guidance is the sober one: decreasing the Intel CPU and CPU Cache by 100 to 200 mV is usually stable, while exceeding 200 mV tends to cause crashes. Start well inside that, around -50 mV, and walk in.

# /etc/intel-undervolt.conf

enable yes

# undervolt ${index} ${display_name} ${value_mV}
undervolt 0 'CPU'          -100
undervolt 1 'GPU'             0
undervolt 2 'CPU Cache'    -100
undervolt 3 'System Agent'    0
undervolt 4 'Analog I/O'      0

# Optional: package power limits (watts) -> short, long
# power package 45 64

# Optional: thermal throttle offset (degrees below Tjmax)
# tjoffset -3

# Daemon polling interval (ms) and what it re-applies
interval 5000
daemon undervolt:once power:5000

Apply it and read it back. The read subcommand is your proof that the registers actually accepted the values:

$ sudo intel-undervolt apply
CPU: -100.59 mV
GPU: 0.00 mV
CPU Cache: -100.59 mV
System Agent: 0.00 mV
Analog I/O: 0.00 mV

$ sudo intel-undervolt read
CPU (mV): -100.59 (0xfffff9e0)
GPU (mV): 0.00 (0x0)
CPU Cache (mV): -100.59 (0xfffff9e0)
System Agent (mV): 0.00 (0x0)
Analog I/O (mV): 0.00 (0x0)
Powerlimit (Short Term): 64.00 W / enabled
Powerlimit (Long Term): 45.00 W / enabled
Critical Temperature Offset: 0 (100 C)

Making It Persist

MSR writes do not survive a reboot or, crucially, a resume from suspend, which is why laptops need the daemon or a service that re-applies on wake. The package ships systemd units for exactly this:

# Apply once at boot
sudo systemctl enable --now intel-undervolt.service

# Or run the loop that re-applies after suspend/resume
sudo systemctl enable --now intel-undervolt-loop.service

# Verify after a suspend/resume cycle
sudo intel-undervolt read | grep -i cache

AMD: Curve Optimizer, PBO, and amdctl

AMD does not undervolt by subtracting millivolts. Since Zen 3 the mechanism is Curve Optimizer, which shifts each core's voltage-frequency curve by a unitless count, and the interaction with Precision Boost 2 is why AMD undervolting so often reads as a mild overclock.

AM5 Desktop: PBO + Curve Optimizer

For AM5 chips like the 9700X, 9900X3D, and 9950X3D, enter BIOS, find Precision Boost Overdrive and set it to Advanced, then open Curve Optimizer. Set it to All Cores, sign Negative, and a magnitude of -20 to start; -25 is the aggressive-but-common daily target on a good chip, and it drops Vcore into the 1.05 V to 1.1 V band under load, which is where the temperature and boost gains live. MSI's own 9950X3D Curve Optimizer walkthrough and SkatterBencher's deep dive both recommend the same discipline: start at -15 or -20 all-core, step the magnitude up in small increments, find instability, and back off to the last stable value.

# AM5 UEFI - PBO + Curve Optimizer (example)

Precision Boost Overdrive ........ Advanced
  PBO Limits ..................... Motherboard
  Curve Optimizer ................ All Cores
    CO Sign ...................... Negative
    CO Magnitude ................. 20        # start; 25 aggressive
  Max CPU Boost Clock Override ... Auto      # +0 to +200 optional

EXPO Profile ..................... Profile 1 # memory stable FIRST

Note the asymmetry trick the benchmarkers use: the two CCDs on a dual-die chip rarely bin equally, so a setting like -25 on CCD0 and -20 on CCD1 (or per-core values) often beats a single all-core number. That is advanced territory; get all-core stable first.

Ryzen Laptops: Per-Core and P-State Zero

On mobile Ryzen such as the 7640HS, the exposed control is frequently a Custom P-state zero or a per-core Curve Optimizer menu in the vendor's tuning app. The field-tested rule: a value of -10 is stable on roughly 90% of hardware, while -20 is reserved for the lucky chips that win the silicon lottery. Laptops run hotter and with less voltage margin than desktops, so be more conservative and lean harder on long-soak testing, because a laptop that is stable on the desk will destabilize the moment it is heat-soaked in a bag on your knees.

amdctl for K10 through Zen 3

If your AMD chip predates AM5, the Linux path is kevinlekiller's amdctl, installable as amdctl-git from the AUR. It sets P-state voltages and clocks directly and covers families 10h (K10) through 19h (Zen 3), roughly 2007 to 2021. It does not drive AM5 Zen 4/Zen 5; those need Curve Optimizer. You undervolt by raising the CpuVid field of a P-state, because higher CpuVid means lower voltage in AMD's encoding, a sign convention that has tripped up everyone at least once.

# amdctl - undervolt an older AMD P-state (Linux, root)
sudo modprobe msr

# Read current P-states on core 0
sudo amdctl -g -c0

# Undervolt P-state 0: raise CpuVid (higher = lower voltage)
# Move in single steps and test each one.
sudo amdctl -p0 -v28

# Apply to all cores
sudo amdctl -p0 -v28 --all

The 13-Step Undervolt Procedure

This is the spine of the whole exercise, platform-agnostic. Each step exists to isolate a variable or to stop you from lying to yourself about stability. The whole run is about 45 minutes of active work plus one overnight soak. Do them in order.

1. Flash the latest BIOS and record stock behavior. Rationale: microcode updates change voltage rules; tuning against firmware you are about to replace wastes the tune. Note stock VID, load temp, and package power.
2. Establish a thermal and score baseline. Run Cinebench with HWiNFO or sensors logging for 10 minutes. Rationale: you cannot claim a win without a before, and you need to know whether you throttle at stock, which decides whether you are chasing temps or recovered clocks.
3. Enable XMP/EXPO and confirm memory is stable on its own. Rationale: memory instability produces the exact same crashes as an over-aggressive undervolt, so isolate it now. If you are still choosing kits, our DDR5 vs DDR6 rundown covers what is actually worth buying.
4. Pick your path. BIOS offset, ThrottleStop, intel-undervolt, or Curve Optimizer, chosen by chip and OS from the sections above. Rationale: using the wrong tool for a locked chip is how people waste an afternoon on sliders that do nothing.
5. Apply a conservative first setting. Intel: -50 mV on Core and Cache. AMD: Curve Optimizer -10 to -15 all-core. Rationale: proving the pipeline works at a safe value separates the tool did not apply from the value was too aggressive.
6. Reboot and read the value back. HWiNFO applied VID under load, or intel-undervolt read, or Ryzen Master's monitor. Rationale: boards silently ignore offsets constantly; confirm the register took before you trust it.
7. Run a 5-10 minute smoke test. mprime Small FFTs or a short Linpack. Rationale: gross instability shows up fast and cheap; no sense running an hour on a setting that dies in five minutes.
8. Step the setting more aggressive in small increments. Intel -10 to -25 mV per step; AMD -2 to -5 CO per step. Rationale: the last-stable edge is found by bisection, not by leaping to a forum stranger's number.
9. Test each step 15-30 minutes and watch two failure modes. A hard crash or WHEA error, and a silent score or clock regression. Rationale: an undervolt that quietly loses performance is failing just as surely as one that blue-screens; both mean back off.
10. Find the crash/error edge, then back off. Retreat 10-15% on Intel (e.g. from -175 to -155 mV) or +2-3 CO on AMD. Rationale: your benchmark-stable edge is not your daily-stable margin; real workloads and hot summer ambients need headroom.
11. Long-soak the backed-off setting overnight. 2-6 hours of blended stress with numerical checks. Rationale: heat-soak and rare instruction paths surface only over hours; the 30-minute pass is necessary, not sufficient.
12. Make it persist. Save the BIOS profile, enable the systemd service, or set ThrottleStop to start with Windows and reapply on resume. Rationale: a volatile undervolt that resets on reboot or wake is a bug that will bite you exactly when you have forgotten it exists.
13. Re-baseline and document. Record final mV/CO, load temp, package power, and score, and stash it with your Clear-CMOS notes. Rationale: future-you diagnosing a random crash after a cooler swap or a heatwave will need this exact sheet.

Stability Testing Without Corrupting Data

An undervolt is not stable because it did not crash. It is stable because it computed correct answers for hours under heat. Those are different claims, and conflating them is how people ship silent data corruption to their own disks.

Why mprime and linpack, Not Just Games

The ArchWiki is emphatic on this and it is right: verify with applications that have built-in numerical checks, specifically mprime (Prime95) and linpack. The reason is subtle and important. An unstable overclock usually crashes hard. An unstable undervolt frequently does something worse: it computes a wrong result and keeps running. mprime's torture test and Linpack Xtreme both verify their own arithmetic against known-good residuals, so they catch the wrong-answer-no-crash failure that a game or a Cinebench loop will sail right past while quietly writing garbage. Games are a final confidence check, never the primary test.

The Test Battery

Run these in escalating order. Small FFTs for maximum heat and to find the thermal edge; blended and Linpack for arithmetic verification; then a long soak.

# Linux stability battery

# 1) Max-heat, MSR-checked (Prime95/mprime Small FFTs)
mprime -t        # choose: Small FFTs, run 30+ min

# 2) Verified all-method CPU stress (stops on miscompare)
stress-ng --cpu 0 --cpu-method all --verify -t 20m --metrics-brief

# 3) Linpack Xtreme - residual check each pass; any FAIL = unstable
#    (GUI or CLI build; watch the 'Residual' / 'PASS' column)

# 4) Overnight blended soak
mprime -t        # choose: Blend, run 4-6 hours, log temps

Reading a WHEA Error

The canary for an unstable undervolt on both vendors is the Windows Hardware Error Architecture (WHEA) corrected-error, logged in Event Viewer under WHEA-Logger as event ID 19 or 47, or on Linux in dmesg as an MCE. A single corrected WHEA under heavy load means your undervolt is on the edge and correcting errors in hardware; it has not crashed yet, but it is telling you it will. Treat any WHEA during testing as a failure and back off. Do not rationalize it. The hardware is not wrong.

# Linux: check for machine-check / correctable errors after a run
sudo dmesg | grep -iE 'mce|hardware error|corrected'
journalctl -k -b | grep -iE 'mce|whea|corrected'

# Windows (PowerShell): count WHEA events since boot
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'}

Five Pitfalls That Will Bite You

Every one of these has cost somebody a weekend. None of them is exotic. They are the same five mistakes, repeated across every forum thread since Skylake.

Silent Corruption vs Hard Crashes

Internalize the distinction before anything else. A hard crash is a gift: it is obvious, it is recoverable, and it points at the last thing you changed. Silent corruption is the assassin: the machine stays up, your compile succeeds with a subtly wrong binary, your save file writes a bad byte, and you find out weeks later. This is why numerical-check stress testing is non-negotiable and why you back off aggressively rather than living on the ragged edge.

The Six Pitfalls

1. Undervolting the core but forgetting the cache. Fix: always set the CPU Cache/Ring offset to match the core; in ThrottleStop's FIVR they are separate domains and the cache is easy to miss.
2. Changing three things at once. XMP, CPU offset, and DLVR or power limits together. Fix: change one variable, test, lock it, then move to the next. When it crashes you must know the culprit.
3. Trusting a value you never read back. Fix: confirm the applied VID under load in HWiNFO or with intel-undervolt read; boards ignore offsets silently and you will tune against a value that was never in effect.
4. Testing only at idle or only in games. Fix: use mprime/linpack with numerical checks for hours; games neither generate peak current transients nor verify arithmetic.
5. Forgetting persistence across suspend/resume. Fix: on laptops especially, use intel-undervolt-loop or a resume hook, because MSR writes vanish on wake and your afternoon-stable undervolt reverts to stock mid-session.
6. Living on the benchmark-stable edge. Fix: back off 10-15% (or +2-3 CO) from the last value that passed, because a hot July ambient or an AVX-512 workload will find the margin you did not leave.

Recovering From an Unbootable Undervolt

If a BIOS undervolt will not POST, do not panic and do not assume damage; undervolting cannot physically harm the chip. Most boards auto-recover to stock after two or three failed boots. If not, Clear CMOS via the jumper or rear button, and the offset is gone. On a laptop, a ThrottleStop or intel-undervolt setting that will not boot the OS is cleared by booting into safe mode (Windows) or by removing the service before the config applies (Linux); if the OS itself will not load, boot removable media and delete /etc/intel-undervolt.conf or disable the systemd unit. There is always a way back, which is exactly why you noted the Clear-CMOS location in step one.

Troubleshooting Table

Symptom to cause to fix, for the failures that actually happen. Read the symptom column, not the internet.

Advanced Tips

Once the all-core baseline is rock solid, there is another few percent and a few more degrees to be had. This is optional, and it is where the silicon lottery pays out for the patient.

Per-Core Curve Optimizer

Cores are not equal. AMD fuses a per-core quality ranking, and Ryzen Master (or HWiNFO) will show you the two or three preferred cores that boost highest. Those golden cores tolerate the least undervolt; the mediocre cores tolerate the most. A per-core Curve Optimizer profile, deep negatives on the weak cores and gentle negatives on the golden ones, beats any single all-core number for both temperature and sustained boost. It takes an hour of per-core testing. It is worth it on a chip you will keep for years.

Undervolting Handhelds and the Steam Deck

Handhelds are the killer app for undervolting because every watt saved is battery life and every degree saved is fan noise against your palms. The APUs in these devices respond well to a modest Curve Optimizer offset, and the community has mapped the safe ranges per device. The trade-off is exactly the efficiency-versus-runtime axis we mapped in the Switch 2 versus Steam Deck comparison: a well-tuned undervolt is often worth more real-world runtime than any in-game setting.

Pairing With Power Limits and the Bigger Picture

Undervolting composes beautifully with power limits. Set a package power cap (PL1/PL2 on Intel, PPT on AMD) and the undervolt lets the chip do more work inside that same wattage envelope, which is the most efficient possible operating point. This is the same discipline, aimed the other direction, as GPU tuning; if you want the inverse art of pushing a chip up the curve instead of down, our GPU overclocking walkthrough is the companion piece. And remember the system view: in a modern rig the graphics card is the real furnace, drawing more than the CPU and RAM combined, as the power figures in our RTX 5090 review make uncomfortably clear. Cooling the CPU is necessary; it is rarely sufficient.

The Complete Working Configuration

Here is the whole thing assembled: a known-good Intel Linux config, an AM5 BIOS settings sheet, and the persistence unit. Treat these as starting points, not copy-paste destinations; your silicon decides the final numbers, and step 13 says write them down.

Intel Linux: Complete intel-undervolt.conf

# /etc/intel-undervolt.conf - COMPLETE WORKING EXAMPLE
# Core Ultra / Raptor Lake desktop. Verify with: sudo intel-undervolt read
# Reference: https://github.com/kitsunyan/intel-undervolt

enable yes

# --- Voltage offsets (mV). Core and Cache MUST match. ---
# Conservative-daily. ArchWiki: 100-200 mV usually OK, >200 mV crashes.
undervolt 0 'CPU'          -125
undervolt 1 'GPU'             0
undervolt 2 'CPU Cache'    -125
undervolt 3 'System Agent'    0
undervolt 4 'Analog I/O'      0

# --- Power limits (W): short-term (PL2), long-term (PL1) ---
power package 64 45

# --- Thermal: throttle 3 C below Tjmax for headroom ---
tjoffset -3

# --- Daemon: apply offsets once, re-check power every 5 s ---
interval 5000
daemon undervolt:once power:5000 tjoffset:once

AMD AM5: BIOS Settings Sheet

# AM5 UEFI - COMPLETE WORKING EXAMPLE (Ryzen 9000)
# Verify Vcore/temps in Ryzen Master or HWiNFO under load.
# Reference: https://skatterbencher.com/amd-curve-optimizer/

Precision Boost Overdrive ........ Advanced
  PBO Limits ..................... Motherboard
  Thermal Limit (Tctl) ........... 85 C        # optional cap
  Curve Optimizer ................ All Cores
    CO Sign ...................... Negative
    CO Magnitude ................. 20          # daily; -25 if it soaks clean
  Max CPU Boost Clock Override ... 0           # +0 first; add later if stable

EXPO / Memory .................... Profile 1   # validated BEFORE CO tuning

# Expected result under load:
#   Vcore ....... 1.05-1.10 V (was ~1.25-1.30 V stock)
#   Temp ........ 10-20 C lower
#   Boost ....... held longer -> ~6% Cinebench uplift (Precision Boost 2)

The systemd Service (Persistence)

# Enable persistence + suspend/resume re-apply, then verify.

sudo modprobe msr
echo msr | sudo tee /etc/modules-load.d/msr.conf

sudo intel-undervolt apply
sudo systemctl enable --now intel-undervolt.service
sudo systemctl enable --now intel-undervolt-loop.service   # re-apply on resume

# Confirm it survived a suspend/resume cycle:
sudo systemctl status intel-undervolt.service --no-pager
sudo intel-undervolt read

That is the whole discipline. Baseline, isolate, step in, verify with arithmetic, back off from the edge, persist, and document. Do it right and you will never think about it again, which is the highest compliment you can pay a tune: the machine simply runs cooler and quieter and holds its clocks, and the only evidence is a fan that no longer screams. For the exhaustive Linux specifics, keep the ArchWiki Undervolting CPU page and the UltrabookReview ThrottleStop guide open in a tab, and pull the tools themselves from the official TechPowerUp ThrottleStop download. The law is the datasheet; the lore is the forum thread. You now have both.