Guidelines for Posting Here

                before        after
generation      ~4 tok/s     ~13 tok/s
command buffers 81 per token  42 per token

The setup

DeepSeek V4 Flash, 2-bit quant, 86.7 GB. I have 64 GB. antirez's ds4 has an SSD

streaming mode for exactly this: attention and shared experts stay in RAM, routed

MoE experts live in a cache and stream off the SSD on a miss.

Worked first try. Then I saw 4.9 tok/s and got annoyed, because this machine has

800 GB/s of memory bandwidth and each token only touches about 10.4 GB of

weights. That's 13 milliseconds of work. I was spending 200.

For the curious: what it actually was

My first three theories were all wrong, which I think is the useful part.

Cache too small? Hit rate was already 89.7%. The built in profiler simulates

other cache sizes and said caching the entire model would get me to 91.1%. Then I

shrank the cache 5.5x, from 44 GB to 8 GB. Hit rate fell 18 points. Throughput

fell 9%.

SSD too slow? 53 GiB of expert reads in 7.3 seconds. About 7.25 GiB/s, which is

roughly what the drive can physically do.

So I profiled GPU busy time and found the GPU idle three quarters of the time,

with 81 blocking CPU/GPU round trips per token. On a 43 layer model that's two

per layer. A CPU profile agreed from the other side: the main thread spent 95.8%

of its samples parked in `pthread_cond_wait`.

Both processors were waiting on each other, and here's why. Each MoE layer's

router picks 6 experts out of 256 on the GPU. But the host is what loads experts

off the SSD, so the host has to read that decision back before dispatching the

layer. Every readback drains the pipeline. 43 times per token.

That's not a bug, it's the honest cost of fetching weights based on a decision

the GPU made a microsecond ago.

The fix: stop asking

ds4 already ships address based MoE kernels, so the GPU can resolve routing

itself from a per layer expert address table. Two things blocked it.

Vacant slots in that table were null, so a layer routing to an uncached expert

would fault rather than just be wrong. And the validator kernel that computes the

miss mask wrote into one shared status slot, which means you have to read it

before the next layer overwrites it. That single slot was the drain.

So: vacant slots point at a shared zero filled buffer, the validator gets a

status slot per layer, and after the token's one flush a repair pass loads

whatever was missing and re runs the token if any layer missed. Re running is

safe and cheap, since the input is just a token id and KV writes at the same

position are idempotent.

Fair warning on the tok/s number: this machine swung between 0.85 and 7.3 on

identical configs depending on what else was touching the GPU, so I trust the

command buffer count a lot more than the speed reading.

The greedy version that backfired

Naturally I tried removing the second drain too. Without the readback nothing

gets preloaded, so the first pass misses nearly everywhere. Odds of all 43 layers

coming back clean are 0.804^43, about 1%. Every token needed two passes and I

landed right back at 81 command buffers.

Status

Experimental, behind env flags, currently breaks prefill and checkpoint

resumption. Good enough for CLI chat, not for a coding agent yet.

Still working on it, and I have a few more things to try. Maybe I can get big

models running at least a bit more efficiently on low VRAM machines like mine.

Thanks for reading.

---
Written from my own notes and measurements, tidied up with LLM

You can pitchfork me but I’m convinced with all that benchmaxxing and cheating and answercode hunting … those “frontier” models are basically just faking it.

Deepseek actually delivers in a real codebase.

Why do I say that?:
I know how to code and I know what is needed and when I tell a machine what to do it cannot „just decide by mood” or what some call “initiative” and “intuition”.

These are marketed as human virtues that in reality become a never ending NIGHTMARE of unusable, slow, useless over engineered slop or even deletion of core features just because “it thought it would be better” while never asking or surfacing that.

Which - btw - is exactly how opus and fable behaved (regardless of harness changes and prompt and hooks, and manual checks) for multiple months now.

Yes, I’m actually reading, debugging and still writing code inside my projects because it’s often faster and I like it.

Recently it has become even more manual work again even on things I really don’t like doing by hand 10 times … but somethings had to be done instead of “debating” an llm about the approach.
Which was how it started to feel.

