We use essential cookies to make our site work. With your consent, we may also use non-essential cookies to improve user experience and analyze website traffic…

DeepInfra raises $107M Series B to scale the inference cloud — read the announcement

GLM 5.2 vs Claude Opus 4.8: Pricing the Task, Not the Token
Published on 2026.08.03 by DeepInfra
GLM 5.2 vs Claude Opus 4.8: Pricing the Task, Not the Token

Every GLM 5.2 vs Claude Opus 4.8 comparison lands in the same place. Opus wins most coding benchmarks, GLM costs a fraction as much, pick according to your budget. That framing takes the price cards at face value, but it’s misleading. Price a finished unit of work instead of a million tokens and the gap moves in a direction neither card shows.

The short version, before the evidence.

GLM-5.2 on DeepInfraClaude Opus 4.8
Input / 1M tokens$0.93$5.00
Output / 1M tokens$3.00$25.00
Cached input$0.18$0.50
Context window1,048,5761,000,000
WeightsMIT, openClosed
Wins onOlympiad math, terminal tasksLong-horizon repo work, vision

Output tokens run 8.3 times cheaper. What actually decides your bill is what happens after a task fails.

Why GLM 5.2 vs Claude Opus 4.8 Is a Cost-Per-Task Question

Per-token pricing is what a provider can meter. Tokens are not what you consume. You consume tasks: fix this failing test, refactor this module, extract these fields from ten thousand contracts. A task almost never maps to a single API call.

In agentic coding it runs five to twenty calls, as we walked through in our breakdown of inference economics at scale. The model reads files, proposes a patch, runs the suite, reads the traceback, patches again. Every turn re-sends the accumulated transcript as input and emits fresh reasoning as output. So your real cost per task comes down to three things no price card mentions: how many turns the loop takes, how many tokens each turn drags along, and how often the whole attempt gets thrown away and restarted.

Move any of those three and the ranking flips. A model that is nominally 8 times cheaper but needs 12 attempts has no cost advantage left. One that costs 5 times more but lands the task on the first pass might be the bargain. For anyone running coding agents at scale, that is the only arithmetic that matters.

Where the Quality Gap Is Real

Start by conceding the benchmarks. GLM-5.2 is a 753B-parameter MoE model under an MIT license, and it does not beat Claude Opus 4.8 across the board. On the tasks that most resemble production software work, it loses badly.

Scores below come from the published head-to-head compiled by llm-stats, not from tests we ran.

BenchmarkGLM-5.2Claude Opus 4.8
AIME 202699.295.7
IMOAnswerBench91.083.5
Terminal-Bench 2.1 (best harness)82.778.9
MCP-Atlas76.877.8
FrontierSWE74.475.1
GPQA Diamond91.293.6
SWE-bench Pro62.169.2
NL2Repo48.969.7
SWE-Marathon13.026.0

Read that table in two halves.

On bounded problems, GLM-5.2 holds its own. It takes olympiad math outright, edges Opus on terminal tasks given a good harness, and lands within a single point on MCP-Atlas and FrontierSWE, both of which lean on tool use. A one-point spread is noise. For a large share of what teams ship every day, these two models are interchangeable.

The bottom three rows tell a different story. NL2Repo and SWE-Marathon measure long-horizon tasks, the kind where you hold a large codebase in your head, plan across many steps, and do not lose the thread. Opus roughly doubles GLM on SWE-Marathon and clears it by 20 points on NL2Repo. No harness tweak closes a gap that size. It is a genuine capability difference, and it shows up precisely when the task is big. Any cost argument has to survive both halves of that table.

The Tokenizer Tax Nobody Prices In

Here is the detail every comparison of these two models has missed, sitting in plain sight in Anthropic’s own documentation.

Claude Opus 4.7 and later run on a new tokenizer. Per Anthropic’s pricing page, it “produces approximately 30% more tokens for the same text,” with the exact increase depending on content and workload shape. Anthropic is upfront that this is a deliberate trade. The finer-grained tokenization is part of why the model performs better.

But billing happens per token, and a token has stopped being a fixed quantity of meaning across the two vendors.

Feed the same 40,000-character file to both models. Opus 4.8 charges more per token and counts more tokens to represent the identical input, and the same inflation applies to everything it writes back. Any ratio computed straight from the two cards understates the real spread, because it assumes both models chop text into tokens the same way.

