Feature request
Add a supported way for host applications to stop or gracefully terminate repeated tool-call loops before they hit a hard outer iteration cap.
Problem
When an assistant keeps producing tool calls, the loop currently treats tool results as a reason to continue asking the model for another turn. That is useful for normal tool use and one-off recoverable errors, but it can also lead to long retry loops where the model repeatedly calls the same tool, repeats the same arguments, or keeps reacting to tool errors without making progress.
In host apps like TunaCode, the only reliable protection is an outer max_iterations / timeout style guard. That works as an emergency brake, but it is not a graceful loop-control mechanism: the host cannot easily say "this pattern is stuck; end cleanly after this turn/tool batch."
Requested capability
Please consider adding one or more explicit loop-control hooks/signals, for example:
- a per-tool-result termination flag, such as
terminate: true, that prevents another model turn after the current tool batch
- an
after_tool_call hook that can inspect/override tool result metadata and mark the batch terminal
- a
should_stop_after_turn hook that receives the assistant message, tool results, current context, and new messages, then can end the loop cleanly
- a
before_tool_call hook that can block tools before execution and return a structured tool error
Example policies this would enable
- stop after the same tool fails 3 times
- stop after repeated calls with identical arguments
- stop after too many consecutive tool-only turns
- stop when an edit tool is repeatedly failing hash/cache validation
- stop when all tools in a batch indicate that another model turn is not useful
Why this matters
This would let applications distinguish between useful model recovery and an obviously stuck tool loop. It would also allow a normal AgentEndEvent / finalization path instead of relying on aborts, hard iteration limits, or request timeouts.
For comparison, similar host-side control points exist in loop designs with afterToolCall, shouldStopAfterTurn, and per-tool-result termination signals. The main ask is not a specific API shape, but a supported integration point for graceful host-side loop termination.
Feature request
Add a supported way for host applications to stop or gracefully terminate repeated tool-call loops before they hit a hard outer iteration cap.
Problem
When an assistant keeps producing tool calls, the loop currently treats tool results as a reason to continue asking the model for another turn. That is useful for normal tool use and one-off recoverable errors, but it can also lead to long retry loops where the model repeatedly calls the same tool, repeats the same arguments, or keeps reacting to tool errors without making progress.
In host apps like TunaCode, the only reliable protection is an outer
max_iterations/ timeout style guard. That works as an emergency brake, but it is not a graceful loop-control mechanism: the host cannot easily say "this pattern is stuck; end cleanly after this turn/tool batch."Requested capability
Please consider adding one or more explicit loop-control hooks/signals, for example:
terminate: true, that prevents another model turn after the current tool batchafter_tool_callhook that can inspect/override tool result metadata and mark the batch terminalshould_stop_after_turnhook that receives the assistant message, tool results, current context, and new messages, then can end the loop cleanlybefore_tool_callhook that can block tools before execution and return a structured tool errorExample policies this would enable
Why this matters
This would let applications distinguish between useful model recovery and an obviously stuck tool loop. It would also allow a normal
AgentEndEvent/ finalization path instead of relying on aborts, hard iteration limits, or request timeouts.For comparison, similar host-side control points exist in loop designs with
afterToolCall,shouldStopAfterTurn, and per-tool-result termination signals. The main ask is not a specific API shape, but a supported integration point for graceful host-side loop termination.