DeepSeek V4 Flash 0731 DS4 in Practice

From experiment to work

When a model stopped being just a toy

For the past few months, I have been doing a lot of vibe coding at work with local models. I started experimenting with Qwen3-Coder-Next, with 80B total and 3B active parameters, in March 2026. To my surprise, it was already useful for simple changes in a real project that had been developed for years.

I develop LED Strip Studio 4 — desktop software for designing, mapping, and controlling pixel LEDs. By my estimate, the codebase contains well over 100,000 lines of code. It is not a small demo application, but a medium-sized product with history, old and new GUI branches, and many interconnected parts.

A few weeks later, Qwen 3.5 arrived, followed by Qwen 3.6 27B and its faster 35B-A3B variant. Qwen 3.6 became my default model for vibe coding. It could add features, refactor existing code, find smaller bugs, and handle much of the routine work around the project, from SVN operations to many other development chores.

Since then, I have rarely needed to type the implementation code myself. That does not mean the model was unlimited.

More about LED Strip Studio 4

Qwen3-Coder-Next model card

A practical limit

What a 27B model can do — and where it breaks

Qwen 3.6 is a very useful work tool, but on a project of this size it operates close to the edge of what it can reliably handle. Some tasks progress almost as slowly as if I were implementing them manually. It is still worthwhile: while the model works, I can do something else or prompt another agent working on another project.

Its most frustrating limitation is looping. On longer or more difficult tasks, a small local model can start revisiting the same thoughts indefinitely without making real progress. I do not encounter this at all with large cloud models such as GPT or Claude; with smaller local models it is a common reason to supervise the run regularly.

Other local models, such as Gemma 4, also gave me toolchain problems: incorrect tool calls or trouble with an otherwise trivial operation such as creating a file. Qwen mostly solved that part, but looping remained.

Qwen was no longer an experiment. It was a useful colleague that still needed regular supervision on harder work.

Larger local models

Using the 96 GB machine more fully

Qwen 3.6 27B is relatively small and, depending on quantization, can run on systems with roughly 24 GB of memory. My Mac M3 Ultra has 96 GB, so I started looking for larger models that might improve autonomous development and, ideally, reduce looping.

The first candidate was Laguna S 2.1 118B. Its Q4 version fit into 96 GB with room to spare. I used it for normal software development for two days. My first impression was promising: it appeared to think more deeply than Qwen. The result was mixed, however. Looping was replaced by toolchain problems. I later found an important setting that fixed part of the problem, but that was not Laguna's only weakness.

The second candidate was DeepSeek V4 Flash 0731 running through the DS4 runtime, shortened below to DeepSeek V4 Flash 0731 DS4. Published results suggested higher quality than the previous version, but its 284 billion total parameters put normal quantizations beyond my machine. Expecting a substantial quality loss, I reached for the much more compact mixed Q2 quantization. To my surprise, the model not only fit into 96 GB but remained highly capable in real work.

With the Mac used almost entirely as a model server, unnecessary applications closed, and the GPU wired-memory limit set to roughly 92 GB, I could use it with a practical 320K-token context. The published model configuration lists a maximum of one million tokens, but 320K is the maximum I actually used on this 96 GB machine.

DeepSeek V4 Flash model card

Computer: Mac M3 Ultra
Memory: 96 GB
Model: 284B total
Quantization: mixed Q2
GPU wired-memory limit: about 92 GB
Practical context: 320K tokens

Local setup

How I ran DeepSeek from the terminal

DS4, now called DwarfStar, is a narrow native inference engine and API server for DeepSeek V4 Flash. The current official setup clones its repository, downloads the recommended 2-bit imatrix GGUF for 96/128 GB machines, and builds the Metal binaries with make on macOS. The downloader evolves and may not retrieve the byte-identical file used in this test; its exact name appears in the command below.

My actual run used a mixed IQ2_XXS/Q2_K GGUF, a 320K context-window limit, and 16 GB of disk space for the KV cache. Caffeinate kept the Mac awake, and I raised the GPU wired-memory limit to 92,160 MB before starting the server. The 320K value is window capacity, not a claim that every run consumed 320K tokens.

Current official setup foundation

