DeepSeek V4 Pro Frontend Programming Test: Compared Against Grok 4.6 and Kimi K3

On the same day, two heavyweight models were released simultaneously—Grok 4.6 officially launched, and DeepSeek rolled out its V4 Pro production version. With two highly anticipated models updating on the same day, the community naturally sparked a wave of comparisons. Based on hands-on testing content from a Bilibili creator, this article focuses on the real-world performance of these two models in frontend programming capabilities, with Kimi K3 and an industry benchmark model (referred to as the reference model below) included for cross-comparison.

Parameters and Cost Comparison: Similar Capabilities, Vastly Different Prices

From the officially published parameter benchmarks, Grok 4.6 trades blows with the reference model across different metrics—scoring slightly lower on some indicators while surpassing on others. DeepSeek^Ad V4 Pro follows a similar pattern, with significantly increased parameters compared to its previous version, and the gap with the reference model is not substantial.

In other words, these two models are already very close to the top tier in overall capability. But what truly differentiates them is cost: DeepSeek V4 Pro is significantly cheaper. LLM APIs typically charge by Token (units of input and output text), and pricing strategies vary enormously between providers. For code generation scenarios, a single complex frontend project generation might consume thousands to tens of thousands of output tokens. The DeepSeek series is known for its highly competitive pricing, with input/output token prices typically only one-tenth or even less than international models of equivalent capability. This means in actual development, if a task requires multiple rounds of iterative debugging (extremely common in AI-assisted programming), the cumulative cost advantage of a low-cost model is further amplified. For enterprise applications or high-frequency calling scenarios, the cost difference can shift from "negligible" to "decisive factor." This is also a core perspective of this test—not just looking at who performs best, but who is more competitive in terms of "cost-effectiveness."

This test uniformly used Clock Code as the tool to ensure consistent testing environments and comparable results. Clock Code is a visual testing tool specifically designed for evaluating AI code generation capabilities. It can directly render and display the frontend code generated by AI models, allowing testers to compare output quality from different models in a unified environment. Compared to manually running code in a local IDE, the advantage of such tools lies in eliminating interference from environmental differences (such as browser versions, dependency library versions) on test results, ensuring fair comparison. The models included in the comparison are: Grok 4.6, DeepSeek V4 Pro production version, DeepSeek V4 Flash production version, as well as Kimi K3 and the reference model as controls.

Test One: Burning Paper Particle Effect Implementation

The first test case evaluates the finesse of frontend particle effects—simulating a piece of paper burning from the bottom-right corner, with the background dynamically changing with the flames, accompanied by drifting ash.

Frontend particle effects (Particle System) are a computer graphics technique that simulates natural phenomena through large numbers of tiny graphical elements. In web frontend development, particle effects are typically implemented using Canvas 2D, WebGL, or CSS animations. Simulating a burning effect requires handling multiple technical challenges: particle lifecycle management (generation, movement, death), color gradients (from bright yellow to dark red to gray), physics simulation (hot air rising, gravity and wind calculations for falling ash), and blending modes with the background. This type of effect places high demands on a model's code generation ability because it requires not only correct algorithmic logic but also a certain "understanding" of visual aesthetics—particle density, randomness of motion trajectories, frame rate optimization, and other details all directly affect the final rendered result.

Performance Comparison of Each Model

• Kimi K3: Flames ignite from the bottom-right corner, background changes according to the fire, ash effects are natural, and overall performance is excellent.
• Grok 4.6: The burning process is smooth with ash effects present, but flame finesse falls short of K3, slightly inferior.
• DeepSeek V4 Pro: Flame effects are weak, the image looks "overexposed," and lacks ash details, performing relatively poorly.
• DeepSeek V4 Flash: Almost failed to achieve the intended effect, the worst in this round.

In this particle effect test round, Kimi K3's flame finesse was the most impressive, while the DeepSeek series exposed shortcomings in visual presentation.

Test Two: 3D Lighthouse Comprehensive Scene Development

The second test case is more challenging—a complex 3D scene containing multiple elements: a lighthouse^Ad, ocean, ships, heavy rain, lightning, and an interactive alarm system. Test items include adjustable wave height, storm intensity, and ship scanning and lock-on functionality in "emergency mode." This case comprehensively tests the model's 3D development capabilities.

Frontend 3D scene development typically relies on WebGL wrapper libraries like Three.js and Babylon.js. Building a complex scene containing a lighthouse, ocean, ships, and weather system involves multiple technical layers: geometry modeling and material texturing, lighting systems (point lights simulating lighthouse beams), shader programming (Shaders for real-time ocean surface wave deformation), particle systems (raindrops and lightning effects), physics engines (wave dynamics), and interaction logic (raycasting for ship selection and lock-on). The challenge this type of comprehensive scene poses to AI code generation models is that it needs to simultaneously coordinate multiple subsystems including the rendering pipeline, animation loop, user input, and state management—any code error in any single component could cause the entire scene to crash or display visual anomalies.

