SCSKiller 1.3.1: NVIDIA 621.01 Support, Smaller Caches and the Unsigned Build Problem
By Indie Kings | October 22, 2026
Updated October 22, 2026: SCSKiller 1.3.1, published on 22 October 2026, adapts the shader precompiler to NVIDIA driver 621.01 and reports much smaller game caches as a result. The release notes are two lines long, and one of them describes a change in the driver rather than in the app, which is the more interesting half of the story. The other thing worth knowing is unchanged and more likely to stop you: the build still is not code-signed.
Image: GitHub repository card for BlueHeisenberg/SCSKiller, the Windows shader precompiler.
What changed in 1.3.1, and why the driver matters
SCSKiller works by reading the shaders a game ships with, working out the pipelines the game will build, and compiling them into the GPU driver's cache ahead of time, in its own process with the game closed. The point is to move the compile work out of the frame, where a driver compile shows up as a 20 millisecond or longer stall, and into a batch job that runs before you play.
That design makes the tool unusually dependent on driver behaviour, because the cache it writes is the driver's, not its own. Version 1.3.1 exists for exactly that reason. The notes list two fixes:
| Change in 1.3.1 | What it means in practice | Who it affects |
|---|---|---|
| Compatible with NVIDIA driver 621.01 | Compiling and cache validation work on the current driver branch again | NVIDIA users who updated the driver |
| Game caches are much smaller | Less disk used per game after a compile | NVIDIA users, because the cause is how the driver now handles the game shader cache |
| Release still unsigned | SmartScreen warns on first run; Smart App Control blocks it outright | Everyone on Windows 11 with default protections |
The second row is the one to read twice. The notes attribute the smaller cache to "how NVIDIA now handles the game shader cache", which means the improvement is not an optimisation the developer wrote. It is the app following a platform change. That is a good sign for maintenance and a warning about portability: a tool whose main artifact lives inside a driver's cache directory is going to keep needing release notes like this one.
The cache got smaller because NVIDIA moved it
The cache location matters more than it sounds. SCSKiller's compile job writes into the same cache the game will read from at runtime, and it re-runs that compile after a driver update clears it. If it guessed the wrong directory, the work would be invisible: the tool would report success and the game would still stutter, because the game would be reading a different cache.
That is why the app offers to stay open after a compile and check that the output reached the cache the game actually uses. It is a small feature that reveals the real failure mode of this category. A precompiler that writes to the wrong place is worse than no precompiler, because it produces a successful-looking log and an unchanged game.
The practical effect of a smaller cache is straightforward on a machine with several large games installed. The games in the README results table are exactly the kind that produce a large driver cache: Hogwarts Legacy records 1,014 stutters on an RTX 5090 from a cold cache, and 27,743 on a Ryzen AI Max+ 395, which is a rough proxy for how many pipelines had to be compiled. A smaller cache after the driver change means less disk per game and a faster validation pass, since the app re-checks every compiled game after a major update.
One detail from the 1.3.0 notes is worth carrying into this release. After that update, SCSKiller re-checked every compiled game once, which the notes warned could take several minutes across a large library, and said later starts would be fast again. That was a one-off migration rather than ongoing behaviour, and it is the correct trade: the alternative is trusting a cache that a driver update may have invalidated.
The unsigned build is the real adoption problem
The release notes lead with a warning that has nothing to do with performance, and it has been there since before 1.3.0. The binaries are not code-signed, so the first run will probably show SmartScreen's "Windows protected your PC". The instructions are to click More info, then Run anyway. Updates, once installed, do not show the prompt again.
On Windows 11 the story is worse. The notes state that Smart App Control blocks unsigned apps outright, and that if it is on, the reader should wait for a signed release. That is the whole instruction, and it is the correct one: there is no supported path in the documentation that involves weakening the protection to run the tool.
Signing through the SignPath Foundation is described as in progress for stable releases, with alpha and beta builds staying unsigned. That split is sensible on its own terms: certifying only the stable channel keeps the experimental builds cheap to produce. Until it lands, the practical advice is to check the hash rather than the publisher, and to treat any build that claims to be signed before the policy page says so as suspect.
Our take: this is the single biggest gap between SCSKiller's reputation and its install base. The project has 3,306 stars, a website, a Patreon, a Discord and a game database, and its download still asks a user to override an operating system warning. A performance utility is exactly the category where people should be suspicious, because the same instructions are what a malicious shader cache cleaner would ask for. Getting signed is not a nice-to-have for a project that wants to be installed by people who are not already following it on GitHub.
What it does around anti-cheat, and what it cannot promise
The anti-cheat position has not changed, and it is more careful than most tools in this space. The README states that SCSKiller only reads the files of games with anti-cheat and adds its recorder to them only in a session the user allows and confirms per game, at the user's own risk. For ELDEN RING and ARMORED CORE VI, the recorder runs without EasyAntiCheat. For other anti-cheat games, there is an explicit setting named "Allow the recorder in games with anti-cheat", and the setting's own label ends with "at your own risk".
The README also says the anti-cheat check can miss a game, and that use is at the user's own risk, with the authors not responsible for bans. That is the honest version of a disclaimer that most projects bury. It is still a disclaimer, not a guarantee, and it should be read as one.
For clarity, because this is the part people skim: precompiling shaders and injecting a recorder into a live game are different levels of risk. The first is file analysis with the game closed. The second runs code alongside an anti-cheat protected process, and no third-party tool can promise an anti-cheat vendor will treat that as acceptable. If a game matters to your account, leave the recorder off for it.
How to check a download you cannot sign-check
Without a signature, the only integrity check available to a user is the hash published in the release notes. The notes give SHA-256 values per artifact, which is a real check but a weak one: the notes are not signed either, and the notes say so. A hash published next to the file by the same account proves the download arrived whole, not who built it.
What that leaves is provenance by consistency. The README names the only official downloads as the repository's releases and lists the official accounts and sites, which is the right thing to publish for a project whose name is generic enough to attract lookalike sites. If you are installing this, get it from the releases page in the README, verify the hash, and treat a copy from anywhere else as untrusted regardless of how it is packaged.
Repository state
The repository was created on 29 September 2026 and has moved quickly since. At the time of writing it holds 3,306 stars, 83 forks, 43 watchers and 107 open issues, with a size of about 2,200 KB. It is C#, GPL-3.0, and the website is scskiller.com. The repository's commit listing reports 18 commits, and the release history is dense: 1.2.4 on 8 October, 1.2.5 on 9 October, 1.3.0 on 18 October and 1.3.1 on 22 October.
The issue count is the number worth watching. A tool that has to model how dozens of game engines build pipelines will always have a long tail of games that compile badly or not at all, and 107 open issues on a three-week-old project is consistent with that rather than with neglect. The in-app report route introduced in 1.3.0, which sends an anonymous report that the user can read in full before sending, is a good way to collect exactly the data needed to fix those cases.
FAQ
What does SCSKiller 1.3.1 fix?
It restores compatibility with NVIDIA driver 621.01 and reports much smaller game caches, which the notes attribute to how NVIDIA now handles the game shader cache.
Does it work on AMD and Intel GPUs?
NVIDIA and AMD are supported, with DirectX 12 games on both and DirectX 11 games on NVIDIA. Intel GPUs are not supported, and the README says the developer does not have one to test on.
Why does Windows warn me when I run the installer?
Because the releases are not code-signed. The notes say signing through the SignPath Foundation is in progress for stable builds, and that alpha and beta builds will stay unsigned.
Can I use it if Smart App Control is on?
No. The notes state that Smart App Control blocks unsigned apps outright and advise waiting for a signed release. Disabling Smart App Control is a system-level change with consequences beyond this app.
Will it get me banned in an anti-cheat game?
The tool only reads files in anti-cheat games unless you enable its recorder for that game, which requires a per-session confirmation. The README still says use is at your own risk and that its anti-cheat detection can miss a game.
Does it fix all stutter?
No. The README limits the claim to shader compilation stutter, and says it does not fix traversal or streaming stutter. A shader it could not find or record can still compile in game.
Bottom Line
SCSKiller 1.3.1 is a two-line release that says something useful about this class of tool. The performance work is real, and the numbers in the README are specific enough to check: worst stalls cut from 347 ms to 8 ms in Silent Hill: Townfall, from 2,400 ms to 100 ms in Hogwarts Legacy on an RTX 5090 with stutters down from 1,014 to 87, and from 9,038 stutters to 11 in Star Wars Jedi: Survivor. But the change that shipped this week is compatibility with a driver branch and a smaller cache caused by NVIDIA's own change, which is the steady-state work of a tool that lives inside somebody else's cache directory. The bigger issue is unchanged: the build is unsigned, Smart App Control blocks it outright, and the available integrity check is a SHA-256 published next to an unsigned file. That is not a reason to avoid it, it is a reason to download it from the releases page, verify the hash, and leave the recorder off in any game where your account matters. If the SignPath signing lands, this becomes a much easier recommendation.
Sources
- SCSKiller repository README, BlueHeisenberg/SCSKiller, accessed 22 October 2026
- Release notes for v1.3.1, v1.3.0, v1.2.5 and v1.2.4, published between 8 and 22 October 2026
- GitHub repository metadata and commit listing for BlueHeisenberg/SCSKiller, accessed 22 October 2026
Related: Microsoft Auto SR Tested: AI Upscaling For Every Game | The Battle of Game Upscaling: DLSS vs. FSR vs. XeSS | XeSS XMX on Linux: Proton Gets a Patched Mesa Driver