git clone https://github.com/antirez/ds4.git "$HOME/ds4"
cd "$HOME/ds4"
./download_model.sh ds4f-q2
make

Show the full server command

Exact command used for my 320K run

cd "$HOME/ds4"

sudo sysctl -w iogpu.wired_limit_mb=92160 && \
caffeinate -dimsu "$HOME/ds4/ds4-server" \
  --metal \
  -m "$HOME/llm-models/DeepSeek-V4-Flash-0731-ds4/DeepSeek-V4-Flash-0731-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-imatrix.gguf" \
  --ctx 320000 \
  --prefill-chunk 2048 \
  --tokens 8192 \
  --kv-disk-dir "$HOME/ds4-kv" \
  --kv-disk-space-mb 16384 \
  --kv-cache-cold-max-tokens 0 \
  --kv-cache-continued-interval-tokens 0 \
  --host 0.0.0.0 \
  --port 8080

The 92,160 MB limit is an aggressive setting for my specific 96 GB Mac and does not reset itself. I always restore it after stopping the server:

sudo sysctl -w iogpu.wired_limit_mb=0

The --host 0.0.0.0 option exposes the API to other devices on the local network. If the client runs on the same Mac, --host 127.0.0.1 is the safer choice.

Official DwarfStar (DS4) repository

There is a cost. Very little memory remains for other applications, and subagents become awkward because their KV caches may need to be moved to disk, discarded, or recalculated when returning to the main agent.

Method

Same start, same prompt, real application

I had two real tasks that needed to be solved in the project, so I used them as practical comparison tests. Within each task, every model started from the same state and received the same prompt.

Same baseline

Within one test, every run started from the same source files and received the same prompt.

Functional result

I built and ran the application, then manually checked every subtask. I scored what worked, not what the model claimed.

Run cost

I tracked prompts, elapsed time, context usage, and interventions needed to break a loop or restart progress.

Change quality

Claude Opus 5 reviewed the archived changes with the same five-part rubric. This is LLM-as-a-judge, not independent ground truth.

Verify reality

The models also saw deliberately stale or misleading project notes. Part of the test was whether they verified those claims against the actual code.

Functional score

completed: 1
minor issue: 0.75
partly completed: 0.5
only a small part completed: 0.25
not completed: 0

Quality score

Correctness
Robustness and safety
Design and maintainability
Verifiability
Change discipline

Correctness has double weight. Summary = (2 × correctness + the other four categories) / 6.

Test 1

Layer drag and drop and a design regression

Three related tasks in the new GUI: fix a design regression after dropping a scene, add layer reordering, and add the correct hover indicators.

Fix the list design that changed after dropping a scene from the bank.
Transfer the missing drag-and-drop logic for reordering layers.
Show two horizontal lines indicating the drop position during drag over.

Show the original Slovak prompt

The models received the Slovak prompt below; the task list above is its English summary.

V GUINewDesign mam spravene MultiSceneView s dokovacim oknom MultiSceneLayersUC2.
V sucasnosti toto dokovacie okno MultiSceneLayersUC2 prebera staging dizajn (vid prvy screenshot), co je spravne, ma vsak chybu, dizajn sa zmeni po dropnuti sceny z banky (vid druhy screenshot). Spravny je povodny dizajn.
Dalej potrebujem doplnit chybajucu logiku z GUI verzie LSS.GUI.MultiScenes.MultiSceneLayersUC ohladom drag & drop teda presuvania layer-ov medzi sebou. Dropovanie scen z banky uz mam implementovane. Potrebujem tam vsak doplnit aj hover effekty pri drag over evente, konkretne chcem aby sa medzi layermi zobrazovali podobne ciary ako vidis v ALGroupUC2 kde sa animacie vedia medzi sebou presuvat a zobrazuju sa nad mysou 2 vodorovne ciary predstavujucu miesto kde sa dragnuta animacia vie dropnut po pusteni mysi. Pozri si ako to robil ALGroupUC2, pouziva styly "bottomMargin", "topMargin" na zobrazenie tych dvoch ciar.
V podsate si pozri Drag, DragOver a Drop eventy z LSS.GUI.MultiScenes.MultiSceneLayersUC a tiez z ALGroupUC2, kde z LSS.GUI.MultiScenes.MultiSceneLayersUC vezmes logiku drag & drop eventov a z ALGroupUC2 vezmes to stylovanie.

