Have you ever watched an AI agent confidently burn through your entire daily API quota while trying to "optimize" its own output?
I recently experienced a hilarious (but expensive) failure case with an agent doing deep research. I told it: "This is consuming too many tokens. Please optimize your process to save tokens."
The agent said "No problem," and got to work.
What it actually did was search the web, realize its summary was too long, and then decide to rewrite the summary to make it shorter. It wrote a new one. It was still too long. So it rewrote it again. And again. And again.
It repeated this loop over 100 times until it gave up and told me, "I really can't make it any shorter." It completely drained my 5-hour quota.
The most terrifying part? The agent had absolutely no idea it was doing something stupid. It couldn't "see" that its retry loop was consuming massive amounts of tokens. It only looked at the text length, completely blind to the physical cost of its own actions.
This is a classic "long-horizon task drift."
Why do agents do this?
Because LLMs lack an external physical witness. They are trapped inside their own textual context. They can read their own text, but they cannot independently verify the real-world cost or the actual state changes of their actions.
To solve this, we need to stop asking the model to "behave" and start enforcing physical boundaries at the infrastructure level.
Here are two lightweight open-source tools I built to fix this exact problem.
- The Budget Proxy: Cut the loop at the HTTP layer
Instead of modifying the agent's complex prompt or loop logic, we intercept the API calls. We built a local, OpenAI-compatible proxy.
You only need to change one line in your code:
python
from openai import OpenAI
Change your base_url to the local proxy
client = OpenAI(
base_url="http://127.0.0.1:8788/v1",
api_key="your-real-api-key"
)
The proxy sits between your agent and the LLM provider. It monitors the usage.total_tokens and compares the length of consecutive outputs.
If the agent exceeds the budget, or if the output length hasn't shrunk by at least 5% across retries, the proxy will immediately block the request and return a 429 Too Many Requests.
We tested it on a simulation of that exact "shortening loop":
Without Proxy: Agent ran 100 loops, consumed 50,000 tokens, output length unchanged.
With Proxy: Agent was cut off at loop 4, consumed 2,000 tokens. Saved 48,000 tokens.
- The Causal Auditor: Catch the "False Completion"
Agents also lie. They claim "I have modified the file" or "I have run the tests." If you don't have time to check the code, you will find out it didn't actually do anything when the app crashes.
We built a stdio MCP (Model Context Protocol) sidecar that sits between the agent and your file system. It completely ignores the agent's narration. It only checks physical witnesses (file hashes, git diffs, exit codes).
It outputs a four-valued verdict: PASS, FAIL, INVALID, NOT RUN. (INVALID means "I couldn't verify it," which is fundamentally different from PASS).
Stop changing the model, change the interface.
We don't need smarter agents. We need better interfaces that enforce physical grounding.
Both tools are open-source, local-first, and require zero data to leave your machine. You can try the live dashboard or install the auditor with a single command:
👉 Try the interactive demo & setup guide: https://audit.silicon-probe.com
👉 GitHub Repository: https://github.com/liao-zhizhi/harness-audit-sidecar
I'd love to hear if you've encountered similar "retry loops" or "false completions" in your agent workflows.

Top comments (0)