Box64 runs x86_64 Linux binaries on machines that are not x86_64, which is how a great deal of software still reaches ARM64 laptops, LoongArch desktops and RISC-V boards. Version 0.4.4, released on August second, changes two defaults that most users were setting by hand anyway. DynaCache, which writes translated native code to disk so a second launch does not repeat the work, is now on out of the box with a two gigabyte cap. The recompiler option BOX64_DYNAREC_CALLRET now defaults to 2, which is a general speedup across every backend. There is also a graphical configurator, which is new territory for this project.
The short answer
Box64 0.4.4 shipped on August second, 2026. DynaCache, which stores generated native code on disk so repeated launches skip the translation work, is now enabled by default and compressed with a two gigabyte ceiling. BOX64_DYNAREC_CALLRET now defaults to 2, a general speedup on every backend. A new Python based box64-configurator manages per application profiles graphically, in English and Chinese, with an optional KDE plugin. LoongArch gained faster opcodes and a zero upper optimisation, RISC-V gained wider AVX support and better extension detection, and improved x87, TF flag and signal handling extends compatibility with DRM protected games.
Emulation projects tend to accumulate options faster than they accumulate good defaults. Box64 has been an unusually good example of that: a long list of tuning variables, a community that traded profiles for individual games, and a recompiler cache that was excellent and switched off. Version 0.4.4 spends most of its effort on that gap.
The cache is on now
Box64 translates x86_64 instructions to native code while the program runs. The translation is quick, but repeated on every launch it becomes the reason a program feels sluggish to start on ARM64 when it starts instantly on a laptop.
DynaCache writes that generated code to disk so the second launch can reuse it. In 0.4.4 it is enabled by default, the stored code is compressed, and the cache is capped at two gigabytes so it does not grow without bound on a device where storage is often the scarce resource. Nothing about the first run changes. Everything after it starts faster, which for large games is the difference between a shader style wait and simply launching.
The other default worth noting is BOX64_DYNAREC_CALLRET, now set to 2, described as a general speedup applying to every backend. If you carry hand tuned profiles from an earlier version, this is a good moment to strip out the settings you were applying manually. Two of the most useful are now the defaults, and profiles that pin old values will hold you back rather than help.
A configurator, in a project that never had one
The second change is cultural more than technical. box64-configurator is a Python application that edits per program profiles in a window, rather than through environment variables exported before a launch or a configuration file edited by hand.
That matters because Box64's tuning surface is genuinely large and genuinely per application. The values that make one game behave are wrong for another, which is why profile snippets have circulated in forums for years. Moving that into a tool the project ships makes the knowledge discoverable instead of tribal. It comes in English and Chinese, and an optional KDE plugin puts it in the file manager, so a game's profile can be set from its context menu.
For a project whose users have historically been comfortable with the command line, that is a deliberate widening of the audience. ARM64 laptops and LoongArch desktops are no longer only in the hands of people who enjoy reading a dynarec's documentation.
Backends, and the accuracy work underneath
The LoongArch backend received the heaviest optimisation pass: faster opcodes and a zero upper optimisation that eliminates unnecessary register clearing. That second one is the sort of change that pays off quietly, because the pattern it removes fires constantly in translated code rather than in one hot function.
RISC-V gained wider AVX support and better detection of which CPU extensions the host actually has. Extension detection matters more on RISC-V than elsewhere, since what a board supports varies enormously and guessing wrong means either crashing or leaving performance unused.
Underneath both, the release improves x87 floating point handling, TF flag management used by debuggers, and signal handling. Those three sound like housekeeping and are the reason the compatibility notes mention digital rights management wrappers, with Capcom and Sony titles called out. DRM layers exercise the strange corners of the instruction set on purpose, so accuracy work tends to surface there first.
If you already run Box64, the upgrade is worth taking for the defaults alone. If you have been keeping a spreadsheet of environment variables per game, open the configurator and delete half of it.
Sources and further reading
- Box86 and Box64 blog: new Box64 v0.4.4 release
- Box64 v0.4.4 release on GitHub
- Phoronix: Box64 v0.4.4 released with new Box64-Configurator app
- Box64 repository and documentation
Frequently asked questions
What is DynaCache and why does enabling it by default matter?
Box64 is a dynamic recompiler: it translates x86_64 instructions into native ARM64, RISC-V or LoongArch code as the program runs. That translation is fast but not free, and by default it was thrown away when the process exited, so every launch paid the cost again. DynaCache saves the generated code to disk, compressed, so anything used a second time starts much faster. It has existed as an option for a while. What changed in 0.4.4 is that it is on unless you turn it off, with a two gigabyte ceiling on the cache so it cannot quietly grow without limit. The practical effect is that the first run of a program feels the same and every run after it starts noticeably quicker.
What is box64-configurator?
A graphical front end, written in Python, for the per application settings that previously meant editing configuration by hand or exporting environment variables before every launch. Box64 has a large number of tuning knobs, and the right values differ per program, which is why the community has traded profile snippets for years. The configurator manages those profiles directly. It ships in English and Chinese, and there is an optional KDE plugin that exposes it from the file manager, so you can set a game's profile from its context menu rather than remembering variable names.
What changed for RISC-V and LoongArch specifically?
The LoongArch backend received the larger share of the work: faster opcodes across the board plus a zero upper optimisation that removes unnecessary register clearing, which is the kind of change that compounds because it fires constantly in translated code. RISC-V gained expanded AVX support and better detection of which CPU extensions are actually present, which matters on that platform because extension availability varies so widely between boards. Both benefit from the new BOX64_DYNAREC_CALLRET default of 2, described as a general speedup across all backends, so ARM64 users get that one for free too.
Does 0.4.4 improve game compatibility?
Yes, mostly through emulation accuracy rather than through per title hacks. The release improves x87 floating point handling, TF flag management used by debuggers, and signal handling, and it specifically extends compatibility with games that use digital rights management protections, with Capcom and Sony titles named. DRM wrappers are hard for an emulator precisely because they lean on the awkward edges of the instruction set and on behaviours a normal compiler never emits, so accuracy work in x87 and signal handling tends to show up first in exactly those titles.
Where does Box64 fit next to a virtual machine or a container?
It solves a different problem. A container shares your kernel and your architecture, so an x86_64 container image will not run on ARM64 without emulation underneath it. A virtual machine gives you another kernel, but not another instruction set, unless you are doing full system emulation with the performance cost that implies. Box64 is user space emulation of the binary itself: the process runs under your kernel, uses your native libraries where it can through its wrapped library mechanism, and only the x86_64 code gets translated. That is why it is usually the fastest route for running one x86_64 application on a non x86_64 machine, and why it pairs naturally with Wine for Windows software on ARM64.