Qwen 3.6 supported image input. DeepSeek and Laguna did not, so I described the screenshots to them in text. I accidentally omitted that description from DeepSeek's first recorded state and supplied it only afterwards.

Run configuration: Laguna used a Q8 KV cache and lacked correct reasoning_content handling, so its run is invalid. DeepSeek used Q2 weights and a 16-bit KV cache. Qwen's KV-cache type was not recorded.

The result without shorthand

DeepSeek finished the last recorded state at 3/3. Qwen reached 2.5/3, while Laguna is not scored because its run was invalidated by a configuration problem.

Q2 quantization

DeepSeek V4 Flash 0731 DS4

3/3functional final

The only model to complete all three tasks.

Change quality: 3.8/5

local 27B model

Qwen 3.6 27B ThinkingCap

2.5/3functional final

Reordering and indicators worked, but the design bug was not fully fixed.

Change quality: 2.5/5

misconfigured run

Laguna S 2.1 118B

N/Ainvalid run

This result cannot be used to judge the model.

Change quality: not reviewed

Result by individual task

Instead of an unexplained sequence of numbers, this shows the final state of every task and what the later review found in the implementation.

Test 1 — three-task comparison across models
Task	DeepSeek · Q2	Qwen 3.6	Laguna S 2.1
1. Design after dropping a scene	Most convincing solution 1/1Completed Fixed the cause by removing only the temporary DropHere class.	0.5/1Partly completed Reduced the visual symptom but preserved the code that cleared every style class.	N/AInvalid run The result cannot be attributed to the model.
2. Layer reordering	Better edge handling 1/1Completed Reordering worked in the final recorded state and edge behavior was handled better.	Review found an issue 1/1Completed Functionally complete, but dragging could also start from action buttons.	N/AInvalid run The result cannot be attributed to the model.
3. Drop-position indicators	Review found a detail 1/1Completed The indicators worked; a small gap remained by the bottom line.	Review found a detail 1/1Completed The indicators worked, but without DragLeave they could remain visible after the pointer left.	N/AInvalid run The result cannot be attributed to the model.

1. Design after dropping a scene

DeepSeek · Q2: Most convincing solution 1/1Completed Fixed the cause by removing only the temporary DropHere class.
Qwen 3.6: 0.5/1Partly completed Reduced the visual symptom but preserved the code that cleared every style class.
Laguna S 2.1: N/AInvalid run The result cannot be attributed to the model.

2. Layer reordering

DeepSeek · Q2: Better edge handling 1/1Completed Reordering worked in the final recorded state and edge behavior was handled better.
Qwen 3.6: Review found an issue 1/1Completed Functionally complete, but dragging could also start from action buttons.
Laguna S 2.1: N/AInvalid run The result cannot be attributed to the model.

3. Drop-position indicators

DeepSeek · Q2: Review found a detail 1/1Completed The indicators worked; a small gap remained by the bottom line.
Qwen 3.6: Review found a detail 1/1Completed The indicators worked, but without DragLeave they could remain visible after the pointer left.
Laguna S 2.1: N/AInvalid run The result cannot be attributed to the model.

Test 1 does not establish whether the recorded states came from one continuing session or separate rounds. Only the safely known final state is shown here.

One small but critical difference decided the result

Qwen preserved a call that cleared every style class from the list. Along with the temporary drag-and-drop class, it also removed persistent style classes. The model treated the visual symptom, but not the cause.

DeepSeek found the root problem and removed only the temporary DropHere class. It fixed the design in its first recorded state and eventually completed the drag-and-drop logic and hover indicators as well.

Why Laguna did not receive a zero

Laguna failed three times: it looped, could not find files that existed, and broke behavior that had previously worked. Nothing usable could be archived. I later found a likely configuration problem: OpenCode was not set up to interleave the reasoning_content field correctly.

After adding the configuration below, Laguna completed two much longer runs without the same catastrophic behavior. The KV cache also changed from Q8 to FP16, so two variables changed at once. I cannot prove which one was decisive, although the reasoning fix matches the observed symptoms much more closely.

