The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Preventing an AI agent from wasting tokens requires two independent stop mechanisms: a hard resource budget and a semantic completion test. Cap turns or iterations, total and per-response tokens, tool calls, and elapsed time; then stop only when the agent has produced a valid final state. If either the budget is exhausted or progress stalls, halt tool execution, save the trace, and return a bounded diagnostic instead of replaying the same prompt. This design protects you when a model stalls, a tool keeps returning unchanged data, or a completion evaluator never becomes true.
What causes an AI agent reasoning loop?
An agent loop is the repeated cycle in which a model chooses an action, a runner executes a tool or handoff, the result is added to the conversation, and the model is invoked again. The cycle ends only after a final response or an explicit stop condition. OpenAI’s Runner reference names the failure raised when a configured turn budget is exceeded MaxTurnsExceeded.
Loops are not always obvious. An agent may call the same search tool with nearly identical arguments, keep rewriting a file without changing it, ask another agent to repeat a completed check, or spend many turns “thinking” after the required evidence is already available. A valid-looking completion predicate can also fail indefinitely if a field is never populated or an evaluator gives inconsistent answers.
Do not assume a model will self-limit. Microsoft Agent Framework’s guidance is blunt: “Always bound autonomous loops. A completion condition can fail, a model can stall, and an evaluator can be probabilistic.” The safe design treats every run as a leased amount of compute, not as an open-ended conversation.
#1 Best Overall
Which limits should an AI agent have?
Use limits at three levels: each model or tool call, the complete run, and the progress made between iterations. A single limit is easy to bypass; a layered policy fails closed.
Per-call limits
- Output-token cap: Restrict the maximum response size for one model invocation. This limits a verbose explanation or an accidental recursive prompt from consuming the whole budget at once.
- Tool-batch cap: Limit how many tool calls the model may request in one response. A batch of ten calls can multiply cost and side effects before your controller can inspect progress.
- Argument and payload limits: Reject oversized tool arguments, file ranges, search result sets, or nested messages before they are sent downstream.
- Timeout: Give each model and tool call its own deadline. A hung network request must not consume the entire run’s wall-clock allowance.
Per-run limits
- Turns or iterations: The number of model-to-tool cycles permitted. OpenAI Runner reports
MaxTurnsExceededwhen this budget is crossed; Microsoft examples configuremax_iterations. - Total tokens: Add input and output usage across the run when your framework exposes it. This catches a loop whose individual responses are short but whose history keeps growing.
- Total tool calls: Count calls separately from turns because one turn can request several tools.
- Wall-clock deadline: Stop at a fixed elapsed time, including time spent waiting for tools or handoffs.
- Cost ceiling: Convert token usage and provider pricing into a maximum amount for production workloads. Keep this separate from a token ceiling so a model-routing change cannot silently raise spend.
Progress limits
Budgets answer “how long may this run continue?” A progress test answers “is another iteration doing useful work?” Require at least one of the following after each iteration:
- a changed state hash;
- new evidence or a new artifact;
- a completed todo item;
- a materially different tool action;
- an evaluator-approved final result.
If none occurs, increment a no-progress counter. A strict policy can stop after the first duplicate action; a less disruptive policy can allow one confirmation attempt and then escalate. The threshold should be chosen from the risk of the task, not from a universal number—authoritative sources publish no generally applicable iteration threshold or token-savings percentage.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallHow do I define semantic completion?
Semantic completion is an explicit, machine-checkable statement that the requested work is finished. It should be narrower than “the model sounds confident.” AutoGen documents combining a max_turns limit with termination conditions so either a valid completion or a hard budget stops the team.
Use a final-state contract
Define the fields that must exist before the controller accepts the result. For a research task, that might be a list of sources, claims, and unresolved questions. For a code change, it might be a patch identifier, test results, and a clean validation status. Reject malformed or incomplete output and terminate with an explicit failure state rather than asking the agent to improvise indefinitely.
Require a completion marker only as a supplement
A marker such as DONE is useful when it is emitted inside a schema-validated field, but it is not proof by itself. Check that the marker is accompanied by required artifacts and that no mandatory todo item remains open. A model can print a marker prematurely or omit it after doing all the work.
Keep evaluator termination bounded
Model-based evaluators are probabilistic. Give the evaluator a fixed number of attempts, a small output budget, and a deterministic fallback. If the evaluator disagrees with itself or cannot inspect the required evidence, stop with completion_unknown rather than launching another unbounded repair cycle.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
- Ideal for Gifting
- Ideal for a bookworm
- Compact for travelling
How can I detect a low-progress loop?
Instrument every iteration before you attempt to optimize it. Camunda’s guidance notes that no single health indicator proves an agent is stuck; combine state, usage, and duration signals.
Record an iteration envelope
At minimum, persist these fields for every model and tool event:
- run ID, parent run or handoff ID, and iteration number;
- model name and routing decision;
- tool name, normalized arguments, and result status;
- response finish reason;
- input, output, and cumulative token counts;
- start time, end time, and elapsed duration;
- a hash of the relevant task state before and after the action;
- completed and outstanding todo items;
- the stop reason if the run ends.
Normalize arguments before hashing them. Remove request IDs, timestamps, random ordering, and other fields that change while the actual action remains the same. Keep the original arguments in the trace for auditability, but use the normalized form for duplicate detection.
Signals that deserve an alert
| Signal | What it suggests | Controller response |
|---|---|---|
| Same tool and materially identical arguments recur | The agent is replaying work without a new state | Stop tools, persist the trace, and request a changed plan or approval |
| Tool-call count rises while the state hash is unchanged | Actions are producing no observable progress | Terminate or pause before the next call |
| Turn duration exceeds the normal distribution | A model, evaluator, or tool may be stalled | Apply the per-call timeout and inspect the last event |
| History grows without new evidence or completed work | Context is expanding while useful output is not | Summarize or refresh context once, then stop if progress remains absent |
| Usage approaches a configured limit | The run may exhaust its budget before finishing | Switch to a bounded finalization path or report budget exhaustion |
Strands exposes explicit stop reasons such as limit_turns, limit_total_tokens, and limit_output_tokens. TanStack’s loop strategies expose iteration count, total and last-turn tool-call counts, finish reason, and messages, which are useful inputs for custom health checks.
How do I build a loop-safe controller?
The controller—not the model—should own budgets, progress checks, and finalization. The following sequence works whether your agent is a single worker, a multi-agent team, or a tool-using chat process.
- Write the run contract. List the required final fields, allowed tools, side effects, and what counts as evidence. Define explicit statuses such as
completed,budget_exhausted,stalled,approval_required, andfailed. - Set conservative defaults. Choose maximum turns, total tokens, tool calls, per-call output, and wall-clock time before the first production run. Make each value configurable by task type, and record the values in the trace.
- Validate tool requests before execution. Check the tool name, schema, authorization, argument size, and remaining budget. Reject unknown tools and calls that would exceed the remaining allowance.
- Execute one controlled iteration. Capture the model response, finish reason, tool calls, tool outputs, token usage, and elapsed time. Do not hide retries inside a library call; count them against the same run budget.
- Compare progress. Recompute the relevant state hash, compare normalized tool arguments with recent actions, and mark newly completed work. A changed model message is not enough if the task state and evidence are unchanged.
- Apply escalation rules. On a duplicate action or failed progress test, pause tool execution. Ask for a revised plan, reduce the tool set, refresh context, or request human feedback. Never blindly replay the same prompt.
- Check semantic completion. Validate the final schema, evidence, todo set, and any evaluator decision. Accept only a result that meets the contract.
- Finalize once. If the run reaches a limit, return a bounded diagnostic with the stop reason and useful partial artifacts. Do not start a hidden “last attempt” after the budget is exhausted.
while true:
if budget.turns_exhausted() or budget.tokens_exhausted() or deadline_reached():
return finalize(status="budget_exhausted")
response = model.invoke(context, limits=per_call_limits)
record(response)
if not schema_valid(response):
return finalize(status="invalid_result")
if response.requests_tools:
if duplicate_action(response) or not state_can_change(response):
pause_tools()
return escalate(status="stalled", trace=current_trace())
outputs = execute_allowed_tools(response.tools)
record(outputs)
if progress_changed(outputs) and completion_contract_met(outputs):
return finalize(status="completed")
continue
if completion_contract_met(response):
return finalize(status="completed")
return finalize(status="incomplete")The pseudocode deliberately finalizes on an invalid or incomplete terminal response. Whether you instead allow one repair attempt is a product decision, but that attempt must have its own token and turn allowance and must not bypass duplicate detection.
What should happen when a loop is detected?
Stopping safely is more than breaking a while statement. Preserve enough context for a person or a later run to understand what happened, and prevent partial side effects from being mistaken for success.
Freeze execution first
Cancel queued tool calls where possible and prevent new calls from being scheduled. For external actions such as sending messages, changing records, deleting files, or spending money, use idempotency keys and an approval pause. A model that is repeating an action must not be allowed to repeat a destructive side effect while a diagnostic is being generated.
Return a bounded diagnostic
Report the run ID, stop status, limits reached, last successful state, unfinished items, and a link or identifier for the trace in your own system. Avoid dumping the entire conversation into the caller’s response; that can create another token spike. Include the last distinct tool action and the reason it was considered non-progressing.
Retry only with a changed plan
A retry is justified when you can alter the conditions that caused the loop: remove a failing tool, narrow the objective, refresh stale context, change the model route, or obtain human clarification. AutoGen documents max-turn pauses and resumable state for human interaction. Resume from the persisted state, not by replaying every prior message as a fresh autonomous run.
How do common agent frameworks expose loop controls?
Framework APIs differ, and labels change between releases. Verify the version you deploy, but evaluate each framework against the same control categories.
| Framework or guidance | Documented control | Practical implication |
|---|---|---|
| OpenAI Runner | Turn budget and MaxTurnsExceeded |
Handle the limit exception as a normal bounded outcome and persist the trace |
| Microsoft Agent Framework | max_iterations examples and an explicit warning to bound autonomous loops |
Do not rely on a completion condition alone |
| AutoGen | max_turns combined with termination conditions, plus resumable max-turn pauses |
Use either valid completion or a hard stop, then involve a person when needed |
| Strands | limit_turns, limit_total_tokens, and limit_output_tokens stop reasons |
Map explicit limit reasons to your own run statuses and alerts |
| TanStack loop strategies | Iteration count, total and last-turn tool calls, finish reason, and messages | Build duplicate and no-progress predicates from exposed telemetry |
| Camunda guidance | Combined state, usage, and duration health indicators | Alert on correlated symptoms instead of one metric |
For a production decision, compare hard limits, semantic termination APIs, duplicate-progress hooks, trace export, approval behavior, state persistence, and the error semantics when limits are exceeded. A framework that has a turn counter but cannot expose tool arguments or state changes will make reliable loop detection harder.
How should limits be chosen for different tasks?
There is no universal safe turn count. Start from the workflow’s required number of distinct actions, then add a small allowance for validation and one planned recovery—not an unlimited cushion.
Short, read-only lookups
Use a small turn and tool-call budget because the expected path is short. Require the answer to cite or return the retrieved record, and stop when the same query returns the same result without a new constraint.
Rank #4
Multi-step research and analysis
Budget by subtask rather than by an unbounded conversation. Track completed evidence items, cap history growth with controlled summaries, and require each additional search to address a named unanswered question.
Code changes and automation
Separate planning, editing, and validation budgets. A test failure may justify one changed repair attempt, but repeated edits to the same file with unchanged test output should trigger a pause. Make writes idempotent and require a final diff or artifact identifier.
Recommended Free Tools
High-impact or destructive actions
Use the tightest limits and an approval gate immediately before the irreversible operation. The agent may prepare a plan and a preview, but a human or deterministic policy should authorize execution. Persist the approval decision with the run trace.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do I keep context from creating a loop?
Long history can make an agent appear busy while it loses the original objective. Keep a compact, structured state separate from conversational messages. Store the current goal, completed items, evidence identifiers, last tool result, and unresolved blockers in that state.
When context must be refreshed, summarize only verified facts and open decisions. Recompute the state hash after summarization; a shorter transcript is not progress unless it preserves the information needed to choose a different action. If the same failed tool result is repeatedly pasted into context, mark it as a blocker and route to recovery instead of asking the model to reinterpret it again.
How should loop incidents improve the system?
Treat every stopped loop as an engineering signal. Store the prompt, normalized and raw tool inputs, tool outputs, model finish reasons, token usage, timing, state transitions, stop reason, and final status. Redact secrets and personal data before wider access, but retain enough structure to reproduce the decision.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Review representative traces rather than only the worst incident. Classify whether the cause was an ambiguous goal, a misleading tool description, stale state, a validation bug, an evaluator disagreement, a provider failure, or an unsafe retry policy. Turn recurring patterns into regression evaluations. The OpenAI agent-improvement cookbook, dated May 12, 2026, describes a loop that combines traces, human and model feedback, evaluations, and reviewed harness changes; it presents a methodology, not a guaranteed savings figure.
Best Value
- It can be a gift option
- Comes with secure packaging
- Helpful in various ways
After each change, test both successful completion and forced failure: make a tool return unchanged data, make an evaluator disagree, delay a call past its timeout, and exhaust each budget independently. Confirm that the controller stops, emits the intended status, and does not schedule a hidden retry.
What are the most common mistakes?
- Relying on a completion phrase: A marker without schema and evidence validation can be emitted too early or never at all.
- Using only a turn limit: A single turn can contain many tool calls, and a short response can still inflate total history and cost.
- Retrying the identical prompt: Repetition is not recovery. Change the plan, context, tools, or authority before retrying.
- Ignoring tool-side retries: HTTP clients, SDKs, and handoff layers may retry invisibly. Count those attempts against the run budget.
- Alerting on one metric: A long turn can be legitimate, and a high tool-call count can be normal for a complex task. Correlate state, usage, and duration.
- Discarding traces after a stop: Without the final state and stop reason, you cannot distinguish a healthy budget exhaustion from a controller defect.
- Allowing side effects before approval: A loop can duplicate an externally visible action even when token usage remains within limits.
What is the safest default policy?
Give every call a token and time cap; give every run turn, total-token, tool-call, cost, and wall-clock caps; require a schema-valid final state; and calculate progress from state and evidence, not from prose. On the first repeated action or failed progress check, pause tools, save the trace, and request a revised plan or human approval. This policy may terminate some difficult runs early, but it guarantees that a broken completion predicate cannot consume unlimited calls.
Frequently Asked Questions
Can an AI agent loop even when its responses are different?
Yes. Different wording can conceal the same unchanged state, repeated evidence, or identical side effect. Compare normalized tool arguments, state hashes, completed work, and new evidence rather than comparing text alone.
Should I lower the model’s temperature to stop loops?
Lower randomness may reduce variation, but it does not replace budgets or progress checks. A deterministic model can deterministically repeat the same failed action, so keep hard limits and semantic termination in place.
What should I show a user when the agent hits its limit?
Show a clear status such as budget exhausted or stalled, the last completed task, and what input or approval would allow a safe retry. Keep raw traces and sensitive tool payloads in the protected observability system instead of exposing them by default.
How can I test runaway-loop protection before production?
Use fault-injection tests that return unchanged tool results, delay calls, invalidate evaluator output, and exhaust turns, tokens, and wall-clock time separately. Assert that no new tool call is scheduled after each stop status and that a resumable state is saved when your workflow supports it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
