Ars Technica’s examination of Valve’s new layers correctly puts FEX at the center of that problem. Valve’s Steamworks documentation confirms the architecture in unusually direct terms: Windows games run through Proton, x86 code is translated to Arm64 by FEX, and Android games take a separate route through Lepton. For Windows game developers and players, the result is a compatibility chain with two jobs that Proton previously did not have to separate on the AMD-powered Steam Deck.
That makes Steam Frame the first major test of whether Valve’s SteamOS strategy can survive a processor-architecture jump without asking the bulk of the Steam catalog to be rebuilt. It also sets a clear limit on the promise: the layers expand the number of possible ports and playable games; they do not make every Windows game, every anti-cheat implementation, or every Android APK automatically compatible.
Proton Handles Windows; FEX Handles the CPU Gap
Proton remains Valve’s Windows-on-Linux layer. It incorporates Wine-derived Windows API compatibility and graphics technologies including DXVK, which translates DirectX calls to Vulkan, Steam Frame’s native graphics API. On a Steam Deck or a typical x86 Linux PC, that translation is sufficient at the processor level because the game and the host system both use x86-family CPUs.
Steam Frame changes that equation. A Windows game’s executable code generally expects x86 or x86-64 instructions; the Snapdragon chip executes Arm64 instructions. FEX is the component that dynamically translates that x86 code into Arm64 instructions, while passing appropriate graphics calls through to native OpenGL or Vulkan libraries. Valve says its code cache is intended to reduce stutter from repeatedly recompiling the same code paths.
In practical terms, a conventional Windows Steam release on Frame follows this path:
- The game’s Windows API and DirectX assumptions are handled by Proton’s Wine- and Vulkan-based components.
- The game’s x86 machine code is translated for the Arm64 processor by FEX.
- SteamOS supplies the Linux host environment beneath both layers.
Calling FEX “the new Proton” would therefore be misleading. FEX does not replace Proton’s handling of Windows APIs, registry behavior, graphics interfaces, launchers, and other Windows-facing assumptions. Proton does not replace FEX’s processor translation. They are stacked because Steam Frame has to bridge both the operating-system gap and the CPU-instruction-set gap.
The performance implication is equally important. Translation has overhead, even where it is highly optimized, and VR is less forgiving than a handheld display when frame pacing deteriorates. A game that runs acceptably through Proton on an x86 Steam Deck may still need profiling, configuration work, or a native Arm64 build before it is suitable for a standalone headset. Valve’s developer materials describe the Windows x86 route as what will make sense “for most developers,” but do not publish a universal performance target, a compatibility percentage, or guarantees for difficult categories such as invasive anti-cheat and proprietary launchers.
FEX Is Long-Term Valve Infrastructure, Not a Last-Minute Emulator
FEX did not appear solely to solve a headset launch. Its lead developer, Ryan Houdek, wrote in November 2025 that Valve had supported the project from its prototype phase, beginning in 2018. Ars Technica also reports that Valve software developer Pierre-Loup Griffais had described the effort as a long-range project rather than a quick compatibility fix.
That history explains why Valve is integrating an open-source project rather than presenting a proprietary emulator as an isolated Steam Frame feature. A capable x86-to-Arm translator needs wide instruction-set coverage, graphics-aware behavior, persistent code caching, and years of testing against awkward real-world software. Gaming is especially harsh terrain: old launchers, custom engines, copy-protection remnants, JIT compilers, DRM, and mod tools all exercise software assumptions that clean benchmarks often miss.
The company’s own choices show where it expects the boundary to fall. Valve recently updated Half-Life: Alyx for standalone Steam Frame operation with an Arm64/aarch64 port, foveated rendering, depth reprojection, and further rendering and performance changes. That is not evidence that FEX failed. It is evidence of the opposite lesson: Valve is willing to use its own flagship game to demonstrate that a native Arm64 path is preferable when performance, thermals, and VR motion comfort are on the line.
For third-party developers, FEX is the route that makes “ship the Windows build” a plausible starting point rather than an immediate architecture-porting project. But a native Arm64 Linux build removes an entire runtime translation stage. It should offer more room for game logic, rendering, battery life, and stable frame delivery—resources that are constrained on a mobile headset.
Lepton Gives Mobile VR Builds a Separate Route
Lepton addresses a different compatibility opportunity: Android games on Linux. Valve describes it as a container-based compatibility layer designed to minimize overhead. Unlike the Windows route, the relevant Android VR software is commonly already compiled for Arm64, which matches the Steam Frame processor architecture.
That means an Android Arm64 build does not generally need FEX. Its proposed path is Android app, then Lepton, then SteamOS on Arm. Valve’s Steamworks documentation explicitly positions this route for VR developers that already have mobile-optimized builds, typically made for other Android Arm64-based hardware.
The operational consequence is significant. Developers that have maintained both a high-end PC VR build and a mobile VR build can make a more targeted decision. The Windows x86 version may preserve visual quality or feature parity but must travel through Proton and FEX. The Android build may better fit Steam Frame’s mobile-class hardware profile and avoid CPU instruction translation, though it still needs validation in Valve’s runtime and Steam distribution environment.
Lepton should not be read as a blanket entitlement to a competing headset’s storefront or catalog. Valve’s documentation describes a technology path for Android games to run on Steam Frame; it does not say that a purchaser’s existing Android-platform licenses transfer to Steam, or that Valve can distribute APKs owned by another store. A developer or publisher still has to participate by bringing a build to Steam and supporting it there. The technical ability to run an Android package and the commercial rights to distribute a game are separate problems.
That omission matters because the attractive shorthand—“Steam Frame can run Quest games”—conceals the work and agreements still required. A studio with an Android build has a lower technical barrier than a studio starting from Windows x86, but Valve has not promised automatic conversion of another platform’s library into Steam Frame titles.
SteamOS for Arm Is the Larger Bet
Griffais told Rock Paper Shotgun that Steam Frame is paving the way for more general SteamOS support on Arm devices. That ambition is credible precisely because FEX is now becoming part of Valve’s shipping compatibility story rather than remaining a developer experiment. An Arm-capable SteamOS stack could matter beyond one VR headset, including future handhelds, compact gaming devices, and systems built around more power-efficient processors.
But “SteamOS for Arm” is not interchangeable with “Windows games run as well on Arm as on x86.” Valve’s existing SteamOS success grew from a relatively controlled target: AMD x86 hardware, a known graphics stack, and years of Proton work informed by actual Steam Deck game usage. Steam Frame adds a mobile Arm chip, stringent VR latency requirements, and a new translation layer. Every additional variable gives developers and Valve another place to test—and another way for a game to fall outside the expected path.
For Windows users, this development is also a reminder of what Valve has been building since Steam Deck: a route to sell and run Windows-originated PC games without making Windows the device operating system. Proton made that proposition credible on x86 Linux. FEX is the missing processor-level piece for an Arm Linux device. Lepton gives Valve a parallel supply of mobile VR software rather than forcing every studio to choose only between a Windows port and a native Linux port.
The immediate advice for Steam Frame developers is straightforward. Treat Proton plus FEX as the compatibility baseline for a Windows x86 game, not as proof of production readiness; test the actual executable, launcher, graphics configuration, controllers, and multiplayer services on the device. If an optimized Android Arm64 VR build already exists, evaluate Lepton as a separate deployment target rather than assuming it is merely a fallback.
Steam Frame’s software story is therefore not one compatibility layer, but a routing system. Windows x86 games must cross Linux and processor-architecture boundaries; Android Arm64 games primarily cross an operating-system boundary. Valve has built a path for both, but the game most likely to define the headset’s credibility will be the one that proves those layers can deliver steady performance where VR users notice every missed frame.