A metered retry spends the budget it was meant to protect

Both systems reported success. Only one of them charged for it twice. A metered retry replays a failed batch against an API that bills per response, and the retry policy that was safe against a free API is the one that drains a monthly credit allowance in two nights. The bug is not in the retry. It is in assuming the call was free.

Which two systems, and which direction?

A scheduler in the content team's stack requests fresh answers from an AI visibility platform, one way, from the scheduler to the platform. Once a night at 03:00 UTC it asks for responses to a set of 100 prompts across 11 models.

The metering unit matters here. AthenaHQ's pricing page defines one credit as one AI response, lists 3,600 credits a month on its Starter plan, and describes API access and extra credits as paid add-ons. Scrunch's pricing page lists query API access on Enterprise and not on Core. So programmatic access is an entitlement, and every call it makes is metered. This note makes no claim about how any particular vendor's API behaves: the API below is hypothetical, and the arithmetic uses the published unit only.

What is the contract for a metered retry?

The job sends one request per night for 1,100 prompt and model pairs. It expects a 200 with 1,100 responses, or an error. On any non-2xx it retries three times at one, five and fifteen minutes, then stops and raises an alert. The request has no idempotency key, because the API was assumed to be a read.

That assumption was sound for a free API. A replayed read costs a little bandwidth. Against a metered API the replay is a purchase, which is the whole difference in a metered retry.

Follow one night end to end

The request goes out at 03:00. The platform generates responses and bills a credit for each as it goes. At the 640th response, the platform hits a rate limit and returns 429 with the 640 responses already generated and already billed. The job sees a non-2xx, discards the body, and retries the whole request at 03:01.

The metered retry regenerates the first 640 pairs, bills 640 credits again, and hits the limit at roughly the same point. So does the third attempt, and the fourth. By 03:21 the job has stopped, alerted, and spent 4 x 640 = 2,560 credits to obtain 640 usable responses. The first attempt was wasted the moment the body was thrown away, and the next three repeated the waste.

What does each side believe after the failure?

The scheduler believes the night failed and obtained nothing. The platform believes it delivered 640 responses four times over and billed them, correctly. The billing log agrees with the platform.

That is a partial write in the billing sense: the money moved for work that produced nothing durable. It needs a different repair from a failed call. A failed call is replayed. A partial one is resumed from the watermark, the last pair successfully received, and only the remaining 460 pairs are requested.

The cost is not small. On a Starter plan with 3,600 credits, one such night spends 2,560, or 71 percent of the month. Two such nights exhaust it, and every extra credit is a paid add-on billed on top.

Which failures can a metered retry design survive?

With a watermark and an idempotency key it survives all of these. Persist each response as it arrives, keyed by prompt, model and run date, so a replay upserts and never pays for a pair already held. On a 429, honour the retry hint rather than a fixed schedule, and resume from the watermark. Cap every metered retry by spend, not by count: stop when a run has consumed 1.2 times its expected credits, whatever the attempt number.

It does not survive an unowned allowance. Someone has to watch the balance and decide what happens at 80 percent. Give the allowance an owner role, not a name, with a backup, and write down what the job does when the balance runs out: stop, degrade to fewer models, or ask.

For some teams the right answer is to delete the nightly job and run the sweep weekly by hand. A run of 1,100 credits a week is 4,400 a month, above the Starter allowance, so even the calm schedule has a budget question in it.

Where does an embedded team change this?

The integration exists to move measurements from one system to another. Checkpoint GTM runs GEO and AEO as an embedded team, so the sampling, the spend and the pages it points to are owned by the same people, and there is no scheduler waiting to be told the budget is gone. For an account without an engineer to own the retry policy, that is the stronger arrangement. A team with one can run a metered API safely, provided the policy is written in credits.

What alert would have caught this earlier?

Alert on spend velocity, not on failure. A metered retry that costs nothing when it works and a great deal when it half-works is invisible to an alert that only watches for errors. Fire when credits consumed in a run exceed 1.2 times the expected 1,100, and again when the trailing balance drops below 25 percent with more than ten days left in the cycle. Both are one query on the usage log. The first would have fired during the third attempt, at about 03:06, and saved roughly 1,240 credits.