GLM-5.2 — built for long-horizon tasks, the whole architecture in plain words.

GLM-5.2 is Z.ai (Zhipu) AI's open-weights flagship: a 744B-parameter Mixture-of-Experts model with only ~40B parameters active per token, a verified 1,000,000-token context window, up to 131,072 output tokens, and a new sparse-attention trick called IndexShare that cuts per-token compute ~2.9× at full context. It is tuned for long-horizon, agentic coding — long sessions where the model must plan, act, and revise over hundreds of thousands of tokens. It ships under MIT, lands within ~1% of Claude Opus 4.8 on FrontierSWE, and costs roughly one-sixth of GPT-5.5. This post explains every one of those pieces in plain language — one read to understand the whole model.

If you only ever read one write-up on GLM-5.2, this is meant to be it. No prior deep knowledge assumed: I explain what a Mixture-of-Experts is, why a million-token window is hard, what "long-horizon" actually means, and how each design choice serves that one goal. Where I give numbers, they come from Z.ai's release and independent coverage — sources are linked at the end.

What GLM-5.2 is, in one paragraph

GLM-5.2 is a large language model from Z.ai (the international brand of Zhipu AI, the Beijing lab spun out of Tsinghua University). It is open-weights — the trained parameters are downloadable and self-hostable under an MIT license, so you can run it on your own GPUs, fine-tune it, and ship it commercially. It belongs to the GLM ("General Language Model") family that runs back through GLM-4.5, GLM-4.6, and GLM-5.1. The 5.2 release is positioned squarely at one job: long-horizon agentic work, especially multi-step software engineering where the model reads a whole repository, plans a change, edits many files, runs commands, reads the errors, and keeps going — sometimes for an hour of wall-clock time and hundreds of thousands of tokens.

The spec sheet at a glance

Property	GLM-5.2	Why it matters
Total params	~744B (MoE)	Big knowledge capacity stored in the weights.
Active params	~40B / token	Only this much actually runs per token — keeps it cheap and fast.
Context window	1,000,000 tokens	Load a full codebase plus a long conversation at once.
Max output	131,072 (128K) tokens	Can write a very long answer / many file edits in one go.
Attention	Sparse + IndexShare	Makes the million-token window affordable.
Thinking	reasoning_effort: low / medium / max	You dial how hard it "thinks" per task.
License	MIT (open weights)	Self-host, fine-tune, commercial use allowed.
Extras	Tool calling, JSON output, MCP, context caching, SSE streaming	Everything an agent framework needs.

Notice the gap between 744B total and 40B active. That ~18× ratio is the headline of the whole design, and it is the first thing to understand.

Keep one framing in mind for the rest of this post: nearly every choice in GLM-5.2 is an answer to the same question — "how do we run a marathon without the bill exploding?" A short answer is easy; a model only has to be smart once. A marathon is hard because it multiplies every cost by the number of steps. So the design attacks cost from three angles at once — how much compute each token costs (MoE), how far each token has to look (sparse attention), and how expensive the looking-machinery itself is (IndexShare). Hold that lens and the spec sheet stops being a list of numbers and becomes a single coherent strategy.

Mixture-of-Experts — a big brain that only wakes a small part

A traditional ("dense") transformer uses every parameter for every token. A 744B dense model would be brutally expensive: every single word you process drags all 744 billion numbers through the math. Mixture-of-Experts (MoE) breaks that link.

In an MoE model, the big feed-forward block of each layer is split into many smaller sub-networks called experts. A small router (a tiny network) looks at each token and picks just a handful of experts to handle it — say the top 8 out of hundreds. Only those chosen experts run. So the model stores knowledge across all 744B parameters, but for any one token it only uses about 40B of them.

Why does this matter for long-horizon work specifically? Because long sessions burn enormous numbers of tokens. If every token cost the full 744B of compute, a one-hour agent run would be unaffordable and slow. MoE keeps the per-token cost near a 40B-class model while keeping the knowledge of a 744B-class model. You get the smarts without paying the marathon-length bill.

The catch with MoE

MoE is not free magic. The router can route badly — sending tokens to the wrong experts, or overloading a few popular experts while others starve (the "load-balancing" problem). And because all 744B parameters must be held in memory even though only 40B run, you need a lot of GPU RAM to host the model even if compute is cheap. Training has to include extra balancing objectives so experts specialize cleanly and the load spreads evenly. GLM-5.2's strong benchmark showing suggests Z.ai got this balance right at very large scale.

The 1,000,000-token context window — and why it's hard

