Open-weight models now rival frontier models on coding and reasoning. That shift matters, but not for the reason most people assume. For vulnerability detection, the model was never the bottleneck.
For most of the last two years the assumption was simple. If you wanted serious reasoning over code, you paid for a frontier model. Open weights were for prototypes and side projects. That assumption is now out of date.
In June 2026, three open-weight models shipped within weeks of each other: GLM 5.2 from Z.ai, MiniMax M3, and Kimi K2.7. Each one closed in on the proprietary frontier from a different angle. GLM 5.2 beats GPT-5.5 on several long-horizon coding benchmarks and sits effectively level with Claude Opus 4.8 on long-horizon engineering work. The newer open models are no longer a tier behind. They are close enough that, for most practical work, the difference is hard to feel.
So open models caught up. The more useful question is what that changes for a security pipeline. For us the answer is narrower than swapping in a different model and moving on.
We made this argument once already, from the other end. In our look at Cloudflare's experience with Project Glasswing, the lesson was that even the most powerful security model ever released, Claude Mythos, could not reliably secure a codebase on its own. The architecture around the model decided whether its capability turned into coverage.
The same logic runs in reverse here. Raw model capability was never the real constraint on vulnerability detection. A model handed source files and told to find the bugs produces shallow, noisy results, whether it is a frontier model or an open one. What moves the needle is understanding. Once an agent understands the code and has enough guidance about where and how things break, security analysis becomes much easier, and the raw horsepower of the underlying model matters far less.
This is the gap between what coding benchmarks measure and what security work needs. A benchmark score reflects how well a model reasons over code it has to digest from scratch. Our pipeline removes that part of the problem. It hands the model an already structured view of the code along with a body of knowledge about how vulnerabilities in that language actually get exploited. The task that remains is narrower and better defined, and that is the task where open and frontier models converge.
Our agents do not read code as text. Across the languages we support, which are Solidity, Go, Rust, and JavaScript/TypeScript, they work through more than 100 specialized tools that query the AST, resolve cross-function data flows, trace state mutations, and map inheritance hierarchies. Next to that tooling sits a detection-optimized vulnerability database for each language. It is not generic reference material. It holds exploitation patterns, mitigation strategies, and language-specific attack vectors, organized around the way our pipeline hunts.
That combination changes what a model has to be good at. Instead of holding a whole repository in context and reasoning about it from scratch, the model receives a focused view of the exact code path that matters, together with prior knowledge of how that class of bug gets exploited. The reasoning task is narrower and better posed, and that is where the distance between open and frontier models stops showing up.
It also keeps token use low. We do not spend a model's context rederiving the structure of your codebase on every pass. We extract that once, deterministically, and feed it where it is needed. That efficiency is what lets us run an open model like GLM 5.2 across many agents at once and go deeper on each pass.
The clearest evidence is what we stopped seeing. Once a model is wrapped in our tooling and fed guided, structured context, the choice of model largely washes out. Paired with our pipeline, GLM 5.2 produced work we could not meaningfully separate from frontier models on the same tasks. The structure and the guidance carry the analysis. The model sits on top of it and reasons, and several capable models reason about equally well once the hard part is already done.
This is why "close enough" is the right frame for GLM 5.2. On paper it trails the very top frontier models by a small margin. Inside our pipeline that margin disappears, because the work the margin would have decided is handled before the model ever sees the code.
None of this means we standardize on one model. We deliberately run more than one, because in a few places using different models helps.
Our analysis is a pipeline of agents with distinct roles. The Security Auditor hunts for candidate vulnerabilities. The Exploitability Analyst and Security Reviewer then try to disprove each finding. Running that review on a model different from the one that produced the finding helps. A reviewer that reasons along the same lines as the hunter is more likely to wave through the same weak findings, while a different model is more likely to catch them. The review still works on a single model with a different prompt, which is how Cloudflare ran it on Mythos, but in our experience model diversity adds a useful margin on top.
The takeaway is not that open models are good now, so pick whichever you like. It is that the model is the wrong thing to evaluate. When a vendor leads with the frontier model they wired up, they are advertising the layer that matters least. The questions worth asking are about everything around it.
A tool that gets those right will beat a tool that gets them wrong, even when the second one runs on a top frontier model. We know, because we built ours to depend on the structure and the guidance rather than the model. The open-weight wave is the proof of that choice, not the reason for it.
The convergence of open and frontier models is easy to read as a procurement story. For security tooling built the right way, the bigger effect is on quality. Capable open models let us run more agents, use different models where independence helps, and spend our effort on coverage and understanding rather than on getting a model to parse source text.
The frontier labs will keep raising the ceiling, and we will keep using their models where a task calls for it. But the floor has come up far enough that the interesting question is no longer which model you call. It is how well you help it understand the code, and what you do with what it hands back.
Multi-agent analysis with structured code input and adversarial validation
Get Started