You cannot pin the multiplier down without measuring your own corpus, and we will not invent a number for yours. The direction is unambiguous: on identical text, Opus consumes roughly 30 percent more billable units than a sticker-price comparison implies. In a matchup that already favors open weights on raw price, the tokenizer widens the gap instead of closing it.

GLM 5.2 vs Claude Opus 4.8 on Price

Most write-ups quote GLM 5.2 at Z.ai’s list rate of $1.40 in and $4.40 out. That is not the cheapest place to run it. On DeepInfra the same MIT-licensed weights serve at $0.93 in and $3.00 out, with cached input at $0.18, and the full 1M context window at standard rates. Every ratio below uses the DeepInfra number, the one you would actually pay.

Rate (per 1M tokens)GLM-5.2 on DeepInfraClaude Opus 4.8Spread
Input$0.93$5.005.4x
Output$3.00$25.008.3x
Cached input$0.18$0.502.8x
Batch inputn/a$2.50
Batch outputn/a$12.50
Fast-mode outputn/a$50.00

Output at 8.3x is the row that governs agentic spend, because reasoning models emit far more output than a chat turn would lead you to expect, and every turn of the loop pays that rate again.

The batch rows are the fairest counterargument here. Anthropic’s Batch API halves both sides, bringing Opus to $2.50 in and $12.50 out. If your workload is asynchronous, that is a real 50 percent cut and you should use it. Even so, Opus output still sits at more than 4x GLM-5.2’s standard rate, and batch is off the table for anything interactive, which is most agent work. Our full provider-by-provider breakdown of GLM-5.2 pricing goes deeper on tiers.

The Retry Budget: How Many Failures Can GLM-5.2 Absorb?

Now put quality and price in the same equation. What follows is editorial math, not a benchmark we ran. The inputs are stated so you can swap in your own.

Take one mid-size coding task, run as an agent loop. Say it accumulates roughly 150,000 input tokens across its turns (the transcript is re-sent every turn) and emits roughly 20,000 output tokens of reasoning and patches.

One attempt, at standard rates:

  • GLM-5.2 on DeepInfra: (150,000 x $0.93 + 20,000 x $3.00) / 1M = roughly $0.20
  • Claude Opus 4.8: (150,000 x $5.00 + 20,000 x $25.00) / 1M = roughly $1.25

You can run GLM-5.2 about six times for the price of a single Opus 4.8 attempt. Fold in the tokenizer difference from earlier and the ratio stretches closer to eight.

Now charge each model for its own failure rate. Using SWE-bench Pro pass rates as a rough proxy for first-attempt success, GLM lands 62.1 percent and Opus 69.2 percent, which puts expected attempts per solved task at 1/0.621 and 1/0.692:

  • GLM-5.2: 1.61 attempts x $0.20 = roughly $0.32 per solved task
  • Claude Opus 4.8: 1.45 attempts x $1.25 = roughly $1.81 per solved task

GLM-5.2 is the weaker model here. It fails more often, retries more often, and still finishes about 5.6 times cheaper per task that actually gets solved. The price advantage swallows the quality deficit whole.

That is the argument. It holds right up until it does not.

Where Retries Stop Paying

The retry-budget math rests on one load-bearing assumption: that a failed attempt is a coin flip you can re-toss. Fail, reset the context, try again, land it eventually. True for bounded tasks. It falls apart on long-horizon ones.

Look back at NL2Repo (48.9 against 69.7) and SWE-Marathon (13.0 against 26.0). Those are not runs of bad luck. A model that loses the thread across a 40-step plan will lose it again on attempt two, and on attempt five, because the failure is structural. Retrying a capability gap just buys the same failure at a discount. At a 13 percent success rate you are looking at roughly eight attempts per solved task, and the transcript grows with every one, so the cost curve bends the wrong way exactly when you can least afford it.

The rule of thumb: retries rescue you when failures are independent and bankrupt you when they are correlated. Bounded, verifiable, restartable work (write this function, make this test pass, extract these fields) is where GLM-5.2’s economics are overwhelming. Sprawling refactors across an unfamiliar repo are where Opus 4.8 earns its premium, and where a cheap model that cannot finish costs more than the expensive one.