Context window = how much text the model can "see" at once: your prompt, the conversation history, retrieved documents, the whole codebase — all of it. GLM-5.2's window is one million tokens, roughly 5× its predecessor GLM-5.1's ~200K, and Z.ai calls it verified lossless, meaning the model actually uses the far end of that window instead of quietly forgetting it.

That "lossless" claim is the important part, and to see why you need to know the dirty secret of long context: most big windows degrade. A model may advertise a huge window but in practice "lose the middle" — it pays attention to the start and end of the input and goes fuzzy on everything in between. A nominal 1M window that forgets tokens 300K–700K is nearly useless for agent work, because the file you edited 20 minutes ago is sitting right in that forgotten middle.

Why long context is expensive: attention scales badly

The reason windows don't just grow for free is attention, the mechanism that lets every token look at every other token. In plain dense attention, if you have N tokens, the model computes roughly N × N relationships. Double the tokens, quadruple the work. At 1,000 tokens that is a million comparisons — fine. At 1,000,000 tokens it is a trillion comparisons per layer, per step. That quadratic blow-up is why naive long context is a non-starter; you cannot afford full attention over a million tokens.

IndexShare — the trick that makes a million tokens affordable

GLM-5.2 does not use full dense attention. It uses sparse attention: instead of every token attending to every other token, each token attends to a carefully selected subset — the tokens most likely to matter. The component that decides "which tokens matter for this one" is called an indexer (sometimes a "lightning indexer"). It scores candidate tokens and keeps only the top ones, so the heavy attention math runs over a small set instead of all million.

The clever new piece in GLM-5.2 is IndexShare. Running an indexer is itself work, and doing it independently in every layer is wasteful. IndexShare reuses the same indexer's selection across every four sparse-attention layers instead of recomputing it each layer. Because nearby layers tend to want the same tokens anyway, sharing the index across a group of four barely hurts quality but removes a big chunk of the bookkeeping. Z.ai reports this cuts per-token compute by about 2.9× at the full 1M-token length.

What "built for long-horizon" actually changes

Plenty of models can answer a hard question. Long-horizon ability is different and rarer: it is the skill of staying coherent and goal-directed across many dependent steps. Three concrete design choices in GLM-5.2 serve this directly.

1. Enough room to never "page out" the task

A full code repository is typically 200K–400K tokens. With a 1M window, GLM-5.2 can load the entire repo and still leave 600K+ tokens of headroom for the running conversation: the plan, the diffs it has made, the commands it ran, and the test output it read back. It never has to drop the codebase from memory to make room for the dialogue. On a 200K-window model, loading a 350K repo is simply impossible — you are forced into retrieval tricks (fetch a few files at a time) that lose the global picture. Long-horizon agents fail most often because they forgot context they needed; a window this large removes that failure mode for most real projects.

2. A 128K output so it can act, not just answer

Most models cap output at a few thousand tokens. An agent doing real work needs to emit a lot: long reasoning, multiple full-file rewrites, a batch of tool calls. GLM-5.2's 131,072-token output ceiling means it can produce a sweeping multi-file change in a single turn instead of being chopped off and forced to stitch fragments together across turns (where state gets lost). Big input window + big output window is what lets a single turn carry a meaningful chunk of a marathon.

3. Selectable thinking effort

GLM-5.2 exposes a reasoning_effort control with three levels. This is how you trade thinking depth against speed and cost per call:

reasoning_effort	Use it for	Behaviour
low	Fast, cheap, simple tasks	Minimal internal reasoning, quick turnaround.
medium	General-purpose coding	Balanced thinking vs. cost.
max	Complex multi-step coding	Deep planning and revision across long sequences — the long-horizon setting.

The model "thinks" by generating internal reasoning tokens before its final answer. Z.ai reports an average of ~43,000 tokens per task with ~37,000 of those being reasoning tokens — meaning on hard tasks the vast majority of the work is private deliberation, and only a small slice is the visible answer. That ratio is the signature of a model built to plan, not just respond. The max setting leans into it for marathon problems; low turns it off when you just need a fast edit.

The agent toolkit: tools, MCP, JSON, caching, streaming

A long-horizon coding model is useless if it cannot act on the world. GLM-5.2 ships the full set of agent primitives:

