Step 5 Preview writes a 3D Chinese Chess game, launched in two hours

Author: 怕浪猫

Tags: 前端, JavaScript, 面试

Let me put the thing out there first. A 3D Chinese Chess game: the Chu River Han Boundary is written directly on the wood-grain board, seven kinds of pieces each with their own distinct 3D shape, red side in cinnabar lacquer with gold characters, black side in ebony with gold characters, and a spotlight slowly rotating around the board. Full rules — horse leg blocking, elephant eye blocking, cannon jumping over a piece to capture, generals and advisors not leaving the palace, draw after sixty moves without a capture — all implemented. Move generation passed the authoritative perft validation (44 / 1920 / 79666, matching the reference values on the Chess Programming Wiki), and 52 assertions all pass. Link: https://jlnvv-tom.github.io/chinese-chess/

It wasn't drawn by me stroke by stroke, nor by an art team: it was generated from scratch in one day by Step 5 Preview. This post breaks down two things: what this model's benchmark numbers really mean, and where it excels and stumbles when writing 3D content like this.

First, look at the results

SHOWTIME · Six real screenshots

Global view. Seven pieces with seven different shapes, all assembled from Three.js primitives; you'll find no model file anywhere in the project.

Red side close-up. The character plates are procedurally generated Canvas textures with gold paint outlines; the font size went through three rounds of adjustment before it was legible.

Chu River Han Boundary. Those four characters once disappeared entirely — three.js r149 without declaring sRGBEncoding will tone-map the texture to white.

The cannon's capturing over a piece is drawn as a parabolic trajectory. Invisible rules are the biggest confusion point for beginners, and this layer was added by the model itself.

Check state, the checked side pulses with red light. This detail came from an iteration after my feedback, not from the first version.

Floating zoom buttons at bottom right. The first version had the direction reversed — pressing + zoomed out.

Behind all these visuals there are no asset files: the pieces are shapes assembled from Three.js primitives, the wood grain rings, gold-painted character plates, glows, distant mountain silhouettes — all procedurally generated textures from Canvas. The lighting is dynamic — the main spotlight slowly circles creating moving shadows, a cool-colored rim light breathes, red light pulses on check, plus firefly particles, rising light dust, and volumetric light beams.

Open your current project and answer one question first: how many of your visual effects are 'supposed to be generated by code' but you're still manually cutting images?

02 PART

What model is this?

THE MODEL · 600B MoE

Step 5 Preview is the flagship base model of StepFun (阶跃星辰). The API went live on September 20, 2026, and the weights were opened on October 15, 2026 as agreed. The Hugging Face repo is stepfun-ai/Step-5-Preview-BF16, split into 28 shards.

The architecture is sparse MoE: 600B total parameters, only 27B activated per token (about 4.5%), 92 layers of a 'narrow and deep' Transformer, 1M token context, native support for text, image, and video input. The price list is also here:

Item	Number
Input price	$1 / million tokens
Output price	$2.7 / million tokens
Cache read	$0.05 / million tokens
Context window	1M tokens
Generation speed	about 100 token/s (official claim)

If you want to self-host, look at the requirements first: the official FP8 solution needs 4x B300 or 8x H200; BF16 weights are about 1.2TB, and based on Forkast's estimate, close to 8x H100 80GB. The community already has third-party GGUF quantized versions circulating, about 2000 downloads in eight days — that's the realistic path for most people.

03 PART

Benchmark numbers: what to trust, what to discount

BENCHMARKS · Self-reported vs third-party

I pulled together a table of all public benchmarks I could find, marking the sourcing — official self-reported and third-party verified are not equally credible:

Benchmark	Score	Source
Artificial Analysis Intelligence Index	44 (v4.3.2)	Third-party
Terminal-Bench 4.0	33.3%	Third-party
Terminal-Bench 2.1	85.0%	Third-party
DeepSWE v1.1	67.7%	Official self-report
SWE-Marathon v1.1	72.7%	Official self-report
CyberGym	84.7%	Official self-report
GPQA Diamond	93.5%	Official self-report
FrontierFinance	66.4	Official self-report

Two readings deserve special mention

First, the gap to closed-source flagships is clear on coding benchmarks: on DeepSWE v1.1, Claude Opus 5 scores 74.0% vs Step 5 Preview's 67.7% — a 6-point gap on the same leaderboard, while according to StepFun's official claims, the per-task cost is about one-eighth of Claude Opus 5. Whether that price difference is worth 6 points depends on what tasks you run.

Second, look at the structure rather than total scores. On Terminal-Bench 4.0 it scores 2.6x Kimi K3 (33.3% vs 12.6%), while both have the same AA Intelligence Index of 44. General intelligence is tied, but agentic tasks separate them — pointing to differences in training objectives: long-horizon reinforcement learning plus context compression, specifically tuned for multi-step tasks.

