Valve developer Pierre-Loup Griffais revealed on September 27 that FEX code caching has been enabled in the Arm version of Proton Experimental, which runs Windows x86 games on Arm devices.
According to Griffais, this is expected to improve frames that take longer to process, particularly on subsequent runs. He stated that "1% low" frame times should improve, but did not specify which games were tested or provide concrete figures on the degree of improvement.
The underlying mechanism for running x86 Windows games on Steam Frame had already been disclosed previously. This latest change is a concrete refinement aimed at reducing the repeated overhead of converting x86 CPU instructions to Arm64, thereby reducing stuttering.
What changed in Proton's Arm version
The change Griffais disclosed involves enabling FEX's code cache within the Arm version of Proton Experimental.
He suggested that particularly on re-runs after a cache has already been built, the frames experiencing the worst frame-time spikes—the so-called "1% low"—could see improvement.
However, this is currently a developer's forward-looking statement, not an announcement of benchmark results. The post includes no before-and-after figures, nor does it name the games or devices used for measurement.
Average frame rate alone makes such differences difficult to detect.
For example, even if most of a game runs smoothly, if just a handful of frames take noticeably longer to render—say, at a scene transition—players will perceive this as a momentary stutter or hitch.
"1% low" is a metric designed to highlight these slow frames, which tend to be masked by average values.
One potential cause that FEX's code cache aims to reduce is the re-translation of CPU instructions.
That said, Griffais's post does not specify what methodology is used to calculate "1% low," nor under what conditions it was measured. As a result, it's currently impossible to judge exactly how much improvement will actually occur.
Nor is this the first time Arm support itself has been added.
Valve had already added FEX-2605 to the ARM64EC build in Proton 11.0-1. In other words, the framework for combining Proton and FEX to run Windows x86 games on Arm64 was established first, and this latest development represents code caching being enabled on top of that within the Arm version of Proton Experimental.
This change should not be interpreted as having been rolled out to all users of the stable version of Proton, nor as having the same effect on Steam Deck, which uses an x86-64 processor.
Reusing previously translated code
FEX dynamically translates CPU instructions built for x86 into instructions that can be executed on Arm64 processors.
This translation process itself requires CPU processing.
When a game later executes the same code again, if the previously generated Arm64 code has been saved and can be reused directly, the same translation process doesn't need to be performed again.
Griffais's specific mention of improvements upon re-execution aligns with this mechanism.
"FEX-2609," released by the FEX development team in September, provides a detailed explanation of this disk caching mechanism.
When the feature is enabled, code generated by the JIT (just-in-time compiler) is saved to disk as a database in FOZ format.
When FEX later needs the same code again, it checks this database for available code before re-translating it via JIT.
The cache isn't limited to use on the second launch onward.
Even during the initial launch, if code that has already been executed and translated needs to be used again later, the previously saved result may be reused.
However, the FEX-2609 release notes and the specific configuration details actually incorporated into Proton Experimental are separate pieces of information.
The FEX development team has published methods—such as environment variables—for enabling code caching on a standalone basis, but Griffais's post does not explain which settings Proton is using or which version of FEX has been incorporated.
Therefore, while the FEX-2609 documentation is useful as a reference for understanding the mechanism, it cannot be definitively concluded that Proton Experimental operates with the exact same storage format or settings.
Additionally, code being executed for the first time naturally will not exist in the cache.
The effectiveness of the cache will vary depending on factors such as how much code a given game repeatedly executes, whether the game itself generates new code during runtime, and whether an update has changed the executable file.
Furthermore, this code cache targets CPU-side x86-to-Arm64 instruction translation.
This is a separate process from shader compilation used by the GPU, and it is not a mechanism that resolves every type of stuttering that can occur during gameplay.
On Steam Frame, Proton and FEX divide responsibilities
The reason this change is relevant to Steam Frame lies in the compatibility architecture Valve itself has publicly disclosed.
Steam Frame is equipped with a Snapdragon 8 Gen 3, which uses the Arm64 architecture.
When running existing Windows x86 games on Steam Frame alone, Proton and FEX handle different roles.
Proton bridges the gap between the Windows API, DirectX, and other Windows-side elements and the Linux-side environment, enabling games built for Windows to run on the Linux-based SteamOS.
FEX, meanwhile, translates CPU instructions compiled for x86 or x86-64 processors into instructions executable on Arm64 processors.
Valve has further explained that it reduces emulation overhead by passing calls such as OpenGL and Vulkan directly to native Arm-side libraries.
In other words, running Windows x86 games on Steam Frame requires two major categories of compatibility processing.
One is the compatibility layer for running the Windows software environment on Linux. The other is the translation process for x86 instructions that Arm64 CPUs cannot execute natively.
The code cache enabled this time serves to reuse code that has already been translated within the latter category.
This does not eliminate the need for the Windows API compatibility layer handled by Proton, nor does it remove the need for translation from DirectX to Vulkan.
Additionally, "Lepton," which Steam Frame uses to run Android games, is a separate compatibility layer and is not directly related to this change.
According to Valve's developer documentation, for many game developers, running an existing Windows x86 version via Proton and FEX will be a viable option, rather than developing a dedicated Arm version specifically for Steam Frame.
The same documentation also describes FEX's code cache as a mechanism intended to minimize in-game stuttering as much as possible.
A feature that had previously been described as part of Steam Frame's compatibility design has now actually been enabled in the Arm version of Proton Experimental.
However, evaluating the actual impact on Steam Frame will require measuring, on a per-game basis, how much the frame-time degradation is actually reduced.
Improvement is expected, but real-world measurements are still absent
As of September 29, 2026, what is known is that FEX code caching has been enabled in the Arm version of Proton Experimental, and that Griffais expects improvement specifically in "1% low" frame times upon re-execution.
Information such as the games tested, the test environment, specific frame-time changes, cache size, and the conditions under which the cache is deleted or invalidated have not been disclosed.
Therefore, it cannot currently be stated that "stuttering has been resolved."
To verify the effect, one would need to compare a first run without any cache to a subsequent run after the cache has been built, using the same Arm device, the same game, and the same scene.
Such a comparison would need to examine not just average FPS but also the distribution of slow-to-render frames and frame times, while keeping all conditions other than the code cache as consistent as possible.
Some games may execute a large amount of code for the first time, making them less likely to benefit from the cache. Meanwhile, in other games, GPU-side processing or shader compilation—rather than CPU instruction translation—may be the primary cause of stuttering.
This post alone does not reveal which games will see the greatest benefit.
The implementation itself also remains a work in progress.
At the time FEX-2609 was released, the FEX development team stated that several challenges remained with the disk cache.
While there was a risk that the cache could grow indefinitely if an application itself generated code via JIT, at that time there was no mechanism for capping cache size or automatically purging old cache entries.
The team also noted the possibility that, if the contents of the original file changed, old cache entries might not be properly invalidated.
However, these are caveats that were disclosed specifically regarding FEX-2609 as a standalone component. It has not been confirmed that the same issues occur as-is within Proton Experimental, and this post does not reveal how Valve is managing the cache on its end.
If "1% low" frame times do improve, players could experience less momentary stuttering and smoother real-world gameplay, even if average FPS barely changes.
However, at this stage, what can be confirmed is limited to the fact that code caching has been enabled and the developer's outlook regarding its effect.
What we'll be watching for next are real-world measurement results comparing first launches to subsequent runs on a per-game basis, along with Valve's explanation of cache size management and how updates to games are handled. Once these are clarified, it will become possible to more concretely evaluate just how effective this change is when running Windows x86 games on Steam Frame.