decomp.anything: A Fork Keeps a Discontinued AI Decompiler Alive

By Indie Kings | October 21, 2026

Updated October 21, 2026: decomp.anything is a fork of decomp.wtf, the AI-driven matching decompiler whose author shut it down and archived it after the decompilation community pushed back. The upstream repository, i12bp8/decomp.wtf, had 531 stars and 294 forks and was archived with its last version tagged v0.10.6. The fork, giveen/decomp.anything, was created on October 19, 2026, and extends the same engine to Windows executables and Linux binaries rather than only game images.

That makes it a different kind of project from the one that was discontinued. The upstream author's stated reason for stopping was that much of the community was against AI decompiling of that kind, and he asked anyone who used it or built on it to respect the rules of the projects they worked with. The continuation keeps the MIT licence, keeps the byte-exact rule, and says in its own README that it never sends anything upstream.

Image: decomp.anything banner. Image credit: giveen/decomp.anything, via the repository.

The fork and the shutdown it came from

The upstream project, decomp.wtf, is an application that hands a game to an AI agent one function at a time. The agent writes C or C++, the original compiler builds it, and the result is compared byte for byte. The scoring is unforgiving: a score of zero means the bytes match, and there is no partial credit.

Its author stopped work on it and archived the repository. The README says so in its first line, and the reason is stated plainly: over a few days he noticed that much of the decompilation community, the people who made the tools and projects everything is built on, was against AI decompiling of that kind. He writes that he did not make decomp.wtf to do harm, that he respects their opinion, and that the code stays up under the MIT licence for anyone who wants to fork it and keep going. He adds that he will not fix issues, review pull requests or make releases, and that anyone using it or building on it should only use it on games they own, should not share the game code it produces, and should respect the rules of the projects they work with.

GitHub's metadata for the archived repository records 531 stars, 294 forks, a Python codebase, an MIT licence, a creation date of October 13, 2026 and a last push of October 15, 2026, with tags running from v0.10.1 to v0.10.6 and no release objects attached.

The fork, giveen/decomp.anything, was created on October 19, 2026 and last pushed on October 20, 2026. It had 22 stars, 3 forks, no open issues and no releases at the time of check. The repository tree holds 268 files, with 127 under the source directory, 66 under projects and 53 under tests.

What byte-exact matching means here

The workflow is the part worth understanding, because it is the claim that makes the tool different from an ordinary reverse engineering tool that hands you a plausible decompilation.

The target is split into functions. splat and spimdisasm do that for MIPS games, and the PE reader does it for Windows programs using the exception directory, the COFF symbol table, exports, the entry point and direct call targets. The Linux reader uses the symbol table, or the unwind tables in a stripped program. Other tools cover GameCube, Wii, DS, GBA and PlayStation targets.

Agents then claim functions, and each one receives the target assembly, the data it touches, its callers, a machine-made draft and notes from earlier attempts. Every attempt is compiled with the target's own compiler and linked at the function's real address, so calls, globals, strings and jump tables are verified too, and a miss returns an instruction diff that goes back to the agent. A hit is saved, named and shared with the other agents.

The README's own worked example shows the standard. A short comparison function from the target compiles to a small branch sequence, and the agent's C, a clamp with two comparisons, compiles to exactly those bytes with KMC GCC 2.7.2 at optimization level two. The matchers cover MIPS, PowerPC, ARM, x86 and x86-64.

Two features sit under that. The autopilot takes free matches before any agent spends a token, first from an identical function already matched elsewhere, then from a machine draft run through the judge. The permuter rewrites near misses in the background, and the README puts its threshold at 95 percent and up, changing statement and declaration order, casts and temporaries. The permuter changes what to try, never what counts as a match.

What the fork adds

The continuation keeps the upstream engine, the project workflow, the app and the installers, and its README lists six things it adds on top.

