Step 5 Preview coding agent performance is attracting attention because the model’s strongest demonstrations are not polished static mockups—they are working projects you can play, inspect, rerun, and break. In a sponsored hands-on review using eight KingBench 3 tasks, StepFun’s new flagship earned 67 out of 80 points, or 83.75%, with especially convincing results in a browser-based archery game and a local fine-tuning workflow.

That number is notable, but it is not the whole story. The more useful question for developers, marketers, founders, and AI-product teams is this: what kind of work can a coding agent actually take from prompt to working deliverable—and where does human review still matter?

The supplied video review offers a useful answer. Step 5 Preview was tested in an open coding environment across simulations, interactive 3D objects, SVG illustration, game development, mathematical reasoning, local model training, and a time-aware 3D interface. Its output suggests that StepFun’s model may be particularly valuable when success can be checked directly in a browser or local runtime, rather than judged solely by whether generated code looks plausible.

What is Step 5 Preview?

Step 5 Preview is StepFun’s flagship model for agentic work, positioned for software engineering, professional knowledge work, long-context tasks, and multimodal understanding. StepFun says the model supports text, image, and video input; a 1 million-token context window; and outputs of up to 64,000 tokens. The platform also supports tool calling, structured outputs, streaming, prompt caching, and configurable reasoning effort. (platform.stepfun.com)

Under the hood, StepFun describes Step 5 Preview as a sparse mixture-of-experts model with 600 billion total parameters and 27 billion active parameters per token. That distinction matters: total parameter count describes the complete model, while active parameters more closely relate to the computation used for each token. In theory, sparse MoE designs aim to deliver capability associated with a much larger model without activating every parameter on every inference step. (stepfun.com)

For builders, the practical specifications are more consequential than the architecture label:

  • 1M-token context can accommodate large codebases, long documentation sets, product requirements, support logs, and multi-file projects.
  • Up to 64K output tokens gives an agent room to plan, write files, repair errors, and explain changes without immediately hitting a short response ceiling.
  • Multimodal input means a workflow can include screenshots, design references, diagrams, or videos in addition to text.
  • Tool use lets the surrounding agent environment execute commands, inspect files, run a development server, and test what the model built.

The final item is easy to underrate. A model does not become a capable coding agent merely because it can write TypeScript or Python in chat. It needs an environment where it can create files, receive terminal output, see runtime failures, revise its code, and validate the result. StepFun’s documentation explicitly notes that tool, search, and code-execution abilities are provided by the application integrating the model—not magically supplied by the model itself. (platform.stepfun.com)

The KingBench result: 83.75%, with important caveats

The review gave Step 5 Preview 67 points out of 80, equivalent to 83.75% or an average score of 8.38 out of 10. Seven of the eight tasks received at least 8/10. The final task scores were:

  1. Elevator simulation: 8/10
  2. Interactive 3D contact lens case: 8/10
  3. Animated folding table: 8/10
  4. Panda eating a burger SVG: 8/10
  5. Playable archery game: 9.5/10
  6. Counting problem: 10/10
  7. Local Gemma 2B fine-tuning app: 9.5/10
  8. 3D wristwatch: 6/10

On the comparison chart retained by the reviewer, the score exceeded the historical figures for MiMo V2.6 Pro (69.38%), MiMo V2.6 Flash (72.50%), and GLM 5.3 Flash (78.75%), while trailing GLM 5.3 at 91.25%. But this should not be interpreted as a clean, universal model ranking.

Why this is a useful review—but not a definitive leaderboard

The video’s methodology has value because it evaluates real artifacts: the reviewer opened projects, interacted with them, ran the game, tested replay behavior, inspected the local web app, and identified defects. That is closer to practical agent use than a benchmark that accepts an answer string without checking whether a generated project actually runs.

