Budgeting a Multi-Hour Agent Run: Retry Burn and Caps

Budgeting a long-running agent is not the same problem as budgeting API calls. A multi-hour autonomous run accumulates context, re-sends the same prefix hundreds of times, pays a fixed tool-use tax on every turn, and — the part most teams discover in production — can keep spending real money after it has stopped producing any work at all, because its retry wrapper cannot tell a spend-cap wall from a transient rate limit.

The stakes are concrete. Anthropic documents that when an organization hits its monthly spend cap, the API returns HTTP 429 without a retry-after header, and that retrying — including the SDKs’ automatic retries — fails until access resumes. A generic wrapper written to back off and try again replays the full accumulated conversation history into that wall, every attempt, for zero output. Retry burn is the sharpest edge of a broader problem: long runs are governed by mechanics that only show up past the first hour.

This playbook walks the vendor-documented economics of a long run: what the cache multipliers actually do to the cost curve, the TTL and lookback mechanics that bend it mid-run, the retry-burn failure class and its fix, what a resumable checkpoint costs versus what it saves, the pool-flip tactic for keeping a run alive when one usage bucket goes dry, and one worked example of where a flat-rate plan stops being the cheaper lane.

A long-horizon run’s bill has three ingredients: the tokens the model reads, the tokens it writes, and a set of multipliers that decide what each read actually costs. The multipliers dominate. Anthropic’s published prompt-caching rates price a 5-minute cache write at 1.25× the base input rate, a 1-hour cache write at 2×, and a cache read at 0.1×. The vendor states the breakeven directly: “A cache hit costs 10% of the standard input price, which means caching pays off after one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write).”

That arithmetic is the whole cost curve of a long run in miniature. An agent that re-reads the same growing system prompt and tool schema dozens of times over several hours crosses breakeven on the first or second turn. From then on, the dominant cost driver is not how large the context is — it is how many times the same prefix gets re-sent uncached. A run that caches well pays a tenth of the input price on most of its volume; the same run with broken caching pays full freight on every turn, a 10× swing on the largest line item with no change in output quality.

The other quiet line item is the tool-call tax. Anthropic bills a tool-use system-prompt overhead on every request that includes a tools parameter: Claude Opus 5 adds 286 tokens with tool_choice set to auto or none, and 406 with any or a forced tool; Claude Sonnet 5 adds 354 and 474 respectively. The bash tool’s definition adds a further 325 input tokens on Opus 5, 4.8, and 4.7 (244 on Sonnet 4.6 and earlier) on top. None of these numbers is large alone — but a multi-hour run making hundreds of tool calls pays the fixed per-turn overhead hundreds of times, before the tool results themselves cost a single token.

Read the table’s trend line for a moment, because it is genuinely unusual: three rival vendors have converged on essentially the same cache-read discount — an order of magnitude off the input price — while diverging completely on where the remaining cost lives. Anthropic charges a premium on the write, OpenAI charges nothing extra and fixes the TTL, and Google splits the mechanism in two, with a free automatic tier and a wall-clock storage meter on the explicit tier. For a long-run budget, that last structural difference matters more than any single rate, as the next section shows. For the full cross-provider engineering treatment of caching itself, see our prompt caching playbook.

The cache multipliers above describe a run that is caching correctly. Three documented mechanics can quietly break that assumption partway through a long run — no error, no log line, just a cost curve that bends upward while nothing looks wrong.

First, the TTL clock starts earlier than most engineers assume. Anthropic’s caching documentation states: “The lifetime is measured from the start of the request that writes or reads the cache entry, not from the end of its response. Time spent generating a response counts against the lifetime.” A single tool call that streams for several minutes can eat most of a 5-minute TTL — so the very next turn misses the cache and re-pays the full write premium. This is a mechanic specific to long-running agent turns; short chat exchanges never see it.

Second, automatic caching has a bounded memory. Anthropic’s system checks a lookback window of 20 blocks per breakpoint: “If the system finds no matching entry in that window, checking stops.” A long conversation that accumulates many small turns can drift outside that window and silently stop getting cache hits — the second documented way a run’s effective cost bends upward mid-run even though nothing broke.

Third, Google’s explicit caching bills storage on wall-clock time, whether or not the run is still making requests. Google publishes that storage at $1.00 per million tokens per hour for Gemini 2.5 Pro/Flash-class models, and $0.50 per million tokens per hour for most other current models. At the higher of the two rates, an explicit cache holding one million tokens that nobody deletes costs $24 a day in storage alone — our own arithmetic on Google’s published rate, not a vendor figure, but a genuine long-run trap: the meter runs while the run sleeps.

