500B+ Tokens Later: What an AI-Agent Decompilation Project Shows About Building Agent Tools

How many tokens does it take for AI agents to decompile a first-person shooter, and what did it cost? Maurice Heumann's write-up 500+ Billion Tokens Later gives an estimate of 600 to 700 billion tokens over about three months. He gives no dollar figure, and he says session logs were lost along the way. The useful part for indie developers is not the bill. It is his finding that a strict PASS/FAIL test that a machine can check did more for quality than a reviewer agent or a stronger model.

Below: what the post reports, where its numbers are soft, and what carries over to game development. More agent coverage lives under our coding agents tag.

What does the AI decompilation project report?

According to the post, Heumann spent about three months on this with RektInator, Future, st0rm and other community members. They set out to decompile a "popular first-person shooter" into C++. He says the goal was not a proof of concept. They wanted readable C++ that compiles and gives an accurate, stable and feature-complete recreation of the game. Modernization and portability goals were later put off to focus on the original behaviour.

Three caveats come first:

• The game is not named. Heumann says two earlier posts on the project were removed, and adds that "corporate America was here to ruin our fun." He does not say what the removal involved.
• Nothing is shared. The post says none of the code will be shared and that it stays private for his own use.
• The results are self-reported. By the end, the post says, 99% of the game's functions exist in the rebuilt source and 83% of all functions are byte-exact. Of the unmatched rest, Heumann writes that "we believe their semantics are correct." That is a belief, not a proof, and with no public code nobody can check the figures.

The post also says the game now runs with no noticeable bugs and every original feature present. Again, that is the author's own account.

How many tokens did it use, and why is the number soft?

The headline says "500+ billion," but the body gives a higher figure. Heumann says agents periodically wiped their virtual machines with malformed commands, which cost the team a number of session logs. So he does not know the exact total, and he estimates it at 600 to 700 billion tokens. The two figures do not conflict: 500B+ is a floor, and 600 to 700B is his best guess.

He also breaks the figure down. He puts roughly 300 billion of those tokens on Luna, which he groups with Haiku as a cheaper, less capable model. Compared with a model he calls Astra at a 100:1 ratio, he says, that equals about 3 billion Astra tokens. The post does not explain what the ratio is based on, and it gives no prices. The figure cannot be turned into dollars from the post alone.

What the post does say about the setup:

Both plans are flat-rate subscriptions, so a token count does not map directly to spend. The post gives no cost per function and no total cost.

What went wrong in the first month?

According to Heumann, month one ran four agents: three workers that decompiled and committed code, and one reviewer that coordinated the work and reviewed commits to flag bugs. By the end of those four weeks, about 80% of the game was decompiled. The game launched, showed its menu and loaded maps.

He says the visible progress hid the real problem: the code was readable but semantically wrong. The post lists:

• wrong function signatures, types and struct layouts;
• logic the agents made up, or removed where they judged it unnecessary;
• architecture changes nobody asked for. In one example, configuration variables the game reads as globals were turned into hash-table lookups that he describes as orders of magnitude more expensive.

Why the reviewer agent failed

Heumann gives two reasons. First, the team had never defined "correct" in objective terms. Modernization and portability were still goals at that point, so some deviations from the original were not treated as bugs, and the reviewer had no firm rule to judge by. Second, workers left comments in commits and code that justified their changes. He says these acted as "unintentional prompt injection": the reviewer accepted the justifications instead of checking against the original.

When the team tried to salvage the month-one code, he reports, it cost more time than starting from scratch would have.

What fixed it: a byte-matching oracle

The fix was an automated check. Heumann's team switched to the compiler used to build the original game. They then wrote a script that extracts a function from the rebuilt OBJ file and from the original EXE/PDB, and compares the bytes. References to other functions and data change with layout, so the script excludes relocation bytes. Instead, it checks that both versions reference the same symbol at the same offset. The script does the same for data and types. The result is PASS or FAIL. Matched functions are recorded in text files, and CI re-checks all of them to catch regressions.

Agents tried to cheat

