Last updated Sep 1, 2026.
GLM-5.3 vs GLM-5.3-Flash on DeepSWE: Cost per Solved Task, and How to Route Between Them
15 minutes read
Shubham Tribedi
Quick answer: On DeepSWE v1.1, GLM-5.3 scores 66.9 and GLM-5.3-Flash scores 63.4, both run on the same harness with the same settings. That 3.5-point gap costs roughly 17x more per solved task on Qubrid AI. For most agentic coding workloads the right answer is neither model alone but a cascade: run Flash first, escalate its failures. The maths below shows that cascade stays cheaper than flagship-only routing until your escalation rate exceeds 94%.
GLM-5.3-Flash resolves 63.4% of DeepSWE tasks at $0.075 each. GLM-5.3 resolves 66.9% at $1.28 each.
The comparison is unusually clean
Cross-model benchmark comparisons are normally close to useless, because the harness does as much work as the model. Different scaffolds, different timeouts, different context budgets, different retry policies - you end up comparing test rigs.
This one is different, and it is worth understanding why before you trust any of the numbers.
Z.ai published DeepSWE results for both models with identical evaluation settings. From the GLM-5.3 model card and the GLM-5.3-Flash model card, both were run under the mini-swe-agent harness at temperature 0.95, top_p 1.0, a 6-hour timeout and 400K context. Same scaffold, same sampling, same time budget, same context window.
That makes this one of the few vendor comparisons where the delta between two models is plausibly about the models.
Model | DeepSWE v1.1 (Pass@1) |
|---|---|
GLM-5.3 | 66.9 |
GLM-5.3-Flash | 63.4 |
GLM-5.2 | 46.2 |
DeepSWE v1.1 Pass@1, all three models run on the mini-swe-agent harness at identical settings.
Per Z.ai's developer documentation, GLM-5.3 improved from 46.2 to 66.9 on DeepSWE v1.1 over GLM-5.2, alongside gains on Terminal-Bench 3.0 and Agents' Last Exam.
3.5 points separate the flagship from the Flash model on long-horizon software engineering. Hold that number, because everything below is about what those 3.5 points cost.
One caveat before the maths
DeepSWE is Pass@1 on a fixed task set with 6-hour timeouts. Agentic benchmarks of this shape carry real run-to-run variance, and a 3.5-point gap is small enough that it may not be perfectly robust across reruns. Z.ai does not publish variance bands or multi-run averages for DeepSWE.
Treat 3.5 points as the best available estimate of a small gap, not as a precisely measured constant. That uncertainty argues for the routing approach below rather than against it, since a cascade does not require you to know the exact gap.
What the gap actually costs
Benchmark tables compare accuracy. Bills compare cost. The metric that connects them is cost per solved task, and almost nobody publishes it.
Both models are on Qubrid AI at these rates:
GLM-5.3-Flash | GLM-5.3 | Multiple | |
|---|---|---|---|
Input | $0.0863 / 1M | $1.61 / 1M | 18.7x |
Output | $0.29 / 1M | $5.06 / 1M | 17.4x |
Implicit cache | $0.0172 / 1M | $0.30 / 1M | 17.4x |
A worked cost model
DeepSWE-style tasks are long-horizon agent loops: many turns, a large and mostly stable prefix, tool calls, file reads. To make the comparison concrete, assume a per-task budget of 800,000 cumulative input tokens and 60,000 output tokens, with 70% of input hitting the implicit cache because the system prompt and tool schemas do not change across turns.
Swap your own numbers in. The ratios barely move, which is the point.
GLM-5.3-Flash, per task:
Uncached input: 240,000 × $0.0863 / 1M = $0.0207
Cached input: 560,000 × $0.0172 / 1M = $0.0096
Output: 60,000 × $0.29 / 1M = $0.0174
Total: $0.0477
GLM-5.3, per task:
Uncached input: 240,000 × $1.61 / 1M = $0.3864
Cached input: 560,000 × $0.30 / 1M = $0.1680
Output: 60,000 × $5.06 / 1M = $0.3036
Total: $0.858
Cost per solved task
Now divide by the solve rate, which is what you actually care about:
Model | Cost per task | DeepSWE solve rate | Cost per solved task |
|---|---|---|---|
GLM-5.3-Flash | $0.0477 | 63.4% | $0.075 |
GLM-5.3 | $0.858 | 66.9% | $1.28 |
Seventeen times more expensive per solved task, for 3.5 percentage points of resolution.
Cost per solved task on Qubrid AI. The 3.5-point accuracy gap carries a 17x price multiple.
Put differently: at flagship prices, the budget that resolves one task with GLM-5.3 resolves seventeen with Flash. Even accounting for Flash's lower hit rate, that budget lands roughly eleven more solved tasks.
The verbosity multiplier nobody mentions
There is a second-order effect that compounds the price gap, and it runs in the direction most people would not guess.
Artificial Analysis measured output token consumption across its Intelligence Index for both models. GLM-5.3 generated 170M output tokens, which it flags as very verbose against a 110M median. GLM-5.3-Flash generated 150M, somewhat above the same median.
The flagship is not just 17.4x more expensive per output token. It also emits roughly 13% more output tokens for comparable work. The effective output-cost multiple is closer to 19.7x, and since reasoning traces bill as output on both models, that lands squarely on agentic workloads where reasoning dominates the token mix.
Why a cascade beats either model alone
The framing "which model should I use" is the wrong question. You have two models behind the same endpoint. Use both.
The pattern: send every task to Flash. Escalate its failures to GLM-5.3.
The cascade: every task starts on Flash, only verified failures reach the flagship.
The cost side is unambiguous
Every task pays Flash's cost. The 36.6% Flash fails additionally pay the flagship's cost:
Cost per task = $0.0477 + (0.366 × $0.858) = $0.362
That is 58% cheaper than routing everything to GLM-5.3 at $0.858, and this is before counting any improvement in resolution rate.
The break-even is startlingly permissive
At what escalation rate does the cascade stop being cheaper than flagship-only? Solve for the escalation rate e where Flash cost + e × flagship cost equals flagship cost alone:
e = 1 - (0.0477 / 0.858) = 0.944
The cascade stays cheaper until you escalate more than 94% of tasks.
Cascade cost crosses flagship-only cost at a 94.4% escalation rate.
Because Flash costs about 5.6% of the flagship per task, the first pass is almost free relative to the second. You would have to be escalating nearly everything before the wasted first attempts cost you anything meaningful. That is an unusually forgiving threshold, and it means the cascade is close to risk-free from a cost perspective even if your escalation logic is bad.
The resolution side is more interesting than it looks
Here is the part that gets skipped. What is the cascade's combined solve rate?
If GLM-5.3 solved a strict superset of what Flash solves, the cascade resolves exactly 66.9% - the flagship's number, at 42% of the cost. That is the floor.
If the two models' failures were statistically independent, the cascade resolves 63.4% + (36.6% × 66.9%) = 87.9%. That is the ceiling, and it exceeds either model alone by a wide margin.
Reality sits between those bounds. The genuinely useful question is where, and there is a concrete architectural reason to think it is not sitting at the floor.
These are not two checkpoints of the same model
This is the detail that makes the cascade argument more than wishful thinking, and it is buried in the model cards.
GLM-5.3 uses the same base model as GLM-5.2, with every improvement coming from post-training. GLM-5.3-Flash starts from a newly trained base model, with its architecture and training recipe redesigned around capability and efficiency - a hybrid sparse and linear attention design, Manifold-Constrained Hyper-Connections, and a fresh 30-trillion-token multimodal corpus.
Different base models, different architectures, different pre-training data. Two checkpoints of the same base tend to fail on the same inputs, which is what makes most model cascades disappointing. These two have materially less reason to correlate.
That does not prove the cascade lands near the ceiling. It does mean the floor assumption - that the flagship simply dominates Flash task-for-task - is the less likely of the two, and it is worth measuring on your own task distribution rather than assuming.
Cost per solved task, all three routing strategies
Strategy | Cost per task | Solve rate | Cost per solved task |
|---|---|---|---|
Flash only | $0.0477 | 63.4% | $0.075 |
GLM-5.3 only | $0.858 | 66.9% | $1.28 |
Cascade (worst case) | $0.362 | 66.9% | $0.541 |
Cascade (independence ceiling) | $0.362 | 87.9% | $0.412 |
Three routing strategies. The cascade matches flagship resolution at 42% of the cost.
Even in the worst case, where the cascade adds not a single extra solved task over the flagship, it delivers identical resolution for 58% less. That result does not depend on the correlation question at all.
Designing the escalation trigger
The cascade is only as good as its decision to escalate. This is the part that is actually hard, and it is workload-specific. Signals worth wiring up, roughly in order of reliability:
Hard failure signals. Tests still failing after the agent declares completion. Patch does not apply. Build breaks. Non-zero exit code on the verification step. These are unambiguous and should escalate immediately.
Loop detection. The agent editing the same file more than three or four times, or re-reading the same files without a state change between reads. Long-horizon agents fail by circling rather than by erroring, so this catches what exit codes miss.
Budget exhaustion. Turn count or token budget hit without a completion signal. Set this deliberately rather than letting it default, because at max reasoning effort the token budget can be consumed by thinking before the work is done.
Self-reported uncertainty. Weak, and easy to over-trust. Useful as a tiebreaker alongside a harder signal, not on its own.
Task-shape pre-routing. Some tasks you can send straight to the flagship without a first pass: known-hard repositories, tasks touching more than some number of files, anything a previous cascade escalated. This is cheap to build and it recovers most of the latency cost of the cascade.
One thing to avoid: escalating on latency alone. Neither model lets you turn thinking off. Both open a reasoning block unconditionally and offer only low, high and max effort levels. A slow response is the normal behaviour of both models, not a failure signal.
Two asymmetries that should change your routing
The DeepSWE comparison treats these as interchangeable text models separated by 3.5 points. On two axes they are not comparable at all.
Flash sees, the flagship does not
GLM-5.3-Flash is the first natively multimodal model in the GLM-5 series, handling image and video input. GLM-5.3 is text-only.
For software engineering work this matters more than it first appears. Bug reports arrive with screenshots. UI regressions are visual. Architecture discussions come with diagrams. Design specs are images. Stack traces get pasted as pictures more often than anyone would like.
For any task whose input includes an image, the routing decision is already made - the flagship cannot accept the input at all. Flash is not the cheap fallback here; it is the only option. That inverts the usual hierarchy on a meaningful slice of real engineering work.
The self-hosting gap is much wider than the price gap
If you are weighing running these yourself, the two models are in different infrastructure classes entirely.
GLM-5.3-Flash | GLM-5.3 | |
|---|---|---|
Total parameters | 320B | 744B-class |
Active parameters | 18B | ~40B |
FP8 checkpoint | ~306 GiB | ~756 GB |
Reference vLLM config | TP4 on a GB200 tray | Eight-GPU class |
As the vLLM recipe documents, Flash's reference deployment is FP8 with tensor parallelism across four GPUs. The flagship needs roughly 2.5x the checkpoint size and correspondingly more hardware.
Both are far outside consumer hardware, so for most teams this is an argument about which API to call rather than which model to host. But if you are sizing a private deployment, the gap between these two is much larger than 3.5 benchmark points would suggest.
What both models share
Worth stating, because it affects how you configure either side of the cascade.
Neither can disable thinking. Both open a reasoning block unconditionally. Your only control is reasoning_effort, with three levels: low, high, max. The default on both is max.
Invalid effort values fail silently. The chat template resolves anything other than low or high to max. Passing "medium", out of habit from other model families, gives you the most expensive setting on both models with no error raised.
clear_thinking defaults to false on both, and Z.ai recommends explicitly passing clear_thinking=true for chat scenarios.
Both recommend max for benchmark reproduction. The DeepSWE numbers at the top of this page were produced at max effort. If you run either model at low in production, you are not running the configuration that scored 66.9 or 63.4. Your own measured solve rates will differ, which is another reason to instrument the cascade rather than trusting published numbers.
Implementing the cascade
Both models sit behind the same OpenAI-compatible endpoint on Qubrid AI, so escalation is a model string change rather than a second integration.
from openai import OpenAI
# Initialize the OpenAI client with Qubrid base URL
client = OpenAI(
base_url="https://platform.qubrid.com/v1",
api_key="QUBRID_API_KEY",
)
FLASH = "zai-org/GLM-5.3-Flash"
FLAGSHIP = "zai-org/GLM-5.3"
def run_task(messages, model, effort="high", max_tokens=8192):
return client.chat.completions.create(
model=model,
messages=messages,
max_tokens=max_tokens,
temperature=0.95,
top_p=1,
extra_body={"chat_template_kwargs": {"reasoning_effort": effort}},
)
def solve_with_cascade(messages, verify):
# First pass: Flash at high effort.
result = run_task(messages, FLASH, effort="high")
if verify(result):
return result, FLASH
# Escalate only on a hard failure signal from your verifier.
result = run_task(messages, FLAGSHIP, effort="max")
return result, FLAGSHIPNote the effort asymmetry. Flash runs at high because it is cheap enough that a second pass costs almost nothing. The flagship runs at max because if you have paid to escalate, you want the best attempt available rather than a hedged one.
verify is your own function and it is the whole ballgame: run the test suite, check the patch applies, confirm the build. A cascade with a weak verifier is just an expensive way to run two models.
Instrument it from day one
Log four things per task and the cascade tunes itself:
Which model produced the accepted result
Actual input and output token counts per stage, from the usage object
Cache hit rate on the input side
Escalation rate, and the trigger that fired
After a few hundred tasks you will know your real escalation rate and your real combined solve rate, which are the two numbers this entire analysis is estimating. At that point you can stop reasoning from benchmark tables and start reasoning from your own distribution, which is the only one that matters.
Frequently asked questions
What does GLM-5.3 score on DeepSWE? 66.9 Pass@1 on DeepSWE v1.1, up from 46.2 for GLM-5.2, run under the mini-swe-agent harness at temperature 0.95, top_p 1.0, 400K context and a 6-hour timeout.
What does GLM-5.3-Flash score on DeepSWE? 63.4 Pass@1 on DeepSWE v1.1, using the same harness and settings as GLM-5.3.
How much better is GLM-5.3 than GLM-5.3-Flash at coding? 3.5 percentage points on DeepSWE v1.1. On Qubrid AI that gap costs roughly 17x more per solved task.
Is GLM-5.3-Flash good enough to replace GLM-5.3 for coding? For most agentic coding traffic, yes, particularly in a cascade where failures escalate. For the hardest tasks the flagship's extra 3.5 points is real, but paying flagship rates on every task to capture it is poor economics.
How much does it cost to run a coding task on GLM-5.3-Flash? Under the token model in this article, about $0.048 per task against $0.858 on GLM-5.3, or about $0.075 versus $1.28 per solved task.
Should I route between GLM-5.3 and GLM-5.3-Flash? Yes for most workloads. Run Flash first and escalate on hard failure signals. The cascade remains cheaper than flagship-only routing until escalation exceeds 94% of tasks.
Can a cascade beat GLM-5.3 alone on resolution rate? Possibly. The floor is the flagship's own 66.9% and the independence ceiling is 87.9%. Because the two models are built on different base models with different architectures, their failures have less reason to correlate than two checkpoints of one base. Measure it on your own tasks.
Does GLM-5.3-Flash support images for coding tasks? Yes. GLM-5.3-Flash is natively multimodal and GLM-5.3 is text-only, so any task with a screenshot or diagram must go to Flash regardless of difficulty.
Can I turn off reasoning on either model? No. Both open a thinking block unconditionally and offer only low, high and max effort levels, defaulting to max.
Which model uses more tokens? GLM-5.3, by roughly 13%. Artificial Analysis measured 170M output tokens across its Intelligence Index against 150M for Flash, which compounds the 17.4x output price difference.
What hardware do I need to self-host each? Roughly 306 GiB for the Flash FP8 checkpoint against about 756 GB for the GLM-5.3 FP8 checkpoint, before runtime and KV-cache overhead. Both are datacenter-class.
Run the comparison on your own tasks
Both models are live on Qubrid AI behind one OpenAI-compatible endpoint, so building the cascade above takes a model string and a verifier.
Generate an API key at platform.qubrid.com
Point your OpenAI SDK at
https://platform.qubrid.com/v1Use
zai-org/GLM-5.3-Flashfor the first pass andzai-org/GLM-5.3for escalationInstrument escalation rate and combined solve rate from the first day
Qubrid AI serves 60+ open-source models behind a single OpenAI-compatible API, alongside on-demand GPU compute and on-premises AI appliances.