Reference Model: In a League of Its Own

The reference model's performance is benchmark-worthy: lighthouse, raindrops, adjustable ocean waves all present and accounted for, storm intensity is controllable, and emergency mode quickly locks onto and continuously scans ships with complete and smooth interaction logic.

Kimi K3: Infinitely Close to Benchmark Level

Kimi K3 also delivered an impressive result—lighting and ocean surface are well-rendered, waves can be amplified to become more complex, and emergency mode can locate ships. Overall slightly behind the reference model, but already very close.

Grok 4.6: Minor Detail Flaws but Generally Usable

When Grok 4.6's quality settings are pushed to maximum, the waves present a "separate canvas" feel, not quite resembling a boundless ocean. This is likely related to its generated Shader code lacking seamless edge-handling techniques for the ocean surface—excellent ocean rendering typically requires multiple layers of noise overlay and distance fog to create the visual illusion of infinite extension. The rain effect is decent, and emergency mode can locate ships. Overall slightly behind Kimi K3 but still at a usable level.

DeepSeek V4 Pro: First Version Failed, Improved on Retry

DeepSeek V4 Pro's first version was almost unusable—the lighthouse was broken, and there was a black shadow continuously overlapping on the screen. Such issues typically stem from coordinate calculation errors in 3D objects or frame buffers not being properly cleared in the render loop. Interestingly though, it was the only version that came with background music, indicating the model considered the audio dimension when understanding "scene atmosphere" requirements. After starting a new conversation and running it again, the results improved significantly—emergency mode could locate ships, but black shadow residue and screen flickering issues remained.

DeepSeek V4 Flash: Lowest Completion Rate

The Flash version lacked raindrop effects, waves were barely visible, and there were unidentifiable elements on screen, with overall low completion quality. As a lightweight model, the Flash version has weaker parameter scale and inference depth compared to the Pro version. When facing complex code generation tasks requiring long context and multi-system coordination, its capability limitations are fully exposed.

Overall Ranking: Balancing Performance and Cost

If cost is not considered, the ranking is clear:

1. Reference Model — In a league of its own
2. Kimi K3 — Infinitely close to the reference model
3. Grok 4.6 — Better than DeepSeek V4 Pro
4. DeepSeek V4 Pro — Acceptable completion, needs fine-tuning
5. DeepSeek V4 Flash — Weakest in this test

But if cost is factored in, the conclusion changes significantly:

• DeepSeek V4 Pro becomes the top choice. While its completion rate isn't the best, it can achieve decent results through multiple adjustment rounds at a cost far lower than Kimi K3 or the reference model. In actual development workflows, AI-assisted programming almost never generates perfect code on the first try—it typically requires 3-10 rounds of iterative optimization, at which point the per-call cost difference accumulates and amplifies.
• Grok 4.6 is the second-best choice, with reasonable pricing and quite good results.
• Kimi K3 and the reference model deliver the best results but at higher cost.

Conclusion and Model Selection Recommendations

It should be emphasized that two test cases cannot fully represent a model's true comprehensive capability—actual model selection should be based on specific use cases. You may not have noticed, but DeepSeek has consistently had a relative weakness in visual capabilities, which was once again confirmed in this frontend effects test. The DeepSeek series models prioritize optimization for logical reasoning, mathematical computation, and general code generation during training, and their training data and reinforcement learning strategies may have relatively insufficient coverage of frontend visual effect code. Frontend visual development differs from backend logic programming—it requires the model to have good code-mapping ability for "perceptual" aspects like spatial layout, color coordination, animation timing, and rendering pipelines. This weakness is not insurmountable—through targeted fine-tuning datasets (such as large collections of high-quality frontend animation code libraries) and specialized RLHF (Reinforcement Learning from Human Feedback) training, subsequent versions could achieve significant improvements in this dimension. Frontend development is an indispensable part of software engineering, and we hope future model updates will specifically strengthen capabilities in this area.

For developers, this comparison conveys a clear signal: the absolute capability gap between models is narrowing, and cost efficiency is gradually becoming the key variable influencing model selection. In an era where AI-assisted programming is increasingly prevalent, choosing a model is no longer just about "who's strongest" but rather "within my budget and usage frequency, who can provide the optimal overall experience"—this marks a shift in AI tool selection from being technology-driven to being driven by economic rationality.