One is four times cheaper per token. The other is twice as fast and scores higher. Neither of those is the number that decides it.
We swapped a support agent from one to the other on a Thursday, expecting the bill to drop by the ratio on the pricing pages. It dropped by about a third of what we projected.
Here is the weird part. The cheaper model was cheaper per token exactly as advertised. It just needed more turns to finish the same job.
The spec sheet, side by side
| MiniMax M3 | GLM 5.2 | |
|---|---|---|
| Released | May 31, 2026 | June 13, 2026 |
| Architecture | MoE, ~428B total, ~23B active | MoE, ~753B total, ~40B active |
| Context | 1M max, 512K guaranteed | 1M, output up to 131K |
| Inputs | Text, image, video | Text only |
| Price (direct, standard) | $0.30 / $1.20 per M | $1.40 / $4.40 per M |
| Cached input | $0.06 per M | $0.26 per M |
| Licence | Custom, commercially restricted | MIT |
| Tool calling | Yes, OpenAI-compatible | Yes, OpenAI and Anthropic-compatible |
Two things in that table matter more than the rest.
M3 takes image and video natively. GLM 5.2 is text in, text out. If your agent reads screenshots or invoices, that decision is already made for you.
And the licences run backwards from the prices. GLM 5.2 ships under MIT, so you can self-host, fine-tune, and ship it commercially with almost no restrictions. M3's weights carry a custom licence with commercial limits. The cheaper API is the more restricted model.

Cost comparison for agent workloads
Per-token rates first, then the part that actually sets your bill.
On Artificial Analysis blended pricing, which weights cache hits, input, and output at 7:2:1, M3 comes in around $0.22 per million tokens against roughly $0.90 for GLM 5.2 in max reasoning mode. Call it a 4x gap.
Now three things that erode it.
GLM 5.2 is verbose. Artificial Analysis flags it explicitly. Verbosity multiplied by $4.40 per million output tokens is a worse combination than the same verbosity at $1.20, so GLM's real cost sits above its headline more than M3's does.
M3 has a cliff at 512K. The moment one request crosses 512,000 tokens, the whole call bills at double: $0.60 input and $2.40 output, cache reads at $0.12. Not the excess portion. The entire request. A 600K-token call costs more than double a 500K one.
GLM 5.2 scores higher, and a retry costs 100%. On the Intelligence Index it lands at 51 against M3's 44. Every task the smarter model completes first time is a task the cheaper model may have to attempt twice, and two cheap attempts beat one expensive attempt only until they do not.
Per-token price is a rate. Per-task cost is a rate multiplied by how many turns you needed. Only one of those appears on a pricing page.
If you want the arithmetic run against a third option, our daily cost breakdown across M3, GLM 5.2 and Claude does exactly that on real task volumes.

Tool calling and function accuracy
Both handle function calling, structured JSON, and streaming. Neither will block you on capability.
The difference is integration surface. GLM 5.2 exposes an Anthropic-compatible endpoint alongside the usual OpenAI-shaped one, which is why more than twenty coding environments picked it up as a drop-in by changing a base URL and a key. M3 is OpenAI and Anthropic-compatible too, but arrived with a narrower tooling ecosystem around it.
On the benchmark side, be careful what you are reading. A lot of the headline tool-calling numbers for both models come from vendor evaluations rather than independent runs. Z.ai published its own suite for GLM 5.2, and a meaningful share of M3's launch figures came from MiniMax's own testing.
The independent number worth anchoring on is the Intelligence Index, which folds in Terminal-Bench v2.1 and a banking-focused agentic evaluation among nine tests. GLM 5.2 in max mode: 51. M3: 44.
For long tool chains that gap compounds, because a wrong tool call at step four does not just cost step four. It costs every step after it.

Speed and latency
GLM 5.2 wins this, and not narrowly.
Head to head on Artificial Analysis, GLM 5.2 in max mode generates around 150 output tokens per second against roughly 76 for M3. Time to first token is close, 1.39 seconds versus 1.46, so the gap is throughput rather than responsiveness.
Median across all providers puts GLM 5.2 near 213 tokens per second, which is unusually quick for an open-weight model of that size.
But read the provider column before you trust any single figure. GLM 5.2 is served by seventeen tracked providers with a 1,064% spread between fastest and slowest. M3 has eight, with a 296% spread. Your provider choice affects speed more than your model choice does.
M3 has an architectural advantage these numbers hide. Its sparse attention design keeps per-token compute at 1M context to roughly a twentieth of the previous generation, with decoding several times faster at full window. At ordinary context lengths GLM is faster. At extreme ones, M3 degrades better.