The honest conclusion is therefore not ‘Laguna scored zero,’ but ‘the Laguna run was invalid because the test environment was not configured correctly.’

Relevant OpenCode configuration used after the first test

"laguna-s-2.1": {
  "name": "Laguna S 2.1",
  "tool_call": true,
  "reasoning": true,
  "interleaved": {
    "field": "reasoning_content"
  },
  "modalities": {
    "input": ["text"],
    "output": ["text"]
  }
}

Quality by category

Reviewer: Claude Opus 5

Quality is separate from functional completion. Laguna has no archived output, so its values remain N/A.

Test 1 — quality comparison by category
Category	DeepSeek · Q2	Qwen 3.6	Laguna S 2.1
Correctness	4/5strong	2/5weak	N/Anot reviewed
Robustness	4/5strong	3/5average	N/Anot reviewed
Design	4/5strong	3/5average	N/Anot reviewed
Verifiability	3/5average	2/5weak	N/Anot reviewed
Change discipline	4/5strong	3/5average	N/Anot reviewed

Correctness

DeepSeek · Q2: 4/5strong
Qwen 3.6: 2/5weak
Laguna S 2.1: N/Anot reviewed

Robustness

DeepSeek · Q2: 4/5strong
Qwen 3.6: 3/5average
Laguna S 2.1: N/Anot reviewed

Design

DeepSeek · Q2: 4/5strong
Qwen 3.6: 3/5average
Laguna S 2.1: N/Anot reviewed

Verifiability

DeepSeek · Q2: 3/5average
Qwen 3.6: 2/5weak
Laguna S 2.1: N/Anot reviewed

Change discipline

DeepSeek · Q2: 4/5strong
Qwen 3.6: 3/5average
Laguna S 2.1: N/Anot reviewed

This test has lower confidence: the original baseline folder was not archived, context usage is missing, and it is unclear whether the recorded times belong to separate rounds or individual prompts. I therefore do not publish them as comparable total times.

Test 2

Six MIDI interface changes

The second round was archived more completely, and the models handled six separate changes to an existing MIDI settings interface.

Move Add into the header and remove the old Remove control.
Add an X button and confirmation dialog to every device.
Remove duplicate names and show Not set for an unconfigured device.
Stabilize animated Learn buttons at 80 pixels wide.
Add selected and hover styles to notes and special commands.
Fix a crash caused by referencing ParentWindow from the old GUI branch.

Show the original Slovak prompt

The models received the Slovak prompt below; the task list above is its English summary.