There's also an official internal test: it autonomously optimized a GPU kernel, running 22 hours straight, finishing at 508 TFLOPS, beating Claude Opus 5's 493 TFLOPS on the same problem, at about one-eighth the cost — this is a vendor-internal claim, not externally reproducible, so take it as a direction.

The market has voted with its feet: on October 10 it topped the OpenRouter Trending chart, with both weekly and daily call volumes ranking second globally.

04 PART

One-day field notes: where it shines, where it trips

FIELD NOTES · First-hand process record

Benchmarks are someone else's numbers. I have first-hand ones. This chess project went from zero to delivery in a single day, with every step and pitfall recorded.

Let's start with the strong points.

Rule correctness isn't a fluke

perft (move enumeration count) initial position validation 44 / 1920 / 79666 all three levels correct. Here's a detail: in the initial position each cannon has 12 moves, the 12th being 'capture the opponent's bottom-line horse across an enemy cannon' — the black cannon acts as the screen. This move is easy to miss by hand deduction. The model enumerated it itself, and also added 52 Node assertions to prevent regressions.

Testing awareness came built in

Node unit tests, Playwright browser game tests, single-file file:// verification — a full pipeline. Delivery was also complete: build scripts, README, screenshot documentation, none missing.

The deliverable is complete

11 JS modules cleanly separated (rules/textures/pieces/scene/camera/sound/AI/interaction/UI/main control), one build script produces a 701KB single file that runs directly from file://, playable even offline.

Now the stumbles — each one I only found by actually running it:

1

three.js r149 color management: CanvasTexture without explicitly declaring sRGBEncoding is treated as linear color, and after ACES tone mapping everything washes out white — the 'Chu River Han Boundary' characters fade to invisible. This isn't the model not knowing; it's a version-specific gotcha that only shows up when run on real hardware.

2

Geometry coordinate consistency: the board box top surface is at y=0.64, but pieces stand at 0.61, sinking into the board; the engraving line lengths were also over (horizontal line written as 8.72, should be 8.0). These errors are invisible in code, only visible when rendered.

3

Interaction details come in a string: clicks during animations are silently swallowed, requiring a pendingCell click queue; zoom direction was reversed in the first version; camera projection center conversion missed a divide-by-2; when undoing a move, the piece's rotation wasn't reset, so pieces lay flat.

So the real division of labor for this day was: the model did 90% of the work to 90 points, and the remaining 10% was 'problems you only find when you actually run it', all caught by a human acting as the acceptance checker. And the validation tool for this project was perft and assertions — without them, you'd have no way to know if the model's rules engine was correct.

05 PART

What this means for people who write code

WHAT IT MEANS · Three judgments

Three judgments, not necessarily right, for reference.

1

The bottleneck is shifting from 'writing' to 'verifying'. The speed at which the model produces output is no longer the constraint; the constraint is your ability to judge whether it's correct. In the chess project, the validation tools were ready-made: chess has perft, an authoritative count. What does your business have? Test coverage, data reconciliation, or a pair of eyes staring at screenshots?

2

Open weights change the cost of trial and error. APIs are pay-as-you-go, OpenAI-compatible, low migration cost; self-hosting is extremely demanding (8 GPUs minimum), but community quantized versions have made 'running a 600B model on your own hardware' possible. For individual developers, this is the first time you can touch a Chinese flagship model of this scale.

3

Don't trust any single leaderboard. The same model scores 67.7% on DeepSWE, not top-tier, but on Terminal-Bench 4 it's a 2.6x performer in the open-source set. Read benchmark numbers together with their methodology; separate self-reported from third-party verified.

Apply this to yourself: if tomorrow you ask a model to rewrite your core module, how do you judge whether it's correct? If you can't answer, don't rush to change tools — first strengthen your verification.

///

LAST

Afterword

CLOSING · A day of reversed roles

The biggest shock from this chess project wasn't that 'the model can write 3D', but the complete reversal of roles: the most time I spent that day wasn't writing code, but being the acceptance checker — running perft, checking assertions, staring at screenshots, reproducing every odd thing users reported. The model was fast, I was right.

Step 5 Preview's numbers are there: 600B params, 27B active, AA index 44, open weights live. It's not perfect — 6 points behind the closed-source flagship on DeepSWE, and it still trips on version-specific pitfalls like color management. But the fact that 'from zero to a playable 3D chess game in one day' happened shows the domestic flagship has entered the usable range.

The model was fast, I was right.

I've organized the chess source code, all screenshots, and raw benchmark tables. Reply 'step5' in the backend to get them.

Do you have something you've long wanted to build but were stuck on art/front-end? Leave a comment below and I'll pick the most upvoted one and write it from scratch with the same model in the next issue.

Since you've read this far, if you found it useful, a like, bookmark, and forward would be appreciated.