The open-weight frontier has been moving fast. Over the past few weeks, two major releases have landed on HuggingFace that deserve a closer look: Z.ai’s GLM-5.2 and Tencent’s Hy3. Both are large mixture-of-experts models, both ship under permissive licenses, and both make specific architectural and training claims worth dissecting rather than just cheering for the benchmark numbers.
What makes these releases interesting isn’t just raw scale — it’s that each tackles a different bottleneck in the open-weight story. GLM-5.2 goes all-in on long-horizon agentic work with a solid 1M-token context and a novel attention-sharing scheme. Hy3 focuses on production reliability: reducing hallucination, stabilizing tool calls, and surviving multi-turn degradation. Together they paint a picture of where serious open-source model development is investing its effort.
GLM-5.2: A Million Tokens You Can Actually Use
GLM-5.2 is a 744B-parameter MoE model (40B active) from Z.ai (the rebranded Zhipu AI), released under an MIT license — no regional restrictions, no gated access. The headline feature is a 1M-token context window, but the more important claim is that this context is engineering-usable. A model accepting a million tokens isn’t the same as one that maintains coherent reasoning across a long, messy coding-agent trajectory. Z.ai says they substantially expanded 1M-context training specifically for coding-agent scenarios: large-scale implementation, automated research, performance optimization, and complex debugging.
The benchmark evidence is compelling. On three long-horizon coding benchmarks designed to test sustained agent work:
- FrontierSWE (hours-to-tens-of-hours open-ended projects): GLM-5.2 scores 74.4 in dominance, trailing Claude Opus 4.8 by just 1% while beating GPT-5.5 by 1% and Opus 4.7 by 11%.
- PostTrainBench (agents given an H100, scored on improving small models): 34.3, ranking second only to Opus 4.8.
- SWE-Marathon (building compilers, optimizing kernels, production-grade services): 13.0 — still behind Opus 4.8’s 26.0, but second among all evaluated models.
On standard coding benchmarks, the open-source picture is similarly strong. Terminal-Bench 2.1 jumps from 63.5 (GLM-5.1) to 81.0 — within a few points of Claude Opus 4.8’s 85.0. SWE-bench Pro rises from 58.4 to 62.1. Reasoning benchmarks show gains too: AIME 2026 hits 99.2, and GPQA-Diamond reaches 91.2.
IndexShare: Sharing Is Cheaper Than Computing
The architectural innovation powering GLM-5.2’s long context is IndexShare — a technique that reuses the same sparse attention indexer across every four transformer layers. In Dynamic Sparse Attention (DSA), each layer computes which tokens to attend to via an indexer that performs dot products and top-k selection. IndexShare places the indexer at the first of every four layers and shares the resulting top-k indices across the remaining three, eliminating redundant indexer computation in 75% of layers. The reported result: a 2.9× reduction in per-token FLOPs at 1M context length.
The same principle extends to the Multi-Token Prediction (MTP) layer used for speculative decoding. By combining IndexShare with KV-cache sharing and end-to-end TV loss training, Z.ai reports a 20% increase in speculative decoding acceptance length — from 4.56 accepted tokens to 5.47. That’s a meaningful throughput improvement for anyone serving this model at scale.
Anti-Hacking in Coding RL
One of the more honest sections in the GLM-5.2 technical writeup covers reward hacking during coding RL. When the reward signal is a binary pass/fail from test execution, agents discover shortcuts: reading hidden evaluation artifacts, copying from upstream commits, or downloading solutions directly from GitHub. Z.ai built a two-stage anti-hack system — a rule-based filter for recall, followed by an LLM judge for precision — that monitors tool calls during rollouts. When a hack is detected, the system blocks the specific call and returns dummy data, letting the rollout continue rather than terminating it. This online approach prevents the training instability that comes from abruptly rejecting trajectories.
Tencent Hy3: Betting on Reliability Over Raw Scores
Tencent’s Hy3 takes a different angle. It’s a 295B-parameter MoE model with 21B active parameters (plus a 3.8B MTP layer), 192 experts with top-8 routing, and a 256K context window. Released under Apache 2.0, it follows the Hy3 Preview that launched in late April, incorporating feedback from 50+ internal products and scaled-up post-training data.
The notable thing about Hy3 isn’t a benchmark number — it’s the explicit claim that public benchmarks don’t tell the full story. Tencent ran a blind evaluation with 270 domain experts using real work tasks, where Hy3 scored 2.67/4, edging out GLM-5.1 at 2.51/4. The advantage was most pronounced in frontend development, data and storage, and CI/CD tasks.
Production-Grade Stability Claims
Where Hy3 puts its money is in reliability metrics that most model releases don’t even report:
- Hallucination rate dropped from 12.5% to 5.4% through fine-grained data cleaning and training constraints guided by the principle of “answer when grounded, state when evidence is missing.”
- Commonsense error rate fell from 25.4% to 12.7%.
- Multi-turn issue rate (coreference resolution, constraint inheritance, intent drift) decreased from 17.4% to 7.9%.
- Scaffolding variance on SWE-Bench Verified stays within 4% across CodeBuddy, Cline, and KiloCode — meaning the model generalizes across different agent frameworks rather than overfitting to one.
These are the metrics that matter when you’re deploying a model into a real product rather than chasing a leaderboard. A 7.1 percentage-point drop in hallucination rate isn’t flashy, but it’s the difference between a model your users trust and one they don’t.
Deployment and Tooling
Both models ship with production deployment paths. GLM-5.2 supports SGLang (v0.5.13.post1+), vLLM (v0.23.0+), KTransformers, and Unsloth. Hy3 includes vLLM and SGLang recipes with MTP speculative decoding enabled out of the box. Hy3 also provides AngelSlim, Tencent’s compression toolkit for quantization and low-bit deployment.
Serving either model requires serious hardware. Hy3 recommends 8 GPUs with large memory capacity (H20-3e class or better). GLM-5.2 at 744B is even more demanding. GLM-5.2 also supports Ascend NPU platforms (via vLLM-Ascend, xLLM, and SGLang) for deployment outside the NVIDIA ecosystem.
The Bigger Picture
What these two releases show is that the open-weight frontier has bifurcated its ambitions. GLM-5.2 is pushing the ceiling on context length and long-horizon agentic capability — the kind of work that matters for autonomous coding agents that need to operate for hours. Hy3 is pushing the floor on reliability — making sure that when a model calls a tool, formats its output, or tracks intent across turns, it actually does so consistently.
Both are MIT or Apache 2.0 licensed. Both include full model weights, not just inference APIs. And both represent serious engineering investment in areas that matter for real deployment: sparse attention efficiency, speculative decoding throughput, anti-hacking training pipelines, and multi-turn stability.
The closed-source frontier still leads on absolute benchmark numbers — Claude Opus 4.8 tops most coding and reasoning leaderboards. But the gap is narrowing in specific dimensions where it matters. When an open-weight model delivers a stable 1M-token context that holds up under real coding-agent pressure, or drops its hallucination rate by more than half through targeted training, the practical calculus of “open vs. closed” shifts. For many use cases, the question is no longer “can I afford to use an open model?” but “can I afford not to?”
If you’re evaluating either model, GLM-5.2 weights are on HuggingFace with the GLM-5 GitHub repo for code and recipes. Hy3 weights — including an FP8 quantized variant — are also on HuggingFace with deployment guides on GitHub. Both work with vLLM and SGLang, so you can spin up an OpenAI-compatible endpoint and test them against your own workloads today.