Naposledy sa pracovalo na GUINewDesign/Controls/ na oknach pre nastavovanie MIDI, ArtNet, DMXIn atd. . Uz je vela veci takmer hotovych ale je tam par veci ktore treba este doriesit. Tu je zoznam par z casti MIDI:
- V GUINewDesign v dokovacom okne MIDIUC2 v lavom panely je zoznam MIDI zariadeni a pod nim tlacitka "Add" a "Remove". Presun tlacitko "Add" do hornej casti nad zoznamom do rovnakeho riadka ako je label "MIDI Devices" ale zarovnaj ho po pravej strane. Tlacitko "Remove" vyhod uplne aj s eventom.
- Pre kazde MIDI zariadenie v zozname pridaj tlacitko "X" po jeho pravej strane ktore bude sluzit na mazanie midi zariadenia. Tlacitko "X" nech vypada rovnako ako v Listbox.ItemTemplate z StripSceneGroupsPane.axaml. Tlacitko "X" nech je vycentrovane vertikalne a zarovnane vpravo podobne ako je to v StripSceneGroupsPane.axaml. A po stlaceni tlacitka "X" nech sa zobrazi dialogove okno s otazkou ci naozaj chcem vymazat dane MIDI zariradenie, pouzi presne to dialogove okno ake pouzivas v StripSceeGroupsPane pri mazani group. MIDI zariadenie maz rovnako ako v tom odstranenom evente po odstraneni tlacitka "Remove".
- Dalej v zozname MIDI zariadeni v MIDIUC2.axaml sa zobrazuju midi zariadenia tak ze zobrazuju duplicitne nazvy zariadeni. Ma sa zobrazovat iba jeden, inspiruj sa StripSceneGroupsPane. Dalej ked pridam nove zariadenie tak este nie je zvolene ziadne MIDI zariadenie tak sa ma zobrazit nieco ako "Not set", teraz sa nezobrazuje nic, nevidim ziaden text, oprav to.
- Dalej ked kliknem na tlacitko "Learn" tak sa zacne pustat animacia v podobe postupneho pridavani troch bodiek ("Learn", "Learn.", "Learn..", "Learn..."), ktora sa neustale opakuje. Toto je spravne ale tlacitko learn nema pevne nastavenu sirku a tak sa sirka prisposobuje dlzke textu a tlacitko sa postupne zvacsuje, nastav mu dostatocne velku sirku napr. 80px, to by mal stacit. A toto urob pre vsetky tlacitka "Learn" v MIDIDeviceUC2.
- V "MIDIDeviceUC2" v casti "Notes" sa nezobrazuje styl selectnutej noty, akoby nebol ziaden styl nastaveny v selectoroch stylov. Inspiruj sa stylami selectnutych commandov v GUINewDesign/SceneCommands, predpokladam ze to je v SceneCommandUC2 kde sa pekne zobrazuje oznaceny command cervenym pozadim. A tiez pridaj aj hover styl z tak ako je v SceneCommandUC2. Pridaj oba styly pre notes aj pre special commands v MIDIDeviceUC2
- V "MIDIDeviceUC2" ked stlacim tlacitko "Add" tak padne v MIDIDeviceUC2.axaml.cs na riadku 125 na probleme s tym ze odkazujes na ParentWindow zo starej GUI vetvy, hoci mas odkazovat na rodicovske okno z novej vetvy GUINewDesign. Pozri si ako sa otvarali ine dialogove okna napr. WorkspaceSettings, a naprav to.

Qwen 3.6 supported image input. DeepSeek and Laguna did not, so they also received text descriptions of the reference screenshots.

Run configuration: both DeepSeek runs used Q2 weights and a 16-bit KV cache; Laguna used an FP16 KV cache with corrected reasoning_content handling. Qwen's KV-cache type was not recorded.

Every run reached 6/6. The path and quality differed.

The final score alone does not separate the models. DeepSeek at 320K completed all six tasks on the first prompt without intervention; the other runs needed corrections, more time, or delivered a weaker change.

Q2 · 320K

DeepSeek V4 Flash 0731 DS4

6/6on the first prompt

The strongest practical run in the comparison.

Prompts: 1
Interventions: 0
Time: 21:55
Context used: 141.8K
Quality: 3.8/5

Q2 · 160K

DeepSeek V4 Flash 0731 DS4

5.5/6first prompt · final 6/6

Deeper design work, but a much longer run.

Prompts: 2
Interventions: 0
Time: 1:27:30
Context used: 154.9K
Quality: 3.7/5

262K

Qwen 3.6 27B ThinkingCap

5/6first prompt · final 6/6

Full completion after three prompts and three interventions.

Prompts: 3
Interventions: 3
Time: 35:23
Context used: 102.6K
Quality: 2.8/5

FP16 KV cache

Laguna S 2.1 118B

4.5/6first prompt · final 6/6

It finished the test but delivered the weakest change.

Prompts: 3
Interventions: 0
Time: 1:21:03
Context used: 270.7K
Quality: 2.2/5

The clearest result of the comparison was DeepSeek at 320K: it completed all six tasks on the first prompt, with no intervention, in 21 minutes and 55 seconds.

The 160K DeepSeek run reached the same functional score but encountered context pressure and autocompaction. It took 1 hour and 27 minutes. Autocompaction probably contributed substantially to the longer time, but two runs are not enough to separate that effect from natural run-to-run variance.

Qwen also reached 6/6, but required three task prompts and three interventions from me: I broke two loops, and once the model stopped working on its own.

Laguna completed the test with the corrected configuration, confirming that its first failure was not a valid model measurement. Among the valid runs, however, it consumed the most context and delivered the weakest change in the quality review.

Task by task

