>At current 2026 API rates, 500 billion AI tokens would cost roughly $100,000–$750,000 depending on the model, with most flagship models in the $150–$400 per million input tokens range
This stuff is all done on highly subsidized subscription plans. I suspect Antropic is quite happy to sell these people $100k of compute for $4k because it boosts their growth numbers and they can tell investors once they stop subsidizing, this will grow to $100k. Despite the fact that most of this stuff simply wouldn't be done without the subsidization.
the exact same arguments were said about uber's business at the start.
Yet, it is now profitable.
The bet is that people realize how valuable these services are, and despite complaining, they still would pay the higher price. This realization would not happen without this initial subsidy from investors.
It isn't too different from drug dealer's first sample free...
Disagree with your second paragraph. Uber/lyft subsidized into deep negative margin territory around ~2015 or so. Anthropic (and OpenAI) are subsidizing but not losing money on these consumer plans.
The claim is that uber and lyft lost money on each ride but that openai and anthropic make money on inference. Just not enough to pay the cost of developing the models. The difference is that uber and lyft had to change their pricing (or payment) models to make money, where anthropic or openai could just sell enough inference (at some level of sales).
to clarify, I mean that the big model companies are charging consumers much less than equivalent API pricing but they're not actually losing money so its more of a steep at-cost discount for inference. It likely does not fully cover amortized R&D just like the other reply stated but it does still cover marginal inference cost (GPU/power/etc)
Uber and Lyft were paying drivers $X but charging users way less than $X so they were literally burning investor money to get market share.
> It likely does not fully cover amortized R&D just like the other reply stated but it does still cover marginal inference cost (GPU/power/etc)
Why does this point come up over and over again, pretending that you can truly separate training and inference costs. Yes, they are separate things but the value OpenAI and Anthropic are presenting to the world is "we're the absolute best, no one else comes close." Well, to keep that up you can't just not train for extended periods of time. You have to keep that engine going non-stop when there's free Chinese models nipping at your heels. You can be profitable on "just inference" all you want but if training expenses dwarf that, you're not going to be profitable overall, and that's the bottom line.
> does still cover marginal inference cost
Simply comparing to the larger models on OpenRouter implies that the pure hosting costs (equipment + power + minimal overhead) still exceed plan pricing if we assume all users always use their full weekly allowance.
So my conclusion is that it only works because the majority of users doen't fully utilize their allowance. Last month I used almost nothing of my Claude 20x plan (did use Codex though).
Moviepass failed because they thought it's going to be like Gym membership - people buy and don't go, but guess what? People love going to movie theaters. On its own its not bad, see AMC Stubs, but AMC owns the theater, they sell you popcorn and soda. OpenAI an Anthropic is closer to AMC than Moviepass.
> Moviepass failed because they thought it's going to be like Gym membership - people buy and don't go, but guess what? People love going to movie theaters.
You think developers won't/don't stretch subscriptions to the absolute limit? The AI subscription model is like the gym model except a large percentage of the customers work out 24/7/365.
You're missing a piece: MoviePass was selling subscriptions while buying tickets from theaters at retail prices. That's why I mentioned AMC A-List, their subscription model works pretty well for them because they control per ticket and subscription price.
The price these companies charge per token is irrelevant to a discussion about subscriptions. You're comparing two selling prices, when what matters is the actual cost. It's like those ads saying, “Normally $20 million, but today it's only $99!” for something that costs $10 to make.
Sure, they're losing money now. But the question is whether the tokens you use through your subscription will eventually cost them less to generate than you pay for that subscription. Their per-token selling price doesn't tell you that.
Last I checked, Uber underperformed the S&P index since its IPO. Even Softbank didn't make a great return on its investment. The growth story was definitely oversold.
Also, Uber was peak ZIRP + COVID, money was cheap and growth was easy. I think the mountain to climb is a lot steeper now.
> I struggle to believe that someone would find it worth that much money to have a decompiled version of a game they also commit to keeping private.
The tone of the blog suggests they are using the game to build out tooling and expertise; the capability to decompile large projects on the scale of AAA games is not worth nothing, e.g. security or "competitor analysis" that lays trade secrets bare.
AI is a great at laundering code, I thought open-source software was the prime prey, but I should have thought bigger.
Also, 500 billion is 500,000 millions. At the lower end of your 140/mil estimate that's 70 million dollars. Even at my 2/mil lookup for Chinese frontier models that's one million. Show your math for 100k-750k, please.
It was a search for "average cost of 500 billion ai tokens" which may or may not have been the correct phrasing, but seemed straight-forward enough that at first blush, accepting the AI-generated answer seemed reasonable.
Even with 95% cache hit, and on cheapest chinese model, it would still be in tens of thousands of dollars (I assume that of 500B tokens at least 10B would be in "output").
If we switch gears to Kimi K* then if would very quickly escalate in hundred thousands USD.
Unless you explicitly need byte-matching decompilation, there are significantly faster ways to produce a decompilation/C which is functionally equivalent. I need to post about this. What's been working for me is that for every function, Agent A is tasked with writing some code which is semantically equivalent to the original assembly, but not necessarily exactly the same. Agent A also writes tests. Agent A submits the implementation of the function and tests to the harness for it to judge. The harness runs both the original function and the submitted function in a virtual machine/simulator/emulator (the tests define function inputs and starting state). The harness will only accept the implementation if 1) the read/write sequence to RAM is identical to the original function's, and 2) there must be complete line and branch coverage of the original function being decompiled.
I've found this to be robust for decompiling games, while giving the agents enough freedom to write code that is readable and not waste a ton of time making sure e.g. instruction ordering, register assignments, etc. are all exactly the same. For me, having byte-matching decompilation is only one way to produce a decompilation I know is faithful to the original. This "high-level decompilation" process I just described is something agents can do much more quickly.
Could you talk more about how you’ve used this technique? I want to start on a similar kind of AI-driven decomp project and I’m looking for any kind of edge I can get.
I used a similar methodology for https://github.com/emberian/don feel free to dig thru anything in there I think all the notes are in the repo itself... of course it helps having a game that was explicitly designed around networked deterministic lockstep. forces the agent to learn a lot of lessons from reality instead of my typing :)
Read/write sequences to RAM are inconclusive regarding semantic equivalence.
You can have identical sequences and semantics can still be wrong (e.g. when working with the FPU and the float stack, or instructions operating purely on registers). You can also have diverging sequences when having identical semantics, e.g. variables occupying different stack slots, despite computing the same thing.
Also, it feels like just fuzzing the function is slow, compared to simply checking bytes. Fast feedback allows agents to iterate much faster. At some point I wrote a tool that simply proves semantic equivalence, while ignoring irrelevant changes, e.g. register selection or stack slot changes. Turns out it was way too slow as a harness. I still used it to verify some of the remaining functions.
It turns out that getting functions byte-matching is actually not that complicated. Most functions are small and can be one shotted, and over time, agents figured out rules how to control code generation for more complex functions. They wrote down techniques and tricks on how to control register selection for example, or how certain control flow operations may impact basic block ordering, etc. Super insteresting what they figured out. So the further we got into the project, the easier it was to get functions exact.
Games depend enough on stuff like global state or externally provided data that in practice this often isn't enough to guarantee the code actually working the same as the original. You can have tens of thousands of tests that exercise every branch in the game code, and the game still may not behave the same. You really won't know for sure that your code behaves the same under all conditions unless you're able to reproduce the same executable.
I struggle to understand what legal leverage they used to threaten him to remove every detail about the game. Can someone post the game name and company name?
So, if you reverse-engineer game X and post reverse-engineered code, what exactly do you infringe, how and in which jurisdiction? What changes if it is done via LLM?
(I understand that LLM decompilation is absolutely out of hand right now and something surely will come to trample the fun. But what and when? I suppose american LLMs will have their system prompt updated to forbid any reversing help and report suspicious activity straight to legal hotline)
> So, if you reverse-engineer game X and post reverse-engineered code, what exactly do you infringe, how and in which jurisdiction? What changes if it is done via LLM?
In 1986 there was a federal court case, Whelan Associates Inc. v. Jaslow Dental Laboratory, in which it was ruled that the "structure, sequence, and organization" of a computer program was protected by copyright, and thus independently produced software could be found infringing if it copied these elements, even if the code were not copied (or mechanically translated) verbatim. This led to a six-year period in which computer software enjoyed generous copyright protection, such that "clones" of copyrighted software were effectively infringing. It wouldn't be until the early nineties that other court rulings would tighten the rules again, notably Computer Associates International, Inc. v. Altai Inc.. The 3-step "abstraction-filtration-comparison" test has been used by most courts since 1992 to determine whether nonliteral parts of program code are eligible for copyright protection, and whether another, independently written program is infringing.
HOWEVER, the Whelan standard was never actually overturned or stricken from U.S. law due to legislation or litigation! And companies have sued and won under the Whelan standard! Most notably, Oracle in their copyright and patent case against Google regarding Java APIs in Android. Google ultimately prevailed, but only because the Supreme Court ruled that Google's use of the APIs was fair use; they did not overturn the Federal Circuit's finding that the "structure, sequence, and organization" of the Java declaration code was ineligible for copyright! And I doubt that the Supreme Court would similarly smile on a reverse-engineered complete video game!
I believe that these reverse-engineered projects infringe copyright, under the Whelan standard and perhaps under the stricter Altai standard as well. You do not get a free pass because the original code was in C and yours is in Rust; or because you created a slightly different version of each function in the original code.
That implies US jurisdiction plus that was made at the time where "hey, let's actually reverse-engineer and copy our competitor" was very expensive and time-consuming, so slapping one company would discourage everyone else to sink money in it. Currently it seems the latter is becoming either automatic (still somewhat expensive) or even free.
Committing copyright infringement against software vendors was automatic and free before, when it involved merely copying files, maybe after cracking the copy protect. It was still illegal. What makes you think this time would be any different? The fact that an LLM did it? Whatever an LLM produces humans assume responsibility for.
When you copy a file, it's trivially simple to prove it's a copy and not an original work.
How can one prove that X is a copy when none of the source code match original? Clean room re-implementations are not illegal after all, if we go that way (yeah, yeah, I know about clean room argument).
While I personally do not think it would be different, but a lot of LLM folks are, and even some companies (rushing to blatantly clone and de-compile stuff). Kinda strange feeling sitting and looking around in the midst of it, y'know.
Doing a clean room implementation would require you to build a test suite using an AI against the binary and then you build a test server against which other people, not you, can run their own implementations and you just report how many tests pass.
But this seems to hinge on the "clean room"- is this a separate set of case law or is it related? As in, if they had been more judicious about the way the game was implemented could they have claimed it was not under copyright?
In case anyone is curious about the obvious question of which game they are talking about... based on months-old reddit posts (which seem like links to prior progress reports of the same project) the game in question appears to be Call of Duty: Modern Warfare 2.
Interesting, if all software can be decompiled and copied what is the future of software. Will all software be SaaS? A time where the majority of PCs will be terminals? Game consoles are almost there. It's only a small jump for all software to go that way.
Most software organizations pay for is effectively a SaaS or something where software is a minor part of the artifact and support is where the real money is.
A future of all SaaS only works if you can't just tell a LLM what you want and get a custom implementation. I've always done a lot of personal projects, but my velocity has increased dramatically and I've replaced a number of projects that I used to pay for with custom ones that work well enough. I can't imagine that SaaS is going to be a viable model unless it involves a community that wants a unified experience, like a multiplayer game.
Non-SaaS, close sourced software is already dead, no? I think pretty soon we'll all be using bespoke software written by the AIs. I already use throwaway software designed for each job because it's so cheap to do so.
I wonder about this too. Although, cracking was always possible. So what changed is that people can now modify, improve proprietary software with zero technical knowledge. I can now tell Astra or Fable (maybe not Fable because of safeguards?) to add a feature to Adobe Photoshop and it might actually succeed even when prompting purely on a functional level (e.g. the functionality I want out of the program). It would take days, but I think it would succeed. Call it PhotoBench?
Eventually Fable-level models will be abliterated and hosted on Openrouter too, like so many others have been. Remember Chinese models are only a few months behind American ones at this point and are trained on their outputs, and can be a literates after release.
The reason this cost so much is because the AI has the ridiculous goal of getting identical assembly output.
If you just went for functional equivalence, it would probably cost 10x or 100x less tokens.
Another false economy was using Sonnet instead of a more intelligent model like Sol 6.1, which would have cost more per token, but is 100x or so better at reverse engineering and coding and therefore can chew through the source code much quicker and make fewer mistakes, meaning less work needing to be scrapped, which is important when reverse engineering because 1 mistake can cascade and spoil the whole thing.
Identical output isn’t ridiculous. It’s pretty much a requirement to ensure the game actually is the same in every way. These decomp projects are pitched as a high performance alternative to emulation.
No one is going to use it if it’s a kind of close but not really reimplementation.
Testing functional equivalence is also pretty much impossible. How would you for example test the new one has exactly the same bugs which haven’t been discovered yet. Or doesn’t introduce new ones? This stuff matters for speed runners.
Identical assembly output is the only way to get functional equivalence, otherwise you're getting equivalence in some percentage of situations, but not 100%. Your bug is my feature etc.
I think you're overlooking an important point here. While the token consumption might feel extremely high, I think it's a bit deceiving.
Due to this strict harness, we were able to use extremely dumb models efficiently.
I think at least 200-300B of tokens (maybe even more) were processed by Luna.
Given that Sol is 100x more expensive per token than Luna, a high token consumption doesn't necessarily mean high cost.
So these 300B Luna tokens would equate to 3B Sol tokens.
Unfortunately a huge part of the logs is lost, so I can't do a detailed analysis on which models were used, how much they cost, etc.
> Due to this strict harness, we were able to use extremely dumb models efficiently.
With all due respect I seriously doubt that. What are you doing that's different? Almost every test between just Opus and Opus conducting cheaper agent swarms ends up with Opus getting better results at a lower cost. People set up harnesses just like yours and see this.
I tried giving glm 5.3 ghidra. I found that it frequently did better just reading the actual assembly, where needed writing decompilers in real time, in the terminal.
The reasoning showed that it was able to write ghidra as needed and indeed where necessary simply read assembly tokens.
Trying to think about ghidra probably confused it.
I also think that there is a gradient of losing intelligence in refusals, opposed to a simple boolean refuse. I suspect that using an abliterated model would boost the intelligence way up.
I am attempting this with a 100 MB GameMaker (HoloCure) game to make mobile and console ports for fun. Because it uses YYC[0] instead of running in a VM which is how GameMaker games usually work (to my crude understanding of the issue) I have to reverse engineer it instead of just extracting assets and putting them into a project template.
I am using Qwen 3.8 27B-8bit in oMLX and Pi agent with GhidraMCP on my MacBook M3 Max. So far it ran for like 10 hours total and I haven't checked in on it much but it seems to have extracted the audio assets successfully and wrote a whole bunch of helper scripts for Ghidra to extract YYC functions which took several hours to run. I put the project on hold cause I didn't want to keep running it at 100% fans for hours every day. It blew through ~200k context of the model 3 times by now. I am not confident in this project, especially because I have very little experience doing grown up reverse engineering that isn't decompiling a C# or Android apps so I can't really guide it.
Can anyone think of any lessons to draw from this for normal development, where we don't have oracles to serve as guardrails? I write specs but the agents still find ways to insert bugs between the lines. Oh well, job security.
It's not really comparable. When decompiling you only care about a one time result. Code quality doesn't matter much. Stability doesn't matter much. Only whether the result is accurate. Once you have the matching decompiled code, all tools used until that point will be usually thrown away.
Normal development isn't so lucky, you do care about code quality. So you have to review the code the agents write and handle the testing yourself. The agents will not do what you want, they'll do what they think you want, and you're the only person who knows what you think.
The obvious lesson is that you need some kind of test/harness, even for normal development. Your spec will always leave room for interpretation in a sense that is undesired.
Obviously matching functions byte-byte is not it, but I think with enough creativity, you can have guardrails and oracles almost everywhere.
E.g. before diving into feature development, you can have agents generate a test suite based on your implementation first. Then, when developing features, this test suite shows what broke and agents can double check if that was intended.
How that test suite looks like obviously highly depends on the environment.
> The avid reader of my blog might have noticed that I had previously written two posts that have since been removed. Everyone else might now be wondering which game I am talking about. To both of you I can only say that corporate America was here to ruin our fun.
Without context I instantly recognized the crude drawing in the current blog post as MW2 2009 cause the caricature of the sniper rifle looks like the Intervention sniper rifle from the game. It really has become an iconic weapon, a BFG or Quake rocket launcher for Gen Z and Millennials.
I sense the approach overcomplicates things. I wonder how long this would have taken in a single session. Maybe this is actually a textbook example of something where subagents make sense, but when I first started LLMs I was often overcomplicating the workflow with all kinds of orchestration. Now I just use one agent, it better allows controlling the output even if the agent works slightly longer. Most time is spent by me writing prompts and reviewing work anyway (for me at least).
The best models have O(1k tokens per second). A billion tokens, sequentially, takes 1-2 weeks. 500B takes 500x that ... not fast. The problem might not have required 500B tokens, but if it needed anything within a couple orders of magnitude then something like the given approach (or anything else yielding equivalent results in exchange for parallelism) was mandatory.
That's plausibly true. I've definitely seen absurd token costs abused and wasted. I've also seen simple problems require absurd token counts regardless of prompt quality. Which factors made this problem require 1000x fewer tokens than they used?
When you see these absurd numbers, they are re-counting cached input for every turn. So a simple tool call when your context size is at 500k counts as another 500k to the sum.
Total Opus 5.5 token usage on OpenRouter last week is 5000B, presumably not counting cached input.
Reverse engineering existing game binaries seems kind of silly when a lot of the most important AAA knowledge is already available to the general public.
The LLMs have presumably already consumed information like this as part of their training sets. Converting between Hammer and Unity scale is a fairly trivial linear operation. You can dump the BSPs to recover geometry and rapidly accelerate map development using timings that are already known to work.
Attacking the raw binary directly is certainly impressive, but it's totally unnecessary.
Interesting read and a thread here. I am working on decompiling two obscure abandoware games from my childhood and it's been a difficult and quirky process...
Even after building whole infra for that and not pursuing identical byte output it's been pretty token hungry process
Great article that really demonstrates why the copious amounts of AI generated PC ports do not fit under ”preservation” guise, which to me has been the point of doing these ports in the first place and what many of the enthusiasts before the LLM wave were aiming for.
> There are no noticeable bugs and all features of the original game are present.
>
> The remaining functions have been reworked repeatedly. While they still don’t match byte for byte, we believe their semantics are correct.
As there are no way to confirm this outside of ”believinh”, what you are left is with a end product that might contain thousands of micro changes that essentially make the game something else than it was intended to be.
Since even Fable 5.1 cannot reliably remember what it wrote into "memory" files before the last compaction, why would we trust it to not forget about some side-effect when handling assembly that is so verbose it'll surely exceed the context and, hence, necessitate compaction.
Well, I received a few DMCAs and thus stopped. We would've likely brought this as close to 100% as we can, but it's just pointless given the circumstances. So our belief and a few final tests were enough.
I'm more interested in how the OP managed to convince claude to do what was probably against Activison's TOS. I am assuming they didn't hand specifics of the game but just a blank binary. Because if you had of given specifics claude would have checked the TOS of the IP holder, found that the company doesn't want people to decompile their software, and refused to work on it. Or am I missing something here?
It doesn't seem to care. I had it do this for a small game the other day just to try it out. I fed it decompiled Ghidra code. It doesn't seem to have the same restrictions that developing malware or hacking web servers has.
Maybe companies will ask anthropic to crack down on it at some point.
I do wonder if LTO would obfuscate this a bit more. Presumably if you can't chunk it into small compilation units, you can't find a way to make C from the machine code.
Reverse engineering dynamic dispatches like vtable and fat pointers/slices and traits would be hell. Different padding and compiler settings also contribute a lot.
One of the few problem is that the decompiler is not always reliable. That forces you to go read the assembly, and it is not apparent to decipher the right kind of feng shui, not even from human before the LLM era. I used to play CTFs and my conclusion is exactly that.
This is extremely apparent when there are self-modifying code (e.g. JIT) is involved. You need a stepping debugger to read the right control flow, because the code will diverge based on the instruction pointer and regions you jumped into. At this point static analysis like IDA and Ghidra stopped working.
Is it the same Call of Duty: Modern Warfare 2 decompilation project? If yes, then why author says he/she does no release source code? If I remember correctly, it has to be open sourced Modern Warfare 2 modernized engine and so on? Or do I miss something?
139 comments
[ 2.2 ms ] story [ 96.6 ms ] thread>At current 2026 API rates, 500 billion AI tokens would cost roughly $100,000–$750,000 depending on the model, with most flagship models in the $150–$400 per million input tokens range
Yet, it is now profitable.
The bet is that people realize how valuable these services are, and despite complaining, they still would pay the higher price. This realization would not happen without this initial subsidy from investors.
It isn't too different from drug dealer's first sample free...
Taxis were an established profitable business model and the uber subsidisation wasn’t anywhere near as much as AI subsidies.
????
Uber and Lyft were paying drivers $X but charging users way less than $X so they were literally burning investor money to get market share.
Why does this point come up over and over again, pretending that you can truly separate training and inference costs. Yes, they are separate things but the value OpenAI and Anthropic are presenting to the world is "we're the absolute best, no one else comes close." Well, to keep that up you can't just not train for extended periods of time. You have to keep that engine going non-stop when there's free Chinese models nipping at your heels. You can be profitable on "just inference" all you want but if training expenses dwarf that, you're not going to be profitable overall, and that's the bottom line.
So my conclusion is that it only works because the majority of users doen't fully utilize their allowance. Last month I used almost nothing of my Claude 20x plan (did use Codex though).
You think developers won't/don't stretch subscriptions to the absolute limit? The AI subscription model is like the gym model except a large percentage of the customers work out 24/7/365.
The price these companies charge per token is irrelevant to a discussion about subscriptions. You're comparing two selling prices, when what matters is the actual cost. It's like those ads saying, “Normally $20 million, but today it's only $99!” for something that costs $10 to make.
Sure, they're losing money now. But the question is whether the tokens you use through your subscription will eventually cost them less to generate than you pay for that subscription. Their per-token selling price doesn't tell you that.
Also, Uber was peak ZIRP + COVID, money was cheap and growth was easy. I think the mountain to climb is a lot steeper now.
The tone of the blog suggests they are using the game to build out tooling and expertise; the capability to decompile large projects on the scale of AAA games is not worth nothing, e.g. security or "competitor analysis" that lays trade secrets bare.
AI is a great at laundering code, I thought open-source software was the prime prey, but I should have thought bigger.
https://developers.openai.com/api/docs/pricing https://platform.claude.com/docs/en/about-claude/pricing
OpenAI and Mythos are both 10/mil in.
https://openrouter.ai/z-ai/glm-5.3#providers https://openrouter.ai/moonshotai/kimi-k3#providers Other frontier models are like 1-3/mil in.
Also, 500 billion is 500,000 millions. At the lower end of your 140/mil estimate that's 70 million dollars. Even at my 2/mil lookup for Chinese frontier models that's one million. Show your math for 100k-750k, please.
I've found this to be robust for decompiling games, while giving the agents enough freedom to write code that is readable and not waste a ton of time making sure e.g. instruction ordering, register assignments, etc. are all exactly the same. For me, having byte-matching decompilation is only one way to produce a decompilation I know is faithful to the original. This "high-level decompilation" process I just described is something agents can do much more quickly.
Also, it feels like just fuzzing the function is slow, compared to simply checking bytes. Fast feedback allows agents to iterate much faster. At some point I wrote a tool that simply proves semantic equivalence, while ignoring irrelevant changes, e.g. register selection or stack slot changes. Turns out it was way too slow as a harness. I still used it to verify some of the remaining functions.
It turns out that getting functions byte-matching is actually not that complicated. Most functions are small and can be one shotted, and over time, agents figured out rules how to control code generation for more complex functions. They wrote down techniques and tricks on how to control register selection for example, or how certain control flow operations may impact basic block ordering, etc. Super insteresting what they figured out. So the further we got into the project, the easier it was to get functions exact.
So, if you reverse-engineer game X and post reverse-engineered code, what exactly do you infringe, how and in which jurisdiction? What changes if it is done via LLM?
(I understand that LLM decompilation is absolutely out of hand right now and something surely will come to trample the fun. But what and when? I suppose american LLMs will have their system prompt updated to forbid any reversing help and report suspicious activity straight to legal hotline)
In 1986 there was a federal court case, Whelan Associates Inc. v. Jaslow Dental Laboratory, in which it was ruled that the "structure, sequence, and organization" of a computer program was protected by copyright, and thus independently produced software could be found infringing if it copied these elements, even if the code were not copied (or mechanically translated) verbatim. This led to a six-year period in which computer software enjoyed generous copyright protection, such that "clones" of copyrighted software were effectively infringing. It wouldn't be until the early nineties that other court rulings would tighten the rules again, notably Computer Associates International, Inc. v. Altai Inc.. The 3-step "abstraction-filtration-comparison" test has been used by most courts since 1992 to determine whether nonliteral parts of program code are eligible for copyright protection, and whether another, independently written program is infringing.
HOWEVER, the Whelan standard was never actually overturned or stricken from U.S. law due to legislation or litigation! And companies have sued and won under the Whelan standard! Most notably, Oracle in their copyright and patent case against Google regarding Java APIs in Android. Google ultimately prevailed, but only because the Supreme Court ruled that Google's use of the APIs was fair use; they did not overturn the Federal Circuit's finding that the "structure, sequence, and organization" of the Java declaration code was ineligible for copyright! And I doubt that the Supreme Court would similarly smile on a reverse-engineered complete video game!
I believe that these reverse-engineered projects infringe copyright, under the Whelan standard and perhaps under the stricter Altai standard as well. You do not get a free pass because the original code was in C and yours is in Rust; or because you created a slightly different version of each function in the original code.
And let's say there's a future where an AI model could zero-shot the game itself. What then?
How can one prove that X is a copy when none of the source code match original? Clean room re-implementations are not illegal after all, if we go that way (yeah, yeah, I know about clean room argument).
While I personally do not think it would be different, but a lot of LLM folks are, and even some companies (rushing to blatantly clone and de-compile stuff). Kinda strange feeling sitting and looking around in the midst of it, y'know.
It reminded me of this: https://malus.sh/ "cleanroom as a service" - which I guess was kind of a joke, but looks pretty serious now.... (discussion back then: https://news.ycombinator.com/item?id=47350424)
But this seems to hinge on the "clean room"- is this a separate set of case law or is it related? As in, if they had been more judicious about the way the game was implemented could they have claimed it was not under copyright?
PIF owns EA, when they invite you to a meeting you might start to worry about foil lined room and carpentry tools lying around
https://www.reddit.com/r/ReverseEngineering/comments/1vxig19...
Presumably at some point Microsoft sent a C&D.
Someone has vibe coded the entire Adobe suite btw: https://getartcraft.com/apps
If you just went for functional equivalence, it would probably cost 10x or 100x less tokens.
Another false economy was using Sonnet instead of a more intelligent model like Sol 6.1, which would have cost more per token, but is 100x or so better at reverse engineering and coding and therefore can chew through the source code much quicker and make fewer mistakes, meaning less work needing to be scrapped, which is important when reverse engineering because 1 mistake can cascade and spoil the whole thing.
No one is going to use it if it’s a kind of close but not really reimplementation.
Testing functional equivalence is also pretty much impossible. How would you for example test the new one has exactly the same bugs which haven’t been discovered yet. Or doesn’t introduce new ones? This stuff matters for speed runners.
Due to this strict harness, we were able to use extremely dumb models efficiently. I think at least 200-300B of tokens (maybe even more) were processed by Luna.
Given that Sol is 100x more expensive per token than Luna, a high token consumption doesn't necessarily mean high cost. So these 300B Luna tokens would equate to 3B Sol tokens.
Unfortunately a huge part of the logs is lost, so I can't do a detailed analysis on which models were used, how much they cost, etc.
With all due respect I seriously doubt that. What are you doing that's different? Almost every test between just Opus and Opus conducting cheaper agent swarms ends up with Opus getting better results at a lower cost. People set up harnesses just like yours and see this.
Do you have any links to these tests? I've had a hunch that this was true for a while but haven't found any benchmarks showing it.
I tried giving glm 5.3 ghidra. I found that it frequently did better just reading the actual assembly, where needed writing decompilers in real time, in the terminal.
The reasoning showed that it was able to write ghidra as needed and indeed where necessary simply read assembly tokens.
Trying to think about ghidra probably confused it.
I also think that there is a gradient of losing intelligence in refusals, opposed to a simple boolean refuse. I suspect that using an abliterated model would boost the intelligence way up.
- please someone do it
I am using Qwen 3.8 27B-8bit in oMLX and Pi agent with GhidraMCP on my MacBook M3 Max. So far it ran for like 10 hours total and I haven't checked in on it much but it seems to have extracted the audio assets successfully and wrote a whole bunch of helper scripts for Ghidra to extract YYC functions which took several hours to run. I put the project on hold cause I didn't want to keep running it at 100% fans for hours every day. It blew through ~200k context of the model 3 times by now. I am not confident in this project, especially because I have very little experience doing grown up reverse engineering that isn't decompiling a C# or Android apps so I can't really guide it.
0 - https://manual.gamemaker.io/lts/en/Settings/YoYo_Compiler.ht...
Normal development isn't so lucky, you do care about code quality. So you have to review the code the agents write and handle the testing yourself. The agents will not do what you want, they'll do what they think you want, and you're the only person who knows what you think.
Obviously matching functions byte-byte is not it, but I think with enough creativity, you can have guardrails and oracles almost everywhere.
E.g. before diving into feature development, you can have agents generate a test suite based on your implementation first. Then, when developing features, this test suite shows what broke and agents can double check if that was intended.
How that test suite looks like obviously highly depends on the environment.
Call of Duty: Modern Warfare 2 (2009)
https://web.archive.org/web/20260925153118/https://momo5502....
https://web.archive.org/web/20260925153131/https://momo5502....
Come at me, corporate America.
Total Opus 5.5 token usage on OpenRouter last week is 5000B, presumably not counting cached input.
https://github.com/ValveSoftware/halflife/blob/master/pm_sha...
The LLMs have presumably already consumed information like this as part of their training sets. Converting between Hammer and Unity scale is a fairly trivial linear operation. You can dump the BSPs to recover geometry and rapidly accelerate map development using timings that are already known to work.
Attacking the raw binary directly is certainly impressive, but it's totally unnecessary.
Even after building whole infra for that and not pursuing identical byte output it's been pretty token hungry process
> There are no noticeable bugs and all features of the original game are present.
>
> The remaining functions have been reworked repeatedly. While they still don’t match byte for byte, we believe their semantics are correct.
As there are no way to confirm this outside of ”believinh”, what you are left is with a end product that might contain thousands of micro changes that essentially make the game something else than it was intended to be.
Since even Fable 5.1 cannot reliably remember what it wrote into "memory" files before the last compaction, why would we trust it to not forget about some side-effect when handling assembly that is so verbose it'll surely exceed the context and, hence, necessitate compaction.
Maybe companies will ask anthropic to crack down on it at some point.
One of the few problem is that the decompiler is not always reliable. That forces you to go read the assembly, and it is not apparent to decipher the right kind of feng shui, not even from human before the LLM era. I used to play CTFs and my conclusion is exactly that.
This is extremely apparent when there are self-modifying code (e.g. JIT) is involved. You need a stepping debugger to read the right control flow, because the code will diverge based on the instruction pointer and regions you jumped into. At this point static analysis like IDA and Ghidra stopped working.
That would reveal the quality of the Windows OS codebase.
My bet is the result ain't gonna be pretty.