I test-ran both of this week's open-weight flash models against 24 small, real workloads from an actual product stack — structured extraction, SEO metadata, and code fixes — and graded everything programmatically. The short version: on quality the two models are effectively tied, per-task cost lands within ~3%, and the biggest practical difference wasn't intelligence at all — it was a 429 storm.
Both models dropped within a day of each other. GLM-5.3-Flash (320B total, 18B active) rode a wave of "frontier intelligence at flash cost" claims, including a now-confirmed anonymous stint as ox-alpha on OpenRouter. Qwen3.8-Flash-Next (125B + 51B N-gram embedding, 6B active) is the architecture preview for Qwen4. On paper they're close: 63.4 vs 58.7 on DeepSWE 1.1. Benchmarks won't settle which one you should actually wire into a product this month. Small, boring, real tasks might.
The setup
- Both via OpenRouter,
temperature: 0, one call per task, same prompts:z-ai/glm-5.3-flash($0.075/M in, $0.25/M out) andqwen/qwen3.8-flash($0.15/M in, $0.47/M out). - 3 suites, 24 tasks total, all graded by machine, not vibes:
- Extraction (10): messy real-world blobs — support tickets, log fragments, changelogs, pricing pages, review text — into strict JSON schemas.
- SEO metadata (10): title + meta description under hard constraints (title ≤ 60 chars, description 140–160 chars, keyword must appear in both).
- Code (4): write or fix small utility functions (slugify with accent transliteration, a buggy debounce, duration parsing, CSV escaping). Pass/fail = does the hidden test suite run green.
- Everything recorded: latency, tokens, cost per call, retry counts.
One honesty note before the numbers: this is one day, one shared API pool, N=24 — not a benchmark lab. Treat it as a smoke test from a builder's desk, which is exactly the decision most people are making this week.
Finding 1: Extraction is a tie — and the "failures" are judgment calls, not errors
Both models returned schema-valid JSON on 10/10 tasks. Zero parse failures either way.
Under strict field-by-field grading against my gold answers, it looks lopsided — until you read the "failures":
| Task | What actually happened |
|---|---|
| Phone-mount listing | Both extracted the product fine. GLM appended a black tag; Qwen kept (BLACK) in the name. Both defensible readings of the same sloppy source. |
| Support-ticket triage | Qwen escalated severity to critical where I expected high. With "URGENT!!!" and lost revenue in the ticket, that's a judgment call, not an error. |
| Changelog parse | My gold answer was the wrong one — both models correctly captured a BREAKING API removal I'd missed when writing the key. Both models beat my grader. |
Regraded with a two-tier rubric (exact on objective fields; "defensible variant" for judgment fields like verdicts and free-text): GLM 4 exact + 4 defensible + 2 real misses; Qwen 3 exact + 6 defensible + 1 real miss. That's inside the noise floor.
Takeaway for builders: on these two models, extraction is a solved problem at the schema level. Your prompt design — how you pin enums, nulls, and array semantics — matters more than which of the two you pick.
Finding 2: Hard constraints — also a tie, but read the token meters
Both models hit 10/10 on the SEO-metadata suite: keyword present, title ≤ 60 chars, description inside the 140–160 window, every task.
The interesting part is what it cost to get there. Measured completion tokens on the same suite:
- GLM-5.3-Flash: ~3,100 output tokens per task
- Qwen3.8-Flash: ~1,500 output tokens per task
GLM burns roughly 2× the tokens to land the same two-line answer — presumably reasoning overhead — while charging half the per-token price. The two effects cancel almost exactly: $0.00048 per task for GLM vs $0.00049 for Qwen, within ~3% of each other across the full run. Price-per-token is half the story; tokens-per-task is the other half, and only their product shows up on your invoice.
Finding 3: Code — GLM 4/4, Qwen never got to answer
GLM-5.3-Flash passed all four code tasks first-try: the transliteration-aware slugify, the debounce fix (early-fire bug), duration parsing with error handling, and CSV escaping with quote-doubling.
Qwen3.8-Flash didn't fail these tasks. It never got to attempt them. See below.
Finding 4: The difference nobody benchmarks — availability
Here's what dominated the actual experience of running this test:
- GLM-5.3-Flash: 24 calls, 24 first-try successes. Zero retries, zero waits.
- Qwen3.8-Flash: upstream 429s on 16 of 20 completed tasks, 41 recorded retry cycles on those tasks alone, single-task waits up to 6 retries and several minutes. The final code suite was unreachable across eight sustained retry rounds spanning ~50 minutes — every attempt bounced — so it's marked blocked at publish time, not failed.
Fair disclosure: that's OpenRouter's shared pool, not a dedicated provider key. But if your mental model of "cheap flash model" comes from a benchmark table, this is the column that's missing: a model you can't call is 0% intelligent, whatever its DeepSWE score. Two days post-launch, demand for Qwen3.8-Flash's pool is clearly outrunning capacity. If you're wiring it into production this week, budget for backoff logic or bring your own Alibaba key.
The bill
| GLM-5.3-Flash | Qwen3.8-Flash | |
|---|---|---|
| Tasks completed | 24/24 | 20/24 (code suite blocked) |
| Total cost | $0.0115 | $0.0098 |
| Cost per task | $0.00048 | $0.00049 |
| Median successful-call latency | ~5.0s | ~17.2s |
| Retries | 0 | 41 |
Flash-model API spend is a rounding error at any realistic volume. The real cost is engineering time spent verifying output quality — which is exactly what suites like this exist to compress into an afternoon.
When to pick which
| Your workload | Pick | Why |
|---|---|---|
| Structured extraction / ETL glue | Either | Schema validity 10/10 both; disagreements are judgment calls |
| Hard format constraints | Either | 10/10 both; token verbosity differs, invoice doesn't |
| Small code generation & repair | GLM-5.3-Flash (today) | 4/4 recorded; Qwen's suite blocked, untested in this window |
| Latency-sensitive or high-volume this week | GLM-5.3-Flash | 0 retries vs a 429 wall; 5s vs 17s median |
| Reasoning-heavy, tight token budgets | Watch Qwen | Half the output tokens for the same answers — if you can reach it |
Limitations
- One day, one shared pool, temperature 0, single attempt per prompt. N=24, not 2,400.
- My gold answers had at least one real bug (the changelog task). Two-tier regrading exists precisely because strict grading miscounted defensible variants as errors — your graders will have the same problem.
- Programmatic graders can't see creativity, tone, or long-horizon agent behavior. For agent workloads, the labs' DeepSWE/CoWorkBench numbers remain the better signal.
- Qwen's availability picture is launch-week demand on a shared pool and may settle; its code-suite row is blocked, not failed.
The task set is 30 minutes of work to replicate against your own workloads — and your workload decides this better than any benchmark table. If you run it, I'd genuinely like to see your numbers.
Top comments (0)