Matthew Berman tests DeepSeek V4.1 Flash: coding, vision and local apps

I've been testing DeepSeek V4.1 Flash on visual coding, multimodal reasoning and practical agent tasks. The demos are impressive enough that I want to look beyond a benchmark score: what actually works, what breaks, and how much speed and price change the experience?

First is a single-page 3D mechanical watch. You can rotate it, hover over components and inspect how the parts fit together. The movement has a level of detail I didn't expect from a prompt, and the interface makes it possible to explore rather than just look at a static render.

The exploded view separates the mechanism into layers, including the balance and hairspring. It is a striking visual result, although it is not a perfect watch simulation: I don't see the automatic winding rotor I would expect. That distinction matters when evaluating a generated demo.

Next I asked for a Fall Guys-style game called Bean Blitz. The character runs through a colorful obstacle course, and the presentation feels surprisingly close to a real game. I can move around and interact with the course instead of seeing only a mock-up.

There are clear rough edges. Some obstacles are static, the character can clip through parts of the scene, and the physics aren't always convincing. The hammers do work, though, and as a one-shot result I think it's very strong, approaching what I've seen from Opus on this kind of task.

I also asked for a 3D folding iPhone Duo and compared it with a Kimi-generated version. There is a lot to like in the model and interface, including the detailed device and the ability to manipulate it. But attractive rendering doesn't mean every interaction is correct.

On the DeepSeek version, the folding animation moves the phone out of position and the screensaver disappears. Those are real failures in the demo even though the overall visual quality is good. Looking at the interaction exposes problems a screenshot alone would hide.

For a multimodal test I gave DeepSeek V4.1 Flash a photograph full of pastries and asked it to count them. It spent about four minutes and 25 seconds reasoning and estimated roughly 137 visible items. It also recognized that items could be obscured and gave a range of around 130 to 145.

The model counted 24 macarons in one part of the image; I count 25. That is close, but neither the model's total nor my quick count is a verified ground truth. The important part is that it tried to reason through a crowded image and acknowledged uncertainty rather than claiming every hidden item was visible.

I followed up by asking it to account for pastries hidden behind others. Its answer estimated additional items, including about 45 macarons in total, and took roughly 23 seconds. That's an extrapolation from a photograph, not a way to establish the true count of objects we cannot see.

I then turned reasoning off and requested a story of about 1,000 words. The answer arrived quickly and directly. By eye I estimate around 125 to 150 tokens per second in that run, though the experience depends on the provider and configuration.

A provider comparison shown in the video reports much higher output rates: roughly 1,286 tokens per second for Lithos and 845 for Baseten. Those are measurements in that comparison, not a promise for every request. Speed makes an already inexpensive model feel different when the output starts arriving almost immediately.

For an agent task, I asked it to find usable clips in a Sam Altman interview. It browsed and returned suggestions with timestamps; the run took about six minutes and 24 seconds. This asks the model to find and interpret material, not just produce code from a prompt.

I checked the first suggested timestamp and found the relevant discussion: Altman says he hadn't looked at code in about a year. Other suggestions concerned programmers keeping busy and a discussion of consciousness. I did not actually cut and export the clips, so the test supports the selection step rather than an end-to-end editing claim.

I also ran the model locally on a DGX Station and asked it to build an offline-first spreadsheet app called Gridline. The run took about 50 minutes. It produced a working interface with basic spreadsheet features, giving me a way to test a longer coding session rather than only quick visual prompts.

Gridline supports formulas, autofill and charts in the demonstration. It isn't a complete replacement for Excel, but making a usable application locally is still notable. I expect quantized versions could also make the model accessible on some high-end consumer GPU setups; that is a possibility, not a test I show here.

Another 3D exercise was a Rubik's Cube simulator. I could scramble the cube and ask the application to solve it, and the moves looked correct in my demonstration. As with the game and watch, the useful test is whether the interaction works, not simply whether the initial image looks convincing.

For a larger local build I used a detailed prompt for a PDF reader called Folio; Opus 5.5 originally generated that prompt. The resulting application uses Electron, React, TypeScript and PDF.js. It is a test of the implementation produced from that specification, not evidence that DeepSeek independently invented the specification.

The reader includes annotations, signatures, dark mode, saving and printing; I also try creating a signature with a camera. It is a substantial collection of features for a locally generated app. My estimate of inference cost is part of the comparison, but local execution still requires hardware and time.

Taken together, these examples make me enthusiastic about the model's combination of capabilities, speed and cost. Some individual tasks have visible flaws, and a short demo cannot establish reliability across every workflow. Still, the breadth—from graphics to document software and multimodal counting—is what stands out to me.

I look at a DeepSWE v1.1 chart that compares coding performance and cost per task. The point I highlight is around 77% pass@1 for roughly $0.20 per task, making the model look like a strong value in that particular evaluation. A benchmark and its pricing assumptions are useful context, not a complete measure of practical performance.

I also discuss scores around 42 on HLE and Terminal benchmarks, but I don't think a single leaderboard tells the whole story. Different tasks exercise different skills; the demos show both impressive results and failures that an aggregate number may conceal.

At the time of this video I quote Lithos prices of $0.15 per million input tokens and $0.60 per million output tokens, with cached input free. I also cite Baseten at $0.30 input, $1.20 output and $0.01 cached input per million tokens, alongside its reported output speed. Provider prices and speeds can change.

My conclusion is that DeepSeek V4.1 Flash is an unusually compelling value for the tasks I tried, and I compare it favorably with alternatives such as Kimi. The choice still depends on the application: check the actual output, provider conditions and cost on your own workload rather than treating my ranking as universal.