DeepSeek: DeepSeek v4.1 Flash 1017

DS isn't better than Sol and Gemini in the benchmarks, but after working with them all for a while now I'm beginning to understand why people find DS _feels_ so much better.

First, it's the tok/s and TTFT from providers. Deepseek blazes through work - at quite good quality - and you don't find yourself waiting for your agents to finish.

Second is the openness. Being able to see the CoT and not being randomly blocked for cyber review. You're never wondering if it's stuck or if it will randomly fail. Combined with the great cost value.. My next subscription will probably be Z.ai

The company's own news page: https://api-docs.deepseek.com/news/news261017

They are showing this new version scoring significantly higher across multiple coding benchmarks, beating Sol 5.6 (6.1 is the latest) across 10/11 benchmarks.

I am going back to DeepSeek for writing code. I was trying out using Sol and liking the result, but this should close a lot of that gap. I use Opus/Sol for an implementation plan and code review also use them for grilling. DeepSeek is also running verifications.

I have started phasing into DeepSeek v4 (Dwarfstar quant from Antirez) as my daily driver and it's going very well. It can one shot iOS apps on my Mac Studio, it's a little slow and sometimes needs retries but can definitely do medium difficulty real work for me.

I didn't try the last flash model because I would need to use SSD streaming (I have 128 GB), but the benches for this release are so compelling (and it using less tokens to get tasks done) it might be worth the throughput hit. I will probably give it a try when I have some downtime.

It feels very freeing to be doing useful work on a local model on my own hardware with my own coding harness. The TCO argument is starting to look compelling too.

I've been using DS v4.1 Flash daily for nearly a month now on Agent Swarm experiments. I've tested it against GLM-5.3-flash and Opus 5.5. DS 4.1 comes out tops for me. Opus 5.5 is still the smartest, but DS 4.1's speed and price more than make up for the "intelligence" gap. I've ran Chief/Builder/Reviewer swarms autonomously for multiple days. I think my new workflow is going to have DS 4.1 Flash do all the engineering and just have Opus review its work. 4.1 Flash really is a very impressive model. Kudos to the Deepseek team.

I really like the having DeepSeek Flash + Opus 5.5 as advisor/reviewer at the moment. I run through a $200 Claude Code subscription in less than 24 hours now just for a single project, and I hate fiddling with different accounts every day. Now that I get a 200 USD api credits inlcuded with the subscriptions I have rewritten my coding agent workflow completely.

Its a great update, I ran a benchmark comparing verbosity and intelligence compared to old weights.

- Reasoning effort = 1 is now actually usable and produces 2.5x less tokens than old weights, without intelligence lost. - Overall 20% less tokens at each reasoning effort. - Same intelligence and same tool-calling pattern.

More details in blog post https://sference.com/blog/deepseek-v41f-1017-benchmark

so i did some apples to bananas comparison.

i let 4 different agents review the same dirty code base (200+ files changed, c++, game engine):

- deepseek v4.1 flash via deepseek API: took 20m to find one p1 issue that was relevant and a p2 issue that was irrelevant

- glm 5.3 flash NVFP4 via TP2 DGX Sparks: took 1h 5m to find a p3 documentation issue

- gpt 5.6 sol: took 5m30s for one p1 and one p2 issue. both relevant

- gpt 6.1 sol: took 4m30s for two p1 and one p2 issue. both relevant.

Worth to mention: none of those findings overlapped.

I let deepseek v4.1 flash and gpt 6.1 sol both plan fixes for the summary of the findings. in this particular scenario: gpt 6.1 sol planned to increase a buffer size from 128 to 256 to fit the 191 elements that blew past a test scenario. it included some headroom. deepseek v4.1 flash on the other hand decided to make it exactly 191 to satisfy the test, for example.

The TPS decode on deepseek is impressive. I never had a second / feeling of being left aone and though "damn this thing is working". Despite all my efforts, it took ~4x longer in a review, found less and planned worse than GPT 6.1 Sol. Wall clock time. I don't have token counts for comparison. If I were to grade those models from 1-10 (10 = top tier GG), I'd give deepseek a solid 6.5 and 6.1 sol a 7.5-8.0 maybe.

Other discussion: https://news.ycombinator.com/item?id=50129045

The native web search api is 10x cheaper than OpenAIs. I hope they will release the web search api as a standalone API.

Hugging Face link: https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017

This and (the not quite yet open) Kimi K2.8 are my main coding engines, and I find them incredibly cost efficient. I find Deepseek in particular is really good with Svelte work.

Right now I use each of them in their own respective coding harnesses, deepseek-harness and kimi-code, but I do wonder what they are like inside something like opencode.

Is it already updated to the newest version on Opencode?

My favorite model just got better. Gotta love what deepseek is doing

By far my favorite model.

At the beginning of the month I realized I had more tokens and more capabilities on Opencode at 8$/month via DS 4.1 flash, than I had on a 200$ account in June with the american providers.

Literally both more tokens and capabilities than Opus 4.8/GPT 5.5.

