DeepSeek V4.1 Flash Gray Test Comparison: Godot + Rust Box Selection Feature Hands-On

Bilibili creator tests suspected DeepSeek V4.1 Flash gray-test version; box selection quality clearly better than old version.
A Bilibili creator used a real Godot + Rust game editor project to test the suspected DeepSeek V4.1 Flash gray-test version, with the same prompt requiring a Blender-style left-click box selection feature. The old version had a logic bug causing flicker from mistaken selection; the new version correctly handles click vs. drag. The test indicates improved understanding of editor interaction state machines and generalization on a non-mainstream stack, but the single-source info is unconfirmed officially.
DeepSeek's new model appears to have entered gray testing. A Bilibili creator ran a comparison using a real Godot + Rust project: with the same prompt, the implementation quality gap between the old version and the suspected V4.1 Flash was obvious.
Test Background: A Down-to-Earth Real Project
This comparison didn't use a toy demo, but a game editor scenario: implementing a Blender-style left-click box selection feature in a project using the Godot engine with Rust. The prompt was straightforward — "in the current edit mode, add left-click box selection similar to Blender."
This kind of requirement places high demands on the model: it needs to understand the editor's interaction state machine, and also handle the boundary between two operations — "click to select" and "drag to box select." The creator ran the old version and the suspected October 17 gray-test V4.1 Flash with the same prompt, and the difference was visible at a glance.

Godot is an open-source cross-platform game engine supporting GDScript, C#, and languages like Rust connected via GDExtension. Rust is often used in game toolchains to write high-performance editor plugins or low-level modules; when paired with Godot's node-scene system, it requires bridging the engine event loop with Rust-side state management. Box selection is a common interaction in editor-type software: on mouse press, record the starting point; after dragging beyond a threshold, draw the selection box; on release, select the objects inside the box; if the displacement does not exceed the threshold, treat it as a click selection. This "click vs. drag" determination is a classic input state machine problem. For AI programming, the difficulty is not syntax, but accurately modeling state transitions and cancellation logic.
Old Version Implementation: Click and Drag Logic Conflict
First, the previous version. The creator pointed out that "the implementation has problems," and a closer look at the operation reveals a typical bug: on left mouse click, the object is selected first; after dragging, this selected object is deselected, and then box selection begins.



This behavior shows that the model did not correctly distinguish the intent of "click" and "drag" — it treated mouse press as selection, and only rolled back the state once displacement exceeded the threshold. For users, every box selection flashes a selection highlight, making the experience disjointed. This kind of state management problem is exactly a common weakness of AI programming: the model can write code that runs, but the interaction details don't hold up to scrutiny.
V4.1 Flash Gray Test Version: Right on the First Try
With the same prompt switched to the suspected October 17 gray-test V4.1 Flash, the creator's assessment was "implemented perfectly." Although the original material did not break down the new version's code frame by frame, from the comparison context, the new version correctly handled the order of click and drag determination, and the box selection process no longer has the flicker of mistaken selection.
For developers, the value of this case lies in verifying one thing: the model's depth of understanding for tasks like "editor interaction" that require state machine thinking is improving. Box selection looks simple, but behind it lies a chain of logic including input event routing, drag threshold determination, and selection set management. Getting it right in one pass shows that the model has a more accurate grasp of contextual intent.
"Gray testing" refers to a mechanism where a product opens a new version to a small group of users before official release to collect feedback. Here, the name "V4.1 Flash" suggests the model may belong to the Flash series focused on inference speed, while the version number V4.1 points to iteration on the DeepSeekAd model line. Since there is no official confirmation, the community can only infer version changes through observed behavioral differences in testing. For developers, the value of a gray-test version lies in observing the model's capability boundaries on specific tasks in advance, but note that gray versions may be adjusted at any time and should not be relied upon in production environments.
Practical Significance for AI Programming
A single test cannot represent overall capability, but the Godot + Rust combination itself has reference value: it is not a mainstream web stack, and training data is relatively sparse, yet the model can still produce a usable implementation, indicating that generalization ability is strengthening. If you work on game toolchains or editor-type development, this kind of gray-test version is worth watching.
It should be noted that the current information comes from a single creator's hands-on test, and whether V4.1 Flash will be officially released and what the exact version number is have not been confirmed officially. It is advisable to treat it as a valuable community signal rather than a definitive conclusion.
FAQ
Is V4.1 Flash an official version? Currently it is only a suspected gray test discovered by a Bilibili creator, and has not been announced officially.
What tech stack was used for the box selection feature test? The Godot engine with Rust, in a game editor scenario.
What is the core difference between the old and new versions? The old version mistakenly selects an object on click and then rolls back, while the new version correctly handles the click vs. drag determination.
One-line Summary
A Bilibili creator hands-on tested the suspected DeepSeek V4.1 Flash gray-test version, and the box selection implementation quality is clearly better than the old version.
Paragraph Summary
A Bilibili creator used a real Godot + Rust game editor project to test the suspected DeepSeek V4.1 Flash gray-test version, with the same prompt requiring implementation of a Blender-style left-click box selection feature. The old version had a logic bug where clicking mistakenly selected an object and then rolled back, causing flicker during box selection; the new version correctly handles click vs. drag determination and runs smoothly. The test shows improved model understanding of editor interaction state machines, and generalization ability even on a non-mainstream tech stack. However, the information comes from a single source, official release is unconfirmed, and it should be viewed as a community signal rather than a definitive conclusion.
Related articles

Uber Deploys ChatGPT Work Company-Wide: AI in the Workplace Enters the Scaled Implementation Phase
Uber deploys ChatGPT Work to 30,000+ employees, extending it from engineering to all roles. We analyze its expert-engineer pairing, end-to-end automation, and questions of AI control and power concentration—insights for scaling AI in the workplace.

Shift at Midnight Hands-On: When "ID Verification" Becomes Alien Hunting
Shift at Midnight blends ID verification with horror survival in a four-player co-op game. We break down its inspection mechanics and chaotic humor.

Zelensky Recounts the Outbreak of War: I Need Ammunition, Not a Ride
Zelensky recalls the first day of war in a YouTube interview: farewell to family, rejecting Biden's evacuation offer with "I need ammunition, not a ride," and how Bucha shaped his stance on compromise and peace talks.