The first is Windows and Linux targets. Windows executables and DLLs, 32-bit and 64-bit, import and match with a relocation-aware x86 matcher, and Linux x86 and x86-64 executables and shared libraries import the same way. The matching path compiles the agent's C to COFF and compares bytes with address fields blanked on both sides, so a call or a RIP-relative load has to point at the same function or global. For Linux, the compiler is taken from what the binary's own comment section says built it, and position-independent programs compile with the position-independent flag set. The README is clear that only C and C++ are matched byte for byte: Rust and Go binaries are identified by their compiler markers, but not matched.

The second is a console for REA, the reverse engineering tool that this site covered in October. The fork describes it as a graphical front end for REA's tool catalog, opened from a procedure work item or from a PC function. It browses native binaries, Android apps, .NET assemblies, JavaScript and Electron apps, web pages, firmware and plain files, and it shows functions, pseudocode, strings, flow graphs and call graphs, plus a generated form for every REA tool. It runs its own REA process so it never switches the target the agents are reading, tools that run programs or write files ask for confirmation, and everything REA shows about a target is treated as untrusted text. Agents can ask the same service for pseudocode, signatures and callers.

One of the six is a console for opencode 2, where the app writes its own V2 configuration, turns Code Mode off and runs the binary in standalone mode, and the other is a set of reference folders, so helpers can read and search a matched decomp, notes or symbol lists by path, with reads confined to that folder.

Separate from that list, the README also documents archive support. Drop in a ZIP or TAR and every regular file inside becomes a work item, with a contents panel that previews the tree. A binary or nested archive can be opened as a linked child project, and findings from the child roll up into the parent's summary. The extraction limits are generous for your own files and stated plainly: 2 GiB of archive input, 20,000 entries, 1 GiB uncompressed, a 1000 to 1 per-entry compression ratio, 256 MiB per entry and 512 MiB extracted per project.

The README also documents a set of quality-of-life pieces that are useful outside the game world: an intake report written beside each project that records what the import already established, including the format, the compiler and flags with the evidence for them, the debug information, the function and string inventory, subsystem hints and the questions still open, and which agents are told to read it first. It adds version comparison, which pairs functions across a patch, demo or port by normalized instructions and reports same, moved, changed, added and removed, with a similarity score for the changed functions. It adds runtime coverage import from a debugger or emulator trace, which maps hit counts onto functions and gives agents a way to find the hot code. It adds reference folders, so helpers can read and search a matched decomp, notes or symbol lists by path, with reads confined to that folder.

Which agents drive it

The application talks to agents over the Model Context Protocol, and the fork lists Claude Code, Codex, the Antigravity CLI and opencode among the ones it drives headlessly. For opencode 2 specifically, the app writes its own V2 configuration, turns Code Mode off and runs the binary in standalone mode.

There is also a built-in loop for any OpenAI-compatible API, which covers DeepSeek, OpenRouter and OpenAI, as well as a model running on your own machine through llama.cpp, Ollama or LM Studio. For local models the README asks for at least 16K tokens of context, and says small models should be given small functions and big models the hard ones.

The tool boundary is deliberate. Agents get decomp.anything's own tools and nothing else: no shell, and no access to files beyond a fork's own source tree and any reference folders the project names. They write only C and C++ sources and headers, never targets, assembly or build scripts, and inline assembly is refused. A change that breaks an already-matched function is undone, and the project's file layout and build wiring are changed by the application itself, never typed by an agent.

For a team, one computer hosts the room and hands out functions so nobody duplicates work, checks each match against its own copy, and shares names, structs and notes. No original bytes or assembly cross the wire, because every member reads the code from their own copy. The address can be a free Cloudflare quick tunnel, your own LAN, Tailscale or a server.

Where the fork draws its line

The README has a section on responsible use, and it is worth reading in full because it widens the upstream rules rather than replacing them. The upstream notice said decomp.wtf contains no game code and provides no ROMs, and asked users to stick to games they own, to avoid getting around copy protection, and not to publish decompiled code of games whose rights they do not hold. The continuation keeps each of those and generalizes them: it contains no game or application code, provides no ROMs, executables or firmware, asks that you only analyze software you own or are authorized to analyze, and says not to publish decompiled code whose rights you do not hold.

