i12bp8/decomp.wtf

Website  ·  Install  ·  How it works  ·  Public decomps  ·  Agents  ·  Decompile together

_{The simulation from decomp.wtf, on the demo ROM that ships with the app.}

Point the AI agent you already use at a game you own. decomp.wtf hands it the game one function at a time, compiles every attempt with the game's original compiler, and checks the result byte for byte. Score 0, or it doesn't count. There are two ways in:

• Start from scratch. Drop in a game for N64, PlayStation 1 or 2, GameCube, Wii, Game Boy Advance or DS: a ROM, a disc image or the program file. decomp.wtf finds every function and your agents take it from there. The result is a project that rebuilds your game byte for byte: the base for ports and mods. GameCube, Wii and N64 are the recommended platforms; the rest are in beta.
• Continue a public decomp. Pick one of the 245 projects on decomp.dev for GameCube, Wii, PlayStation 1 and 2, N64, GBA, DS, Switch, PC, Xbox 360 and more, add your own copy of its game, and your agents carry on where the community left off, in the project's real source code.

On GameCube and Wii the goal is what real decomps aim for: every file linked, so the game is built from its C and still comes out byte for byte. That's the starting point for a native PC port.

Everything runs on your computer. No account, no telemetry, nothing uploaded.

decomp.wtf runs on Linux, Windows and macOS. The compilers it runs are Linux programs, so it runs on Linux everywhere: on Linux itself, on Windows in its own small Linux (a WSL 2 distribution called decomp-wtf), on macOS in Docker. The same Linux, set up by the same script, on every computer.

Linux

curl -fsSL https://decomp.wtf/install.sh | bash

Windows (PowerShell)

irm https://decomp.wtf/install.ps1 | iex

It turns on WSL 2 if it isn't yet (Windows asks for permission once, and may want a restart), makes decomp.wtf's Linux from Debian's official WSL image and installs everything in it. You get a decomp command, a Start menu entry and a desktop shortcut. Your projects are at \\wsl.localhost\decomp-wtf\home\decomp\Decomp.

macOS (needs Docker Desktop, OrbStack or Colima)

curl -fsSL https://decomp.wtf/install.sh | bash

decomp.wtf runs in a Docker container (decomp-wtf) with your projects in the volume decomp-wtf-home; you get a decomp command and a decomp.wtf app in ~/Applications. decomp shell opens a terminal inside.

One line sets up everything: uv, the app, the period compilers (pinned and checksum-verified) and the m2c draft decompiler. It then opens decomp.wtf in your browser. After that, start it any time from your apps menu (the Start menu on Windows) or by typing decomp in a terminal.

Updates come by themselves: when there's a new version, decomp.wtf asks once, and one click installs it and restarts the app in the same tab (helper agents carry on). Settings has "check now", "install updates by itself" and "don't look for updates".

Already living in Claude Code, Codex, Antigravity CLI or opencode? Give it decomp.wtf's tools once:

decomp connect

Then ask it, in your own terminal:

decompile my game at ~/roms/game.z64

It confirms the game is your own copy, imports it, opens the live view so you can watch, and gets to work with every tool decomp.wtf has: the original compiler, the byte-for-byte judge, the autopilot, helper agents running in parallel (start_agents) and the rebuildable export. Behind it is decomp mcp, an MCP server that starts the app when needed; you can also add it yourself (claude mcp add decomp -- decomp mcp).

1. Open a ROM. splat and spimdisasm find every function and data symbol, and decomp.wtf recognises the compiler that built the game.
2. Add agents. Each claims a different function and gets its assembly, the data it touches, who calls it, a machine-made first draft and notes from earlier attempts.
3. Watch them match. Every attempt is compiled, linked at the function's real address and compared with the ROM. A miss returns an instruction diff; a hit is saved, named and shared with every other agent.

800007D0  slt     $v0, $a0, $a1
800007D4  bnez    $v0, .L800007EC
800007D8   addu   $v0, $a1, $zero
800007DC  addu    $v0, $a2, $zero
800007E0  slt     $v1, $v0, $a0
800007E4  beql    $v1, $zero, .L800007EC
800007E8   addu   $v0, $a0, $zero
.L800007EC:
800007EC  jr      $ra
800007F0   nop

s32 clamp_s32(s32 v, s32 lo, s32 hi) {
    if (v < lo) {
        return lo;
    }
    if (v > hi) {
        return hi;
    }
    return v;
}

Most games people decompile already have a community project with its build set up and part of the code done. decomp.wtf plugs your agents into them as they are:

