More than two weeks ago, after testing Kimi K3, my conclusion was that domestic models had touched the first tier. This week Qwen 3.8 Max was released, and honestly, my first reaction was disinterest.

I haven't taken Qwen seriously for a long time. My impression was that its coding ability wasn't great, and that impression stuck around long enough that seeing the release news didn't stir much.

But Qoder happened to be offering 800 free calls.

I thought of a lazy but fair approach: take the three scenarios I tested with K3 and run them again, verbatim, on Qwen 3.8 Max.

Too strong, Kimi K3: I'd call it Kable

Here's the answer upfront. It tied on all three scenarios, and in one area it did even better than K3.

What is Qwen 3.8 Max

Hard specs first.

2.4 trillion parameters, 95 billion activated MoE, 1 million token context window, API pricing at $2 per million input tokens and $6 per million output tokens — the output price is roughly one-eighth of Claude Fable 5.

Officially, they also say the weights will be open-sourced next week. This is the first time a Qwen Max-level model has had its weights opened, and a 27B small model will be open-sourced at the same time.

The official positioning is "second only to Fable 5."

A word of caution here. The Anthropic models in its comparison table are Opus 4.8 and Fable 5; Opus 5, released on July 24, is not included.

So take this table with a grain of salt. I won't go through it line by line; let's look at the actual tests.

What I care more about now is how to use it inside Qoder.

In the model selector, Qwen 3.8 Max costs 0.5x Credit, with an additional 50% discount during off-peak hours (10 PM to 8 AM), and three context window options: 200K / 400K / 1M.

In terms of call quota, new users get 800 calls upon registration, plus an additional 300 after logging in, totaling 1100 calls; after subscribing, you can claim another 2000 calls.

The cost to reproduce the tests in this article is zero.

How I Tested This Time

Three scenarios, exactly the same as the K3 test: building a video workstation from scratch, a real-time seat-selection ticketing system, and a physics-based driving mini-game.

A few caveats need to be stated clearly, otherwise the conclusions won't hold up.

First, this time I gave only one round of requirements per scenario, aiming for a one-shot implementation. The prompts were not the exact same wording as the K3 test. With K3, I added several rounds of requirements back and forth — membership, waitlist, and other features were added later. This time, I consolidated those multi-round requirements into a single complete prompt, with more detailed acceptance criteria. This favors Qwen; it received a clearer exam paper, so the "tie" conclusion should be discounted accordingly.

Second, this is a comparison of Qwen + Qoder versus K3 + Kimi Code — both are model-plus-framework workflows, not bare-model benchmarks. This is the comparison I care more about now anyway; bare-model scores are too far removed from real-world usage.

Third, there were no real-world project cases this time. The K3 article included private repo MR reviews, legacy system architecture reviews, and an online alert; none of that is here. The 800 free calls were just enough, and I didn't have suitable real-world tasks on hand. Whether it can fit into a real workflow, this article can only answer halfway.

Time-wise, the video workstation took about 30 minutes, the ticketing system about 50 minutes, and the game about 30 minutes.

Qoder was in YOLO mode. During the process, I didn't help it install dependencies, modify code, or handle the environment. After project delivery, I personally tested every feature hands-on.

Scenario 1: Video Workstation

The requirement was to build a pure front-end editing tool comparable to the workflow of Jianying, with an asset library, program preview, multi-track timeline, clip inspector, undo/redo, and local persistence.

Feature-wise, it tied with the K3 version — everything that should be there was there. The interface was more restrained than K3's, with a dark editor color scheme, clear information hierarchy, and noticeably less of an AI-generated feel. It also had some extra professional features: track locking and muting, clip edge trimming, left/right arrow key frame-by-frame navigation, and a narrow-screen read-only review mode.

There's one design difference worth noting.

When adjusting clip speed, the K3 version changes the clip length on the track according to the speed; the Qwen version keeps the clip length fixed and clamps the speed upper limit based on the source material length. Both semantics make sense, but the Qwen version can be confusing on first use.

Engineering-wise, it delivered 28 unit tests, all passing, with zero TypeScript type-checking errors.

Scenario 2: Real-Time Seat-Selection Ticketing System

This was the heaviest requirement.

Consumer-side seat selection and purchase, an operations backend for managing venues and shows, with a complete state flow in between: seat locking, payment, ticket issuance, refunds, waitlisting, and verification.

Let's start with the architecture — it's a real backend.

PostgreSQL for business data, Redis for real-time events, seat status pushed to the frontend via SSE, plus a Worker handling lock expiration and waitlist seat assignment, all spun up with a single Docker Compose command.

After paying and refunding, I refreshed the page, opened a brand-new browser session and logged in again — all data was consistent.