Still, several limitations matter:

  • The video was sponsored by StepFun.
  • The Step 5 result came from this review, while some comparison figures were retained historical scores rather than a new, fully controlled side-by-side run.
  • The reviewer used a particular agent environment, reasoning setting, token allowance, and task interpretation.
  • A sample of eight tasks is informative but too small to establish broad superiority across software engineering.
  • Scoring includes human judgment about usability, completeness, and deduction severity.

Those caveats do not invalidate the result. They clarify how to use it. Treat 83.75% as evidence that Step 5 Preview can produce strong outcomes on a mixed set of build-and-test tasks, not as proof that it will beat every competitor on every repository, stack, or deployment environment.

Why interactive prototypes are the standout use case

The archery game is the most persuasive result in the review because it demonstrates a full interaction loop instead of a one-shot visual output. The prompt required four targets, a time-based leaderboard, and higher ranking for faster completion. Step 5 Preview reportedly produced a playable browser game in which users could draw, aim, and release arrows, hit moving targets, account for wind, complete a timed round, see a leaderboard result, and start again.

That is a much higher bar than generating a canvas with a bow graphic. A functioning game needs several pieces to work together:

  • Input handling for aiming and release
  • State management for targets, arrows, hits, misses, and round completion
  • Timing logic
  • Collision detection
  • Leaderboard sorting
  • Replay/reset behavior
  • A UI that makes the state understandable to the player

The review found that the game correctly avoided counting misses as hits and did not let repeated hits on the same target falsely complete the challenge. It also reset the timer, arrows, and targets on replay. The deduction came from an edge case in which a slow score outside a full top-10 leaderboard could show rank zero.

What this means for teams building products

For a founder, product designer, or marketer, a working interactive prototype can be more useful than a page of technical specifications. It can test whether a product idea has a coherent flow before engineering invests in production architecture. It can give a sales team something tangible to demonstrate. It can let user researchers observe where people hesitate, misunderstand a control, or abandon a task.

A coding agent that reliably gets to a playable prototype changes the early-stage workflow. Instead of moving from idea to wireframe to engineering ticket to first test build, a team can often use an agent to create a rough but executable version first. The prototype is not production software, but it becomes a shared object around which product, design, engineering, and marketing can have a concrete conversation.

That said, “working demo” is not synonymous with “shippable application.” The rank-zero defect in the archery game is a small but revealing example. State-heavy interfaces often fail at boundaries: empty states, duplicate submissions, ties, resets, unusual timing, accessibility paths, mobile touch behavior, lost network connections, and persistence across sessions. A capable agent can accelerate the first 80% of visible behavior; teams still need disciplined testing for the last 20%.

The elevator, lens case, and folding table show a pattern

Three 3D or simulation tasks each earned 8/10: an elevator simulation, a contact lens case, and a folding table. These are valuable examples because they show both the strength and the recurring weakness of AI-generated interactive work.

The elevator task required three one-person elevators, queues of people on different floors, randomly assigned destinations, and observable pickup and delivery behavior. Step 5 Preview reportedly created a simulation that moved all 12 generated people to their destinations with no people left waiting or riding. However, overlapping floor controls and a reset bug during pickup reduced the score.

The contact lens case was interactive: its left and right caps could be opened independently, closed again, and viewed through camera controls. But the geometry and default framing needed refinement, and the lens and liquid moved upward with the lids rather than staying in their wells.

The folding table delivered smooth, continuous 3D animation as a slider changed the table’s position. Yet it reversed the intended control direction: moving one way extended the legs while labels described the opposite effect.

The lesson: functional correctness and product correctness are different

These examples demonstrate a practical distinction that teams should put directly into their AI-assisted development process.

Functional correctness asks whether the core mechanism works. Does an elevator pick up passengers? Does a lid respond to a click? Do table legs fold? Does a slider produce an animation?

Product correctness asks whether the implementation behaves as intended across the entire user experience. Are controls unambiguous? Does the model reflect real-world physics or user expectations? Are labels accurate? Are resets safe? Does the initial camera framing make the object understandable? Are edge states handled gracefully?

