GLM-5.2 vs Claude Fable 5: Why Output Budget Changed the Benchmark

GLM-5.2 vs Claude Fable 5: Why Output Budget Changed the Benchmark#

The short version: this test did not show that glm-5.2 cannot reason. It showed something more operationally important.

GLM-5.2 solved the reasoning tasks after the output budget was raised.
Claude Fable 5 was more efficient under the original token budgets.
For long runnable code, Claude Fable 5 completed the task after a larger max_tokens setting, while GLM-5.2 still truncated at 8000.

That distinction matters. In production, a request can return HTTP 200 and still be unusable if the visible response body is empty, if the response stops with finish_reason=length, or if a generated HTML file is not actually closed and runnable.

This benchmark was run through the Crazyrouter OpenAI-compatible API. The goal was not to declare a permanent winner. The goal was to find what a developer should log before trusting a model comparison.

Test context:

Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Test date: 2026-07-06
Models:
- glm-5.2
- claude-fable-5
temperature: 0.2

You can run the same style of OpenAI-compatible requests through Crazyrouter:

https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=model_compare_series_20260706&utm_content=glm52_fable5_en

Why This Test Used Three Task Types#

Many model comparisons are too easy to game. If you only ask multiple-choice questions, you mostly test short-form recall and formatting. If you only ask coding prompts, you may confuse output length with coding skill.

This benchmark used three task types:

The third task is especially useful because it forces the answer to become a real artifact. A model can sound convincing in a code block and still fail if the HTML is cut off before </html>.

Model Availability Check#

Before testing, the model list was checked through the platform. Both models were available through OpenAI-compatible usage:

A minimal request looks like this:

curl https://cn.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [
      {
        "role": "user",
        "content": "A fair coin is flipped until HH first appears. Derive the expected number of flips using states."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 3200
  }'

To compare against Claude Fable 5, keep the same request and change only the model field:

{
  "model": "claude-fable-5"
}

API URLs should not include UTM parameters. Registration and article links can.

Task 1: Expected Flips Until HH#

The math task:

Flip a fair coin until the first occurrence of two consecutive heads, HH.
1. Find the expected number of flips.
2. Derive it using state equations or recursion.
3. Explain in one sentence why the answer is not 4.

The reference solution is:

E0 = 1 + 1/2 E1 + 1/2 E0
E1 = 1 + 1/2 * 0 + 1/2 E0
E0 = 6

The first run looked surprising:

The key point is that the original glm-5.2 response was not a wrong derivation. It had no visible derivation. Almost the entire completion budget was consumed as reasoning tokens.

After increasing max_tokens to 3200, glm-5.2 returned the correct state equations and the correct answer, 6.

Practical takeaway:

For glm-5.2, low visible output does not always mean low reasoning ability.
It may mean the output budget was consumed before the final answer became visible.

Claude Fable 5 was more direct on this task. It completed within the original 1600-token budget and gave the expected derivation.

Task 2: Bullet, Block, Spring, and Friction#

The physics task:

A bullet with m = 0.02 kg and v = 300 m/s embeds into a stationary block.
The block has M = 1.98 kg and is attached to a spring with k = 800 N/m.
The surface has kinetic friction coefficient 0.10. Use g = 9.8 m/s^2.
Find the common velocity after collision and the maximum spring compression.
Explain where momentum conservation applies and where energy accounting applies.

The reference result:

Collision:
mv = (M + m)V
V = 3.0 m/s

Compression stage:
1/2(M + m)V^2 = 1/2kx^2 + friction work
9 = 400x^2 + 1.96x
x = about 0.148 m

Observed results:

This task made the pattern clearer:

At max_tokens=1800, glm-5.2 returned HTTP 200 but no visible answer.
At max_tokens=3600, the main calculation became visible but the response still ended by length.
At max_tokens=8000, the answer completed naturally.

The completed glm-5.2 answer correctly separated the two stages:

Momentum is conserved only during the short inelastic collision.
Mechanical energy is not conserved during the collision.
After the collision, the moving block-bullet system loses kinetic energy to the spring and to friction.

Claude Fable 5 gave the correct result under the original budget and also pointed out the large kinetic energy loss during the inelastic collision:

