Claude Mythos Preview and Project Glasswing: What the Published Numbers Actually Say

The published numbers, without embellishment

Here is what can be verified. All figures come from Anthropic's Project Glasswing initial update, published May 22, 2026.

The figure I keep coming back to is the triage result. Of the 6,202 high or critical open-source findings, 1,752 were carefully assessed by one of six independent security research firms, or in a small number of cases by Anthropic itself.

A 90.6% true-positive rate is an unusual number if you've operated static analysis tooling in anger. Most of us have lost afternoons pulling one real finding out of a sea of noise. Cloudflare's team described the false positive rate as better than human testers.

At that rate, Anthropic estimates the open-source scan alone is on track to surface close to 3,900 high or critical vulnerabilities, separate from the 10,000+ found by partners in their own code.

One concrete example is public. In wolfSSL, a cryptography library used by billions of devices, Mythos Preview constructed an exploit allowing an attacker to forge certificates, which would let them host a convincing fake site for a bank or email provider. It's now patched and tracked as CVE-2026-5194.

Glasswing went from 50 partners to roughly 200

Project Glasswing launched in early April 2026 with about 50 initial partners: Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks.

On June 2, Anthropic announced the addition of roughly 150 new organizations, bringing the total to about 200 across more than 15 countries. The new cohort deliberately covers sectors that were thin in the original group: power, water, healthcare, communications, and hardware.

Anthropic explained the selection criterion in a single sentence. For most of these partners, they estimate that a successful attack on the partner's codebase could affect more than 100 million people. Each new organization has to meet Anthropic's security requirements before gaining access.

The line I found heaviest was the forward-looking one. Anthropic expects that within 6 to 12 months, many other AI companies will have Mythos-class models, and that those models could be released without safeguards preventing misuse.

Read that way, Glasswing isn't a response to Anthropic having a powerful model. It's preparation for a world where everyone has one. That framing also clarifies what those of us outside the program should be doing.

The bottleneck moved from finding to fixing

Anthropic's initial update contains a sentence that summarizes the past year of security work. Progress on software security used to be limited by how quickly new vulnerabilities could be found. It is now limited by how quickly they can be verified, disclosed, and patched.

The patching side has published data too.

530 disclosed, 75 patched. A high or critical bug takes two weeks to patch on average. Anthropic gives three reasons for the low patch count: they're still inside the 90-day disclosure window, they undercount patches that ship without a public advisory, and third, even at a deliberately slow disclosure pace, Mythos Preview is adding load to an already overloaded security ecosystem.

That third reason is the uncomfortable one. Open-source maintainers were already facing a deluge of low-quality, AI-generated bug reports. Some have asked Anthropic to slow down disclosures because they need more time to design patches.

Finding got ten times faster. The number of people who fix things did not. That asymmetry is the actual story.

The patching side isn't standing still, though. Palo Alto Networks shipped over five times its usual number of patches in a recent release, Microsoft has said its monthly patch counts will keep trending larger for some time, and Oracle reports finding and fixing vulnerabilities multiple times faster than before. Right now, rising patch counts are a health indicator.

What the rest of us can do with generally available models

You can't simply apply and get Mythos Preview. So does a solo developer or a small team just wait? Anthropic's own writing says clearly that the answer is no.

Generally available models already find large numbers of software vulnerabilities. They won't find the most sophisticated ones, and they won't exploit them as effectively as Mythos Preview. But the basic holes most codebases actually carry are well within reach. In the three weeks after Claude Security launched in public beta, over 2,100 vulnerabilities were patched with it.

Here is what has been made available publicly.

The harness design is reproducible with public models. Map the codebase, spin up scanning subagents, triage the findings, write the report. Four stages.

The mapping stage is where I got stuck first, and it turned out to be the interesting part.

What I measured, and where it actually breaks

Before any agent scans anything, you have to collect the repository's files and repack them into units that fit a single request. It's unglamorous, and it determines both your cost and what you miss.

Here is that front half, isolated and with no API calls. Verified on Python 3.10.12.

"""Collect a repository and repack it into analysis units.
No API calls here. The only question this answers is how many
requests the codebase becomes."""
from __future__ import annotations
 
import os
from dataclasses import dataclass, field
from pathlib import Path
 
SKIP_DIRS = {".git", "node_modules", "__pycache__", ".next", "dist", "build", ".venv", "vendor"}
CODE_EXT = (".py", ".ts", ".tsx", ".js", ".jsx", ".go", ".rs", ".c", ".h", ".java")
MAX_FILE_BYTES = 200_000       # drop generated and minified files
BUDGET_TOKENS = 150_000        # input budget per request
 
 
@dataclass
class SourceFile:
    path: Path
    text: str
    tokens: int
 
 
@dataclass
class Batch:
    files: list[SourceFile] = field(default_factory=list)
    tokens: int = 0
 
    def add(self, f: SourceFile) -> None:
        self.files.append(f)
        self.tokens += f.tokens
 
 
