Speaking of vulnerability task, my current view is that the right framing is discovery -> fixing, not “can one open model replace Opus everywhere.”
Discovery is the expensive part because it has to search broadly across a codebase. Fixing / patching is narrower once the relevant area is identified, so it is much more plausible to spend frontier-model dollars there.
Aisle’s earlier point was that the moat is the system / scaffold, not just the base model. (AISLE1) Their new post strengthens that materially: they now describe a public whole-codebase scanner, nano-analyzer, that scans files independently in three stages — context generation, vulnerability scan, and skeptical triage with grep plus an arbiter — and they report that it can replay the flagship Mythos FreeBSD bug and surface new real bugs from full-kernel scans. (AISLE2)
This also matches Anthropic’s own description more than people initially assumed. In the Mythos post, Anthropic says they used the same simple agentic scaffold as their earlier vuln-finding work: launch a container with the target project, invoke Claude Code with Mythos, let it read code and experiment, rank files by how likely they are to contain interesting bugs, run agents in parallel on different files, and then do a final validation pass on candidate bug reports. (Red Anthropic)
So the practical architecture I’d suggest is:
-
Discovery: a specialized but relatively simple harness using a cheaper model, because this is where token burn is highest.
-
Fixing / verification: once the relevant area is localized, escalate to a stronger coding agent / model like Codex or Claude Code, and if needed a frontier model for harder reasoning, because patching should consume much less total context/tokens than discovery.
For the discovery harness itself, the best public starting point is now probably Aisle’s nano-analyzer rather than inventing everything from zero. Their repo is public, but they are also clear it is a research prototype, biased toward C/C++ memory-safety bugs, with false positives, false negatives, and single-file analysis limitations. So I would treat it as the best v0 baseline, not a complete production system. (GitHub)
If we want to improve beyond that, the main public design reference I’d borrow from is VulnLLM-R. Their scaffold applies the model function-by-function, gives it initial context from three sampled call paths from entry points to the target function, and lets it retrieve function implementations by name on demand. The paper explicitly says this kind of context is important because without it the model adds both false positives and false negatives. (arXiv)
On model choice: from Aisle’s public results, GPT-OSS-120B looks like the strongest open model among the ones they tested in this harness. My own guess is that GLM-5.1 may still be stronger if Chinese models are allowed. (AISLE2). They cost >10x cheaper than Opus.
So the clean recommendation is:
Do not frame this as “replace Opus with one fine-tuned open model.”
Frame it as: use a cheap discovery harness + cheaper model for broad search, then use a stronger model only for the much smaller set of fixing / verification tasks. The public evidence now points pretty strongly to the harness / targeting / triage loop being a major part of the value.