Coding agents are increasingly strong at the first category. The second category still requires deliberate direction, acceptance criteria, visual review, and behavioral testing.

A good prompt can narrow the gap. Rather than asking, “Build an interactive lens case,” specify acceptance checks such as: “The lens and liquid must remain stationary within each well while the corresponding cap rotates around a hinge,” “both lids must be independently operable,” “the initial camera must frame the entire object,” and “test opening each lid after opening the other.” The more a requirement can be expressed as something a human or script can verify, the more effectively an agent can work toward it.

The local fine-tuning workflow may matter more than the game

The game is visually impressive. The local fine-tuning task may be more strategically important.

According to the review, Step 5 Preview generated a panda-facts dataset, ran a LoRA training job on Gemma 2B using MLX, saved and fused the trained adapter, then deployed a local web interface that generated a different panda fact when refreshed. The reviewer had to correct a cache setup issue and continue the run, but after that intervention the workflow completed. The resulting app reportedly performed inference locally with the trained weights.

This result matters because it spans a full chain of work that is often fragmented across separate tools and roles:

  1. Define a narrow model behavior.
  2. Produce and format training data.
  3. Configure a training environment.
  4. Run the job.
  5. Save adapters or merged weights.
  6. Load the resulting model for inference.
  7. Put the model behind a usable interface.
  8. Verify that the deployed interface is using the trained artifact.

MLX is an open-source framework designed for machine learning on Apple silicon, using Metal acceleration and unified memory. Apple describes it as suitable for experimenting with, training, and fine-tuning generative models locally, while MLX’s official examples include LoRA and QLoRA workflows for parameter-efficient tuning. (developer.apple.com)

Why “locally trained and locally served” changes the conversation

For many teams, local development is not mainly about eliminating API bills. It can also be about data control, repeatability, latency, offline development, and the ability to inspect every file in the pipeline.

A small local model fine-tuned for a narrow task can be useful for:

  • Internal knowledge-base formatting
  • Product catalog normalization
  • Brand-safe copy classification
  • Controlled content transformation
  • Specialized extraction or routing tasks
  • Offline demos and prototypes
  • Educational experiments with model customization

The review’s panda-fact dataset also exposes the central risk. The model completed the pipeline, but generated factual errors in the training data, including an incorrect statement related to pandas in a U.S. zoo. That means the workflow succeeded operationally while being unreliable semantically.

This is one of the most important lessons from the Step 5 Preview review: an agent can automate model training without automating truth. If your fine-tuned model is intended for customer-facing content, healthcare, legal work, financial communications, or any authoritative knowledge task, synthetic or model-generated examples require source-based validation before training. A polished web UI and successful local inference do not compensate for bad data.

Long context helps, but it does not replace task design

A 1M-token context window is a real capability advantage for complex agent workflows. It can let a model hold more repository files, requirements, logs, test outputs, and previous decisions in one working context. StepFun positions Step 5 Preview specifically for long-document analysis, multi-step agent tasks, coding, and multimodal work. (platform.stepfun.com)

But large context should not become an excuse to dump everything into a prompt. More context can include more stale instructions, irrelevant files, contradictory documentation, credentials accidentally copied into logs, and unreviewed assumptions. Larger input also has cost and latency implications.

A better operating model is selective context engineering:

  • Start with a concise product brief and measurable acceptance criteria.
  • Include only the files relevant to the change.
  • Give the agent a project map before sending raw repository content.
  • Ask it to state a plan and identify assumptions before editing.
  • Require tests, screenshots, logs, or manual verification steps as deliverables.
  • Keep a human approval step before merges, deployments, or model-training runs.

The context window gives the agent more capacity to reason over a project. It does not remove the need for a clean source of truth.

Pricing makes Step 5 Preview interesting for iterative agent work