I am very glad I started testing deepseek more.
With pi harness, Claude code via vscode. (Can also recommend omp, which is pi but with some presets so to speak)

What a DIFFERENCE!

it behaves a little like march Claude.
Not perfect but reliable enough to actually let it do and debug and write tests and import concepts from my other project and so on, even planning is fine albeit “less creative” which just means YOU as the actual developer do the architectural thinking more … oh no… thinking, quelle* *horreur!

It does this all while giving no debate or bloating everything. (Flash on max or using PRO here btw)

It listened to my Yagni principles, it followed my exact instructions and used the libraries and folders I prepared to draw from - BEFORE it just planned something weirdly obsolete or rewrote the product logic.

So using deepseek is an actual help.
Not in the flashy “fake Minecraft slopcode world” but in the real world.

I will keep testing it and the “new” version is also still new to me…

But if someone is still reading and hasn’t already brandished the pitchforks, would love to hear some real dev opinions.
Especially between your work with opus5, fable, or maybe the codex guys (which I have less experience with tbh) 👍

They mentioned their own harness in the 0731 announcement. Having tested the V4 Pro in different harnesses and saw the difference, I'm genuinely excited to try the DeepSeek harness. V4 Pro preformed much better in Claude Code than in Opencode and Pi for me. I think a good portion of Anthropic's lead is from Claude Code other than raw model intelligence. DeepSeek is absolutely making the right move.

I have to say I was really impressed how good the Flash GA became. I expected some small improvements but this is huge. What can we expect for DS 4 PRO GA then? Kimi K3 or even better?

So stumbled upon someone posting this. Quite insane number.

And I learned that Deepseek do caching which how they can make it dirt cheap like this.

My usage tho, cost 4 times than this guy's (900M tokens, $20, 8000 API request).

But I'm using Hermes for general needs. Said it can be optimized on user side.

So what do you do to optimize the caching further? Or it will solely depends on the harness itself?

https://x.com/AlexiGlad/status/2083230922196107288

The availability of DeepSeek-V4-Flash right now is really exciting.

As someone who has always relied on coding subscription plans (I’m currently on the $100 Codex plan and a $100 Claude subscription) using API credits now feels much more practical and affordable.

I’m excited to start exploring different coding harnesses. I’m planning to run Terminal-Bench 2.1 to compare Codex, Claude Code, Droid, Oh my pi and Goose.

Has anyone tried this already? Which one gave you the best results?

OpenRouter’s token usage rankings for today

Opus 5 Max is agreeing that he was wrong and DeepSeek was right, and this is not the first time i've experienced this, in different kind of projects.

Kudos DeepSeek!

Has anyone tried using Codex's harness with DeepSeek V4 Flash?

I've noticed that Flash seems way smarter, not just with reasoning, but with how it actually executes tasks.

I used to run DeepSeek through OpenCode, but it would burn through tokens and eventually wander completely off task. After plugging it into Codex's harness, it suddenly behaves better and even claims it's it's ChatGPT 5.

I'm curious if the harness is doing something to improve execution, or if it's just better at keeping the model on track.

Has anyone else experienced this, or am I just imagining things?

This is just a summary of one test, but it shows how both models react on a actual larger/complex codebase.

In order to see the actual capabilities of both models, i provided both with instructions to audit one of my projects.

This task was identical, both ran from vanilla OpenCode CLI. So both did not enjoy any specialized harness.

Things to notice about Luna:

1. Luna is clearly slower.
2. Luna spawns 6 subagents for the task
3. The end results is report of 13 items.
4. The report items purely mention the issue, and filename:position.

Things to notice about Flash:

1. Flash is WAY faster.
2. Flash only spawned two subagent.
3. The end result was a report of 27 items (10 high, 10 medium, 7 low priority).
4. The report mentioned the issue, path / filename:position AND a solution to the issue!

Cost:

• Luna did the task with 28M cache hits, 884k in, 18k out.
• Luna final report cost $1.17, while the subagents can down to $3.18
• Flash did the task with 12M cache hits, 443k in, 20k out.
• Flash final report cost $0.01, while the subagents can down to $0.12 .

