k3 degenerates into infinite identical-tool-call loop at large context (thinking says "Edit", emitted call stays "Read")

What version of Kimi Code is running?

0.38.0

Which model were you using?

k3 (alias kimi-code/k3), thinkingEffort high, maxTokens 1000000

What platform is your computer?

Linux x86_64

What issue are you seeing?

During a multi-file review/fix task, the model entered a repetition loop: it emitted the exact same Read call (same path, same line_offset, same n_lines) ~90 times in a row, while its own thinking blocks explicitly recognized the loop and announced it would now call Edit — the emitted tool call stayed Read every single time. Across the whole session: 395 tool calls, 0 of them Edit/Write, although the task was "fix everything". The user had to cancel the turn 9 times.

No hook blocked anything, no test failed, no tool returned an error — this is pure model-side degeneration at large context.

Evidence from the wire log

Session session_c2cfd570-745b-44c1-8bf1-4609c34fc07a (2026-08-24, exportable via kimi export on request):

• 400 LLM requests, all model k3
• Context size per turn grew 203k → 374k tokens
• 395 tool calls total; 0 Edit/Write calls
• 11 turns, 9 ended user_cancelled

Turn 6 (147 steps, 149 tool calls) — from step 6 onward, two Read calls alternate in a loop:

• Read(stage-matrix.md, line_offset=69, n_lines=4) — 72 times
• Read(SKILL.md, line_offset=129, n_lines=4) — 70 times

Both returned identical successful results every time. Meanwhile the thinking blocks say, verbatim (repeated dozens of times):

"I'm stuck in the same loop again — reading instead of editing. I need to break this. Let me make the edits NOW. I have the exact strings. I'll use Edit tool directly."

The following tool call is the same Read again — every time.

Why this is severe

1. Thinking/emission mismatch: reasoning correctly identifies the loop and the correct next action (Edit), but the emitted tool call does not follow — looks like a generation-level repetition lock, not a reasoning failure.
2. No guard rail exists: nothing detects N identical consecutive tool calls and stops the turn. The loop burns tokens/quota until the user notices (~34 min, ~100k wasted tokens in one turn here).
3. Realistic trigger: a broad review+fix task across many files pushed context past ~350k tokens, where the degeneration began — normal power-user scenario.

Suggested fixes

1. Loop detection in the agent loop: hash (tool name + normalized arguments); if the same call repeats ≥3–5× consecutively with an unchanged target (file mtime), force-stop the turn with a clear notice. (We implemented this locally as a PreToolUse hook and it works; built-in would be better since hooks are opt-in.)
2. Repetition penalty / loop breaker at model or sampler level when thinking repeats verbatim across steps.
3. The client-side staleGuard already records file mtimes — it could feed detection instead of only recording.

Additional information

Happy to provide the full debug ZIP / wire log excerpt. We also have a working reference implementation of the loop-detection hook if useful.

Start in the agent loop and inspect how the client-side staleGuard records file mtimes; the issue does not name specific files or tests. Review the wire-log pattern and the suggested PreToolUse hook, then determine how repeated normalized tool calls should be detected and surfaced. Done means the unchanged Read loop is stopped with a clear notice before it consumes the turn.