1. Browse the decomp.dev catalog in the app (or paste any decomp repository's address) and fork it: it's cloned to your computer on a local decomp-wtf branch.
2. Add your copy of the game. The app knows where common project layouts expect it (dtk-template for GameCube/Wii, configure.py + ninja, splat + make) and runs the project's own setup. Anything else you set up by its README, and decomp.wtf picks it up once it builds.
3. Add agents. Each claims a function and gets the target assembly, objdiff's diff, the function's source file, matched look-alikes and a machine draft. Its code goes into the real source file, the project's build compiles it with the project's compilers, and objdiff judges it.
4. Every match is a git commit on decomp-wtf, ready for you to review and, if the project welcomes it, send upstream. Nothing is sent anywhere by itself.

Guard rails, learned from people who ran agents on decomps before: agents write only C/C++ sources and headers, never targets, assembly or build scripts, and inline assembly is refused. A change that breaks any function that already matched is undone. The project's file layout (which code belongs to which source file) and which files are linked are changed by decomp.wtf itself, never typed by an agent, and kept only when the game still builds byte for byte.

A function at 100% is matched. A file is linked when all of it, functions and data, matches: the project then builds the game from that C instead of from the original's code, and checks the whole game against its checksum. That's decomp.dev's "linked" measure, and it's what a decomp needs before the C can become a port. For GameCube and Wii projects (dtk-template) decomp.wtf takes care of the steps between:

• Every function gets a source file. Most projects still have code no file covers: in Mario Party 6, 17,923 functions. Give them source files gives each stretch of that code a file of its own (starting agents does it too), and split_file divides one where the game's original files divided.
• Files closest to done come first. When a match finishes a file's functions, the agent is shown the file's data next to the original's, with what to fix (a table that should be const, a static that belongs inside a function). file_status shows it any time.
• Finished files link themselves. decomp.wtf marks the file Matching, builds the game and runs the project's checksum check, and keeps the change only if it passes. A linked file can't be changed in a way that alters the game. The app shows % linked next to % matched.

Agents only get decomp.wtf's tools: no shell, and no access to your files beyond a fork's own source tree. The app installs missing agents for you and tells you how to sign in. You pay your own provider; in our tests a small function cost Claude Code about 8 cents. Big functions take many more attempts, and cheaper models often get stuck on them on register allocation, so expect the easy part of a game to go fast and the rest to take real time.

Local models. Start the model with at least 16K tokens of context (llama.cpp: -c 16384; Ollama: OLLAMA_CONTEXT_LENGTH=16384, or it quietly cuts the start of each request off; LM Studio: Context Length), choose its preset under Agents & models → API key, and set the context size there if it isn't llama.cpp (which says it itself). The agent trims older tool output to stay within it. Small models do the small functions; the big ones need a strong model.

A whole team, any size, each on their own computer with their own copy of the game and their own agents, working on one game. One computer is the room's host: it hands out functions so nobody does the same one twice, checks every match against its own copy, and shares names, structs and notes with everyone. Nothing goes through decomp.wtf's website: the people who decompile together host their room and decide who's in.

On a home PC: open the project, click Decompile together, Open the room. Send the link.

On a server (or any always-on machine):

curl -fsSL https://decomp.wtf/install.sh | bash
decomp host mygame.z64 --own-copy --address http://my-server:6481 --service

That runs decomp.wtf in the background (starting with the computer), imports your copy, opens the room and prints the link. Joining: paste the link into Join a team's room in the app, or decomp join <link> <your copy> --name you.

| Every kind of project | Games started from a ROM, GameCube, Wii and DS games started from scratch, and forks of public decomps. A git project's members get its source tree from the host (only what git tracks, never the game), build it with their own copy and tools, and follow every commit made in the room: matches are confirmed and committed by the host, edits of shared files are made there. |

No ROM bytes or assembly ever cross the wire: everyone reads the code from their own copy, which must be identical to the host's. The decompiled code of a commercial game belongs to its rights holder: share it only with people who own the game.

Recommended platforms: GameCube, Wii and Nintendo 64. They're the most tested path from dropping in a game to a full decomp you can port and mod:

• GameCube and Wii projects are the same kind as decomp.dev's (dtk-template): the game is rebuilt and checked byte for byte on every build, and finished files are linked into it as they're done, which is where a native PC port starts. Imported from scratch from Mario Party 4, Melee, Mario Kart: Double Dash, Mario Kart Wii and Twilight Princess discs.
• Nintendo 64 imports are tested on Super Mario 64, GoldenEye and Perfect Dark, including code loaded later and code shipped compressed, and the export rebuilds the ROM byte for byte. For now the export puts every function at its original address: right for matching and for a port, while a mod that makes code bigger needs a shiftable build, which is coming.

Beta: PlayStation, PlayStation 2, Game Boy Advance and DS. They work end to end and are tested on homemade games, much less on real ones so far. Expect rough edges, and please report what you hit: the app's error panel copies everything an issue needs. Public decomps of any platform run in their own project's build, so their status is the project's.

From scratch. splat and spimdisasm split MIPS games, decomp-toolkit analyses GameCube and Wii programs inside a generated dtk-template project, ds-decomp analyses DS ROMs (ARM9, ITCM, DTCM, overlays) inside a generated project of the same kind, and Game Boy Advance ROMs are split by luvdis plus decomp.wtf's own pass for code nothing calls. Code beyond the main program is found too: N64 code the game loads later (placed at its address from its own calls, including code run through the TLB and code Rare and Nintendo shipped compressed), and the PlayStation 1 and 2 overlays in a disc's other files. Every attempt is compiled with the game's compiler and checked byte for byte: linked at its address in the original (MIPS, ARM) or judged by objdiff inside the project's own build (GameCube, Wii, DS).

The base for ports and mods. Export project writes a normal decomp tree (matched functions as C, the rest as assembly from splat or luvdis, a linker script and build.py) and proves it rebuilds your game byte for byte. GameCube and Wii projects are dtk-template projects and DS projects are ds-decomp projects; both rebuild the game on every build, and GameCube and Wii files are linked as they're finished. Game code and data stay out of git: they're regenerated from your own copy, so the tree can be shared and continued with any tool or agent.

C and C++. GameCube, Wii and DS games are often C++, and decomp.wtf handles it there: code with C++ symbol names goes into .cpp files, drafts come out as C++, and agents get a guide to classes, vtables, constructors, inlines and name mangling. On N64, PlayStation, PS2 and GBA, functions started from scratch are written in C for now; C++ there (mostly PS2 games) is coming. Public decomps use whatever language the project does.

Proprietary compilers (IDO, CodeWarrior, CodeWarrior for DS) are only installed after you accept that. Heavy tools run with a memory cap, so a runaway analysis can't take your computer down.

Windows and macOS. Several of the compilers (KMC GCC, the PlayStation GCCs, EE-GCC, agbcc) only exist as Linux programs, so decomp.wtf runs in Linux everywhere: its own WSL 2 distribution on Windows, Docker on macOS. The installer sets that up; you use the app in your browser as usual, and the results are byte-identical on every computer.

When something goes wrong. A failed import stays on screen with the reason and what happened, and Copy for a bug report puts the version, the error and the log on your clipboard for an issue. The full log is .decomp/logs/decomp.log in your projects folder (~/Decomp), also at The full log in that panel.

uv sync
uv run decomp              # opens the app; projects live in ~/Decomp (or $DECOMP_HOME)
uv run pytest

git clone -b <branch> https://github.com/i12bp8/decomp.wtf && cd decomp.wtf
powershell -ExecutionPolicy Bypass -File site\public\install.ps1      # Windows
bash site/public/install.sh                                           # macOS (or Linux; --docker to use Docker)

splat and spimdisasm split ROMs, objdiff judges forks, m2c and Ghidra write first drafts, the decompals recompiled period compilers do the building, and decomp.dev lists the public projects. The look-alike finder follows the idea of coddog; decomp-toolkit, maspsx and wibo are in the pinned toolbelt (decompnet toolchain install <name>). Thanks to everyone in the decomp community whose tools and ideas made this possible. decomp.wtf isn't affiliated with any of these projects.

decomp.wtf contains no game code and doesn't provide ROMs. Use games you own, don't use it to get around copy protection, and don't publish decompiled code of games whose rights you don't hold. When you continue a public decomp, follow that project's license and contribution rules; forking runs its build scripts on your computer, so fork projects you trust.

Many community decomps don't accept AI-written contributions, and the ones that do expect a person to stand behind every line. decomp.wtf never sends anything upstream: your agents' work stays on your local branch. Before you open a pull request, read the project's CONTRIBUTING (or ask its maintainers), review the code yourself, and say how it was made.

MIT © 2026 Sam Wolfs

_{Not affiliated with Nintendo or Sony. Nintendo 64 and PlayStation are their trademarks.}