Thermal management
Updated: May 13, 2026
Quest headsets are dense, untethered devices with high CPU, GPU, and display workload. They have a fixed thermal envelope — the amount of heat the device can dissipate before its surface temperature, internal sensors, or battery temperature reach safety thresholds. When workload pushes heat past those thresholds, Horizon OS protects the device and the user by throttling the system. Your app sees this as reduced frame rate, longer load times, or, in extreme cases, an enforced cool-down state.
Designing for the thermal envelope is one of the highest-leverage performance choices you can make. An app that runs near the thermal ceiling drops frames in long sessions; an app that leaves headroom feels smooth from minute one to minute sixty.
How thermal management works
Horizon OS continuously monitors temperature across multiple sensors — SoC, battery, surface — and adjusts behavior in stages:
- Sustained workload budgeting. The system uses CPU and GPU levels to keep the device inside a steady-state thermal envelope. Choosing a lower sustained level when you can leaves headroom for short bursts.
- Throttling. When sensors approach a threshold, the system reduces clock speeds. Your app keeps running, but per-frame cost rises and frame timing becomes more variable.
- Frame-timing adaptation. The runtime’s frame timing algorithm, FrameSync, is designed to absorb the variable frame cost that throttling produces — sliding-window statistics and outlier rejection keep frames landing in their target vertical sync intervals when workload spikes.
- Cool-down state. If sustained workload pushes temperature past a hard limit, Horizon OS may force the device into a low-power cool-down state until sensors recover. The user sees a cool-down notification.
What this means for your app
Build for the long session, not the demo. The most common shipping mistake is profiling only startup and missing the thermal cliff at minute ten. If your app feels great for the first three minutes and then visibly degrades, you are running near the thermal ceiling.
- Build for the long session, not the demo. Apps often look fine for the first three minutes and then visibly degrade as the device heats up. Profile sustained sessions, not just startup.
- Stay below the sustained CPU and GPU level you actually need.Boosting is for short bursts (loading, scene transitions, physics-heavy moments). Sustained boost defeats the purpose and costs you battery and thermal headroom.
- Stagger expensive work across frames. Single-frame spikes are absorbed by FrameSync’s outlier rejection, but predictable per-frame patterns produce the smoothest output and the lowest sustained heat.
- Detect and adapt to system signals. Apps should detect battery saver mode and reduce visual fidelity or disable non-essential effects when the device asks for help.
- Test on the device, not the simulator. Thermal behavior is hardware-dependent — only on-device profiling reveals the real envelope.
Common patterns that cause thermal pressure
- High shader complexity combined with high-resolution post-processing
- Continuous full-resolution passthrough alongside a heavy 3D scene
- Always-on physics simulation, particle systems, or dynamic lighting
- Failing to take advantage of fixed foveated rendering or App Spacewarp when the workload allows