• Function / tool calling — the model can emit a structured request to call a tool (run a shell command, read a file, query an API), get the result back, and continue. This is the loop that turns a chatbot into an agent.
• MCP support — it speaks the Model Context Protocol, the emerging standard for plugging models into external tools and data sources. An MCP-aware agent framework can wire GLM-5.2 to your tools without custom glue.
• Structured output (JSON) — it can be forced to return valid JSON matching a schema, so your code can parse its answers reliably instead of scraping free text.
• Context caching — if you reuse the same big prefix (e.g. the whole repo) across many calls, the cached part is billed far cheaper ($0.275 vs $1.10 per 1M input tokens). For agents that hammer the same context repeatedly, this is a large real-world saving.
• SSE streaming — tokens stream out as they are produced, so a UI or tool runner can react mid-generation instead of waiting for the whole answer.

How good is it? The benchmarks

GLM-5.2's pitch is "near the closed-source frontier, at open-source prices." The numbers back a strong version of that claim, especially on the long-horizon coding benchmarks it was built for.

Benchmark	GLM-5.2	What it measures
FrontierSWE	74.4% — ~1% behind Claude Opus 4.8, ~1% ahead of GPT-5.5	Hard real-world software-engineering tasks.
SWE-Marathon	~13% behind Opus 4.8	Very long multi-step engineering "marathons."
Terminal-Bench 2.1	81.0	Operating a real terminal to get things done.
AIME 2026	99.2	Competition-level math reasoning.
Code Arena	Ranked 1st globally	Head-to-head human-judged coding preference.
Intelligence Index v4.1	51	Aggregate cross-domain capability score.
GDPval-AA v2	1524	Economic-value-weighted task suite.

Read these carefully rather than as a leaderboard. The headline is FrontierSWE within ~1% of Claude Opus 4.8 — an open model landing a hair behind the strongest closed coding model. But notice SWE-Marathon, ~13% behind Opus: on the very longest marathons the closed frontier still pulls ahead. So GLM-5.2 is frontier-competitive on hard coding and excellent on terminal/math, with the last gap showing up only on the most extreme long runs. For most teams that gap is dwarfed by the price difference.

Price — the part that changes the decision

Capability near the frontier is only half the story; the other half is that GLM-5.2 reportedly costs about one-sixth of GPT-5.5 per token. Representative API pricing:

Token type	Price / 1M tokens
Input	$1.10
Cached input	$0.275
Output	$3.851

Two things make this even cheaper than it looks for long-horizon work. First, cached input at $0.275 means the repeated repo prefix is billed at a quarter of the normal input rate. Second, because the weights are open under MIT, you are not locked to any provider's API at all — you can self-host on your own GPUs (you do need enough VRAM to hold all 744B parameters) and pay only for the hardware. For a high-volume agent product, the ability to take inference fully in-house is often worth more than the per-token rate.

GLM-5.2 vs GLM-5.1 and the frontier

Dimension	GLM-5.1 (prev)	GLM-5.2
Context	~200K	1,000,000 (verified lossless)
Focus	5.1-HighSpeed emphasized throughput (~400 TPS)	Context depth + long-horizon coherence
Attention	Sparse	Sparse + IndexShare (~2.9× cheaper at 1M)
Output	128K	128K (kept)
Coding	Strong	FrontierSWE ~1% behind Opus 4.8

The jump from 5.1 to 5.2 is not a "smarter on a single prompt" upgrade so much as a "can sustain a marathon" upgrade: 5× the window, lossless recall deep into it, and the IndexShare efficiency that makes operating at that length practical. Where 5.1-HighSpeed chased raw tokens-per-second, 5.2 chose to spend the engineering budget on depth and coherence instead.

How you actually call it

GLM-5.2 is reachable through Z.ai's BigModel API (OpenAI-compatible) and through partner clouds; the model id is glm-5.2. A minimal call sets the context, picks an effort level, and lets it stream:

POST https://open.bigmodel.cn/api/paas/v4/chat/completions
{
  "model": "glm-5.2",
  "reasoning_effort": "max",        // low | medium | max
  "stream": true,                    // SSE streaming
  "messages": [
    { "role": "system", "content": "You are a coding agent." },
    { "role": "user", "content": "<... whole repo + task ...>" }
  ],
  "tools": [ /* function specs the agent may call */ ]
}

Because the endpoint is OpenAI-compatible, most existing agent frameworks (and OpenAI-style SDKs) work by just changing the base URL, the model name, and adding reasoning_effort. The same model is also exposed through OpenAI-compatible routes on partner platforms, so dropping it into an existing coding-agent stack is usually a config change, not a rewrite.

Who should care, and when

