Stop Repeated Agent Retries with a Circuit Breaker
A small, inspectable experiment with its inputs, decisions and limitations recorded. This guide is not a production guarantee.
Use caseFind uncertain results, risk signals, and items needing review
Study a semantic circuit breaker, with hard limits kept in code.
Source · Ashutosh Mathore · X companion
2026-09-21 · Editorial update; no live model call
Problem
Section titled “Problem”The author describes a circuit breaker for agents that make different attempts while keeping the same incorrect assumption. The numerical improvement in the post is an author example, not a JevLog measurement.
Check progress without expanding authority Goal → Observed outcomes → New evidence? → Hard limits → Pause + handoff
The model cannot expand its own budget.
Before you begin
Section titled “Before you begin”-
Use a small fictional or authorized dataset. Do not paste private customer data into an unfamiliar service.
-
A current browser for reading. Check the linked project for its own runtime, access and cost requirements.
1. Capture a small trace
Section titled “1. Capture a small trace”Use a fictional trace with a goal, recent actions and observed failures. Redact tokens and personal data. Keep the raw evidence for review.
2. Set a hard budget first
Section titled “2. Set a hard budget first”Enforce a maximum number of calls, elapsed time and spend in deterministic code. These limits must work even if the decision model fails.
3. Ask a narrow progress question
Section titled “3. Ask a narrow progress question”Compare the recent outcomes with the stated goal. Ask whether a new attempt contains new evidence, rather than whether an arbitrary action text looks different.
4. Pause instead of improvising a fix
Section titled “4. Pause instead of improvising a fix”Route a suspicious loop to a user-visible stop and a concise evidence log. The model must not grant itself more budget or new permissions.
Different actions can repeat the same bad assumption
A trace may contain navigation, refresh and a new selector while making no progress at all. If every observation is the same permission error, changing the next click does not create new evidence. Record observations as well as action names.
Enforce maximum calls, elapsed time and spend in code before adding a model-based check. These limits must hold when the model fails or asks to continue. Send only a minimal, redacted trace to any evaluator. Keep raw credentials and private account information out of the prompt.
Ask whether the next attempt has new evidence or still relies on a rejected assumption. Keep an insufficient-evidence outcome. A suspicious loop should pause with the goal, latest observations and reason visible to a person. The model cannot grant itself more budget or permissions.
Before resuming, observe the real current state. If a previous write may have succeeded, query its result rather than repeat it. A pause is not completion; it is a controlled handoff that prevents an error from being amplified.
| Step | Action | Observed result |
|---|---|---|
| 1 | Open report | 403 |
| 2 | Refresh | Same 403 |
| 3 | Change entry link | Same account restriction |
| 4 | Try another selector | No new evidence |
Fictional trace, not the author’s run.
Result and cautions
Section titled “Result and cautions”A small, inspectable experiment with its inputs, decisions and limitations recorded. This guide is not a production guarantee.
- A valid label can still be wrong. Keep a review path and keep irreversible actions outside the exercise.
- A community demonstration is not an independent benchmark. This collection does not reproduce the linked video or repository.
- You can identify the input, its source, and the fields that leave your system.
- Original identities, failed rows, uncertain cases and human corrections remain visible.
- You distinguish an offline fixture, an author demo and a live evaluation you ran yourself.
Source boundary: compiled from the linked public sources; not reproduced here. Review classifications before acting; they do not run actions automatically.
Related guides
Section titled “Related guides”Why add semantic checks to a step cap?
Section titled “Why add semantic checks to a step cap?”They may stop waste sooner, but require false-stop and missed-stop evaluation.
Does stopping always mean model failure?
Section titled “Does stopping always mean model failure?”No. Access, input and environment can be the cause.