It missed none of the K3 version's feature baseline, and the engineering details were even more meticulous.

Seat locking is an atomic operation — if any single seat is unavailable, the entire batch fails; the payment endpoint carries an idempotency key, so repeated clicks don't create duplicate orders; duplicate verification returns 409; the waitlist queue has a 24-hour anti-starvation mechanism, where a regular user who waits a full day gets upgraded to a priority tier and can no longer be cut in line by later-joining members.

I clicked through all nine backend modules — creating venues, creating shows, granting memberships, verifying tickets — all actually performed, and the data in orders, waitlists, audit logs, and notification records all matched up. Throughout the entire process, the browser console had zero errors.

Scenario 3: Physics Driving Mini-Game

The requirement was to create an original game following the gameplay of Drive Mad, using only forward and backward controls to navigate a vehicle over obstacles, with five themed levels and a set of instant-death mechanics.

I knew K3's weaknesses here very well. The five levels were too similar, the difficulty was low, and to this day I'm not sure whether it used a mature physics engine under the hood.

The Qwen version addressed both weaknesses. It explicitly used planck.js (a Box2D-family physics engine), and not just for show — suspension springs, collision impulse judgment, and per-level parameter tuning for low gravity and icy friction were all real. The five level themes were the same as the K3 version, but the mechanic density per level was noticeably higher. The construction site had in-level box-pushing to pave the way, the ice field had phase-rotating bars, and the volcano had falling rock zones plus consecutive broken bridges.

I tested every instant-death mechanic one by one. Bottoming out, getting swept by a rotating bar, being hit by falling rocks, falling off the level boundary, touching a lava hazard surface — all triggered for real. The difficulty was also higher than the K3 version; the ice field and volcano required timing, and I died several times playing it myself.

It also came with a test suite — 23 tests, all passing, including headless simulation playthroughs of all five levels, using scripts to simulate input and automatically drive the car to the finish line.

That said, K3 didn't lose on every front. The K3 version had noticeably richer colors and a more playful results card. The Qwen version's art style is more plain; it wins on feel and mechanics, not on visual appeal.

The Thing That Surprised Me Most

Across all three scenarios, it took a bit longer than K3. I initially thought the model was slow, but after looking at the process logs, I realized that wasn't it.

After finishing each scenario, it would open a browser and do its own acceptance testing — and it was quite thorough about it.

When building the video workstation, it noticed that the preview would freeze in a background tab due to rAF throttling, and proactively changed the playback loop to a dual-drive of rAF plus setInterval; when it found that the Delete key wasn't deleting clips, it dispatched keyboard events itself to debug the issue.

When building the ticketing system, it first checked the environment itself, found that Docker wasn't running and started it up, ran 25 tests, then went into the browser to walk through the full flow.

In other words, the extra time it took was spent on self-verification.

This is something you'd never see in a benchmark table, but it's exactly what a backend engineer uses to decide whether to trust a model with real work.

All three projects came with their own tests, zero console errors, and details like idempotency and auditing were all accounted for. At this level, it's no longer just about getting a demo to run — it knows what a deliverable should look like.

Final Thoughts

My bias against Qwen has been thoroughly dismantled this time. Across three scenarios identical to K3's, it tied on features and was slightly stronger on engineering rigor.

Of course, the caveats bear repeating. It received a more complete prompt, which gave it an advantage; there were also no real-world project comparisons this time, so I still don't know how it performs in complex legacy systems.

But even after applying those discounts, there are some things I want to say plainly.

Before this, Qwen's place in my mind was "bad at coding, don't bother."

That impression sat there for so long that I myself forgot when it first formed.

After running these three scenarios, I have to admit something: my judgment of it had been stuck on an old calendar, while it had quietly changed positions.

Since starting this blog, similar experiences have happened three times this year already — once with GLM 5.2, once with K3, and now with Qwen.

Once is an accident; three times is not. This time, domestic models have genuinely caught up.

In the past couple of days, I've also seen some completely opposite reviews — some calling it a "PowerPoint model," others just dropping a dismissive "it's trash."

I don't know whether they actually tested it, nor can I rule out that my three scenarios just happened to play to its strengths. Anyway, my own initial impression is: not bad.

If you're also curious about its actual level, my advice is simple: don't trust benchmarks, don't fully trust this article, and don't trust a one-line drive-by comment.

Go download Qoder — new users get 1100 free calls — throw a real scenario from your own work at it, and run it once. Your own task will give you a better verdict than any review.

If this was helpful, feel free to follow 「子昕AI编程」, and also give it a like, a "wow," or forward it to friends who are also tinkering with AI coding tools.