GLM-5.3-Flash Hands-On: Snapping Timelines, Broken Payments, and a Playable Game

“

Niu Lai finally claimed it, and the real test has just begun. Hands-on testing gets closer to the answer than specs and benchmarks.

— Zixin

Hello everyone, I'm Zixin.

A few days ago, an anonymous model suddenly appeared on OpenRouter, with the provider listed only as "stealth" and the name Ox Alpha. The Chinese community quickly gave it a nickname: Niu Lai.

It had no launch event, no company name, and no complete technical report — just a set of very aggressive specs. A 1-million-token context window, text, image, and video input, reasoning enabled by default, and free.

After going live, the model quickly shot to #1 on OpenRouter's usage leaderboard. According to the platform's public data as of yesterday, Ox Alpha processed 27.2T tokens, while DeepSeek V4 Flash processed 12.3T — the former more than double the latter. OpenCode also put it into a free preview, and developers rushed to connect it for code and agent tasks.

Over the past few days, the community has been guessing who made it. Some compared tokenizer segmentation results, some compared token consumption for video input, and others watched API error behavior and parameter behavior. Several clues ultimately pointed to Zhipu's GLM series.

Yesterday, Zhipu confirmed it in response to a media inquiry. Ox Alpha is a new version of the GLM series, subsequently officially released and open-sourced under the name GLM-5.3-Flash.

"Niu Lai finally claimed it."

I got a 7-day trial card for Zhipu's GLM Coding Plan, used the official ZCode directly, and re-ran the three scenarios I previously used to test Qwen 3.8 Max and Kimi K3.

This article is about that hands-on test. Official specs and benchmarks are placed up front, but the conclusion is still based on what I actually operated.

📌 Article Highlights

01

Model Parameters and Pricing

02

Three Real-World Scenario Tests

03

Comparison with Competitors

01

FACTS

What GLM-5.3-Flash Actually Is

Let's first lay out the hard information most relevant to developers.

GLM-5.3-Flash is the first natively multimodal model in the GLM-5 series, with 320B total parameters, 18B activated parameters, a 1M context window, and a maximum output of approximately 131K tokens. Input supports text, images, and video; output remains text, and it also supports tool calling.

Its architectural goal is clear: make long-context and multimodal capabilities cheaper. For the first time in the GLM series, the official implementation combines sparse attention and linear attention within the same model, and adds mHC and IndexPool. In plain terms, the model tries to compute fewer irrelevant positions while retaining the global information that needs to be retrieved.

The official architecture diagram gives a comparison: compared to GLM-5.3, GLM-5.3-Flash reduces attention computation by approximately 3.01x and KV Cache size by approximately 4.44x. For coding agents that need to run for long periods, these numbers are closer to the cost question than total parameters.

On the training side, Zhipu states it used 30T tokens of multimodal pre-training data. The official release placed it in tests like Terminal Bench, DeepSWE, AutomationBench, HLE w/ Tools, and GDPval-AA. In the public charts, GLM-5.3-Flash's scores are 84.3, 63.4, 48.8, 55.3, and 1773 respectively.

For Artificial Analysis's Intelligence Index, Zhipu's blog states a score of 57, positioning it at the intersection of frontier models and low cost. A caveat here: benchmark scores come from specific test conditions and cannot be directly converted into a project delivery success rate.

Pricing is also very attractive.

To put it in the same table as DeepSeek V4 Pro, I uniformly calculated the USD price per million tokens based on official APIs.

Model	Cache Hit Input	Cache Miss Input	Output
GLM-5.3-Flash, Z.ai	$0.03	$0.15	$0.50
DeepSeek V4 Pro, Off-Peak	$0.022	$0.66	$1.98
DeepSeek V4 Pro, Peak	$0.044	$1.32	$3.96

DeepSeek V4 Pro's off-peak price is already $0.66 for input and $1.98 for output, doubling during peak hours. For regular input and output, GLM-5.3-Flash is roughly 4x cheaper; for cache hits, DeepSeek's off-peak price is actually lower. This difference needs to be factored in for long sessions that heavily reuse prefixes.

The OpenRouter page also shows limited-time discount prices from some providers: GLM-5.3-Flash input at $0.075, output at $0.25, and cache read at $0.015. This pricing belongs to a different distribution channel and cannot be directly added to or compared with DeepSeek's official API pricing.

The GLM Coding Plan currently distributes a limited 10,000 7-day trial cards per day. I entered ZCode through this trial card and then gave it three real, operable scenarios.

Get a 7-Day Trial Card

In terms of specs, both have a 1M context window.

DeepSeek V4 Pro's maximum output is about 384K, while GLM-5.3-Flash's is about 131K — DeepSeek leaves more room for single-pass long document generation.

GLM's advantage lies in native image and video input. When I tested V4 Pro in my previous article, the Codex entry couldn't read the Drive Mad screen recording, so there was no game test. DeepSeek later placed visual capabilities separately in V4-Flash-Vision-Exp.

Public benchmarks are also not suitable for direct ranking. The previous article recorded V4 Pro at 87.9 on Terminal Bench 2.1 and 62.7 on DeepSWE; GLM's official chart shows corresponding numbers of 84.3 and 63.4. The harnesses, runtimes, and evaluators are not exactly the same on both sides. Below, we'll look at what happened in the same set of real-world scenarios.

02

METHOD

How This Test Was Conducted

The three scenarios are consistent with the previous two articles: a pure frontend video workstation, a real-time ticketing system with a waitlist flow, and a physics driving game replicated from Drive Mad gameplay video.

I care about whether the model, after generating the page, can tie together functionality, state, and interaction. The video workstation needs to show timeline and parameter modification; the ticketing system needs to see if payment, refund, and waitlist can proceed; the game needs to show control feedback and level difficulty.

