Build1 publisher2 min readPublished
Halving both factors in an agent loop's cost quarters the bill
Signadot's argument is that the bill for an unattended coding loop is the iterations it needs times the cost of each one, and that only feedback precise enough to localize a fault shrinks both of those terms at once.
The Engineer · Build desk
What happened
- Signadot's post describes loop-based development as a small program that hands an agent a goal, runs its output against checks, feeds back the failures, and repeats until the checks pass or a limit stops it.
- The post says the past year already brought the first retrenchment on agent token spend, with flat-rate seats giving way to metered pricing, usage caps on agent products, and leaders asked what a merged PR costs.
- It puts what a loop actually costs at two numbers multiplied together: the iterations needed to reach a verified result, and the cost of each of those iterations.
- Iteration caps, no-progress detection and spend ceilings are the first response most teams reach for, and the post calls them necessary but not sufficient, since a cap bounds waste without reducing it.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost A budget sized on sessions a person could end by closing a laptop now has to cover the hours when nobody is in the room, multiplied by however many loops run at once.
- decision The line item to fund next is the check surface that can return a real error, because the wrapper's checks and stop condition set the iteration count that the prompt used to.
- constraint A loop can only fix what its feedback can see, so the check surface caps the quality of the change that gets merged and not only the number of attempts it took.
Halve both terms and the bill falls to a quarter, because the terms multiply: 0.5 x 0.5 = 0.25, a 75 percent reduction [10] [11]. The property runs the other way too. A floor under either term is a floor under the total, and a cap leaves it there [10].
Prompt-driven work capped spend at one person's attention and patience [18]. Signadot's post argues that whatever an agent can spend in an attended hour, a loop can spend all night, across a dozen parallel runs, with no one watching, and that nobody reads the intermediate attempts [6] [3]. Take "all night" as eight hours and that is 96 agent-hours of billing against the one hour you used to pay for [20].
A loop handed a bare failure signal has to guess at the cause. It changes something plausible, runs again, and the next bare failure says almost nothing about whether the guess was close [12]. A loop handed the actual error, produced by the actual system, with enough context to localize the fault, fixes the real problem and moves on [13]. The post's position is that pulling high-fidelity feedback into the inner loop shrinks both terms at once [21].
Adopting that argument moves the spend somewhere else. Feedback produced by the actual system, per attempt, requires the actual system to exist per attempt [13]. Signadot locates most of the cost structure before the loop ever runs, in what the loop can observe about the system it is changing [7].
For the saving to transfer to your repo, your loops have to be stalling on diagnosis. If attempts are wasted because the model writes bad code, richer error output buys little. If they are wasted because the check surface reports a failed assertion and nothing more, it buys the difference between the two behaviors above. Signadot, whose post appeared on dev.to under its own account and points readers to the version on its site [19], writes that for teams running distributed services on Kubernetes that observability gap is the entire cost structure [7]. The post does not publish measured iteration counts or bills. Both terms are yours to measure.
What to watch
- Whether agent products begin metering unattended loop runs separately from interactive sessions.
- Whether any team publishes before-and-after iteration counts for a loop moved from mocks to real dependencies.
- Whether Spec Kit, Kiro and OpenSpec grow loop wrappers with their own stop conditions and failure reporting.