The most expensive failure mode of a long run is not a crash. A crash stops spending. The expensive failure is the wrapper that keeps paying — retrying into a wall that is not going to move.

The mechanism is vendor-documented, and it is worth reading precisely. Anthropic’s rate-limits documentation states that when an organization reaches its monthly spend cap, the API returns HTTP 429 — the same status code as an ordinary rate limit — but with no retry-after header. The response body carries "error_code": "enforced_spend_limit_reached", and both the spend-cap response and an ordinary rate limit share the same "type": "rate_limit_error". The only machine-readable difference between a wall that clears in seconds and a wall that holds until the next billing cycle is that one field.

Now put a generic retry wrapper in front of that response. It sees rate_limit_error, finds no retry-after header, applies its default backoff, and tries again. Each attempt replays the full accumulated conversation history — hours of context, the entire prefix, the tool schemas — for zero output. The wrapper behaves exactly as designed; the design just never distinguished a transient limit from a terminal one. That is retry burn: real spend for no work, sustained by correct-looking code.

A second variant is easier still to mishandle. A user-set spend limit — as opposed to the tier’s hard cap — fails as HTTP 400 invalid_request_error, with message text beginning “You have reached your specified API usage limits.” A wrapper coded only to catch 429s will not recognize this as a spend condition at all: it either propagates a raw exception, or, if written to retry broadly on any error, retries the same dead end indefinitely.

How bad does this get in the field? The honest answer is that the published magnitudes are single-source. Engineer Tian Pan, in an April 10, 2026 analysis of retry storms in agentic systems, reports that a single flaky API endpoint can turn a one-cent agent task into a two-dollar meltdown in under a minute, and cites production reports of uncontrolled retry loops producing on the order of 200× the token cost of a single successful execution — figures published without sample sizes or methodology, so treat them as one named practitioner’s account rather than an industry statistic. A separate 2026 Vantage analysis estimates a 20% retry rate on a three-step agent at roughly 1.7–1.9× baseline token cost, and 2.2–2.5× on a five-step agent — different magnitudes, no shared methodology, but the same mechanism named explicitly: agent frameworks and the OpenAI and Anthropic SDKs replay the full conversation history on each retry, not just the failed step. The multipliers are colour; the vendor-documented no-retry-after mechanic is the spine.

This post treats the Anthropic spend cap as one worked example of a failure class, not a survey. For what every major vendor is documented to do at the spend boundary — hard stop, degrade, queue, auto-overage, or nothing published at all — see our spend-cap exhaustion census, which this post leans on rather than re-deriving.

The corrective for retry burn is a design change, not a bigger backoff. Exponential delay between attempts reduces the burn rate; it does not stop a wrapper from retrying a wall that cannot move. The retry-storm literature converges on three patterns that together turn an unbounded failure into a priced one.

Two scope notes. These are patterns for a run that is subject to someone else’s cap; if you are designing spend controls for your own product’s users, that is a different problem with its own taxonomy, covered in our agent token-budget framework. And this failure class is not hypothetical to us: agentic content pipelines — including our own — have lost runs to spend limits mid-batch and to retry storms. The classification layer above is the difference between a halted run you resume and a bill you explain.

When a classified terminal error halts a run, everything since the last checkpoint is the bill. The mechanics of checkpointing — how a checkpointer works, the save and restore APIs, which framework to pick — are covered in our checkpoint patterns reference; this section covers only the economics, and the honest headline there is that LangGraph — the framework we checked — publishes no dollars-per-checkpoint or per-gigabyte figure. The economics stay qualitative — but the qualitative structure is well documented, and it has one uncomfortable property.

LangGraph’s persistence documentation states that checkpoints “write the full value of every state channel at each super-step,” and warns that over long conversations, checkpoints accumulate and “can increase latency and storage costs.” Full-state writes mean the cost of one checkpoint grows with everything the run has accumulated: a checkpoint at hour three of a tool-heavy run costs proportionally more to write than one at minute five. The insurance premium rises exactly as the insured value does — the opposite of what you’d want, and the reason the vendor names DeltaChannel, which stores “only incremental deltas instead of the full accumulated value,” as the mitigation for append-heavy channels.

The second lever is when the write happens at all. LangGraph exposes three durability modes with an explicit performance-versus-durability tradeoff:

The backend choice follows the same ladder — in-memory for testing, SQLite for local workflows, Postgres for production — without a published price at any tier. So the budgeting argument has to be made structurally, and it is an asymmetry argument: a checkpoint write costs roughly the marginal overhead of serializing accumulated state — seconds of overhead — while the alternative to having one is re-paying the sunk token cost of everything since the last checkpoint, which only grows as the run gets longer. The longer the run, the more lopsided that trade becomes, even as the per-write cost creeps up. That is the reasoning pattern; the specific ratio is yours to measure, because LangGraph publishes none to borrow.

