[BUG] ReactLoopAgent.turn() step loop has no upper bound — a stalled model can burn ~1M tokens in a single turn

[syukouyuu]

packages/core/agent-loop/src/agent.ts's ReactLoopAgent.turn() runs an unbounded while (true) step loop. There is no maxSteps/step-budget/timeout circuit breaker anywhere in the codebase (confirmed via grep -rn "maxSteps\|max_steps\|maxIterations\|stepLimit" across packages/ and apps/ — zero matches). The only exits are:

1. the model emits an assistant message with zero tool calls,
2. the request hits max-tokens, or
3. a tool result sets concludesTurn: true.

If the model keeps calling tools indefinitely, nothing in the harness intervenes.

Repro

A single exploratory Q&A turn ("how do I delete an archived branch conversation in the Web GUI?") ran 27 steps over ~103s before I manually interrupted it with a new message. The model's own reasoning blocks explicitly concluded it had enough information at least twice (step 9/10 and step 22/23 — "Now I have all the facts I need. Let me summarize") but kept issuing new bash/grep tool calls anyway instead of emitting a final text-only message.

Why it gets expensive fast

Each step's buildRequest() calls this.session.deriveMessages() (agent.ts:342) and resends the entire accumulated session history as messages (agent.ts:488) — there's no summarization/windowing inside a turn. So per-step input token cost grows roughly linearly with step count, making total turn cost grow close to quadratically. In this session (deepseek-v4-flash, reasoningEffort: high, maxTokens: 256000/step), 27 steps pushed cumulative token usage to roughly 1M.

Suggested fix

• Add a configurable maxSteps per turn (alongside the existing maxParallelToolCalls in AgentLoopSettings), and give TurnEndReason a new max-steps variant so hitting the cap ends the turn cleanly instead of running forever.
• Optionally, when a step's reasoning explicitly states the task is already answerable but the model still emits tool calls, surface that as a soft "wrap up" nudge before hard-capping.

Related but distinct

This looks related to #2107 (web profile ships with compaction-basic/command-compact/tool-result-pruner disabled, so long web sessions never auto-compact and eventually hit context-exceeded), but it's a separate root cause: #2107 is about compaction not firing; this report is about the step loop itself having no ceiling regardless of compaction state. Fixing one doesn't fix the other — a turn can still spin indefinitely even with working compaction, and compaction alone won't stop a model that keeps calling tools past the point of having enough information.

Environment

• Model/provider: deepseek-v4-flash via deepseek-official
• reasoningEffort: high, maxTokens: 256000
• Agent preset: standard, contextWindow: 1000000

[NovaRouteAI]

This failure mode bit us too. Our incident write-up: a stalled model in a loop burned through budget before detection caught up — detection lagged ~90 seconds, which was the real gap. Two mitigations that stuck: a hard step budget inside the loop, and per-request cost telemetry so anomalous burn shows up in logs rather than on the invoice.

Full notes, including what we'd do differently: https://github.com/NovaRouteAI/failover-field-notes
Telemetry schema + validator: https://github.com/NovaRouteAI/per-request-cost-telemetry

[argszero]

Verified against the current checkout (master @ 99f6f02fec, rc.7) — the report's core claim still holds, and there are a few implementation details that make the fix slightly subtler than just "add a counter".

1. The unbounded loop is confirmed at source.

• grep -rn "maxSteps\|max_steps\|maxIterations\|stepLimit" across packages/ → zero matches. No step budget, no timeout circuit breaker.
• ReactLoopAgent.turn() (packages/core/agent-loop/src/agent.ts:263) is while (true). Its exits all require turnEnds to be set: reject → blocked (:267), empty messages → break (:271), turnEnds && inbox.nextStep.length === 0 → break (:295-299), or nothing pending → return false (:324).
• turnEnds only becomes non-null when a step returns completed / max-tokens (step() :391-399: no tool calls, or a tool sets concludesTurn). A model that keeps emitting tool calls returns null forever → the loop never reaches any breaker.
• The mechanism that keeps the loop fed: executeToolCalls splices each tool's context message back into inbox.nextStep (:395-398). So every tool call manufactures the next iteration's input — the model can sustain the loop indefinitely, exactly as reported (27 steps / ~1M tokens).

2. The cost claim checks out, and the telemetry foundation already exists.
buildRequest calls session.deriveMessages() per step (:341) and ships the full accumulated history as messages (:488) — per-step input cost grows linearly, total turn cost ~quadratically. Worth noting for NovaRouteAI's "per-request cost telemetry" point: assistant/message already records assembler.usage per step (:387), so the data for a per-turn cost budget is already in the session log — a budget would only need the loop to check it.

3. Fix design fits two existing patterns almost exactly.

• TurnEndReasonMap (packages/core/session/src/types.ts:155-177) is a merge-extensible map — adding 'max-steps': { kind: 'max-steps' } is the intended extension path (the map's JSDoc literally invites plugin variants).
• 'max-tokens' is already a sticky turn ender: agent.ts:285-291 preserves it against later "normal" step outcomes. A max-steps variant needs the same sticky guard (note :290 only special-cases 'max-tokens' today — a cap set at step N must not be overwritten by a later completed).
• Settings-wise, AgentLoopSettings.maxParallelToolCalls (packages/core/agent-loop/src/index.ts:244-251) shows the zod schema + resolution pattern for a new maxSteps field.

4. Two subtleties that make "just set a counter and break" insufficient:

• The break at :295-299 only fires when inbox.nextStep is empty. A hard cap must decide what happens to already-queued tool-result contexts (in-flight parallel calls): either drain them into the log before ending, or keep the turn alive just long enough to emit their tool/results. The existing agent/turn-stopping dispatch (:296) is the natural hook for that cleanup — and it's also exactly where the "soft wrap-up nudge" idea (surface 'you have enough info' when reasoning says so) would live, since it fires once per turn before the end.
• The retry loop inside step() (:339, while (true) over buildRequest → stream → agent/request-error waterfall) is separate from the step loop. It's bounded in practice because the default action throws and only an explicit {kind:'retry'} continues, but it's worth mentioning in the same audit — a retry-happy middleware currently has no global cap either.

5. On the #2107 distinction — agreed, they're orthogonal: compaction governs context length across turns; a step budget governs model-call count within one turn. A capped turn still spins fine with broken compaction, and working compaction doesn't stop a model that keeps calling tools. The two fixes compose; they don't substitute.

The suggested maxSteps + 'max-steps' end-reason + turn-stopping cleanup is the smallest design that matches the codebase's own extension conventions — this would make a solid PR once the maintainers can accept them.

[NovaRouteAI]

This source-level confirmation is the most thorough the thread has gotten — the executeToolCalls splice detail is the piece I was missing, because it explains why the loop is self-feeding rather than merely uncapped.

Your point about assembler.usage already landing in the session log per step matches what we saw operationally: the data for a per-turn budget exists, what's missing is a consumer inside the loop. The smallest version we'd trust: accumulate input/cached/output tokens across steps, recompute cost locally against the price card, and compare against a budget at each step boundary. Two additions from our field notes: make the cap sticky the same way 'max-tokens' is, so a late completed outcome can't overwrite it; and when the cap fires, surface the actual spend in the turn-end payload rather than a bare timeout, because "why did this turn stop" is the first question in any incident review.

Your distinction with #2107 also matches our experience — compaction governs context across turns, a step budget governs calls within one turn, and we ended up needing both.

Quick question on placement: would you put maxSteps in AgentLoopSettings next to maxParallelToolCalls, or do you see it belonging per-agent so plugin variants can override it?