Before collision: 900 J
After collision: 9 J
Energy lost in collision: 891 J

Practical takeaway:

Both models can solve the physics.
Claude Fable 5 used fewer output tokens.
GLM-5.2 needed a larger budget before the answer became complete and visible.

Task 3: A Complete Canvas Animation#

The coding task asked for a single self-contained HTML file:

800x500 canvas
central star
at least five orbiting particles
requestAnimationFrame animation loop
semi-transparent trails
pause/resume button
reset button
speed slider
FPS and speed HUD
functions named init, update, draw, animate
no external libraries, images, or network requests

This task is intentionally different from the math and physics tasks. A partial answer is not enough. The file has to run.

Original Run: max_tokens=3200#

At 3200 tokens, neither model delivered a usable final file.

The difference was in the failure mode. glm-5.2 produced no visible HTML because the response budget was mostly spent on reasoning tokens. Claude Fable 5 produced a plausible HTML fragment, but it was truncated.

That is why this benchmark does not score partial code as success.

Retest: max_tokens=8000#

The glm-5.2 retest produced a visible HTML file of around 6908 characters, but it still stopped inside JavaScript:

grad.addColorStop(1, 'rgba

There was no closing </html>. That makes it an incomplete artifact, regardless of whether the beginning of the file looks promising.

Claude Fable 5 completed the file at 8000 tokens. Browser validation found:

console errors: none
canvas: 800x500
buttons: pause and reset
range slider: present
changedPixels after 700ms: 55090
hasAnimation: true

Practical takeaway:

For a long, runnable, single-file artifact, Claude Fable 5 was more reliable in this test.
GLM-5.2 still truncated at max_tokens=8000.

The Scorecard That Actually Matters#

A simple "which model won" framing hides the important operational details.

Manual evaluation from this specific run:

The ratings are not universal model grades. They are task-specific results under the recorded settings.

What Developers Should Log#

If you use glm-5.2 or any model with visible and hidden token behavior, do not stop at HTTP status.

Log at least:

{
  "model": "glm-5.2",
  "max_tokens": 3200,
  "finish_reason": "length",
  "completion_tokens": 3200,
  "reasoning_tokens": 3178,
  "visible_content_chars": 0,
  "html_closed": false,
  "browser_validation": "not_run_incomplete_html"
}

The most dangerous case is:

HTTP 200
finish_reason=length
completion_tokens reached the budget
reasoning_tokens consumed most of the budget
visible content is empty or incomplete

That can look like a successful API call in a dashboard while being useless to the end user.

When to Use Which Model Based on This Test#

For short or medium reasoning tasks:

GLM-5.2 can work, but give it enough output budget and log reasoning_tokens.
Claude Fable 5 was more compact and stable under lower budgets in this run.

For long code generation:

Do not trust a code block until the artifact is complete and executed.
Check for closing tags, syntax validity, console errors, and visible runtime behavior.

For API routing and production use:

Treat max_tokens as part of the benchmark configuration.
Treat finish_reason as part of the result.
Treat browser or runtime validation as mandatory for generated code.

You can test both models behind an OpenAI-compatible interface through Crazyrouter:

https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=model_compare_series_20260706&utm_content=glm52_fable5_en_bottom

Final Takeaway#

This benchmark is less about brand-level model ranking and more about evaluation discipline.

glm-5.2 did not fail the reasoning tasks once the output budget was raised. It did, however, show a repeated pattern where reasoning_tokens consumed most of the completion budget, leaving little or no visible answer under the original settings.

claude-fable-5 was more direct on the math and physics tasks, and it delivered the complete Canvas animation file after max_tokens was raised to 8000.

The practical conclusion:

For reasoning: GLM-5.2 is usable, but budget-sensitive.
For low-budget responses: Claude Fable 5 was steadier in this run.
For long runnable code: Claude Fable 5 was clearly stronger in this test.
For future comparisons: always record max_tokens, completion_tokens, reasoning_tokens, finish_reason, visible output length, and runtime validation.

The next step in this model-comparison series should be harder programming tasks: LRU cache implementation, async retry with backoff, concurrency limits, interactive charts, and small browser games. For GLM-series tests, reasoning_tokens and visible output length should stay in the main results table, not in a footnote.