The caveat comes first. The future half of that plan has no announced timetable and no published performance data, and PCWorld reports that Valve hasn't publicly demonstrated it. What has shipped is narrower, and it is covered below.
What is shipping now, and what is only planned
Two stages are easy to blur together:
- Shipped: a persistent on-disk cache for FEX's translated code. Griffais said on Bluesky that the FEX code cache is now enabled on Proton Experimental (ARM) and should exhibit improved 1%-low frame times, especially over subsequent runs. The phrase "subsequent runs" matters. The cache builds up as you play.
- Planned: Steam Pre-Caching integration. Instead of waiting for you to play the game and fill the cache yourself, Valve wants translated code ready before the first local launch. How that code would be produced, distributed, validated and updated hasn't been explained.
One reader comment on GamingOnLinux wondered whether Valve might share caches between users the way it does with shaders. It is a reasonable question, and the same commenter raised the security problem of accepting arbitrary code. That is speculation from a reader, not anything Valve has said.
How the Arm translation path works
Most Windows games are compiled for x86 processors from AMD and Intel. Arm chips use a different instruction set. FEX is the translator, and Valve's stack for a Windows x86 game on Arm runs through Proton, then FEX, then SteamOS on Arm.
FEX doesn't have to translate everything. Griffais told PCWorld that, in a proper Arm execution environment such as Proton ARM, FEX only translates the application's CPU code. He says Proton crosses over at the Win32 API boundary, so no Proton, OS or graphics driver code requires translation. FEX is left with the game's own CPU instructions.
Why translation causes hitches
Griffais says translation overhead is typically modest, especially in GPU-bound games. The problem is timing. A game running at 60 fps has about 16.7 ms to finish each frame. If FEX hits code it hasn't seen before and has to translate it mid-gameplay, that work can use up the frame budget and show up as a hitch.
A cache avoids repeating the work. As GamingOnLinux puts it, the cache is a place where FEX keeps the Arm64 machine code it generates after translating x86 code, so it doesn't repeat the same translation. The same report notes it can't cache everything, so it is one tool among several.
Why does the first run matter so much? A cache that fills during play helps your second session far more than your first. Pre-caching aims at the first session, which is where a new game would otherwise feel worst.
The FEX cache so far: September to October
The FEX project introduced disk caching in its September 2026 release (2609). Its description of the mechanism:
- Once enabled, code the JIT generates is written to a database in the FOZ file format.
- When FEX needs to JIT code later, it checks that database first.
- That lookup happens on the first run and on later runs.
The early release came with stated limits. The cache could grow without bound, there was no way to remove stale entries, and changed file contents might not invalidate old entries correctly. Those early instructions called for FEX_DISKCACHE=1 or the "DiskCache": "1" JSON option. Files went to Wine's %APPDATA% directory or $HOME/.cache/fex-emu/ by default, and the developers advised deleting those directories if space ran short. This describes the original developer-facing setup. It isn't necessarily how Steam's Proton Experimental build configures things today.
The October release (2610) addressed several of those problems:
- The disk cache automatically limits its size to 1GB and stops caching at that point. The limit is configurable.
- An optional in-memory buffer holds hot code blocks. The FEX developers say it is only worth using if a game stutters frequently from JIT invocations and you have spare RAM.
- FEX removes old disk caches when it updates, so you don't accumulate several 1GB files.
- For cached ELF files that carry a GNU build-id hash, FEX uses it as a partial key. That helps when a file was replaced and an outdated cache entry might otherwise be used.
Where this sits among other stutter fixes
PCWorld places the effort alongside other attempts to move costly compilation off the gameplay path. It points to Microsoft and Nvidia's Advanced Shader Delivery, where supported games can receive shaders compiled for a given hardware configuration. It also mentions Intel's Graphics Shader Distribution Service.
Those systems deal with GPU shaders. FEX's cache stores translated CPU code. The two aren't interchangeable, and neither fixes hitches from asset streaming, CPU bottlenecks or poor optimization. The shared idea is to get expensive work out of the way before it interrupts you. PCWorld also notes that Steam is well placed to help, because Valve already runs the delivery platform and has spent years building shader pre-caching for SteamOS.
What this does not tell you
- No benchmarks yet. The 1%-low improvement is Valve's expectation, not a measurement. Digital Citizen noted that Valve promised better 1% lows without publishing a single figure. There is also no comprehensive independent testing across Arm chips.
- 1% lows aren't the whole story. They reveal slow frames that averages hide, but they don't capture every cause of stutter.
- GPU differences remain. Griffais cautioned that Arm GPUs can differ substantially from the desktop GPUs games target, which can add performance costs with newer graphics features.
- Power still matters. CPU translation can affect battery life and power consumption even when the frame-rate impact is small.
- It isn't a universal fix. A cache for translated code doesn't show that any given game will run well on any Arm device.
Why Windows users should care
This is a Linux-and-Steam story on the surface, but it touches the Windows ecosystem. Arm PCs running Windows, including Snapdragon machines, depend on their own translation layers for x86 games. Valve's route avoids Windows entirely, running Proton and FEX on SteamOS for Arm. It is one more sign that "can it run my x86 library?" is becoming a question about how smooth the translation feels, not only whether it works.
If you're curious how this plays out, watch for three things. Valve might publish frame-time data for the cache. Steam might surface pre-caching for Arm titles. And FEX's cache limits and cleanup might change as it matures.
Bottom line
The shipped change is modest: a persistent translated-code cache in Proton Experimental for Arm, with the FEX project's October fixes for size and staleness. The ambitious part is pre-caching translated code before your first launch. It is a sensible idea with no schedule and no evidence yet. Treat it as a promising direction, not a solved problem.