Functional scoring and the later code review answer different questions. Completed means the manual test passed; a warning marks an issue or weaker implementation found later in the archived change.

Test 2 — six-task comparison across four runs
Task	DeepSeek · 320K	DeepSeek · 160K	Qwen · 262K	Laguna
1. Move Add into the header; remove Remove	Most convincing 1/1Completed First prompt and final Removed both the obsolete class and the dead row.	1/1Completed First prompt and final Removed the dead row but kept the obsolete class.	1/1Completed First prompt 0.5/1 · final 1/1 Completed the behavior but kept the obsolete class.	Review found an issue 1/1Completed First prompt 0.5/1 · final 1/1 Removed the bad class but added two unrequested changes.
2. Delete a device through X	Review found a bug 1/1Completed First prompt and final The index guard was correct, but deleting an unselected device incorrectly changed selection.	Most convincing 1/1Completed First prompt and final The only run to handle both the index and conditional reselection correctly.	Review found a bug 1/1Completed First prompt and final Passed functionally but contained the same reselection bug.	Review found a bug 1/1Completed First prompt and final The same reselection bug plus a missing index guard.
3. One name and a Not set state	Most convincing 1/1Completed First prompt and final Used the existing GuiTitle property, which returns exactly Not set.	1/1Completed First prompt and final Used Name, producing the functional text no MIDI device.	1/1Completed First prompt 0.5/1 · final 1/1 Functional, but less precise than using GuiTitle.	Review found an issue 1/1Completed First prompt 0.5/1 · final 1/1 Added a new converter and hard-coded text; the Active state was wrong.
4. Fixed width for animated Learn buttons	1/1Completed First prompt and final Set the width three times inline; functional but duplicated.	Best design 1/1Completed First prompt and final Fixed the width once in the shared style and skipped the button that did not need it.	Review found duplication 1/1Completed First prompt and final Set the width four times, including a button that did not need it.	Review found duplication 1/1Completed First prompt and final Set MinWidth four times, including a button that did not need it.
5. Selected and hover styles	Limited verification 1/1Manually completed First prompt and final The shared hover-style file is outside the archive and cannot be independently reviewed.	Limited verification 1/1Manually completed First prompt 0.5/1 · final 1/1 Also found a leak, but its fix introduced a detach-and-reattach issue.	Limited verification 1/1Manually completed First prompt and final The shared hover-style file is outside the archive.	Limited verification 1/1Manually completed First prompt 0.5/1 · final 1/1 The shared hover-style file is outside the archive.
6. Fix the ParentWindow crash	Most convincing 1/1Completed First prompt and final A clean fix within the requested scope.	Most convincing 1/1Completed First prompt and final A clean fix within the requested scope.	1/1Completed First prompt and final Also fixed the same problem in helpButton_OnClick.	Review found a risk 1/1Completed First prompt and final Passed functionally, but the operation order remained risky.

1. Move Add into the header; remove Remove

DeepSeek · 320K: Most convincing 1/1Completed First prompt and final Removed both the obsolete class and the dead row.
DeepSeek · 160K: 1/1Completed First prompt and final Removed the dead row but kept the obsolete class.
Qwen · 262K: 1/1Completed First prompt 0.5/1 · final 1/1 Completed the behavior but kept the obsolete class.
Laguna: Review found an issue 1/1Completed First prompt 0.5/1 · final 1/1 Removed the bad class but added two unrequested changes.

2. Delete a device through X

DeepSeek · 320K: Review found a bug 1/1Completed First prompt and final The index guard was correct, but deleting an unselected device incorrectly changed selection.
DeepSeek · 160K: Most convincing 1/1Completed First prompt and final The only run to handle both the index and conditional reselection correctly.
Qwen · 262K: Review found a bug 1/1Completed First prompt and final Passed functionally but contained the same reselection bug.
Laguna: Review found a bug 1/1Completed First prompt and final The same reselection bug plus a missing index guard.

3. One name and a Not set state

