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.