GLM 5.2

GLM 5.2’s result is interesting because it does not look like a model that is equally good everywhere. It looks like a model with a strong center of gravity. When the benchmark asks for a localized repair, a schema change with obvious tests, or a Python service fix where the failing test points at the right layer, it behaves like a first-place agent. When the task asks it to move a product feature through several packages and keep every consumer aligned, the same model can look surprisingly ordinary.

That is why the rank-1 number is useful, but the shape behind it matters more than the number itself.

The best version of GLM 5.2 shows up in two clusters. The first is Open Library, a large Django-era Python codebase with enough tests and naming convention to reward careful search. GLM 5.2 solved 8/10 tasks in release-zh-013 and 7/10 in release-zh-015; more importantly, 12 of those Open Library tasks were stable enough to pass in all three attempts across the two suites.

The second cluster is ops-shaped code: Ansible modules, inventory behavior, and vuls scanner configuration. These are not trivial tasks, but they tend to expose a narrow invariant. In vuls release 012, the model went 4/4. In one representative task, it had to add Docker image digest support through config structs, validation, and scan-result output. That is exactly the kind of patch where GLM 5.2 can read the tests, find the right seam in the codebase, and finish without inventing a larger product design.

The weak side has a different texture. Flipt asks for product plumbing: authentication methods, feature-flag semantics, storage interfaces, API behavior, and UI-adjacent surfaces have to move together. GLM 5.2 often makes the obvious local edit, then misses a second-order consumer. That is why the Flipt releases sit at 10-40%, with several suites around 1-2 solved tasks out of 10.

qutebrowser and Navidrome are even harsher. qutebrowser release 018 is 0/9, and Navidrome release 017 is 0/5. The qutebrowser failures are not about Python syntax; they are about runtime behavior across QtWebEngine versions, dark-mode settings, URL pattern support, and browser state. Navidrome’s misses are Go service changes that combine schema migration, repository interfaces, and HTTP/Subsonic behavior. In both cases, the patch has to remain coherent after it leaves the first file.

The verifier audit is the main caveat. The headline run reports 140 harness-ok attempts out of 453. Under the stricter re-verification pass, 101 remain verifier-backed, moving the score from 37.59 to 32.87. That does not make the result disposable; it means the right reading is “top-tier, but with a visible brittle band,” not “dominates the suite.”

So if you are choosing an agent, I would treat GLM 5.2 as a strong default for Python services, ops tooling, Ansible-style automation, and localized backend repairs. I would be more cautious when the task is a Go product feature that touches storage, API, auth, and frontend consumers at once, or a browser/runtime integration where the tests encode behavior that is not obvious from static code search.