DeepSeek · 320K: Most convincing 1/1Completed First prompt and final Used the existing GuiTitle property, which returns exactly Not set.
DeepSeek · 160K: 1/1Completed First prompt and final Used Name, producing the functional text no MIDI device.
Qwen · 262K: 1/1Completed First prompt 0.5/1 · final 1/1 Functional, but less precise than using GuiTitle.
Laguna: Review found an issue 1/1Completed First prompt 0.5/1 · final 1/1 Added a new converter and hard-coded text; the Active state was wrong.

4. Fixed width for animated Learn buttons

DeepSeek · 320K: 1/1Completed First prompt and final Set the width three times inline; functional but duplicated.
DeepSeek · 160K: Best design 1/1Completed First prompt and final Fixed the width once in the shared style and skipped the button that did not need it.
Qwen · 262K: Review found duplication 1/1Completed First prompt and final Set the width four times, including a button that did not need it.
Laguna: Review found duplication 1/1Completed First prompt and final Set MinWidth four times, including a button that did not need it.

5. Selected and hover styles

DeepSeek · 320K: Limited verification 1/1Manually completed First prompt and final The shared hover-style file is outside the archive and cannot be independently reviewed.
DeepSeek · 160K: Limited verification 1/1Manually completed First prompt 0.5/1 · final 1/1 Also found a leak, but its fix introduced a detach-and-reattach issue.
Qwen · 262K: Limited verification 1/1Manually completed First prompt and final The shared hover-style file is outside the archive.
Laguna: Limited verification 1/1Manually completed First prompt 0.5/1 · final 1/1 The shared hover-style file is outside the archive.

6. Fix the ParentWindow crash

DeepSeek · 320K: Most convincing 1/1Completed First prompt and final A clean fix within the requested scope.
DeepSeek · 160K: Most convincing 1/1Completed First prompt and final A clean fix within the requested scope.
Qwen · 262K: 1/1Completed First prompt and final Also fixed the same problem in helpButton_OnClick.
Laguna: Review found a risk 1/1Completed First prompt and final Passed functionally, but the operation order remained risky.

Quality review

A functional 6/6 does not mean a flawless diff

No run scored above 3 out of 5 for correctness. Every result contained at least one behavioral issue, and none of the models added automated tests.

DeepSeek at 320K was the best at completing and checking the task in one pass, but it still introduced an incorrect unconditional reselection after deleting a MIDI device.

The 160K run made some deeper design choices: it fixed the Learn width at the shared style level and found an existing event-subscription leak. At the same time, its cleanup created a latent detach-and-reattach lifecycle problem.

The two runs of the same DeepSeek model ended almost level — 3.8 and 3.7 — but arrived there through different strengths and weaknesses. The score therefore belongs to a run, not permanently to the model.

Quality by category

Reviewer: Claude Opus 5

These scores compare the specific archived changes, not permanent model quality. Categories are rows so the differences can be compared directly across runs.

Test 2 — quality comparison by category
Category	DeepSeek · 320K	DeepSeek · 160K	Qwen · 262K	Laguna
Correctness	3/5average	3/5average	3/5average	2/5weak
Robustness	4/5strong	4/5strong	3/5average	3/5average
Design	4/5strong	Highest score 5/5best	3/5average	2/5weak
Verifiability	Highest score 4/5strong	3/5average	2/5weak	2/5weak
Change discipline	Highest score 5/5best	4/5strong	3/5average	2/5weak

Correctness

DeepSeek · 320K: 3/5average
DeepSeek · 160K: 3/5average
Qwen · 262K: 3/5average
Laguna: 2/5weak

Robustness

DeepSeek · 320K: 4/5strong
DeepSeek · 160K: 4/5strong
Qwen · 262K: 3/5average
Laguna: 3/5average

Design

DeepSeek · 320K: 4/5strong
DeepSeek · 160K: Highest score 5/5best
Qwen · 262K: 3/5average
Laguna: 2/5weak

Verifiability

DeepSeek · 320K: Highest score 4/5strong
DeepSeek · 160K: 3/5average
Qwen · 262K: 2/5weak
Laguna: 2/5weak

Change discipline

DeepSeek · 320K: Highest score 5/5best
DeepSeek · 160K: 4/5strong
Qwen · 262K: 3/5average
Laguna: 2/5weak

