GLM-5 vs Gemini 3.8 Flash: 41% More Reasoning Tokens at a Higher Output Rate

One model wrote 15% fewer answer tokens and still cost 38% more on the output side. Reasoning is billed at the output rate, it made up 70% of that model's output, and the two output rates are not the same. Here is how to find that line in your own usage record.

AI disclosure — AI-assisted. The 38 API calls behind these measurements were run by the author and the raw logs were reviewed before publication; the prose was drafted with AI assistance. Set the platform disclosure selector to "AI-assisted".

Cover image generated with AI. It restates the two token counts discussed below, not a product screenshot.

1. The line no cost comparison reads

Put two API bills side by side and the conversation goes straight to the total. One number is smaller, so that model is cheaper. The reasoning is never stated because it feels like it does not need to be.

Reasoning tokens break that shortcut in a way that is easy to miss. They are not a separate invoice line. They are counted inside the completion, and the completion is billed at the output rate. So a model that thinks a great deal before answering pays for that thinking at the most expensive rate on the price sheet — and the two models in this comparison do not share that rate.

That matters because output rates vary more than input rates do. In the pair measured here, input rates sit 25% apart while output rates sit 17% apart in the opposite direction. Whoever reasons more is paying the higher of the two.

2. What I ran

Nineteen tasks, six groups: repairing broken code, writing a function from scratch, calling a tool, answering questions about a repository, obeying an output format, and pulling one value out of a long file. Both models went through the same OpenAI-compatible endpoint with identical request settings, one pass per task per model — 38 calls in total, all logged.

The two heaviest tasks asked for a single value inside a large file: a 402-line log and an 883-line module, each capped at six turns. The longest document was roughly 14,000 tokens. Both models publish context limits of 200,000 and 1,000,000 tokens, so this run never came close to either ceiling and says nothing about long-context behaviour.

Both task prompts are written in Chinese, which is the working language of the harness. That is a real limitation and it shows up once, in section 6.

3. Reasoning is billed as output, and the rates differ

Start with what the invoices and the usage records actually say.

Read the last two token rows together. Gemini 3.8 Flash produced more total output and less actual answer. Its visible answer was 15% smaller than GLM-5's, while its output token count was 18% larger, because reasoning took a bigger share of the total: 70% against 58%.

Figure: output tokens split into reasoning and visible answer. Reasoning is billed at the output rate.

Now apply each model's own published output rate:

The output side is where the two bills diverge, and it diverges in the opposite direction from the headline totals. Gemini 3.8 Flash looked 23% cheaper overall, and on the one component that is priced purely by how the model behaves, it was 38% more expensive.

4. The model that wrote less paid more

Split the output bill into the part that is thinking and the part that is the answer.

The last row is the one worth sitting with. Bill only the text the user actually receives, apply each model's own output rate, and the two are the same to four decimal places — a gap of two millionths of a dollar.

Two very different models, reading the same nineteen tasks, charged essentially identical money for the answer itself. Every cent of the difference sat in how long each one thought before producing it.

Figure: the same output billed three ways. Only the visible-answer column is level.

Reasoning also occupies very different shares of the two bills: 22.8% of GLM-5's total and 49.0% of Gemini 3.8 Flash's. Roughly half of what the second model charged went to tokens no reader ever saw.

5. Pulling this out of your own traffic

You do not need a benchmark to check this. The numbers are already in every response; they are just not the numbers most people log.

Reasoning tokens arrive inside the completion details. On an OpenAI-compatible endpoint the shape is:

resp = client.chat.completions.create(
    model="glm-5",
    messages=messages,
)

usage = resp.usage
total_out = usage.completion_tokens
reasoning = getattr(usage.completion_tokens_details, "reasoning_tokens", 0) or 0
visible = total_out - reasoning

# Bill the two halves separately, at the model's own output rate.
OUTPUT_RATE = 3.20 / 1_000_000
print(f"reasoning ${reasoning * OUTPUT_RATE:.6f}  "
      f"answer ${visible * OUTPUT_RATE:.6f}")

flowchart TD
    A["completion_tokens"] --> B["completion_tokens_details<br/>.reasoning_tokens"]
    A --> C["visible answer<br/>= total - reasoning"]
    B --> D["billed at the output rate"]
    C --> D
    D --> E["one invoice line<br/>no separation"]

