Claude-Built Oblivion Remastered Mod Raises Frame Rates 41% Without Lowering Settings

TL;DR

OblivionRemasteredPerformanceFix is a free, MIT-licensed DLL for The Elder Scrolls IV: Oblivion Remastered. It patches about 40 hot spots in the game's code in memory and leaves every graphics setting where it was. The README says Claude did the profiling, reverse engineering, fixes, benchmark and docs, working in Claude Code. The human maintainer, LTSharpe, set the goal, made the calls and played every build. On the test PC, a 4K flight around the Imperial City went from 72 to 102 fps and from 19.5 hitches to 4.8. The repo ships the benchmark that produced those numbers, so you can rerun it on your own machine.

What shipped

Version 1.0.0-beta landed on GitHub on October 17 and 1.1.0-beta followed on October 18, with a Nexus Mods listing carrying the same files. Installing it means dropping a version.dll and an ini next to the game's executable. Nothing on disk is modified, and uninstalling means deleting two files. GitHub Actions builds the release from the public source, and each zip carries SHA-256 checksums and a build attestation you can verify with gh attestation verify.

The rule LTSharpe set was simple: never change the look. No lowered settings, no shorter view distance, and hardware ray-traced lighting stays at the top setting. The README puts it as changing "how the engine does its work, never what it draws." Screenshots with the fix on and off were compared automatically across times of day and weather, and the differences matched those between two stock runs.

The origin story is one most PC gamers will recognize. TweakTown reports that LTSharpe went from a GeForce RTX 2070 Super to a Radeon RX 9070 XT and still had low frame rates and stutter, then pointed Claude at the problem (TweakTown names the model as Opus 5.5). OC3D says LTSharpe puts the work at about two and a half weeks. Spending a GPU budget to fix a CPU problem is a classic PC gaming experience.

The numbers

Every figure below comes from the repo and was measured on one machine: a Ryzen 7 5800X, a Radeon RX 9070 XT, 32 GB of RAM, Windows 11 and Steam build 19115871. "4K" here means FSR Performance with hardware ray tracing on and Ultra settings with shadows at High. Each row is the mean or median of 2-4 freshly launched runs per side, with stock and fix runs alternating.

Hitches improved as much as averages did. On the Imperial City flight, frames of 50 ms or longer fell from 19.5 to 4.8 per flight, the worst frame went from 135 ms to 66 ms, and the 1% low rose from 33 to 45 fps. The worst frame after stepping out of a door dropped from 187 ms to 95 ms, and opening the Graphics settings page went from a 0.74 s freeze to 0.43 s.

The fine print is spelled out in the repo too. The Imperial City row was measured on the current release, but some Cheydinhal rows came from earlier builds that had a third to two thirds of today's fixes. OC3D's headline "+37%" comes from an earlier comparison video. If your GPU is the bottleneck (native 4K in a rainy forest, say), the frame rate barely moves, although the hitch, door and menu fixes still apply.

How Claude found the frames

Oblivion Remastered runs two engines at once. The 2006 engine runs the world on its own thread while Unreal Engine 5.3 handles drawing. According to the repo's research notes, Cheydinhal runs at 30-40 fps on a fast PC while Task Manager shows the CPU about 30% busy. All the time is going into a few single-threaded steps, and whichever one is slowest sets the frame rate.

The method was ordinary performance engineering, done thoroughly: stack sampling and call counting inside the running game, per-thread CPU time from PresentMon, and Unreal's public 5.3 source to name the functions behind each address. None of that source ships in the repo. The notes describe a chain of three bottlenecks, each exposed once the previous one was cleared.

Wall one: a masked store and a chatty weather system

One loop accounted for 32.7% of the RenderThread's samples. It copies every animated character's skeleton into a GPU upload buffer, roughly 7,200 bones per frame at the Cheydinhal chapel. The last 16 bytes of each bone were written with a masked AVX store (vmaskmovps) into write-combined memory, and masked stores defeat write combining there. The mask always meant "write the low 16 bytes," so a plain 16-byte vmovups writes exactly the same data. After the swap, the loop's share fell to 1.1%.

A rough picture of write-combined memory: a shuttle bus that only leaves once every seat is taken. A masked store shows up with a list of seats that must stay empty, so the bus gives up and makes a separate run each time.

The second RenderThread problem was weather. The game's time-of-day plugin called a "mark dirty" hook after every property write, whether or not the value had changed. That came to about 3,700 rebuild requests per second. The sun got pulled out of the scene and re-added every frame, and each re-add walked about 13,000 primitives. The fix compares the object's bytes before and after each write and skips the dirty call when nothing changed. Requests dropped to about 10 per second.

