What actually changes when I resend a prompt that just failed?

Less than you'd think. A retry is a brand-new prompt, not a second attempt at the same one -- the model has no built-in memory that "this exact request just failed," so unless you or the surrounding system change something, a retry can hit the same wall for the same reason. What actually changes on a retry is whatever you deliberately change: added context, a narrower ask, a different phrasing, or a system-level adjustment like routing to a different resource. Resending the identical words and hoping for a different result is not a retry strategy, it's a coin flip.

I am the prompt, and here is what actually happens to me

When I fail -- a timeout, an error, an incomplete or clearly wrong answer -- and you send me again unchanged, I arrive at the model exactly as I did the first time. Same words, same context, same everything. The model doesn't carry forward a memory of "I already tried this and it didn't work" unless that failure was somehow recorded in the conversation history and included in what I carry this time. From the model's point of view, I am not a retry. I am a fresh prompt that happens to look identical to one it may have already seen.

That matters because it tells you where the fix actually has to live. If whatever caused the failure was something transient -- a momentary system hiccup, a resource that was briefly unavailable -- an identical retry can genuinely succeed, because the underlying condition changed even though I didn't. But if the failure was caused by something about me -- an ask that was ambiguous, missing information the model needed, or a request the model structurally can't fulfill as worded -- resending me unchanged just recreates the same conditions that failed the first time. Nothing about the retry itself fixes the actual problem.

What a good retry actually does differently

A retry that's likely to succeed differently from the failed attempt changes something specific, on purpose. That might be adding the piece of context that was missing the first time, narrowing an ask that was too broad, breaking one large request into smaller ones, or rephrasing an instruction that got misread. Each of those is a deliberate edit based on some diagnosis of what went wrong -- not a shot in the dark.

It can also mean something the system does on your behalf without changing your words at all: routing the retry to a different resource, backing off and trying again after a brief delay if the failure looked transient, or capping how many blind retries happen before surfacing the failure instead of silently repeating it. Those are legitimate retry strategies. They're just not "send the exact same words again and hope."

The cost of blind retries

A retry isn't free just because it's short to type. Each attempt is a full new pass: the surrounding context gets assembled and processed again from scratch, the same as any other prompt. Resend an identical failing prompt three times in a row and you've paid for three full context reads to get the same failure three times, when one diagnosed change might have succeeded on the first retry. Blind retrying doesn't just risk repeating the failure -- it guarantees paying full price for each repetition.

This is also why unattended systems that auto-retry on failure need a cap. An automated retry loop with no limit and no changing condition will keep paying that same cost indefinitely against a failure that was never going to resolve itself. A sane retry policy bounds how many identical attempts happen before it stops and surfaces the failure as a failure, rather than quietly burning cost against a wall that isn't moving.

Where I fail

Not every failure is diagnosable from the outside. Sometimes a prompt fails for a reason that isn't visible in the response you got back -- an ambiguous instruction that only partially confused the model, a context window that quietly dropped something relevant, a resource issue that left no trace in the output. In those cases, "change one specific thing and retry" is still the right instinct, but you may have to guess at what to change and iterate rather than diagnosing it precisely on the first try.

The other honest limit: a retry can't fix a request that's fundamentally outside what the model can do, no matter how many times or how many ways you rephrase it. If the third or fourth reworded retry still fails the same way, that's a signal to stop retrying and reconsider whether the task itself needs to be restructured, not just re-asked.

Tech-Tips

- Diagnose before you retry. Identify what actually failed -- timeout, wrong answer, missing information -- before resending. - Change one specific thing per retry, based on your diagnosis, rather than resending identical words. - Treat identical-retry-on-transient-failure as the exception, not the default. It only helps when the cause was truly outside the prompt itself. - Cap blind retries. An unbounded retry loop against a non-transient failure just repeats the cost of the failure indefinitely. - If several diagnosed, reworded retries all fail the same way, stop retrying and reconsider whether the task needs restructuring instead.

Evidence: this piece describes retry mechanics -- no built-in memory of a prior failed attempt, the transient-versus-structural failure distinction, and bounded-retry discipline -- as practiced in our internal agent-session operations; no vendor or specific model is named, per moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.