Even if you pay per token, you're still unlikely to outspend american providers.

Performance charts and benchmarks are here:

https://www.reddit.com/r/DeepSeek/comments/1x84wke/deepseek_...

Probably a week ago someone posted a thread with the title "Why isn't the industry freaking out about DeepSeek 4.1 Flash?"

I have been intrigued about Chinese models for a long time, but never tried anything except an early Qwen. My daily driver was Luna, with occasional elevation to Terra or Sol - all on 5.6 as I found the output of 6 jarringly incomprehensible.

I still had 95 USD on my OpenRouter account, so I thought I would give DeepSeek Flash 4.1 a try.

I think now I can understand the person who created that thread.

Here is the setup I settled on, after a lot of refactoring and calibration of the workflow:

I have a "plan" prompt which explains to the agent (Luna) that I want to have a discussion about an idea I have in mind. The agent should use the Socratic method to pull out all the necessary info from me using pointed questions. When the agent feels it has a complete picture, it should elevate to a higher level model (Sol), and ask its review. If Sol has complaints, Luna keeps asking me until the points raised by Sol are clarified. The review rounds with Sol continue until Sol says "ready to implement".

At this point Luna creates four files in a directory I specify:

1. PLAN.md: the implementation plan with all the details that came out from the design discussion 2. PHASES.md: implementation phases 3. DECISIONS.md: design decisions (this serves the same role as ADRs aka. architectural decision records) 4. DIARY.md: append-only log of what happened during implementation

Files 2-4 are written by the implementing agent. Luna only adds headers to explain the purpose of the files.

Once these files are there, I start up a new Pi session, switch to Deepseek 4.1 Flash and then point it to this plan folder.

And then it goes brrrrr... :-)

Here is what I implemented in the past week using this method:

1. A capture/analysis/decompilation pipeline for C64 demos: I ask the agent to start a selected demo through VICE, and say "on" or "off" when I want it to start/stop capture. The capture process uses VICE's builtin trace functionality: the trace log is piped into Clojure where it is saved into an optimized binary format (chunks of trace events). Once I have everything captured, I unleash my analysis pipeline which checks the write patterns of the executed code: what it wrote (VIC, SID, CIA, memory) and when (rasterline, cycle). Then it splits the execution trace into segments by type deduced from the write patterns (decruncher, loader, raster, music) and then decompiles each segment into both traditional ASM files and a s-exp based syntax which roundtrips back into the in-memory representation. Once I have the results of the analysis pipeline, I can tell the agent to analyze any demopart and it can explain how the effects are built down to the tiniest timing detail. As a first test, I asked it to create a clean-room implementation of Fairlight's legendary intro and two days later I had it, with everything in sexp assembly, including the music routine and its data. (The reason it took so long was that this was the first decomp and it provided a lot of feedback to the pipeline development.) Finally I had it write an assembler, linker and packager which creates a PRG from the assembled and linked artifact, then runs it through VICE. Done.

2. A DSP compiler which lets me compile sexp forms of a C-like DSP language into native DSP kernels running on the JVM, JS and WASM. Currently I have about 600 tests which verify that the behavior of the three targets matches that of a reference interpreter written in Clojure. I have a full numeric tower with i32, f32, f64, support for arrays and structs, typical control flow constructs, and a library of DSP building blocks like oscillators, filters, LFOs, delays and a chorus effect. By the time this is ready (end of the weekend?), I will be able to build synthesizers like Synth1, Surge XT or Vital in Clojure/Script, compile the DSP kernels in the browser, choosing between JS or WASM backends, driving the kernels via AudioWorklets and sequencing them from the host language.

There are two power tools at play here:

1. Deepseek Flash 4.1 2. Clojure and ClojureScript

Deepseek is a BEAST. It just goes on and delivers, phase after phase. What it needs: clear instructions - this is covered by the planning process quite well, but I still find it needs some steering from time to time (the right nudget of wisdom dropped into its thought stream at the right moment works wonders)

And Clojure... well. That article PG wrote about LISP (Beating the averages): what I witness now proves all of those claims.

The agent LOVES Clojure. Especially the REPL (not so much the parentheses).

Winning strategy: give it two tools: start_jvm and clojure_eval. Implement everything else it may need - tools to start up HTTP servers, compile ClojureScript, add dependencies, capture a C64 demo, run Playwright via spel, etc. - as lightweight Clojure namespaces which provide APIs to all these functionality. Let these namespaces be thin: the namespace and the functions therein shall have docstrings which tell the agent what the functions do, but the functions themselves shall be lightweight proxies to the real implementations in sub-namespaces. Then point the agent to these top-level API namespaces via your AGENTS.md. Bam, instant discoverability with minimal context usage. It will do EVERYTHING through clojure_eval and the round-trip time will be phenomenal, a perfect match to the raw speed of the agent.

...

Now all I need to figure out is what will I do when all my dreams become manifest in flesh.

[dead]

[flagged]

[dead]

[flagged]