Two habits follow from this. Log visible = completion_tokens - reasoning_tokens as its own metric from day one, because it is the only output number that describes what your users got. And when you compare two models, compare the answer bill and the reasoning bill separately — the totals can point the opposite way from the components, as they did here.

6. Reasoning budgets are a spend control, not a quality dial

If reasoning is a large share of your output bill, the direct lever is not a cheaper model — it is a smaller reasoning volume on the calls that do not need it.

Two things are worth knowing before you touch that lever.

A reasoning budget set too low does not fail loudly. The model answers anyway, with less deliberation, and the output looks like a normal answer. You will not see it in your error rate; you will see it in a slow drift in quality on the harder tasks, which is exactly the kind of regression that never gets attributed to the config change that caused it.

A budget set too high is invisible in the other direction. It costs money on every call and produces nothing you can point at. In this run the reasoning share differed by 11.5 percentage points between two models on the same nineteen tasks — same prompts, same settings. That spread is not a tuning artefact; it is the models behaving differently, and it means the right budget is model-specific rather than a single number you set once.

The practical move is to pick the ten most expensive calls in your own traffic, log the reasoning split on each, and set the budget at roughly the level the successful calls already use. Then watch the answer bill separately from the reasoning bill, because a budget cut that halves reasoning and doubles retries is a loss disguised as a saving.

7. Where this breaks down

One run. These are single passes over nineteen tasks. The 41% reasoning gap is a measurement from this run, not a property of either model. Treat the direction as informative and the multiplier as provisional.

Small sample. Nineteen tasks means one task is worth more than five percentage points of pass rate. The pass-rate difference between the two models should not be read as a ranking.

Reasoning is not waste. Nothing here says one model reasons too much. On the two tasks that separated them, the extra thinking did not rescue the answer: Gemini 3.8 Flash exhausted its six-turn cap on one of them and returned an empty string with stop_reason: tool_calls, and on the other it returned the right value in the wrong shape. Whether reasoning volume and task success correlate is a different question from whether reasoning is expensive. It is expensive either way.

The prompt language. Both prompts are in Chinese. The format violation above produced Chinese output, which is expected when the instruction is Chinese, but I did not run a second pass in English to isolate the effect. Do not read that failure as language-independent.

Caching and batch were not exercised. Gemini 3.8 Flash offers a cached input rate of $0.075 per million and a batch tier at $0.375 in / $1.88 out. GLM-5 lists cache at $0.20 and no batch tier. Neither was used here, and both can move the result more than the reasoning gap does if your workload fits them.

Prices move. Rates below are per million tokens as published on 2026-10-22, and the Crazyrouter page for GLM-5 shows the same figures as the reference rate rather than a discount. Confirm current rates before you build a budget on them.

8. Key takeaways

• Reasoning tokens are counted inside the completion and billed at the output rate. They never appear as their own line.

• In this run they were 58% of GLM-5's output and 70% of Gemini 3.8 Flash's.

• Gemini 3.8 Flash reasoned 41% more at an output rate 17% higher, so its reasoning cost 65.6% more.

• It also wrote 15% less visible answer — and cost 38% more on the output side overall.

• Billed on the visible answer alone, the two models came out 0.02% apart. The answer is the same price; the thinking is not.

• Log completion_tokens - reasoning_tokens separately, and compare the two halves of the output bill instead of the totals.

FAQ

Are reasoning tokens billed twice? No. They are a subset of completion_tokens, not an addition to it. The invoice charges the output rate once for the combined total. Splitting the two halves is an analysis step, not a second charge.

Which model is cheaper for my workload? The one whose reasoning volume is smaller relative to your answer volume — but only if your output rate gap points the same way. Work the two components separately with your own numbers. A short-answer workload barely notices reasoning; a reasoning-heavy agent loop is dominated by it.

Why did the model that answered less cost more? Because it produced more total tokens. Output is billed per token produced, and tokens the reader never sees are produced all the same.

Does a higher reasoning count mean better answers? Not here. The model with 41% more reasoning tokens passed two fewer tasks and hit a turn cap on one of them. This run is too small to settle that question either way.

Where do I find these numbers? In the response body under usage, inside completion_tokens_details. If your gateway strips that field, you cannot separate reasoning from answer and you are comparing blended totals.