Flash Models Are No Longer Pro's Cheap Backup — They're the Execution Layer for Agents
The model world has always been lively, with new models emerging every month.
In the past month, domestic large models have been launching new ones continuously — Step 3.7 Flash, MiniMax M3, GLM-5.2, and Kimi K2.7 Code were all released almost back-to-back.
I took a close look at these new models, and their approaches are somewhat different. Step 3.7 Flash focuses on cost-effectiveness and low latency, MiniMax M3 goes all-in on ultra-long context and Agentic Workflow, GLM-5.2 takes a general-purpose open-source route, and Kimi K2.7 Code specifically serves programming scenarios.
Looking at the current landscape, one trend is very clear: competition among large models is no longer just about who has the best performance or the strongest reasoning ability. Everyone is now pushing toward the Agent direction — in high-frequency usage scenarios, it's about which model is easy to use, stable, and more cost-effective.
Previously, when we talked about Flash models, we all thought of them as cheap substitutes for the Pro version, not very useful. Complex tasks went to Pro, simple and unimportant ones were thrown to Flash — Flash was just a cost-saving option.
Now, the situation is different. Flash models are no longer the backup we used to talk about; they have become a separate category, and every model vendor is launching this type of model.
Currently, we can simply divide models into two tiers.
The first is the Pro tier. It focuses on extreme reasoning, complex programming, and long-chain Agent tasks. Models like Claude Opus 4.8 and GPT-5.5 fall into this category. They score very high on difficult evaluation sets, but their prices are also very high. Running a few high-frequency tasks can make the bill a bit hard to stomach.
The second can be called the Flash tier, or the efficiency frontier. Step 3.7 Flash, DeepSeek V4 Flash, Gemini 3.5 Flash, and Qwen3.6 Flash are all in this camp. These models don't pursue the strongest single capability; instead, they find a balance between speed, cost, context length, and stability in high-frequency, multi-turn, low-latency, large-scale usage scenarios.
Especially in Agent scenarios, the role of Flash models is increasingly like that of an execution-layer model. It may not be responsible for the most extreme reasoning, but it needs to handle the decomposition of a large number of actual tasks, tool calls, code generation, error fixing, and result organization.
Therefore, judging whether a Flash model is good cannot rely solely on benchmark evaluations or simple single-turn Q&A. You have to see whether it is stable in real tasks, makes fewer mistakes and requires less rework, and can complete a task in one go.
Today, let's first take Step 3.7 Flash for a test, put it alongside several other Flash models, and run through real projects from three angles: code generation efficiency, response speed and cost, and tool-calling stability, to see which one is actually better to use.
Test Method
We are using Claude Code here for testing. Since there are many models to test, we can install cc switch. After configuring each model vendor, you can switch with one click, which is very convenient.
You can also switch models by modifying the JSON configuration file ~/.claude/settings.json, for example, the configuration for Step 3.7 Flash:
export ANTHROPIC_BASE_URL="https://api.stepfun.com/step_plan"
export ANTHROPIC_AUTH_TOKEN="your key"
export ANTHROPIC_MODEL="step-3.7-flash"
A heads-up in advance: this is not a particularly rigorous benchmark. It's more like I ran a few real tasks myself to see how the models perform when actually doing work.
Because during actual testing, the toolchains available to different models are not exactly the same. For Step 3.7 Flash, DeepSeek V4 Flash, and Qwen3.6 Flash, I mainly ran them in Claude Code. For Gemini 3.5 Flash, I could only test it inside Google Antigravity.
So when you see data like time, tokens, and error counts later, don't interpret them directly as a leaderboard. We're not trying to prove who is number one, but rather to see which model is more stable, makes fewer mistakes, and ultimately delivers a usable finished product in real Agent tasks.
Case Tests
Case 1: Building a Developer Log Site from Scratch
In this case, we mainly compare the two models Step 3.7 Flash and DeepSeek V4 Flash.
I directly fed the following prompt to Claude Code, running each model once:
This task is not particularly difficult. The model needs to understand the tech stack requirements, set up the Next.js project structure, configure Markdown parsing, write list and detail pages, add tag filtering and syntax highlighting, and generate 5 decent sample log entries.
If any step in the middle goes wrong, the project might not run, page functionality could be incomplete, or the frontend display might not look great.
Let's first look at the results from deepseek-v4-flash.
The overall page functionality met the requirements. The model produced the result in one round without requiring multiple prompts from us. During execution, the model encountered 3 errors during compilation, all of which it fixed itself, ultimately delivering a usable web page product.
Now let's look at the results from Step 3.7 Flash.
This page was also generated in one round. The layout adopted a card-based grid structure, with each article displayed as a combination of title, description, and tags. Clicking a card enters the detail page. Compared to DeepSeek V4 Flash's more list-oriented information presentation, the page generated by Step 3.7 Flash emphasizes visual hierarchy more. The navigation bar has fixed category filtering, and the interaction is closer to a mature blog system, with a more polished overall look.
Which style do you prefer between these two web pages? I lean more towards the step-3.7-flash style.
After looking at the results, let's examine the time and cost consumption. I made a comparison chart:
| Item | deepseek-v4-flash | step-3.7-flash |
|---|---|---|
| Total Input | 726.6k | 747.4k |
| Total Output | 14.0k | 25.7k |
| API Time | 2m 1s | 2m 30s |
| Estimated RMB Cost | ¥0.72 | ¥1.22 |
From the chart, the input tokens for both models are basically similar. Step 3.7 Flash's model output is much more — could this be the reason the result looks better? The API time consumed doesn't have a big gap either. In terms of cost, DeepSeek is indeed cheaper. Looking at API pricing, it seems no model domestically or internationally can compare with DeepSeek.
Case 2: GitHub Project Radar
Let's see how Step 3.7 Flash and Gemini 3.5 Flash compare in performance.
The prompt is as follows:
Help me build a GitHub Project Radar from scratch:
- Use a Python script to scrape this week's trending AI projects on GitHub Trending
- Extract for each project: name, star count, language, description, last update time
- Auto-classify (Agent Framework / Model Inference / RAG / Multimodal / Toolchain / Other)
- Generate an HTML report page: category cards + statistical summary + raw data table
- The project should run directly and output `report.html`
Let's first look at Gemini 3.5 Flash's results, feeding the prompt directly to Google Antigravity.
The task was completed in one go. Although there were 2 tool errors in the middle, the model auto-fixed them without human intervention, ultimately providing a complete, runnable script and page.
Gemini's task completion was fine, but the page organization was relatively loose, with unfriendly information density and visual hierarchy.
Now let's look at Step 3.7 Flash's results, feeding the same prompt to Claude Code.
The task was also completed in one go, with no errors occurring during the process, providing a complete, runnable script and page.
The page adopted a card-based layout, with each card clearly presenting the project name, short description, programming language, total stars, and weekly increment. Information density is moderate, and visual hierarchy is clear. A slight drawback is that the category navigation is not fixed at the top; you need to scroll to the corresponding area to see other categories. But overall typography, font, and spacing control are relatively comfortable. Step 3.7 Flash is closer to a deliverable dashboard page.
In this round of tasks, Step 3.7 Flash consumed a total of 406.5k input tokens and 18.7k output tokens, with no cache hits. In terms of execution time, API time was 2 minutes 25 seconds, and the full Wall time was 4 minutes 45 seconds. Based on Step 3.7 Flash's official pricing, this task cost approximately 0.7 RMB.
Gemini 3.5 Flash's consumption is hard to check; there is no place to view the records. The time consumed was similar on both sides, around 3 minutes. Here it only showed that 28% of the quota was consumed, and the specific token consumption cannot be viewed.
Case 3: Source Code Interpretation
Writing code is only part of a Coding Agent.
Another high-frequency scenario is reading code, something we often encounter: taking over an unfamiliar project, understanding an open-source library, analyzing the core chain of a framework, and then turning it into documentation the team can read.
So for the third case, I chose a source code interpretation, asking it to analyze the source code and output an HTML page. This source code interpretation requires multiple rounds of tool calls, so we can see how they perform in multi-turn tool calling.
The prompt is as follows:
Please analyze the source code of this GitHub open-source project and generate a static HTML architecture analysis report.
You are required not to just look at the README, but to analyze based on the source code directory, core modules, classes, and function call relationships.
Analysis objectives:
1. What does this project do?
2. What problem does it solve?
3. What is the core architecture?
4. How do the main modules collaborate?
5. How does a memory write flow proceed?
6. How does a memory retrieval flow proceed?
7. What external components does it depend on, such as LLM, Embedding, Vector Store, Graph Store, databases, etc.?
8. If I were to implement a simplified version myself, what is the minimum core chain?
9. What are the advantages, complexities, and potential limitations of this project?
Please complete the following tasks:
1. Scan the project directory
- Find the core source code directory
- Find the main entry files
- Find core classes, core functions, and key configuration files
2. Analyze the source code structure
- Explain the responsibility of each core module
- Explain the call relationships between modules
- Don't speak in generalities; try to point out specific file paths
3. Generate an architecture report
- Create `mem0_architecture_report.html`
- Use pure HTML + CSS, do not rely on external CDNs
- The page needs to include the following chapters:
- Project Overview
- Directory Structure Interpretation
- Core Module Descriptions
- Memory Write Flow
- Memory Retrieval Flow
- Key Classes and Functions Table
- Architecture Flowchart, using HTML/CSS or Mermaid code blocks
- Simplified Implementation Ideas
- Advantages and Limitations
- List of Source Files Suitable for Reference
4. Report Requirements
- Content should be suitable for engineers to read
- Don't just write concepts; combine with source code file paths
- Each core conclusion should try to annotate which file or directory it comes from
- The HTML page should have clear typography
- Code paths should be displayed in monospace font
- Tables should be clear and readable
5. Acceptance Criteria
- Must ultimately generate `mem0_architecture_report.html`
- The report should be directly readable when opened
- If you find the source code structure inconsistent with the README description, the source code prevails
Let's first look at Qwen3.6 Flash's results.
During execution, there were multiple tool call failure scenarios, but the Agent fixed them all in the end, completing the task in a single conversation.
Overall, the result was acceptable. It completed the task according to our requirements, and the source code summary of the memo0 memory architecture framework was quite on point.
Now let's see how Step 3.7 Flash performs.
During execution, no tool call errors occurred, and all tasks were completed in one go. Compared to Qwen3.6 Flash, the difference is not huge, except there is an extra navigation menu on the left that allows direct clicking to quickly jump to the desired section.
After looking at the results, let's examine the time and cost consumption. I made a simple comparison table for everyone to see.
| Item | Qwen3.6 Flash | Step-3.7-Flash |
|---|---|---|
| Total Input | 1.38M | 1.2M |
| Total Output | 40.8k | 20.6k |
| API Time | 6m 17s | 4m 08s |
| Estimated RMB Cost | Approx ¥2.07 | Approx ¥1.79 |
Horizontal Comparison After Several Rounds of Testing
| Dimension | Step 3.7 Flash | DeepSeek V4 Flash | Gemini 3.5 Flash | Qwen3.6 Flash |
|---|---|---|---|---|
| Tool Call Stability | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★☆☆ |
| Error Self-Repair Ability | High | High | High | High |
| UI/Frontend Aesthetics | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★★☆ |
| Single Token Cost | Medium | Low | Medium-High | Medium |
| Hidden Rework Cost | Low | Medium | Medium | Medium |
From this table, it's clear that the cost of a Flash model cannot be judged solely by the single token price.
DeepSeek V4 Flash's single token cost is indeed lower, which is a significant advantage. But in Agent scenarios, another variable truly affects cost: the retry cost after failure. For example, tool call failures, repeated code error modifications, page structures not meeting expectations, reports needing manual secondary organization — all these become hidden costs.
Let's break down the cost of an Agent into two parts:
Total Cost = Token Cost + Failure Retry Cost + Human Intervention Cost.
From these rounds of testing, Step 3.7 Flash is not the cheapest model for a single call, but its tool call stability is better, rework is less, and the final deliverable completion is higher. Therefore, if the task is a high-frequency, multi-turn Agent execution scenario requiring continuous tool calls, the comprehensive cost of Step 3.7 Flash may not necessarily be higher; instead, it might be a more worry-free choice.
When to Choose Step 3.7 Flash
After the case tests above, everyone should have an intuitive feel for Step 3.7 Flash. If I were to position Step 3.7 Flash, my view on it is:
Its price is indeed a bit more expensive than DeepSeek, and its context window cannot compare to DeepSeek and Gemini, but its tool call stability, API response speed, and frontend interface aesthetics are very good.
It is not the strongest model in any single aspect, nor does it have obvious shortcomings. It is one of the models prioritized for the real Agent execution layer within the current Flash model tier, based on a comprehensive assessment of speed, cost, and stability.
Scenarios suitable for choosing Step 3.7 Flash:
High-frequency, multi-turn, low-latency Agent tasks
Production-grade coding-agent workflows with requirements for both speed and stability
Needing multimodal understanding, such as screenshot-to-code, chart-to-conclusion
Budget-sensitive but unwilling to sacrifice too much stability
Step 3.7 Flash also has a relatively obvious shortcoming: its context window is only 256k.
If you need to process a large amount of codebase, long documents at once, or need to stuff a lot of materials into the context, this window might not be enough. In such scenarios, DeepSeek V4 Flash would be more suitable.
There is no absolute optimal model; it still depends on the scenario.
Final Summary
In real projects, we are not just pursuing how smartly a model answers, but hoping it can execute tasks stably and controllably, round after round, without constantly making mistakes and requiring rework.
The cases we did can only serve as a reference. The model truly suitable for you still needs to be run through your own projects.