Some work is out of reach entirely: GLM-5.2 is text-only. If your pipeline reads screenshots, PDFs, or design mockups, the comparison ends right there.

Wiring the Comparison Up Yourself

The policy this points to is simple. Give the cheap model first refusal, and let the expensive one see only what it could not close. The routing ends up worth more than either model alone, the same swappable-backend argument we made for running an open-source coding agent.

GLM-5.2 speaks the OpenAI-compatible API, so first refusal costs you a base URL change:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPINFRA_API_TOKEN"],
    base_url="https://api.deepinfra.com/v1/openai",
)

def attempt(task: str, max_tries: int = 3) -> str | None:
    """Give GLM-5.2 first refusal. Escalate only if it cannot close."""
    for _ in range(max_tries):
        response = client.chat.completions.create(
            model="zai-org/GLM-5.2",
            messages=[{"role": "user", "content": task}],
        )
        patch = response.choices[0].message.content
        if tests_pass(patch):          # your verifier: suite, linter, schema check
            return patch

    return None                        # hand off to the expensive model
copy

The load-bearing line is tests_pass. Retry economics only work when failure is cheap to detect, which makes the router only as good as your verifier. Without an automatic way to tell a bad patch from a good one, every retry just buys another bad patch at a discount.

One more lever. Retry loops re-send a large, mostly identical prefix on every attempt (repo context, system prompt, the failing traceback), which is precisely the shape context caching was built for. At $0.18 per million cached input tokens against $0.93 uncached, a warm prefix cuts the dominant cost term in the loop by roughly 80 percent. The model that retries most is the one caching rewards most. Our GLM-5.2 integration guide walks through the architecture and API setup from here.

Which Path to Choose

The benchmarks say Claude Opus 4.8 is the better model. They are right. The bill says being the better model is worth far less than the price gap assumes. Also right.

  • GLM-5.2 for the bulk of the work. Bounded, verifiable, restartable tasks: test fixes, function-level edits, structured extraction, terminal work. Six attempts for the price of one, an 8.3x output advantage, and a failure rate the savings absorb.
  • Claude Opus 4.8 for the hard tail. Long-horizon repo surgery, multi-hour agent runs, anything with an image in it. No retry budget fixes the NL2Repo and SWE-Marathon gaps.
  • Both, routed. Give GLM-5.2 first refusal, escalate what it cannot close, and pay the premium only where it buys something.

The mistake is treating this as one decision, made once, for everything. It is a per-task routing call, and DeepInfra makes that call cheap: one OpenAI-compatible endpoint, GLM-5.2 live from day one, pay-as-you-go.

Start on the GLM-5.2 model page to see current pricing and fire off a first request. Then tell us where your routing threshold landed. Join us on Discord, reach us at feedback@deepinfra.com, or find us at @DeepInfra.

Related articles
Kimi K2.5 API Benchmarks: Latency, Throughput & CostKimi K2.5 API Benchmarks: Latency, Throughput & Cost<p>About Kimi K2.5 Kimi K2.5 is Moonshot AI&#8217;s flagship open-source reasoning model, released in January 2026. It is a native multimodal agentic model built through continual pretraining on approximately 15 trillion mixed visual and text tokens. The model features a Mixture-of-Experts (MoE) architecture with 1 trillion total parameters and 32 billion activated parameters. Kimi K2.5 [&hellip;]</p>
DeepInfra is now a supported Hugging Face Inference ProviderDeepInfra is now a supported Hugging Face Inference ProviderDeepInfra is officially live as an Inference Provider on the Hugging Face Hub. You can now call DeepInfra-hosted models directly from Hugging Face model pages, through our OpenAI-compatible router (use it with any OpenAI SDK), or via the Hugging Face SDKs in Python and JavaScript.
vLLM vs SGLang: Performance, Features & Deployment ComparedvLLM vs SGLang: Performance, Features & Deployment Compared<p>Somebody on your team read a benchmark post, and now there&#8217;s a ticket to migrate the inference stack. That&#8217;s how most vLLM vs SGLang decisions start. A published test reports a 29 percent throughput gap, the number lands in Slack, and two weeks later you&#8217;re debugging kernel version conflicts at midnight while p99 latency sits [&hellip;]</p>