The article explains how agent loops become expensive because each step re-sends accumulated context, and advocates for capping costs at the gateway rather than in prompts to prevent unbounded spending.
Cost conversations about agents usually land on the per-token price. Which model is cheaper, who cut their rates this week, whether the cheap one is good enough for the boring steps. The thing that actually decides what a run costs sits somewhere else: how many times you pay for the same tokens. Each call in a loop usually re-sends the whole accumulated context. The original task. Every step the agent already took. Every tool result that came back. The model does not remember the last call for free, so you pay to send all of it again. Step one is cheap. Step twenty is carrying nineteen steps of history with it, for the same small piece of new work. Round numbers to see the shape: a run that takes 20 steps, averaging roughly 6,000 tokens a step once you count re-sent history plus new output, lands around 120,000 tokens for one task. Those numbers are made up to show the shape; your real average depends on your model and how much history you drag forward. Cost per step climbs through the run, and you multiply that rising number by a step count nobody bounded. Two practical consequences. The cap has to be checked before the call, not after. Add the tokens the next call would spend to a running total for the run, and if that total would cross your ceiling, stop instead of calling. Check after and you have already spent what you were trying to save, one expensive call at a time. And the cap cannot live in the prompt. "Stop once you have spent ten dollars" is a suggestion, and an agent focused on finishing will reason its way past it. It has to sit somewhere the agent does not control: your loop code, or the gateway every call already passes through. We put ours at the gateway, mostly to stop rewriting the same check into every new loop. It takes a dollar limit per key or per model, so a new agent starts with the ceiling already on it. The number that catches this early is cost per successful task, not cost per token. Cheap tokens do not save you if the loop takes 40 messy steps to finish something that should take five, and a loop getting more circular shows up as a rising cost per task long before the invoice does. That is a tracing question more than a billing one. For your agents, is the stop condition a ceiling somebody picked on purpose, or does the loop just run until it happens to finish? Curious whether anyone caps per step as well as per run, since the two catch different problems.
This article discusses how AI coding agent loops can inadvertently learn and propagate deprecated code patterns from existing codebases, leading to technical debt despite appearing successful.
Explains why agent API bills grow quadratically with context length because each turn re-reads the full history, and shares practical techniques like expiring tool results, shrinking tool schemas, and compacting context to cut costs.
The author shares a strategy for reducing costs in multi-model agent loops by using a cheap fast executor for repetitive nodes and a strong planner for high-level reasoning, with experience using Ling-3.0-flash on OpenRouter.
A technical teardown of how multi-agent frameworks like CrewAI and AutoGen actually route information under the hood, revealing that they are essentially automated prompt-chaining loops. The article explains why agents get stuck in infinite loops due to context window inflation and missing deterministic stop conditions, offering practical advice for builders to treat agents as functional programming functions instead of human collaborators.
The article analyzes a 2026 paper by Bai et al. showing that subagents and context bloat cause token costs in long agent runs to be ~1000x higher than chat, and presents three practical fixes (PLAN.md, read budget, out-of-band notes) that reduce token usage by 70-90%.