By Walter Jobs, Technology writer and editor · Published 10 October 2026
The reason this question has no clean answer is that the vendors do not agree on what a frame cap is for. NVIDIA presents it primarily as a latency and variable-refresh tool, with power saving third. AMD presents it as a power, heat and noise tool and never claims a latency benefit at all. On AMD hardware, the frame limiter and the latency feature cannot even be switched on at the same time.
So the honest version of this article is not a yes or a no. It is: here are the four reasons to cap, here is which of them applies to you, and here is the one place where NVIDIA’s own documentation says two different things.
The four reasons, in order of how often they are the real one
| Reason to cap | Where to set the cap | Whose documentation supports it |
|---|---|---|
| Stay inside a variable refresh window | A few frames below your panel’s maximum refresh | NVIDIA states this purpose directly |
| Cut power draw, heat and fan noise | At or just below your refresh rate | AMD states this as the primary purpose |
| Stop a game burning the machine on a menu | A high cap, well above your play frame rate | AMD documents the problem explicitly |
| Reduce latency in a GPU-bound game | Slightly below your average frame rate | NVIDIA, with a contradiction covered below |
The variable refresh case, which is the strongest
If you own a G-SYNC or FreeSync display, this is almost certainly why you are asking. A variable refresh panel has an upper limit, and once your frame rate exceeds it the sync has nothing left to give: the display is already at maximum and the frames are arriving faster than it can show them. The tearing or the queueing you were trying to avoid comes back.
NVIDIA names this as one of three purposes for its driver-level limiter: “This feature is particularly helpful when trying to save power, reduce system latency, or keep within a specific Variable Refresh Rate range on a G-SYNC or G-SYNC Compatible display.” Its instruction is specific: “Set the Max Frame Rate slightly below the maximum refresh rate of your display to stay within the Variable Refresh Rate range – providing a no-tear, low system latency experience!”
How far below is a judgement nobody publishes as a specification. Blur Busters, which tested this at length and is a third party rather than a vendor, recommends “a minimum of 3 FPS limit below display’s maximum refresh rate”, with worked examples of 57 at 60 Hz, 117 at 120 Hz and 141 at 144 Hz. We cite that as their tested recommendation, not as a vendor statement, because no vendor makes one.
The rest of the variable refresh configuration, including whether VSync belongs on or off alongside it, is a longer argument with a surprising answer, and it has its own article.
The power and heat case, which belongs to AMD
AMD is the vendor that leads with this, and its wording on its frame rate limiter is the clearest statement of the case any manufacturer has published: “Limiting the frame rate not only saves power, but also reduces heat and noise, keeping your GPU cool and quiet.” It adds when the gain is largest: the limiter “can reduce GPU power consumption (great for games running at frame rates much higher than the display refresh rate)”.
AMD’s formal version of the same claim, which reads like it went past a legal review, is worth having because it is the most precise sentence on the subject: “Frame rate targeting is designed to reduce heat, noise and power consumption by letting users set a target frame rate for their games and applications.”
What no vendor publishes is a number. Not a watt figure, not a degree figure, not a percentage, from either AMD or NVIDIA, for how much a cap saves. AMD publishes percentages for its performance features and nothing at all for this one. So if you see “capping your fps saves 30% power” stated as fact, it came from somebody’s measurement of one machine, which is fine if it is labelled and misleading if it is not. The direction is documented. The magnitude is yours to measure.
Where this matters most is a laptop, where the saved watts come straight out of the thermal budget shared with the processor, and where NVIDIA documents an interaction worth knowing: if its limiter and its battery features are both on, “the NVIDIA Control Panel will cap the framerate to the lowest of the limits”.
The menus and loading screens case, which is the one people never think of
This one deserves more attention than it gets, and AMD states it better than we could: a frame rate limiter “caps performance not only in 3D rendered in-game scenes, but also in splash screens, loading screens and menus, where frame rates can often run needlessly into the hundreds of fps. Users might wish to set a very high cap just to limit wasteful fps like that seen in menus and such, while still taking advantage of the responsiveness given by fps well beyond 60.”
That is a specific, useful recommendation that follows from it: a cap does not have to be near your refresh rate to be worth setting. A cap at, say, 300 fps will never touch your gameplay and will stop a title rendering a static pause menu at four figures with the fans at full speed. If you have ever heard a machine get suddenly loud while you were reading a menu, this is the fix, and it costs you nothing anywhere else.
The latency case, where NVIDIA disagrees with NVIDIA
This is the part of the subject where almost every guide picks a side without noticing there are two, so here are both, in NVIDIA’s words, from two NVIDIA pages.
From the announcement of its driver limiter: “To maximize latency reduction in GPU bound scenarios where FPS is consistent, set Max Frame Rate to a framerate slightly below the average FPS and turn Low Latency Mode to Ultra.”
From its own latency optimisation guide, on the variable refresh configuration: keeping VSync on with a latency feature “will automatically cap the framerate below the refresh rate, preventing VSYNC backpressure, eliminating tearing, and keeping latency low if you become GPU bound below the refresh rate of your display. Do note, however, that this method will result in slightly higher latency than just letting your FPS run uncapped with NVIDIA Reflex enabled.”
So one page says cap it to reduce latency, and the other says a cap costs slightly more latency than running uncapped. NVIDIA has never reconciled these in print, and we are not going to pretend it has.
They are reconcilable, and the reconciliation is the useful part. The two pages are describing different machines:
- Without a latency feature, a GPU-bound game fills the render queue, and every queued frame is delay. A cap slightly below your average stops the queue filling, so it genuinely reduces latency. That is the first quote’s situation.
- With Reflex or an equivalent, the queue is already dealt with. NVIDIA’s description of Reflex is that it works by “eliminating the GPU render queue and reducing CPU back pressure in GPU intensive scenes”, and its own comparison is explicit: “instead of being locked to a particular framerate, your framerate can run faster than your limit, further reducing your latency. You can think of it as a ‘dynamic’ framerate limiter that keeps you in the latency sweet spot at all times.” A fixed cap on top of that is a blunter instrument than the one already running, so it costs a little. That is the second quote’s situation.
The practical rule that falls out: if the game supports a latency feature, turn that on and leave the frame rate uncapped unless you need the cap for a variable refresh window. If it does not, a cap slightly below your average frame rate is the best latency tool you have. The mechanics of why the queue does this are covered in frame rate and input lag.
The AMD complication, which is a real cost
On Radeon hardware there is a decision the NVIDIA documentation does not have an equivalent for, and it is buried in a support note: “Radeon Chill and Radeon Anti-Lag cannot be enabled at the same time. When Radeon Chill is enabled, Radeon Anti-Lag will automatically be disabled, and vice versa.”
So AMD’s dynamic frame limiter and AMD’s latency feature are mutually exclusive. You choose power and quiet, or you choose responsiveness. That is a genuine divergence from how this works on a GeForce card, and it belongs in any honest answer to the question on this page.
Two more AMD specifics worth having, since both are regularly reported wrongly. Its fixed frame rate target feature covers DirectX 9 through 12 and Vulkan and “offers targets in the range of 30 to 200 fps, in full-screen exclusive mode”, with a workflow limitation AMD states plainly: “Changes to the Frame rate target must be done outside of the game, i.e. exit the game completely, make your changes, and then start the game again.” And the dynamic one has a published auto-tuning behaviour: on a fixed refresh display its maximum “will match the peak refresh rate” and its minimum “will be one-half of the peak refresh rate”.
Three things commonly said about this that are not true
That Radeon Boost is AMD’s frame limiter. It is not a limiter at all. AMD describes it as a feature that “dynamically lowers resolution of the entire frame when fast on-screen character motion is detected via user input”. It raises frame rate rather than capping it, and it works only in AMD’s published list of supported titles, which is around thirty games.
That AMD’s dynamic limiter replaced its fixed one. AMD answers this itself, in its own FAQ: “Does Radeon Chill replace FRTC (Frame Rate Target Control)? No. It currently does not.” Both exist, and the fixed one is still listed for current Radeon cards.
That an in-game cap is always lower latency than a driver or external one. This ranking is everywhere and no vendor has published it. NVIDIA has never compared limiter types. The widely repeated ordering originates in third-party testing by Blur Busters, which is reputable work, and it should be attributed to them rather than presented as a vendor position.
When not to cap
Three situations where the answer is no.
You are already below your refresh rate. A cap you never reach does nothing except give you something else to have configured wrongly. Measure first, with an on-screen counter, before setting one.
You are on a fixed refresh display with VSync off and you prefer the responsiveness. Uncapped with tearing is a legitimate choice, and it is the configuration competitive players have used for twenty years. The tearing is real and so is the lower latency.
You cap at exactly your refresh rate on a variable refresh panel. This is the common mistake rather than a strategy. A cap at precisely the panel’s maximum lets the frame rate touch the ceiling, which is the one place the sync stops helping. A few frames below is the setting; the VRR article explains what happens at the boundary.
A note on games whose engines care
Beyond the user-facing reasons, some engines have their own stake in frame timing. Epic’s documentation for its engine describes the underlying problem without reference to any cap: its engine “uses a variable frame rate”, and “while this is good for hardware scalability, it creates a challenge for the physics engine”, which “works best with small fixed time steps”. Its solution, substepping, divides the frame and ticks the simulation several times, with the trade-off stated: “The smaller the max sub-step time the more stable your simulation will be but at a greater CPU cost.”
Older engines handled this less gracefully, which is where the folklore about specific frame rates breaking specific games comes from. Valve’s community developer wiki, documenting the frame limit console variable in its own engine, notes that running far above the limit can produce timing problems including the game running faster than it should, and that uncapped rates can bring tearing and coil whine. That is a wiki rather than engineering documentation and we flag it as such, but it is first-party enough to establish that engine-level frame rate sensitivity is a real category rather than a myth. It is also a list of named cases, not a general rule, so it is not a reason to cap by default.
Common questions
What number should I actually set?
If you have a variable refresh display and no latency feature in the game: a few frames below your panel’s maximum. If you have a latency feature: leave it uncapped and let the feature work. If your goal is heat and noise: at your refresh rate. If your goal is only to stop menus screaming: something high, like 300.
Does capping fps reduce input lag or increase it?
Both, depending on whether a latency feature is running. Without one, a cap below your average reduces it by keeping the render queue from filling. With one, NVIDIA’s own guide says a cap costs slightly more latency than running free. The section above sets out both quotes.
Will capping my frame rate make my GPU last longer?
It will run cooler and quieter, which both vendors document. Neither claims a lifespan benefit and we are not going to either, because nobody has published data on it.
Is 60 the right cap for a 60 Hz monitor?
On a fixed 60 Hz panel, yes, and the frames above 60 were being discarded anyway. On a 60 Hz variable refresh panel, slightly under is better for the reason above.
Should I cap below my frame rate to make it more consistent?
This one does work, and it is underrated. A cap at a level you can always sustain converts a fluctuating frame rate into a flat one, and the research on this is unambiguous that flatness matters more than height: see how many fps you need for the study that found the average is a poor predictor and the floor is a good one.