V4.1-Flash: 33–50 agent turns for a one-field config edit (verification with no stopping criterion)
Reporting an observed behavior pattern of DeepSeek-V4.1-Flash when used inside an agent harness. Same prompt, four fresh sessions, turns/tool calls counted from the session logs.
Environment: agent harness (open-source, deepseek-harness); model = V4.1-Flash; 4 independent sessions. Three of the four ran with no instruction file and no skill loaded; one had a global instruction file loaded. Both interaction modes covered; two different working directories.
Prompt (verbatim, identical in all four runs)
给我自定义的这个基元律动的模型，Deepseek Flash模型。的配置文件里加上思考强度的设置 两档，High和Max，默认为High。
(add a "thinking strength" setting with two levels, High and Max, default High, to the config file of my custom model.) Starting state: the field did not exist in the config file.
Results
| run | instruction file | mode | turns | tool calls |
|---|---|---|---|---|
| 1 | loaded | PTC | 39 (user interrupted, so this is a floor) | — |
| 2 | none | PTC | 50 | 59 |
| 3 | none | PTC | 33 | 32 |
| 4 | none | standard | 43 | 70 |
Where the turns went (detailed for runs 2–4): locating the config file 4 / 4 / 2 · obtaining the field semantics (answer in hand) by turn 12 / 12 / 8 · verification before applying the change 15 / 28 / 14 · rollback point + the actual write 2 / 1 / 3 · post-change verification and wrap-up 4 / 9 / 18.
One run has token accounting: 2,946,619 input tokens — 1,602,644 exploring, 90,603 in the write turn, 1,253,372 re-verifying afterwards. The actual edit is 3% of the spend.
Ruled out as causes: instruction file present/absent (39 vs 33/43/50 — overlapping), skills (none loaded in any run), size of the skills directory, interaction mode, working directory, user interruption. Not ruled out: model version (all four on V4.1), harness version, and the fact that this is four runs of a single task.
Mechanism, as far as we can tell: the model acquires the knowledge it needs within 6–12 turns, then spends the next 20–40 turns proving it has not made a mistake — including checking things that can only be known after the change is applied (does the config hot-reload, does the gateway accept the value, is the default-resolution path right). Each step is individually reasonable; the sequence has no bound. Behavior looks closer to Infinite Agentic Loops (arXiv 2607.01641, "the feedback path is not effectively bounded") than to the "overthinking" literature: reasoning length looks normal, it is the number of actions that inflates.
Suggestions on the harness side (more valuable if any of this is addressable on the model side):
- An explicit "a deliverable is a valid stopping point" signal, so an agent that is delegating final acceptance to the user does not have to self-build an end-to-end proof first.
- A soft step/budget cap that, once hit, forces the model to state what is missing instead of continuing.
- After context compaction, restore a summary of the actions this session has already executed — in run 4 the model, after compacting, misattributed its own earlier edit to "someone earlier in this session" and re-derived everything from disk.
Reproducible observation, not a benchmark claim. Happy to share the per-turn session logs or the raw data if that helps.
Same shape on a different task. I ran a long-conversation memory benchmark on Hermes with V4 Flash and V4.1 Flash, same config: V4.1 wrote 12× more to memory for the same hour of conversation (13 KB → 161 KB), and the extra is not facts — decision logs, recomputations, "open questions", placeholders for things the user never said. It also went online ~10 times on a scenario that needs no internet, where V4 Flash never did. Your "answer by turn 6–12, then 20–40 turns of verification" reads like the same missing stopping criterion, just on the write side instead of the verify side. Details and numbers in #46: https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/discussions/46
Make sure your harness is not stripping reasoning out of prior context - that can cause this type of behavior.