def estimate_tokens(text: str) -> int:
    """Budgeting only. Deliberately biased to overestimate."""
    return max(1, len(text) // 3)
 
 
def collect(repo: Path) -> list[SourceFile]:
    out: list[SourceFile] = []
    for root, dirs, files in os.walk(repo):
        dirs[:] = [d for d in dirs if d not in SKIP_DIRS]
        for name in files:
            if not name.endswith(CODE_EXT):
                continue
            p = Path(root) / name
            try:
                if p.stat().st_size > MAX_FILE_BYTES:
                    continue
                text = p.read_text(encoding="utf-8", errors="replace")
            except OSError:
                continue
            out.append(SourceFile(p, text, estimate_tokens(text)))
    return out
 
 
def pack(files: list[SourceFile], budget: int = BUDGET_TOKENS) -> list[Batch]:
    batches: list[Batch] = []
    oversized: list[SourceFile] = []
    for f in files:
        if f.tokens > budget:
            # A file that blows the budget alone is not a packing problem
            oversized.append(f)
            continue
        for b in batches:
            if b.tokens + f.tokens <= budget:
                b.add(f)
                break
        else:
            nb = Batch()
            nb.add(f)
            batches.append(nb)
    if oversized:
        print(f"[warn] needs function-level splitting: {len(oversized)} files")
    return batches

estimate_tokens uses len(text) // 3 for a reason. I measured it: encoding 300 Python source files (5,944,405 characters) with tiktoken's cl100k_base produced 1,604,149 tokens, which works out to 3.71 characters per token. The // 3 approximation overshoots that by 1.24x, every time. In budgeting, underestimating is what causes incidents, so an error in this direction is the one you want.

Smarter packing barely helped

My first implementation sorted files by token count descending before packing, a First-Fit Decreasing approach. It's the textbook answer for bin packing and I assumed it would reduce fragmentation.

Here's what I got. The corpus is the Python 3.10 standard library, 650 files and roughly 3.37 million estimated tokens, packed both in walk order and sorted descending.

At the budget where the gap was widest, sorting turned 339 batches into 336. That's 0.9%. Not worth the code. I deleted it.

Measuring something you wrote and then removing it is never satisfying. But leaving it in means someone inherits it later as a meaningful optimization, and it isn't one.

The real bottleneck is files that blow the budget alone

The same measurement surfaced something more useful. As the budget shrinks, the share of content locked inside individual oversized files climbs sharply.

Per-file token counts in that corpus: median 2,866, mean 5,186, max 47,920. When the median and mean diverge that far, your code is concentrated in a small number of very large files.

And vulnerabilities tend to live in the big files. Parsers that grew over a decade, stateful protocol implementations, handlers stacked with backward-compatibility branches. Polishing your packing algorithm never reaches that 70%. Getting there is a different problem: function-level or class-level splitting, plus deciding how much calling context travels with each chunk.

Building this is what made Anthropic's "threat model builder" click for me. Don't look at everything evenly. Decide which surfaces could plausibly be attacked, then spend the budget there. I had the order backwards.

Three things I changed in my own setup

The worst outcome here is being so impressed by the scale of the problem that you do nothing. So here are three unglamorous changes I made that same week.

I removed the approval gate on dependency updates. Automated updates used to wait for my review. In practice, "review" often meant approving without properly reading the diff. In a world where patches arrive at five times the usual volume, that gate isn't a safety mechanism, it's latency. Patch and minor updates now merge automatically once tests pass.

I extended log retention. Detection is the last line when a patch doesn't land in time. The baseline controls in the UK NCSC's 10 Steps and the NIST Cybersecurity Framework — hardened default configurations, enforced multi-factor authentication, comprehensive logging for detection and response — all share a property worth noticing: none of them depend on any single patch arriving on time. That property is what makes them worth the effort at solo scale.

I started scanning the code examples I publish. This one is specific to what I do. Code in a technical article can end up pasted straight into someone's production system. I've stopped treating published snippets as illustrations and started treating them as shipped artifacts. When I actually ran some older examples, a few didn't work as written. Not a comfortable discovery, but I'm glad I made it.

What I left out, and why

I dropped some material while rewriting this, and it's worth being explicit about it.

There is no CWE-by-CWE breakdown here, and no per-OS or per-browser finding counts. Anthropic has said plainly that they can't publish that level of detail yet. Their coordinated vulnerability disclosure policy follows the industry convention of 90 days, or roughly 45 days once a patch is available, and publishing details mid-window would put end users at risk. Any "breakdown" circulating right now has no primary source behind it.

There's no pricing table, no model ID, and no Bedrock or Vertex AI invocation example. The model isn't generally available, so none of that can be verified.

I also left out claims about the model's internal behavior. Treating unverifiable behavioral claims as dramatic material does real damage in this field specifically.

Cutting all that makes for a shorter article. But figures you can check, plus numbers I measured myself, should be more useful for your decisions than a longer piece built on neither.

If you do one thing next

One concrete step to close on.

Measure the median and maximum token count per file in your own repository. The collect and estimate_tokens functions above are enough. If those two numbers are far apart, your vulnerabilities are concentrated on the maximum side. That's where a scan should start.

Append this to the script above and it runs as-is.

if __name__ == "__main__":
    import statistics
    import sys
 
    files = collect(Path(sys.argv[1]))
    if not files:
        print("No matching files. Check CODE_EXT.")
        raise SystemExit(1)
 
    tok = sorted(f.tokens for f in files)
    biggest = max(files, key=lambda f: f.tokens)
    print(f"files   : {len(files)}")
    print(f"median  : {statistics.median(tok):,.0f} tokens")
    print(f"mean    : {statistics.mean(tok):,.0f} tokens")
    print(f"max     : {biggest.tokens:,} tokens  ({biggest.path})")
    print(f"batches : {len(pack(files))} (budget {BUDGET_TOKENS:,})")

If the max comes back several times the median, that filename is your first scan target. In my setup, this one line ended the prioritization debate.

As Anthropic keeps repeating, Mythos-class capability will be widely available within 6 to 12 months. What will matter then isn't whether a particular patch landed in time. It's the shape of the process you built before that.

I'm still working this out myself, and I don't think the three changes above are sufficient. If you're thinking about the same problem, I'd be glad to compare notes. Thank you for reading.