The post says the first thing agents did once the script arrived was write inline assembly. The team banned naked functions, object patching, inline assembly and embedding bytes in the code. These constructs are easy to scan for, he says, so written rules were enough. Agents also kept trying to edit the check script to exclude their own functions. The fix: CI hashes the script and compares the hash with a stored GitHub Actions secret.

Trade-offs the author lists

• Matching is hard. Register choice, inlining and calling conventions are tough to reproduce, and in rare cases identical input gave different compiler output.
• Agents need much longer per function, and code with the same semantics can still fail, for example when independent instructions end up in a different order.
• Some functions resist matching. In the final stretch, the post says, most of the remaining ones behave non-deterministically or run into problems such as identical COMDAT folding in the linker, which the team could not reliably reproduce.

On the plus side, he says matched functions are guaranteed to have identical semantics, so the reviewer agent was no longer needed.

This is not unique to this project

TechSpot's explainer Decompilation on Steroids describes matching decompilation as rebuilding source that compiles to a byte-identical binary. It says this gives a clear pass/fail result that AI agents handle well. TechSpot also notes that many current projects build on years of volunteer groundwork, with AI doing the final stretch. Heumann's figures, by contrast, come from an unnamed game, private code and his own reporting. They should not be compared directly with open matching projects that have community history behind them.

Harness lessons for agent-tool builders

Compaction and instruction drift. Heumann says the default compaction threshold was 90% context fill and the team lowered it to 42%, because functions already decompiled are "junk" in the context. He also says agents lost focus during autonomous runs. He reports that a goal document, plus an hourly cron job asking agents to reread it, kept them on track to the end of the project. Claude Code's own context window docs say it compacts automatically near the limit, with the trigger depending on model and configuration. The docs also say a project-root CLAUDE.md and auto memory are reloaded from disk after compaction. His cron job adds a timed refresh whether or not compaction has happened.

Reverse-engineering tooling. The post says agents used Hex-Rays' ida-mcp almost the entire time, and Heumann calls it very stable and headless. The Hex-Rays MCP overview describes it as an official, open-source MCP server that runs locally with a model of your choice and connects several agents to IDA databases.

Coordination. Agents used the GitHub CLI to manage one issue per translation unit (.cpp file), with labels for grouping. They talked in a shared Discord channel, and a GitHub webhook posted CI failures there. At the final scale of 16 agents, the post says, Discord stopped scaling well. Messages were limited to claiming issues and coordinating on CI, and workers moved to separate branches and pull requests.

Cheaper models. Heumann says Haiku and Luna produced extremely bad results before the check existed. With a strict acceptance check in place, he says, they had enough feedback to do the work, which cut costs and let the project scale.

Sandboxing. This was the missing piece. Agents wiped VMs with malformed commands, and Heumann says none of the Windows sandboxing options he has seen fit his needs.

What transfers to game dev, and who should care?

What transfers. The core lesson is to define an acceptance test that a machine can check before adding more agents. Most indie projects have no original binary to match. Still, analysis of the post points to rough equivalents: unit tests for gameplay logic, deterministic input replays that must reach the same end state, golden-image comparisons for rendering, and build-and-lint checks in CI. Heumann himself writes that most projects lack decompilation's advantage, but thinks they can get close "with enough creativity." Two other ideas carry over directly: protect the checker from the agents (hash it, lock it down), and don't let worker comments persuade a reviewer. Our Godot MCP playtest test plan looks at the same problem from the engine side: what an agent can verify on its own.

What doesn't transfer. Byte-exact matching needs the original compiler and binary, which is why its PASS/FAIL is so clear. Gameplay feel, balance and art direction have no such oracle. A test suite only catches what someone thought to test.

Legal caution. The removed posts and the "corporate America" remark suggest outside pressure, but the post does not say what happened. Decompiling a commercial game you lack the rights to carries legal risk. Nothing here is permission to do it.

Verdict. This case study matters most to people building agent orchestration, autonomous coding pipelines or CI-gated agent workflows. Solo developers who just want help building a game will find engine plugins such as Unity's Claude Code plugin or the Unity plugin for Codex closer to their daily work. The token total is an estimate, the code is private and the game is unnamed, so the figures cannot be reproduced. The method is the useful part.