GLM-5 vs Claude Sonnet 5: cost comparison

Quick answer: GLM-5 is cheaper per token, until a retry eats the discount.

GLM-5 and Claude Sonnet 5 overlap on a lot of use cases, long-context assistants, coding help, general reasoning, at very different price points. At current catalog rates, GLM-5 runs $0.514 per million input tokens and $2.314 per million output tokens. Claude Sonnet 5 runs $1.60 per million input and $8.00 per million output, roughly three times the per-token rate on both sides. That per-token gap is where most comparisons stop, and it is a real number. What it leaves out is that GLM-5 is a reasoning model: before it writes a visible answer, it can spend a large chunk of your max_tokens budget on internal reasoning tokens that are billed as output but never shown to the caller. Set max_tokens too tight on a reasoning-heavy prompt and the call can hit finish_reason=length with an empty visible answer, which means a wasted call followed by a second, paid retry. Claude Sonnet 5's default responses do not carry that same hidden-token overhead, so a similarly tight budget more often lands on a complete answer in one call. The rest of this page works through where that difference actually shows up in a bill, with token math for three realistic request shapes and a side-by-side of both models' catalog prices.

Where the money actually goes: visible output vs reasoning tokens

The practical failure mode looks the same across most reasoning models, GLM-5 included: a prompt that needs real multi-step reasoning gets a modest max_tokens cap, the model spends most or all of that cap thinking through the problem, and the response comes back with finish_reason=length and an empty or truncated visible answer. The call still bills at full price. From there you either retry at a higher cap, paying for the wasted tokens plus the second call, or ship an incomplete answer. Claude Sonnet 5 can also hit a max_tokens ceiling, but its default responses (extended thinking off) do not carry the same hidden reasoning-token tax, so the same nominal budget more often lands on a complete, visible answer in one call. That mechanic is what drives the worked numbers below.

• Visible output: the words, code, or JSON the caller actually reads. This is what most people picture when they hear "output tokens."
• Reasoning tokens: internal step-by-step working a reasoning model generates before it commits to a visible answer. Providers bill these as output tokens even though the caller never sees them directly.
• finish_reason: tells you why generation stopped. stop means the model finished on its own; length means it hit the max_tokens cap, which can happen mid-reasoning with zero visible content produced.
• completion_tokens: the total output token count charged for the request, reasoning and visible content combined. This is the number on the bill, not the character count you can actually read in the response.

Worked example: what three real request shapes actually cost

The token counts below are illustrative, built from how reasoning-token billing behaves on request shapes teams actually run, not a live benchmark. Your own completion_tokens and reasoning_tokens will vary with the prompt, but the pattern holds: a well-budgeted call favors GLM-5's per-token discount, and an under-budgeted reasoning call can erase it.

Why GLM-5's price tag doesn't always win

The sticker price is only the starting point. What the cheaper model does to your retry rate and review time decides whether the saving is real.

• A cheap per-token rate multiplies against however many tokens the request actually burns. Reasoning tokens can run several times the length of the visible answer on a hard prompt, so token count, not just the rate, decides the bill.
• finish_reason=length is not a soft warning. It means you paid full price for output that stopped mid-thought, and if the visible answer is empty you still owe for every reasoning token that led up to the cutoff.
• Retrying at a higher max_tokens does not refund the first call. The two calls stack, so a workload that retries often on a reasoning model can end up costing more per completed answer than a single steady call on a pricier one.
• Batch jobs hide this pattern. An average cost-per-request number can look fine while a meaningful share of individual calls are wasted length-cutoffs mixed in with cheap successful ones.
• Context window is a separate limit from max_tokens. A 200K window and a 1M window both cap how much conversation history fits, not how many tokens a single response is allowed to spend reasoning before it answers.

GLM-5 vs Claude Sonnet 5, side by side

Claude Sonnet 5's catalog price sits 20% below its official list rate, the standard discount applied to global models here. GLM-5, a Chinese model, comes in about a tenth below its own official rate. Both discounts are already reflected in the input and output prices below.

How to budget and route between GLM-5 and Claude Sonnet 5

None of this requires picking one model forever. The cheaper rate and the retry risk both sit on GLM-5's side of the ledger, so the workloads worth routing to it are the ones where you can set a generous max_tokens up front and an occasional retry is cheap to absorb: batch jobs, background summarization, high-volume coding tasks. Keep Claude Sonnet 5 for calls where one steady response matters more than shaving a fraction of a cent.

• Set max_tokens with real headroom on reasoning-heavy prompts. A cap sized for the answer you expect from a non-reasoning model is usually too tight for GLM-5; give it two to four times that before concluding it is expensive.
• Check finish_reason on every response, not just the ones that look wrong. A finish_reason of length paired with little or no visible content is a wasted call, not a slow success.
• Log completion_tokens per request, and reasoning_tokens if your provider exposes it, before scaling a workload from a handful of test calls to production volume. Averages hide a tail of expensive retries.
• Keep a non-reasoning-heavy model as the default for latency-sensitive interactive traffic, where a truncated answer costs more in a bad user experience than a slightly higher per-token rate costs in dollars.
• Point both model IDs at the same OpenAI-compatible endpoint, such as APIsRouter's /v1/chat/completions, so you can A/B glm-5 against claude-sonnet-5 on identical prompts without maintaining two SDKs or two billing dashboards.
• Cap retries at one. If a reasoning-heavy call still comes back truncated after a generous second budget, the prompt shape is the problem, not the max_tokens number, and further retries just add to the bill.

Config example: call both models from one endpoint

Both model IDs sit behind the same OpenAI-compatible chat completions endpoint, so switching between them is a one-line change, not a new integration. Set max_tokens generously on the GLM-5 call, since that is the side where a tight budget causes truncated, wasted requests, and check finish_reason on the response before trusting completion_tokens as the whole story.

curl https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer sk-APIsRouter-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5",
    "messages": [{"role": "user", "content": "Work through this step by step and give a final answer."}],
    "max_tokens": 4000
  }'

FAQ