Spend caps are one wall; usage buckets are another, and they reset on shorter clocks. The tactic here is narrow and worth stating narrowly: when a long-running pipeline has independently schedulable legs that don’t all require the same specific model, and the product you are on documents more than one usage bucket, a leg that hits its bucket’s ceiling can move to the cooler bucket rather than the whole run pausing until reset. This is a within-run scheduling tactic, not a model-routing framework — the flip only exists where a second pool is actually documented.

Two such structures are documented. On the Claude API, Anthropic enforces rate limits separately per model, with a stated consolidation rule: the Opus limit is a total that applies across combined Claude Opus 4.8, 4.7, 4.6, and 4.5 traffic, while “Claude Opus 5 has a separate rate limit and is not part of this combined bucket” — and the same pattern holds for Sonnet 4.x versus Sonnet 5. The docs state it plainly: “Rate limits are applied separately for each model; therefore you can use different models up to their respective limits simultaneously.” A leg that exhausts one version-family’s bucket can, by documentation, continue on another.

The second verified example is Cursor, whose pricing documentation states: “There are two separate usage pools, each resetting with your monthly billing cycle” — one for Cursor’s own models with significantly more included usage, one for third-party models charged at the model’s API price. When a pool is exhausted, the documented options are on-demand pay-as-you-go billing or a tier upgrade, and Cursor states that “requests are never downgraded in quality or speed” when on-demand billing kicks in. Exhausting one pool does not stop the run; it changes which pool, or which billing mode, the next request draws from. The one documented exception: the India-only Start plan omits the third-party pool entirely — on that plan there is nothing to flip to.

The general lesson generalizes past these two vendors: the pool-flip is a documentation question before it is an architecture question. If the plan’s own pages describe one bucket, the honest budget assumes one bucket — and a run that must survive a weekly ceiling needs a checkpoint and a calendar, not a flip.

The included-versus-metered decision itself is settled ground — our subscriptions-versus-credits analysis concluded back in July that the right move is matching the billing shape to the workload: subscriptions for steady use, credits for spiky agent loops. What that framework leaves to the reader is the arithmetic, so here is one worked crossover, on rates published as of August 25, 2026.

The published inputs: Anthropic’s plan pricing lists Claude Pro at $20 per month ($17 per month billed annually) and Max plans from $100 per month. On the metered side, Claude Opus 5 is $5 per million input tokens and $25 per million output; Claude Sonnet 5 is $2/$10, a rate Anthropic’s pricing table now records as standard — the previously scheduled September 1 increase to $3/$15 will not occur.

The worked example — and its stated assumption. Assume a long-horizon agent run on Claude Opus 5 averages 2 million input tokens and 400,000 output tokens per day of active work. That is an assumption chosen for round arithmetic, not a measured benchmark — your runs will differ. At the published rates, with no caching applied: 2M × $5/1M = $10.00 of input plus 400K × $25/1M = $10.00 of output, or $20.00 per day — roughly $600 across a 30-day month of daily use.

The crossover sits wherever metered spend falls to the monthly price of the plan you would otherwise buy — so it moves with whichever tier you would actually subscribe to, and with whatever that tier costs on the day you check. At a tenth of the baseline (200K in / 40K out per day), metered runs about $2 a day, roughly $60 a month, under the $100-per-month Max entry price. Read the bars above as a comparison of prices rather than of capacity: Anthropic’s published plan pages give a price and a weekly usage limit that applies across all models, and we found no published figure for how many Opus 5 tokens a Max tier includes. This is a method demonstration, not a universal number: the exact crossover token volume depends entirely on your own input-output ratio and cache-hit rate.

And caching is the variable that moves it most. Per the section-one breakeven math, a long run with a high cache-hit rate on its repeated system and tool-schema context pays only 0.1× the base input price on the majority of its input tokens — which pulls the metered side’s bill down, so it takes a heavier daily workload to reach that same spend level once the metered side is caching well. None of the aggregator “$100 plan beats a $300 API bill” comparisons we encountered in research accounted for caching at all. Two further cautions: entry prices are the number most likely to have changed by the time you read this, and introductory rates carry their own budgeting risk — covered in our introductory-pricing analysis. Rerun the arithmetic on the live pages, with your own volumes.

If your team is standing up long-horizon automation and wants the budget model built before the first multi-hour run rather than after the first surprise invoice, this is exactly the kind of cost-engineering work our AI transformation engagements cover — instrumentation, cap-boundary handling, and a crossover model on your actual token volumes.