Below, I'll go scenario by scenario, writing down both what was accomplished and what wasn't.

03

VIDEO STUDIO

The Video Workstation Won in One Area

Pulse Studio's requirements are not low. It needs a media library, video preview, multi-track timeline, subtitles, voiceover, music, clip trimming, a parameter inspector, and local operations — it can't just be an upload-and-play page.

The GLM version can upload media and trim clips. What surprised me most was that moving track material indeed has a snapping feature. Neither the Qwen 3.8 Max nor the Kimi K3 version implemented this detail; here GLM took a step ahead.

But this advantage didn't rescue the overall experience.

The page styling has a distinct AI flavor — text overlaps, and the layout is jumbled.

After trimming, the clip automatically drifts to the beginning of the track; its original position is not preserved. Speed change and gradient parameters also don't take effect after modification — the controls exist on the page, but the functionality hasn't caught up.

Track movement itself is also unstable. Dragging material often lands it in unexpected positions. All three models are roughly similar on this point; none did it very smoothly.

"GLM produced an operable prototype; snapping is the highlight, but timeline state and parameter response are lacking."

These are functional problems, not something that can be fixed by tweaking colors a bit more.

04

TICKETING

The Ticketing System Stuck at the Payment Step

SeatFlow this time best illustrates the gap between "the page can run" and "the business flow can complete."

The project itself can start, and basic functionality is fine.

But the main flow in the browser got stuck.

💡 After completing seat locking and initiating payment, the page directly threw an error, blocking all subsequent flows.

This payment error blocked MockPay, ticket issuance, refund, verification, and the waitlist entirely.

The most important state chain of the ticketing system did not complete, and the subsequent functions could not be tested.

Several interaction details also exposed state design problems. In my pending orders, I could only continue payment; there was no cancel order option.

The sales dashboard entry was accessible, but the waitlist queue was not visible.

The waitlist page was likewise empty; there was no queue to view in the backend.

After clicking full-order refund, the page only then prompted that the performance had already started and could not be refunded, yet the button itself remained clickable.

The states of the performance list and detail page also didn't match. The list showed "on sale," clicking into the detail page still allowed seat selection, and the next step then told me sales had stopped. Users have to click several times to know whether they can actually buy — this isn't a problem unique to complex business logic; it happens when the frontend state hasn't caught up with the backend state.

For the same scenario with Qwen 3.8 Max and Kimi K3, I was able to complete the main flows of seat locking, payment, ticket issuance, refund, and waitlist.

GLM this time stopped at the payment error. The number of pages doesn't explain the gap; the key is whether the state continued to advance.

Moreover, the AI flavor on this system's pages is even more severe.

05

GAME TEST

The Game, Counterintuitively, Most Resembled a Finished Product

For the Drive Mad scenario, I directly fed the gameplay video to GLM and asked it to replicate forward, reverse, obstacle crossing, and mid-air attitude control based on the video.

Among the three scenarios, this game was actually the one I was most satisfied with. The overall replication was fairly close; forward and reverse controls were basically normal; the vehicle's rotation and landing feedback in the air were also playable. The number of scenes wasn't large, and the design was still simplistic, but at least you could operate from start to later stages without it breaking immediately.

Its problems lay in control tuning. Pressing the forward key too quickly makes the car continue accelerating its rotation in the air, and attitude quickly goes out of control. Pressing too slowly means it can't climb slopes and can't cross obstacles. I kept getting stuck on the third level, not because the keys weren't responding, but because the speed and physics feedback weren't tuned to a comfortable range.

This is somewhat similar to Kimi K3's game version: overall playable, scenes simplistic, details still needing polish. GLM's version is more flexible — flexible to the point of sometimes flinging the car away. Among the three scenarios, it remained the one closest to the requirements.

∞

THE END

Final Thoughts

Putting the three tests together, GLM-5.3-Flash gave me a very polarized feeling.

Native multimodality, million-token context, open weights, low API pricing, and a 7-day trial card — developers can easily throw real tasks at it. It at least produced a playable game from a video and made a timeline with snapping.

But parameters and benchmarks didn't complete the final acceptance check for it. The video workstation's controls didn't all take effect; the ticketing system was directly interrupted at the payment step; the game required repeated control tuning.

All three projects illustrate the same thing: the model can produce a first version, but state consistency, interaction details, and post-failure fixes still need human oversight.

Viewed alongside Qwen 3.8 Max and Kimi K3, GLM has one clear highlight in the video workstation's snapping; material movement itself is unstable across all three models. The ticketing system this time didn't complete the main flow, putting it at a certain gap behind the previous two models. Game completion is close to Kimi K3, with higher control difficulty and no clear advantage formed.

DeepSeek V4 Pro's results can serve as a more direct reference. For the same ticketing system, in my previous article I got through payment, ticket issuance, refund, and verification; the waitlist only errored when accepting a qualification to pay. GLM this time stopped right at the payment entry.

The video workstation is a different kind of difference: both sides had problems with speed, transitions, and dragging; GLM additionally produced track snapping. This comparison indicates that GLM's advantages are currently more concentrated in the multimodal entry point and pricing; complex backend state progression still falls short of DeepSeek.

"Useful, but not comprehensively leading."

It pushes the trial cost of frontier models very low, suitable for quickly validating real tasks. When preparing to hand results over to others, you still need to reserve testing and manual acceptance.

If this article was helpful to you, feel free to follow "Zixin AI Programming," and also give a like, a "wow," or forward it to friends who are also tinkering with AI programming tools.

END

I'm Zixin, focused on sharing AI tools, AI programming, AI efficiency, and other tech topics.

If you found today's article rewarding, welcome to like, wow, and forward — see you in the next one.