We reproduced Anthropic's Mythos findings with public models

I think you're misrepresenting what they're doing here.

The Mythos findings themselves were produced with a harness that split it by file, as you noted. The harness from OP split each file into chunks of each file, and had the LLM review each chunk individually.

That's just a difference in the harness. We don't yet have full details about the harness Mythos used, but using a different harness is totally fair game. I think you're inferring that they pointed it directly at the vulnerability, and they implicitly did, but only in the same way they did with Mythos. Both approaches are chunking the codebase into smaller parts and having the LLM analyze each one individually.

"For example, Opus 4.6 turned the vulnerabilities it had found in Mozilla’s Firefox 147 JavaScript engine—all patched in Firefox 148—into JavaScript shell exploits only two times out of several hundred attempts. We re-ran this experiment as a benchmark for Mythos Preview, which developed working exploits 181 times, and achieved register control on 29 more."

https://red.anthropic.com/2026/mythos-preview/

That's not too surprising for those of us who have been working with these things, either. All kinds of simpler use cases are manageable with harnesses but not reliably by LLMs on their own.

On what grounds can we assume that? That's what the marketing department wants us to assume, but what makes us even suspect that that's what they did?

I kind of confirmed this against some of my own code bases. I pointed Opus 4.6 against some internal code bases. It came up with a list of possibilities. The quality of the possibilities was quite mixed and the exploit code generally worthless. So I did at least do a spot check on that aspect of their marketing and it checked out.

The problem is that this changes the attacker versus defender calculus. Right now, the world is basically a big pile of swiss cheese, but we are not all being continuously popped all the time for full access to everything because the exploitation is fundamentally blocked on human attackers analyzing the output of tools, validating the exploits, and then deciding whether or not to use them.

That "whether or not to use them" calculus is also profoundly affected by the fact that they can generally model the exploits they've taken to completion as being fairly likely to uniquely belong to them and not be fixed by the target software, so they have the capability to sit on them because they are not rotting terribly quickly. It is well known that intelligence agencies, when deciding whether or not to attack something, also consider the impact of the possibility of leaking the mechanism they used to attack the user and possibly losing it for future attacks as a result. A particularly well-documented discussion of this in a historical context can be found around how the Allies used the fact they had broken Enigma, but had to be careful exactly how they used the information they obtained that way, lest the Axis work out what the problem was and fix it. All that calculus is still in play today.

The fundamental problem with the claims Mythos made isn't that it can find things that may be vulnerabilities; the fundamental sea change they are claiming is a hugely increased effectiveness in generating the exploits. There's a world of difference in the cost/benefits calculus for attackers and defenders between getting a cheap list of things humans can consider, which was only a quantitative change over the world we've lived in up to this point, and the humans being handed a list of verified (and likely pre-weaponized with just a bit more prompting) vulnerabilities, where the humans at most have to just test it a bit in the lab before putting it in the toolbelt. That is a qualitative change in the attacker's capabilities.

There is also the second-order effect that if everybody can do this, the attackers will stop assuming that they can sit on exploits until a particularly juicy target worth the risk of burning the exploit comes up. That get shifted on two fronts: Exploits are cheaper, so there's less need to worry about burning a particular one, and in a world where everyone has Mythos, everyone is scanning everything all the time with this more sophisticated exploiting firepower and just as likely to find the exploit as the nation-state attackers are, so the attackers need to calculate that they need to use the exploits now, even if it's a lower value attack, because there may not be a later.

If, if, if, if, if the marketing is even half true, this really is a big deal, but it's because of the automated exploit generation that is the sea change, not just finding the vulnerabilities. And especially not finding the same vulnerabilities as Mythos but also including it in a list of many other vulnerabilities that are either not real or not practically exploitable that then bottlenecks on human attention to filter through them. Matching Mythos, or at least Mythos' marketing, means you pushed a button (i.e., simple prompt, not knowing in advance what the vuln is, just feeding it a mass of data) and got exploit. Push button, get big unfiltered list of possible vulnerabilities is not the same. Push button, get correct vulnerability is closer, but still not the same. The problem here is specifically "push button, get exploit".

You missed this part:

> For transparency, the Focus on lines ... instructions in our detection prompts were not line ranges we chose manually after inspecting the code. They were outputs of a prior agent step.

We used a two-step workflow for these file-level reviews:

Planning step. We ran the same model under test with a planning prompt along the lines of "Plan how to find issues in the file, split it into chunks." The output of that step was a chunking plan for the target file. Detection step. For each chunk proposed by the planning step, we spawned a separate detection agent. That agent received instructions like Focus on lines ... for its assigned range and then investigated that slice while still being able to inspect other repository files to confirm or refute behavior. That means the line ranges shown in the prompt excerpts were downstream artifacts of the agent's own planning step, not hand-picked slices chosen by us. We want to be explicit about that because the chunking strategy shapes what each detection agent sees, and we do not want to present the workflow as more manually curated than it was.