StepFun’s current documentation lists Step 5 Preview pricing at 7 yuan per million cache-miss input tokens, 0.35 yuan per million cache-hit input tokens, and 20 yuan per million output tokens. It also states that both the model’s reasoning process and final response are counted as output tokens. (platform.stepfun.com)

The large discount for cached input is particularly relevant to agentic workflows. Coding agents often repeatedly send common context: system instructions, repository conventions, framework rules, a product specification, and a shared set of files. When a workflow is designed to reuse eligible cached context, repeated iterations may cost materially less than resending the full prompt every time.

Cost is not simply input plus output

Teams evaluating coding models should measure total task cost rather than comparing a single headline price. The real bill depends on:

  • Number of agent turns
  • Amount of model reasoning and generated code
  • How often the environment produces errors requiring retries
  • Whether the agent re-reads large files repeatedly
  • Cache-hit rates
  • Tool-call loops and test cycles
  • The human time spent correcting incorrect direction

A cheaper token price can be expensive if the model takes many attempts. Conversely, a model with a higher output price may be economical if it plans well, produces a complete first version, and successfully repairs its own runtime errors. The best comparison is not “cost per million tokens”; it is “cost per accepted, maintainable result.”

How Step 5 Preview compares with benchmark-first alternatives

The review’s chart places Step 5 Preview below GLM 5.3 but above the historical reference figures for MiMo V2.6 Pro, MiMo V2.6 Flash, and GLM 5.3 Flash on this particular eight-task scorecard. That makes the model competitive, but it does not settle which agent is best for a specific workflow.

Different models can excel at different failure modes. One may be better at deep repository reasoning, another at quick front-end iteration, another at strict tool calling, and another at highly constrained mathematical work. A model that wins a coding benchmark can still produce weak visual hierarchy; a creative front-end model can still mishandle tests; a strong planner can still be slow or costly in a multi-agent loop.

Instead of choosing solely from aggregate leaderboards, run a practical bake-off using three task types from your own work:

  1. A deterministic repair task — for example, fix a failing unit test in an existing codebase.
  2. An interactive build task — for example, create a working onboarding prototype with validation, empty states, and a mobile layout.
  3. A multi-step operations task — for example, ingest structured data, transform it, generate a report, and provide an audit trail.

Score each model against a rubric that covers more than visual polish:

  • Completion without human code edits
  • Correctness of core behavior
  • Test coverage and test results
  • Edge-case handling
  • Code organization and maintainability
  • Dependency hygiene
  • Security and secrets handling
  • Accessibility
  • Time to a usable result
  • Total token and infrastructure cost

That framework will tell you much more than a single percentage.

A practical workflow for using Step 5 Preview as a coding agent

The review indicates that Step 5 Preview is strongest when it can make, run, and inspect artifacts. To get similar value, structure work around visible verification rather than long, open-ended prompts.

1. Write an acceptance-test prompt, not a feature wish

Weak prompt: “Make a dashboard for campaign performance.”

Stronger prompt: “Build a responsive campaign-performance dashboard using mock data. Include date filtering, a channel breakdown, an empty state, loading skeletons, keyboard-accessible filter controls, and a chart with visible labels. Add automated tests for filtering and error handling. Run the app and report the test results.”

The second prompt turns subjective requests into testable conditions.

2. Require a plan before execution

Ask the agent to list files it expects to create or modify, dependencies it will introduce, assumptions it is making, and how it will verify behavior. This catches scope creep before the agent writes hundreds of lines of code.

3. Give it a real feedback loop

Let the agent run linting, type checks, tests, builds, or a development server where appropriate. Agent quality is magnified when it can read its own error output and recover.

4. Inspect behavior, not only source code

Open the prototype. Trigger invalid inputs. Refresh the page. Resize to mobile. Try keyboard navigation. Restart the server. Run through an empty state. This is how the review found issues like control overlap, reversed direction, incorrect object movement, and the leaderboard edge case.

5. Keep generated data separate from validated data