This is the part where model choice stops being a spreadsheet exercise. On BetterClaw you pick your provider from a dropdown, bring your own key with no markup from us, and swap models on a live agent without touching a config file. Free plan, no card, see what the free tier includes.
Context window in practice
Both advertise 1M tokens. Both mean something slightly different by it.
M3's 1M is a ceiling with a 512K guaranteed minimum, and that maximum counts input and output combined. Independent trackers list its usable context as 512K for exactly that reason. Push past it and you get wider latency variance plus the doubled billing tier.
GLM 5.2 publishes a flat 1M input window with a separate output ceiling of about 131K tokens. That output figure is roughly five times what GLM 5.1 allowed, and it matters if your agent writes long documents or large files in one pass.
Here is what nobody tells you about either. Agent loops fill context without asking permission. Every turn appends tool results and reasoning, so by turn ten or fifteen you are dragging history no single step needed. Then you cross the cliff, and your cheap model is not cheap.
Prune between turns. It is worth more than either model's window.
If you are choosing between these two and Claude rather than just each other, our three-way comparison of GLM 5.2, Sonnet 4.6 and MiniMax M3 covers where a frontier proprietary model still earns its premium.

Which to pick by use case
High-volume, short-context agents. M3. Support triage, classification, routing, enrichment. Thousands of small calls where a 4x rate difference compounds and no single request comes near 512K.
Multimodal agents. M3, by default rather than by merit. GLM 5.2 does not take images.
Long-horizon coding and repository-scale work. GLM 5.2. Higher intelligence score, faster output, an Anthropic-compatible endpoint that drops into existing agent tooling, and a 131K output ceiling for large generations.
Anything you self-host or ship to customers. GLM 5.2, on licence grounds alone. MIT versus a custom commercial restriction is not close, and 40B active parameters against M3's 23B is what that freedom costs you in GPU terms.
Enormous single-request context. M3, if you can live with the doubled tier. Its sparse attention holds up better at the far end of the window than anything at that price.
The honest answer for most teams is both. Route cheap high-volume work to M3, send the hard reasoning and code to GLM 5.2, and stop hunting for one model that wins every row. If you run agents through an OpenClaw-compatible setup, our OpenClaw model comparison covers wiring multiple providers into one agent.
If any of this resonated, give BetterClaw a try. Free plan, one agent, 500 credits a month, no credit card. $49 a month for Pro, $39 on annual. Twenty-eight-plus model providers, BYOK with zero markup so your token bill stays with the provider, and per-agent cost caps so a runaway loop cannot surprise you. Full pricing here.
We picked wrong the first time. Not because we misread the pricing pages, but because we assumed the cheaper model would need the same number of attempts.
The model comparison that matters is not the one on the vendor's site. It is the one you run for a week on your own tasks, counting completions rather than tokens.
Frequently Asked Questions
What is the difference between MiniMax M3 and GLM 5.2?
M3 is a roughly 428B-parameter Mixture-of-Experts model from MiniMax with native text, image, and video input and a 1M-token ceiling, priced around $0.30 per million input tokens. GLM 5.2 is a roughly 753B-parameter MoE model from Z.ai, text only, MIT licensed, priced around $1.40 per million input. M3 is cheaper per token, GLM 5.2 is faster and scores higher on independent testing.
How does GLM 5.2 compare to MiniMax M3 for tool calling?
Both support function calling and structured JSON output. GLM 5.2 has the edge in practice, scoring 51 to M3's 44 on the Artificial Analysis Intelligence Index, which includes agentic and terminal benchmarks. GLM 5.2 also exposes an Anthropic-compatible endpoint, so it drops into existing agent tooling without an SDK rewrite.
How do I switch between MiniMax M3 and GLM 5.2 without rewriting my agent?
Both offer OpenAI-compatible APIs, so a base URL and key change covers most cases. Watch for prompt sensitivity, because reasoning-mode models like GLM 5.2 in max mode often need shorter instructions than you had tuned for a cheaper model. Run both against the same fifty tasks before committing.
Which is cheaper for agent workloads?
M3, on rate. Roughly $0.22 per blended million tokens against $0.90 for GLM 5.2 in max mode. The caveat is that M3 doubles its rate on any single request above 512K tokens, and GLM 5.2's higher accuracy means fewer retries, so per-completed-task cost can land closer than a 4x rate gap suggests.
Are open-weight Chinese models reliable enough for production agents?
On capability, yes. Both are open weights with independently benchmarked performance and multiple Western hosting providers, so you are not obliged to send data to either lab. The real diligence items are licence terms, which differ sharply between these two, and where your chosen provider actually runs inference. Self-host or pick a provider in your jurisdiction if data residency is a constraint.




