CrazyrouterGLM-5.2 vs Claude Fable 5: Output Budget, Reasoning Tokens, and the 0.8 Pricing Angle
A practical Crazyrouter benchmark comparing glm-5.2 and claude-fable-5 across math, physics, and Canvas animation tasks, with a new note on glm-5.2's current 0.8 discount multiplier in Crazyrouter pricing data.
GLM-5.2 vs Claude Fable 5: The Real Difference Was Output Budget#
This follow-up is not a generic model ranking. It is a practical note from one API benchmark: GLM-5.2 could solve the reasoning tasks after the output budget was raised, while Claude Fable 5 was steadier under lower budgets and stronger on a long runnable HTML animation task.
Why this test matters#
The test used the Crazyrouter OpenAI-compatible API rather than a chat UI. That matters because the result was not judged only by prose quality. Each response was checked with operational metadata:
Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: glm-5.2, claude-fable-5
temperature: 0.2
Test date: 2026-07-06
The important fields were max_tokens, completion_tokens, reasoning_tokens, finish_reason, visible content length, whether the generated HTML was closed, and whether the animation actually moved in a browser.
What was tested#
The benchmark deliberately mixed three task types:
| Task | Purpose | Reference result |
|---|---|---|
MATH-003 | State-based expectation reasoning | Expected flips until HH = 6 |
PHYS-003 | Momentum plus energy accounting | V = 3.0 m/s, x ≈ 0.148 m |
CODE-003-ANIM | Long runnable artifact generation | Complete 800x500 Canvas animation HTML |
The first two tasks measured reasoning. The third task measured whether a model can produce a complete artifact, not merely a convincing partial code block.
Observed results#
| Task | glm-5.2 | claude-fable-5 |
|---|---|---|
| Math, original budget | finish_reason=length, completion_tokens=1601, reasoning_tokens=1600, visible body empty | finish_reason=stop, complete and correct |
| Math, retest | Correct after max_tokens=3200 | Retest not needed |
| Physics, original budget | finish_reason=length, visible body empty | Complete and correct |
| Physics, retest | Correct after max_tokens=8000 | Retest not needed |
| Animation, original budget | Empty visible HTML at max_tokens=3200 | Partial HTML, truncated |
| Animation, retest | Still truncated at max_tokens=8000 | Complete HTML; browser validation passed |
The most important observation is that GLM-5.2 was not failing the reasoning itself. In the math and physics tasks, it produced correct answers after a larger output budget. The problem was visibility and completion: a request could return HTTP 200 while the user-facing content was empty or incomplete.
For the long Canvas animation, the difference was sharper. GLM-5.2 produced a visible HTML fragment at max_tokens=8000, but it stopped inside JavaScript and did not close the file. Claude Fable 5 completed the HTML at max_tokens=8000; browser validation showed no console errors, an 800x500 canvas, controls, a speed slider, and changedPixels=55090 after 700 ms.
Cost-performance note#
At the time of writing, Crazyrouter's pricing API lists glm-5.2 with a discount multiplier of 0.8. That makes it a very cost-effective option when your workload can tolerate higher output budgets and when you monitor reasoning_tokens carefully.
This is the practical tradeoff:
| Workload | Better fit from this test |
|---|---|
| Short reasoning with enough output budget | GLM-5.2 can be a cost-effective option |
| Low-budget reasoning responses | Claude Fable 5 was steadier |
| Long single-file code generation | Claude Fable 5 was stronger in this run |
| Batch evaluations where metadata is logged | GLM-5.2 becomes easier to operate safely |
Do not treat the 0.8 multiplier as a permanent universal price. It is a pricing-data snapshot from Crazyrouter at publication time and should be checked again before a large deployment.
Integration notes#
Minimal request:
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": "Solve the HH expected-flips problem with state equations."
}
],
"temperature": 0.2,
"max_tokens": 3200
}'
To compare Claude Fable 5, keep the same payload and change only the model:
{
"model": "claude-fable-5"
}
For production-style evaluations, log this shape for every request:
{
"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"
}
API endpoints should stay clean. Do not add UTM parameters to https://cn.crazyrouter.com/v1. Use tracking only on human-facing article or registration links.
Run the same OpenAI-compatible request on Crazyrouter and compare both models in your own workload.
FAQ#
Did GLM-5.2 fail the reasoning tasks?#
No. In this run, GLM-5.2 solved the math task after max_tokens=3200 and the physics task after max_tokens=8000. The issue was that lower budgets were consumed mostly by reasoning tokens before visible content appeared.
Why not score HTTP 200 as success?#
Because HTTP 200 only means the API call returned. A benchmark answer can still be unusable if finish_reason=length, visible content is empty, or generated code is incomplete.
Why was the animation task included?#
Long code generation exposes a different failure mode. A model can write a convincing first half of a file and still fail if the HTML or JavaScript is cut off.
Is GLM-5.2 still worth testing?#
Yes. The current 0.8 discount multiplier makes it attractive for workloads where you can allocate enough output budget and monitor response metadata.
What should be recorded in future comparisons?#
At minimum: max_tokens, completion_tokens, reasoning_tokens, finish_reason, visible output length, artifact completeness, and runtime validation.
Final verdict#
The practical conclusion: GLM-5.2 is attractive on cost and can reason well, but it needs stricter output-budget monitoring. Claude Fable 5 was the safer choice for compact answers and complete single-file code in this run.
