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.

One more thing that comes before the implementation. Count the extensions in your own repository rather than borrowing the CODE_EXT list above. When I counted one of my Lab sites, .tsx and .ts covered 70 files, while four .mjs build scripts fell outside the list entirely. A file skipped by the collector never announces itself in the results. What you get instead is a quiet line saying nothing was found.

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.

Reaching that 70%: split on definitions, not on files

Leaving "that's a different problem" on the page bothered me, so I went back and implemented just that piece. The idea is small: take a file that exceeds the budget, cut it at top-level boundaries, and re-attach only the import block to the front of each fragment.

import ast
 
 
def _start(node) -> int:
    # A decorated definition starts at its first decorator, not at the def line
    return min([node.lineno] + [d.lineno for d in getattr(node, "decorator_list", [])]) - 1
 
 
def split_python(sf: SourceFile, budget: int) -> list[SourceFile]:
    # Cut only at top-level boundaries. Every line ends up in exactly one fragment
    try:
        tree = ast.parse(sf.text)
    except SyntaxError:
        return [sf]
    if len(tree.body) < 2:
        return [sf]
 
    lines = sf.text.splitlines(keepends=True)
    starts = [_start(n) for n in tree.body]
    starts[0] = 0                       # leading comments and the docstring go with the first unit
    ends = starts[1:] + [len(lines)]    # run up to the next definition, keeping comments in between
 
    header, units = [], []
    for node, s, e in zip(tree.body, starts, ends):
        seg = "".join(lines[s:e])
        (header if isinstance(node, (ast.Import, ast.ImportFrom)) else units).append(seg)
    if len(units) < 2:
        return [sf]
 
    head = "".join(header)
    head_tokens = estimate_tokens(head)
    chunks, cur, cur_tokens = [], [], 0
    for seg in units:
        t = estimate_tokens(seg)
        if cur and head_tokens + cur_tokens + t > budget:
            chunks.append("".join(cur))
            cur, cur_tokens = [], 0
        cur.append(seg)
        cur_tokens += t
    if cur:
        chunks.append("".join(cur))
 
    return [
        SourceFile(Path(f"{sf.path}#part{i + 1}"), head + c, estimate_tokens(head + c))
        for i, c in enumerate(chunks)
    ]

Here is the same corpus measured before and after splitting, on the Python 3.10.12 standard library, 650 files.

At a 6,000-token budget, the unreachable share drops from 70.6% to 18.0%. Compared with the 0.9% I bought by sorting, it's clear where the work belonged.

The batch count going from 169 to 499 deserves a note, because it looks like a regression. It isn't three times the work. Those original 169 batches only ever covered about a third of the code. The increase is the part that was never billed to you, and never read either.

When you add a cut, add a check for what you're dropping

I got this wrong the first time. My initial version collected only ast.FunctionDef and ast.ClassDef nodes, on the reasoning that a code splitter should collect definitions.

Comparing fragments against their sources is what caught it. Decorators sit on lines above node.lineno, so they disappeared. Module-level constant tables aren't definitions, so they were never picked up at all. Across 170 files, 121 came back with part of their body missing. In a scanning pipeline, silently losing source text means a missed finding arrives as a clean report.

The fix was to define each boundary as "up to the next definition" rather than "the extent of this definition" — that's the ends line above. Running the same check again, the number of files that lost a line went to zero out of 170.

Whenever you add a way to cut something up, add the check that counts what you dropped. Splitting fails quietly, so that extra step is the one I keep.

The remaining 18.0% stays remaining. Those 65 fragments are cases like BaseEventLoop in base_events.py, Popen in subprocess.py, and the entity table in entities.py, where a single definition exceeds the budget on its own. From there you either descend to method-level splitting inside the class, or raise the budget for those few and send them separately. I do the latter. There are few enough of them that handling them carefully turns out cheaper.

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.