If a model generates a dataset, label it as draft data. Validate claims against authoritative sources, remove unsupported examples, document provenance, and only then use it for fine-tuning or customer-facing retrieval.

6. Turn recurring corrections into reusable rules

If your team repeatedly corrects accessibility labels, date handling, design tokens, analytics events, or API error states, add those standards to the agent’s persistent instructions and code-review checklist. Over time, the value comes from the operating system around the agent—not only the model itself.

The missing community reaction is a signal, too

The supplied source included no top community comments and no independent related coverage. That limits the ability to assess how broadly developers have reproduced the results, whether others encountered reliability issues, or how the model behaves across different tooling stacks.

This is common with new model launches: vendor specifications and a compelling first review arrive before a broad body of third-party testing. StepFun does provide official documentation for the model and API, including model capabilities, reasoning effort settings, multimodal limits, and pricing information, which makes hands-on evaluation feasible. (platform.stepfun.com)

For now, the right stance is neither hype nor dismissal. Treat the review as a strong early signal, then verify the model against your own stack. The most important question is not whether Step 5 Preview can make an archery game under review conditions. It is whether it can help your team consistently complete the repetitive, high-context, testable work that currently slows your roadmap.

The bigger takeaway: execution quality is becoming the model benchmark

The Step 5 Preview review reflects a broader shift in how AI coding systems should be judged. Code generation alone is no longer enough. The relevant unit of value is increasingly the verified outcome.

A verified outcome has several qualities:

  • The project runs.
  • The requested interaction works.
  • Edge cases are addressed or documented.
  • The output can be inspected by a user.
  • Tests or observable checks support the claim of correctness.
  • The code can be revised by a human developer.
  • Data and dependencies are traceable.

Step 5 Preview’s best work in the review—the game and local fine-tuning app—fits this definition better than its weaker wristwatch result. The watch was completed but scored only 6/10 because it was merely adequate rather than exceptional. That gap is instructive: a model can deliver a functional result and still fail to create much product value.

For builders, the opportunity is to use AI agents where output quality is directly observable and iteration is cheap: prototypes, internal tools, simulations, testing harnesses, data utilities, content operations, proof-of-concepts, and local experimentation. For production systems, the same tools should be paired with code review, security controls, observability, deployment gates, and data governance.

Step 5 Preview appears worth testing if your work involves interactive browser prototypes, long-context agent workflows, or local AI experimentation. Its 83.75% score is promising. Its more meaningful accomplishment is showing that an agent can traverse multiple steps—from idea to files to execution to an inspectable experience—without stopping at a code snippet.

FAQ

Is Step 5 Preview open source?

StepFun announced that Step 5 Preview would be released with open weights on October 15, while the preview model is available through its products and API. Before adopting it for a commercial deployment, verify the released weight license, permitted use, hosting requirements, and redistribution terms. (stepfun.com)

What was Step 5 Preview’s KingBench score?

In the supplied hands-on video review, Step 5 Preview scored 67 out of 80, or 83.75%, across eight KingBench 3 tasks. It is a reviewer-scored evaluation rather than a universal or independently controlled leaderboard result.

What were the best Step 5 Preview coding-agent demos?

The strongest demos were a playable archery game with timer, moving targets, leaderboard behavior, and replay support, plus a local Gemma 2B fine-tuning workflow that generated data, ran LoRA training through MLX, saved model artifacts, and served a local web app.

Can Step 5 Preview fine-tune a model locally?

The model itself does not fine-tune another model on its own. In the reviewed workflow, it acted as an agent that set up and executed a local fine-tuning pipeline using Gemma 2B and MLX. The surrounding machine, local framework, commands, and permissions performed the actual training.

Is Step 5 Preview ready for production code?

It may accelerate production development, but the review also found bugs in otherwise strong projects. Use it with automated tests, dependency review, security checks, human code review, and staged deployment practices. Its current sweet spot appears to be generating and iterating on verifiable prototypes and structured development workflows.