Meta CTO Addresses Quest 3 Battery Setting Issue Following Bungled Horizon OS Update

Meta’s latest Horizon OS update for Quest (v76) introduced a new Battery Saver setting as default, which has led users to experience frame rate issues in apps and games. Now, Meta CTO Andrew ‘Boz’ Bosworth says the company is rolling out a fix and “taking a serious look” at how OS updates are communicated in the future.

In a recent Instagram AMA, Bosworth addressed recent user complaints about a quietly included system default, which automatically toggles a more aggressive version of Quest 3’s Battery Saver mode.

Previously, Battery Saver limited Quest’s refresh rate to 72Hz, applied fixed gaze rendering, and reduced brightness to 50%—something which could be toggled on in the settings to extend battery life.

The latest v76 release of Horizon OS however includes a new version of Battery Saver as default, putting the headset’s refresh rate to 90Hz, but critically capping many games at a nauseating 45FPS.

If users were unaware they could turn off Battery Saver, they would have no idea why the headset all of a sudden decided to act up, possibly even leading to blame falling on individual developers for poor optimization.

PSA: To disable Battery Saver on Quest 3, navigate to the “Power” settings within the “Device” menu in the settings app. Then, toggle off the “Power Saving Mode” option.

Notably, many Quest apps don’t use Application Spacewarp (AppSW), which some older titles implemented to smooth out low framerate stutter by generating synthetic frames between real frames, effectively doubling the perceived frame rate.

Bosworth says Meta is “rolling the fix out for that.” He further notes that while the usual staggering of Horizon OS updates “helps us identify regressions sooner,” the company could “do better on documentation” when it comes to patch notes. As it stands today, iterative Horizon OS patch notes are fairly paltry, often times only including a few line items without much explanation.

Here’s the full transcript of Bosworth’s comment below:

Yeah, good discussion and feedback from developers this last week on the stability and changes that we’re making in our rollouts, making sure that those are higher quality than they have been.

I think it’s great feedback. We’re taking it seriously for the battery saver issue. We’re rolling the fix out for that.

And more generally, I don’t think it’s the case that we’re rolling things out too quickly. I do think it’s just the case that we’ve got to have a stronger set of processes in place for quality control before things go out the door, which we’re doing.

We’re taking a serious look at this. We’re spending time on it. So we appreciate the feedback as always from developers. We take it seriously. That’s our responsibility. These are our mistakes. And we’re going to fix them.

And we understand that this is not casual. This is people’s livelihoods and time spent on the line that matters a ton in the experience that consumers have of people’s software.

So yeah, taking that seriously. We’re doing the work. I think staggering things helps because staggering things actually helps us identify regressions sooner. But I agree we could do better on documentation too.