• Agent / coding-tool builders — this is the target user. Full-repo context, big output, tool calling, MCP, and cheap cached input are exactly the primitives an autonomous coding agent needs.
• Teams cost-bound on a closed model — if you are paying frontier prices for SWE-style work, near-frontier quality at ~1/6th the cost (or fully self-hosted) is a serious lever.
• Researchers — open MIT weights at this scale are rare. You can probe MoE routing, sparse-attention behaviour, and long-context recall directly instead of guessing at a black box.
• Privacy/sovereignty-bound deployments — self-hostable weights mean data never leaves your infrastructure.

When not to reach for it: if your tasks are short and latency-critical, a smaller model is cheaper and snappier; the million-token machinery is wasted. And if you cannot host ~744B parameters and need the absolute top of SWE-Marathon, the closed frontier still has a slim edge.

Limitations and what's still unknown

An honest write-up names the gaps. A few things about GLM-5.2 are not public, and a few are genuine trade-offs rather than wins.

Undisclosed internals. Z.ai has published the headline architecture (744B MoE, ~40B active, sparse attention with IndexShare) but not the fine print: the exact number of experts, how many fire per token, the precise sparse-attention window sizes, the training-data composition, or the post-training recipe (the supervised fine-tuning and reinforcement-learning steps that turn a raw pretrained model into a helpful agent). Open weights are not the same as an open training pipeline — you can run and study the model, but you cannot fully reproduce how it was made from the release alone.

Memory cost is real. MoE saves compute, not memory. All 744B parameters must sit in GPU memory to be routable, even though only ~40B run per token. So self-hosting needs serious hardware — a multi-GPU box with enough combined VRAM to hold the full parameter set. "Open weights" does not mean "runs on a laptop." For many teams the practical deployment is still a hosted API, which softens the sovereignty advantage.

Reasoning tokens are billed tokens. The same deep deliberation that makes GLM-5.2 strong on long-horizon tasks (~37K reasoning tokens on a hard problem) is output you pay for. On easy work that is waste; that is exactly why reasoning_effort: low exists. Pick the effort level deliberately — leaving everything on max turns a cheap model into an expensive one.

The marathon gap. The ~13% deficit on SWE-Marathon is the one place the closed frontier still clearly leads. For the longest, most tangled multi-hour engineering runs, Claude Opus 4.8 holds an edge. GLM-5.2 narrows the gap dramatically and wins on price, but "near-frontier" is not "frontier" at the extreme tail — set expectations accordingly for your hardest workloads.

Benchmarks are a snapshot. All numbers here come from launch-window reporting. Benchmarks get gamed, re-run, and contested; independent re-evaluation over time is what settles a model's real standing. Treat the scores as a strong directional signal, not gospel, and — as always — measure on your tasks before committing.

The whole thing in one breath

FAQ

Is GLM-5.2 really open source?

The weights are released under MIT — you can download, self-host, fine-tune, and use them commercially. You do need substantial GPU memory to hold all 744B parameters even though only ~40B run per token.

Does the 1M context actually work, or is it a marketing number?

Z.ai calls it "verified lossless" and reports coherence held across an 850K-token live coding session — meaning it could still recall and act on context from hundreds of thousands of tokens earlier, which is the real test most large windows fail.

What is IndexShare in one sentence?

Compute which tokens matter (the sparse-attention "index") once and reuse that selection across every four layers instead of recomputing it each layer — about 2.9× less per-token compute at full context with little quality loss.

How is it different from a normal big model?

Mixture-of-Experts: it stores 744B parameters but only runs ~40B per token by routing each token to a few specialist experts — frontier-scale knowledge at a fraction of the per-token compute.

Is it better than Claude Opus 4.8 or GPT-5.5?

On FrontierSWE it's ~1% behind Opus 4.8 and ~1% ahead of GPT-5.5, and it ranks 1st on Code Arena. On the longest SWE-Marathon runs Opus still leads by ~13%. So: frontier-competitive on most coding, with the closed frontier holding a slim edge on the very longest marathons — at roughly 1/6th the cost.

References & extra reads

• VentureBeat — GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6th the cost · benchmarks & pricing
• TheRouter.ai — GLM-5.2: 1M context, 128K output, coding routing · context & agent features
• Qubrid AI — GLM-5.2 complete technical deep dive · params, reasoning effort, pricing
• The Decoder — GLM-5.2 closes in on closed-source leaders in coding marathons · SWE-Marathon framing
• LimaxAI — GLM-5.2 intro: built for coding and long-horizon tasks · IndexShare overview
• DataNorth — Zhipu AI releases GLM-5.2 open-weight model · release summary