These images show only part of the six-task test: moving Add into the header, adding X buttons, and showing Not set. The original is on the left and the 320K DeepSeek result on the right; both open at full size.

Original MIDI settings screen before the test, with Add and Remove buttons below the device list. — Original · Add and Remove below the list

DeepSeek V4 Flash 0731 DS4 result at 320K context, with Add in the header, X buttons, and a Not set item. — DeepSeek · 320K · Add in header, X, and Not set

Why the 160K run went deeper but took much longer

I do not treat this difference as evidence that a 160K context produces better solutions. It was most likely natural run-to-run variance: after autocompaction, the model spent longer reasoning and solved more design details.

That extra depth came at a cost. The 160K run took 1 hour and 27 minutes, while the 320K run completed all six tasks on the first prompt in under 22 minutes without my intervention.

One run was more ambitious and the other more efficient in practice. Both still reached 6/6 with similar quality scores, so the difference does not change the main result of the comparison.

After one working week

DeepSeek became my primary working LLM

The first test convinced me to use DeepSeek for a full working week. My subjective experience in normal work matched the tests: it felt closer to working with an older generation of large cloud coding models than with the small local models I had used before.

I describe a task, wait thirty minutes or an hour, and the model usually does it well. When it does not, a few follow-up prompts generally move it to the right place. I can trust it to keep moving the task forward slowly and steadily.

I never had the same level of confidence with Qwen. That is not meant as criticism: Qwen has 27B total parameters, while DeepSeek has 284B, roughly 10.5 times more. Total parameter count is not a complete measure of capability or compute cost for MoE models, but the scale difference is relevant context.

Qwen remains very capable and is often the more practical local model. DeepSeek is far more memory-intensive and consumes almost the entire machine. For harder work on this particular codebase, however, it crossed an important threshold: I can hand it a substantial task and trust it to keep making progress with less supervision.

After this week, DeepSeek V4 Flash 0731 DS4 became my primary working LLM. My current impression is that it will stay there for some time.

My testing led me to a clear conclusion: DeepSeek V4 Flash 0731 DS4 is the best local model I can currently make practical use of on my Mac.

How to read the results

A practical comparison, not a laboratory benchmark

The conditions were not identical down to the last detail, because the goal was to compare the models in real work on my 96 GB machine. Within each task, however, they started from the same state and received the same prompt.

The models used different context limits and run configurations because the goal was to find the best practical setup for each one on a 96 GB machine.
Laguna's Test 1 run was invalid because of a configuration problem and is not used as evidence against the model; Laguna ran with the corrected setup in Test 2.
Two tasks do not establish a universal ranking of coding models, and repeated runs can vary.
I verified functionality manually in the application, while Claude Opus 5 reviewed the archived changes with the same rubric.

Even with those caveats, the result for my use was clear: only DeepSeek fully completed the valid Test 1 run, and its 320K run solved Test 2 at 6/6 on the first prompt without intervention. Together with a full week of normal work, that makes DeepSeek V4 Flash 0731 DS4 the best local model I can currently use in practice on my machine.

DeepSeek V4 Flash 0731 DS4 in real software development

When a model stopped being just a toy

What a 27B model can do — and where it breaks

Using the 96 GB machine more fully

How I ran DeepSeek from the terminal

Same start, same prompt, real application

Same baseline

Functional result

Run cost

Change quality

Verify reality

Functional score

Quality score

Layer drag and drop and a design regression

The result without shorthand

Result by individual task

1. Design after dropping a scene

2. Layer reordering

3. Drop-position indicators

One small but critical difference decided the result

Why Laguna did not receive a zero

Quality by category

Correctness

Robustness

Design

Verifiability

Change discipline

Six MIDI interface changes

Every run reached 6/6. The path and quality differed.

Task by task

1. Move Add into the header; remove Remove

2. Delete a device through X

3. One name and a Not set state

4. Fixed width for animated Learn buttons

5. Selected and hover styles

6. Fix the ParentWindow crash

A functional 6/6 does not mean a flawless diff

Quality by category

Correctness

Robustness

Design

Verifiability

Change discipline

Why the 160K run went deeper but took much longer

DeepSeek became my primary working LLM

A practical comparison, not a laboratory benchmark