It also says that many community decomps do not accept AI-written contributions, and that the ones that do expect a person to stand behind every line. The continuation never sends anything upstream on its own: the agents' work stays on your local branch, and before opening a pull request you are told to read the project's contribution rules, review the code yourself, and say how it was made.

That is a coherent position for a project that exists because its author asked for it. The upstream notice asked anyone continuing the work to keep the MIT licence and to respect the rules of the projects involved. The continuation kept the licence, kept the byte-exact standard, and wrote the rules down for software rather than games alone, since the byte-exact path now covers PC binaries as well.

The remaining question is the one the whole scene is arguing about, and the continuation does not settle it. Whether AI agents should be allowed to produce matching decompilation at all is a question for the people who own the projects, and several of them have said no, as this site reported in October. What the continuation does is make the case that the output quality can be judged mechanically, byte for byte, and leave the decision to the project owner.

FAQ

What is decomp.anything?
An MIT-licensed fork of decomp.wtf, a matching decompilation workbench where an AI agent writes C or C++ for one function at a time and the target's original compiler proves the result byte for byte.

Why was decomp.wtf discontinued?
Per its README, the author stopped because much of the decompilation community was against AI decompiling of that kind, and he respects their opinion. The code stays up under MIT and he asks that anyone continuing it respect the rules of the projects they work with.

What does the fork add?
Six things, per its README: a graphical console for the REA tool catalog that also serves agents, Linux targets, Windows targets, REA access for agents, reference folders, and opencode 2 support. The README also documents archive support, an intake report, version comparison and runtime coverage import.

Does it need the original game files?
The project does not provide them: the README says it contains no game or application code and provides no ROMs, executables or firmware. Your own copy of the target is what you match against, which is why it asks that you only analyze software you own or are authorized to analyze.

Will it send my work upstream?
No. The README says the agents' work stays on your local branch and nothing is sent anywhere by itself. It also says many community decomps do not accept AI-written contributions, so check a project's rules before opening a pull request.

What does it need to run?
Linux x86-64 or Windows through WSL 2, Python 3.12 or newer, uv, Node.js for npm-based agents and for REA, and Java 21 or newer for Ghidra. macOS is not supported. There is no account, no telemetry, and nothing is uploaded.

Our take: The interesting decision here is not technical. Extending byte-exact matching to Windows and Linux binaries is a real widening of what the engine can do, and the RE console opens the same workbench to anything that can be analysed rather than matched. The decision that matters is that the continuation kept the MIT licence and the byte-exact standard, and restated the responsible-use rules for software rather than games alone. Whether the community wants AI-produced matching decompilation is still an open fight, but a project that argues for itself with a compile-and-compare judge is a more useful answer than a manifesto.

Bottom Line

decomp.anything is an MIT-licensed Python fork of decomp.wtf, the AI-driven matching decompiler its author archived in October 2026 after community pushback against AI decompiling. The fork was created on October 19, 2026 and had 22 stars, 3 forks, no releases and no open issues at the time of check. It keeps the upstream byte-exact rule, where a score of zero means the compiled function matches the target's bytes and nothing less counts, and extends it to Windows PE executables and Linux ELF binaries, adds a graphical console for the REA tool catalog that agents can also query, and treats archives as projects whose files become work items. It runs on Linux or Windows through WSL 2 with Python 3.12 or newer, and it asks that you analyze only software you own and never publish decompiled code whose rights you do not hold.

Sources

giveen/decomp.anything repository README, including the fork statement, what stays from upstream, what the fork adds, the target and platform tables, the agent table, the tool boundary, the pinned tool versions, the repository layout and the responsible use section, verified October 21, 2026.

i12bp8/decomp.wtf README and repository metadata, including the discontinuation notice, the last release and the archive state, verified October 21, 2026.

GitHub repository metadata for giveen/decomp.anything, verified October 21, 2026: 22 stars, 3 forks, 0 open issues, Python, MIT, created October 19, 2026, last push October 20, 2026.

Related: Decomp.dev: One Founder Is Shutting The Door On A Broken Community | REA: A Reverse Engineering MCP Server Born in April 2026 Crosses 300,000 GitHub Stars