Wall two: a 4-byte backport from UE 5.5

Next in line was the RHIThread, spending about 55% of its time translating command lists to DirectX 12 alone. In UE 5.3, only Nanite's raster passes take the parallel path. UE 5.5 made parallel translation the default. Claude found the setne r8b instruction that picks the path and replaced it with mov r8b,1, a single 4-byte write that sends every render-graph pass down the parallel route 5.3 already used for Nanite. RHIThread load fell from 82-93% to 53-59%, and fps rose 22-25% where the CPU was the limit.

That change also surfaced an Unreal 5.3 descriptor-heap crash, which got its own guard. Without the guard, parallel translation stays off. On cards with less than 9.5 GB of VRAM it switches itself off too, because it costs about 0.5-1 GB of extra video memory.

Wall three: the game itself

With the fix in place, the GameThread sets the frame rate. In a 40-NPC crowd it needs 25-27 ms a frame, and about 4 ms of that is NPCs checking line of sight to each other five times a second. Cutting that to 2.5 Hz gave +10% fps in crowds, and it was rejected because NPCs would notice things half as often. That counts as a gameplay change, and the rule was no gameplay changes.

What it refused to ship

The research doc keeps a long table of ideas that were measured and not shipped, each with its reason. Turning hardware ray tracing off gave +39-46% fps and was rejected because it changes the look. A tighter ray-tracing culling radius gave +10% and visibly changed water reflections. Popular internet "Engine.ini tweak packs" are dismissed because many of their keys don't exist in this UE5 version, and because comments after a value aren't comments in Unreal ini files.

Most performance mods are assembled from that list: settings that buy frames by lowering quality. This project measured each of them, wrote down what it gained, and shipped none of them.

Engineering you can reuse

• Find, verify, then patch. Every fix locates its target with a byte pattern, decodes it, and checks offsets, call targets and vtable slots before writing anything. If the code doesn't match, that fix turns itself off and logs why, so a game update degrades the mod to stock instead of crashing the game.
• An offline self-test. About 7,000 lines of tests map the game executable, apply every patch to that copy and check the result without launching the game. The fixes themselves come to roughly 22,000 lines of C++, one file per fix.
• A benchmark harness you can run yourself. PowerShell scripts plus a UE4SS Lua mod start a new game hidden and muted, fly fixed camera paths, and produce a stock-vs-fix report. Along the way the project found and fixed a UE4SS memory leak and offered the fix upstream.
• Docs written for the next agent. AGENTS.md orients Claude Code, Codex or Cursor in a few thousand tokens, and porting.md walks through re-targeting the fixes after a game patch.

Version 1.1.0-beta stopped the game rebuilding every piece of a character for the GPU on each frame of its fade-in. When many characters appeared at once, as on Anvil's docks, that briefly took more than a gigabyte of extra video memory; peak VRAM at a dock exit fell from 13.0 to 11.3 GB. The changelog labels each bug fix "game bug" or "our bug." A game bug that stretched robes and capes into long strips is fixed, and so is an "our bug" from 1.0 that made clouds vanish after lightning.

Caveats

• One test PC. Every number comes from a single Ryzen 7 5800X and RX 9070 XT machine. NVIDIA, Intel, low-core-count CPUs, Steam Deck and the Game Pass version are untested or experimental, and the maintainer is asking for reports.
• It's a DLL injection. Loading as version.dll is a standard modding technique and also a standard malware technique, so expect antivirus warnings. Read the source or check the attestation before you trust it.
• Attribution is self-reported. The public history has five commits, so you can't see from outside how the work split between Claude and LTSharpe. The README's own split is that Claude wrote everything and the human decided and tested.
• Pinned to one game build. The fixes target Steam build 19115871. A patch from the developer could switch some of them off until a new release ships.

Key Takeaways

• OblivionRemasteredPerformanceFix is an MIT-licensed DLL with about 40 in-memory patches, built by Claude in Claude Code under LTSharpe's direction.
• On the test PC, the Imperial City 4K flight went from 72 to 102 fps and from 19.5 to 4.8 hitches, with graphics settings and image unchanged.
• The biggest wins came from a masked-store swap, skipping no-op weather updates, and a 4-byte patch that backports UE 5.5's parallel command translation.
• A table of rejected tweaks, including turning ray tracing off for +39-46%, shows what the project chose not to trade for frames.
• Pattern-verified patches, an offline self-test, a reproducible benchmark and an AGENTS.md add up to a template for agent-driven binary performance work.
• Results so far come from one machine, so run the included benchmark before believing them on yours.

Sources: OblivionRemasteredPerformanceFix on GitHub, research.md, how-it-works.md, releases and changelog, TweakTown, OC3D