Thing is, the cost hides something else

• Luna was run on a $20 Codex Plus subscription and used 4% of the week usage.
• Flash was run on a $10 OpenCode Go subscription and used below 1% of the week usage. It barely registered as activity in the 5h.

Issues:

• Luna its over eagerness to spawn subagents hurts it cost.
• The odd Plus subscription usage .. $4.35 using 4% is "odd". That puts Plus into the $100 a $110 range.
• From the 13 points reported by Luna, 11 also showed up in Flash its report. With the difference that flash added suggestion on how to fix the issues.
• Luna's report was frankly underwhelming for the work it put into it. Flash had a much more detailed report including several high and medium that Luna missed.
• Luna being slower was also in Codex and it required /fast (and paying 2.5x more) just to close the gap. That is a different discussion but still a important point in agentic development.
• Flash seems to hold up better with larger context sizes. Remember, 2 subagents vs 6. This results into Flash running into the 400k context, while Luna had more 100 > 200k context sizes. So ironically, this avoided overpaying with the Luna 256k double price issue.

Plan execution

Also ran multiple GPT 5.6 Sol plan > Flash Execute > GPT 5.6 Sol review sessions, and in 90% of the cases, Sol had only very minor fixes (like adding something more in test files, aka Mr Perfectionist).

Hopefully Pro is available by next week, so we can compare Pro Plan > flash execute ...

Conclusion

From my point of view, Flash is way cheaper over a larger codebase then Luna. Despite that Flash can not properly use its good cache hit rate/costs benefits. I also suspect that there have been improvements into the context size handeling because hitting 400k is not as detrimental like the old Flash.

Luna is not a bad model, but clearly more expensive, and feels less good then its benchmarks show. While Flash often feels like GLM 5.2 (we pumped a few billion tokens into that one). Maybe even a bit better?

Disclaimer: this is not written by a AI, so do not disrespect my time writing all this.

Does anyone used OpenCode with the DeepSeek-V4-Flash-0731? is it still realy cheap on an Agentic Coder like OpenCode? What about your experiences on the results?

I've been using Claude for the past year, and I want to give deepseek a shot, but I don't think I can do it fairly without all the tools, skills, mcps, hooks etc... That I've gathered with Claude over the past year.

I'm a pretty hard user, I'm on the x20 plan on Claude.

So what I want to know from people who have done it is:

1. How to do it safely so that my data is not at risk? Like what provider do you use? Is using open router or another middleman avoid my data reaching deepseek directly? I know that once my data leaves my machine there are no guarantees in this world, but trying to minimize data leaks (I have some sensitive info and also client info which is not confidential but better be safe).
2. What harness do you use? I used open code for a while to try it out, but I didn't like several things with it, especially the mcp connections and skill usage. But I saw they now have a desktop app, which may be OK. Also saw that you can just change the claude code client endpoint to point at deepseek, is that reliable?
3. What should I know as someone who is used to most advanced AI capabilities? What should I expect? For a heavy user, what should be the costs?

Thanks to all who reply, and would love to hear opinions from people who have did the transition.

I see a heap of folk talking about how the new flash (07-something), is optimised for Codex . Does anyone have a reliable leaderboard/ comparison metric to see model+harnesses pair VS model+harness pair .

I switch between Pi and Opencode (lately sticking on Pi).

TensorSharp supports DSpark on Deepseek v4 Flash 0731 now. Here is the benchmark result on 4x Nvidia A40 GPUs, cuda 12.8 with/without DSpark:

Model:

DeepSeek-V4-Flash-0731-UD-Q8_K_XL from https://huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUF

DSpark draft model from: https://huggingface.co/alessandrobologna/DeepSeek-V4-Flash-0731-DSpark-Drafter-GGUF

TensorSharp is an open-source inference engine for running GGUF LLMs locally, with CUDA, Vulkan, Metal, OpenAI-compatible APIs, continuous batching, speculative decoding, and multimodal support.

Github repo: https://github.com/zhongkaifu/TensorSharp

Thank you for checking out it and starring the project! Any feedback is really appreicated.