DeepSeek V4 Flash just went live — and it's built for agents.

Here's the announcement in one breath. DeepSeek-V4-Flash — the small, fast, cheap tier — is now live in public beta on their official API. DeepSeek call it a massive upgrade to agent capabilities, with benchmark scores that now far surpass their previous V4-Pro-Preview. It natively supports the Responses API format and is fully adapted for Codex-style coding loops. And here's the detail most people will skim past: the new build, V4-Flash-0731, uses the exact same architecture and size as the preview. Nothing got bigger. It just got better at being an agent.

Same model. Much better agent.

This is the part worth slowing down for, because it's the whole story.

Normally when a model gets better, it gets bigger. More parameters, more hardware, higher price.

Not here. DeepSeek were explicit: V4-Flash-0731 uses the exact same model architecture and size as the preview. The upgrade is in the training, not the size. Same speed. Same tier. Sharper agent.

And what they trained it for is exactly what you and I do all day:

Agent capability. DeepSeek say the benchmark scores now far surpass their own previous V4-Pro-Preview — the bigger, stronger tier. The small model catching the big one is the headline.

Native Responses API support. That's the format modern agent tools speak. It means fewer adapters, fewer translation layers, fewer weird failures in the middle of a long run.

Fully adapted for Codex. Tuned for the iterative write-run-fix loop that coding agents actually do — not one-shot question answering.

Two things to keep straight, because DeepSeek flagged them: this upgrade applies only to the V4-Flash API for now — the V4-Pro API and the app and web versions are unchanged. And the official V4-Pro release is coming.

What builders are saying — as it landed.

This is hours old. Here's the live conversation around it.

Pulled live from X, hours after launch — tap any card to open the original post. This one is fresh enough that the conversation is still forming.

I added it to my Agent OS the hour it launched.

Here's the part I like about running an operating system instead of chasing tools: a launch like this is a config change, not a rebuild.

Three places it went in, and each took minutes:

1 — As a Hermes profile. A deepseek profile pointed at V4, so my agent can think with it directly. One command to use it:

hermes -p deepseek

Smoke-tested end to end the moment it was created — it answered on the first try.

2 — In the coding-agent dropdown. My OS has an OpenCode tab where I type a prompt and a build streams out into a workspace gallery. DeepSeek V4 Flash 0731 and V4 Pro now sit in that model list, straight off the official API, next to every other engine.

3 — On the benchmark. Which is where this gets interesting, and where I found something worth telling you about.

Make sure you're actually running the new one.

This is the most useful thing in this whole guide, and it applies to every model launch, not just this one.

When I went to benchmark the new Flash, I checked where I'd be getting it from — and found the trap.

The router and marketplace entries for DeepSeek V4 Flash are undated. They're just called "v4-flash". Ask one which build it's serving and it tells you its own slug back. It can't tell you whether it's the new 0731 build or the older preview. And DeepSeek said this upgrade applies to their API for now — so a third-party route may well still be serving yesterday's model under today's name.

Which matters enormously, because the whole point of this release is that the name didn't change but the model did. Same architecture. Same size. Same label. Different behaviour.

The rule: on launch day, go to the source. Use the provider's own API, confirm the model shows up in their official model list, and only then judge it. Anything else and you're forming an opinion about a model you might not be running.

That's exactly what I did before benchmarking — which is why the numbers on this page are worth something.

I ran it through all 50 of my build tests.

Every model I take seriously goes through the same gauntlet: one prompt, one file, no follow-ups, no hand-holding — then the result gets rendered in a real browser and checked on what actually appears on screen.

Games, 3D worlds, simulations, tools. If it renders black or freezes, it counts as rendering black or freezing. No posed screenshots.

Here's how V4-Flash-0731 did, on the official API so the results belong to the build DeepSeek actually shipped:

Every single one came back complete. Fifty tasks, fifty valid, properly closing files — not one truncation. That's rarer than it sounds; plenty of models trail off mid-build on the harder tasks.

Forty-two rendered perfectly on the first attempt. Eight came back black or nearly black — the interface would draw but the 3D scene wouldn't show up.

Then the interesting part. I don't patch broken builds by hand — that would flatter the model. Instead each failure goes back to the model with the real screenshot evidence: your scene isn't visible, fix the root cause. All eight came back fixed on the first try. Every one of the fifty now renders.

That self-repair behaviour is exactly what the 0731 upgrade was supposed to improve, and it's the thing you'll feel most in daily use — an agent that can read the evidence of its own mistake and correct it without you narrating the fix.

One honest caveat: it is not fast. V4 reasons at length before writing a single line, so a full 3D game build took several minutes each. You're trading speed for a cheap tier that finishes what it starts.

All fifty builds are live and playable on my benchmark — you can open any of them and judge for yourself.

Play them yourself

Twelve of the fifty, all one prompt each, all untouched by me. Click any one — they run right in your browser.

3D open world

Dragon Realm

Fly-through fantasy realm with dragons, HUD, souls counter and real WASD movement.

Play it →

retro FPS engine

Raycaster

A from-scratch raycasting engine — walls, textures, movement, the lot.

Play it →

open-world on foot

Street Sim

Third-person city wander with traffic, buildings and a live minimap.

Play it →

3D flight

Flight Sim

Cockpit HUD, horizon, terrain and working flight controls.

Play it →

block builder

Voxel Craft

Place and break blocks in a voxel world with first-person controls.

Play it →

tile adventure

Top-Down RPG

Overworld map, party movement, encounters and stats panel.

Play it →

atmospheric explorer

Twilight Vale

A moody 3D valley you actually walk around in.

Play it →

arcade shooter

Neon Blaster

Twin-stick neon shooter with waves, particles and score.

Play it →

torch-lit dungeon

Crypt

The build that first rendered black — repaired by the model itself.

Play it →

air combat

Dogfight

Chase enemy planes with working flight physics and targeting.

Play it →

dungeon crawler

Nordic Crypt

Norse-themed crawler with lighting, enemies and loot.

Play it →

3D circuit

Racing

Drivable track with lap timing and a chase camera.

Play it →

Every one of the fifty is on my benchmark too, playable next to the same task built by every other model on the board.

I was you. Then I stopped chasing launches.

Before

Every model launch used to cost me a day. New announcement, new tool to install, new setup to figure out, new subscription to argue with myself about. By the time I'd wired it in, something else had launched. I was permanently three days behind and permanently rebuilding.

Then I built the system first and made models a dropdown.

After

Today DeepSeek launched at breakfast and it was running in my OS before lunch. One profile, one dropdown entry, one benchmark run — and every existing agent, memory note and workflow carried straight over. Nothing rebuilt. Nothing re-learned. That's the whole difference: launches stopped being interruptions and started being upgrades.

You can have this too. Build the system, then let the models come to you.

Real people. Real builds. Inside the Boardroom right now.

The members running this stack — agency owners, ecom founders, course creators — plugging in new engines the week they ship.

Most people collect models. Operators plug them in.

The old way: a model launches, you read six threads about it, maybe install another app, and end up with ten half-used tools and no system. When the next one lands, you start again. Worse — you test whatever build a random route hands you and form an opinion about a model you never actually ran.

The new way: the system is permanent, the models are swappable parts. A launch means one profile, one dropdown entry, one benchmark run — and everything you've already built inherits the upgrade instantly. You go to the source so you know what you're running, you measure it yourself, and you keep the winner. That's how you compound instead of restart.

What's actually stopping you isn't technical.

Try it properly — four steps.

The whole launch in 30 seconds.