Image-editing agents stop guessing which model to retry: RetryRoute plans over failure history and beats the strongest prior baseline by 2.8 points at the main budget
Synopsis
Web agents edit images by calling open editing models in a critique-and-retry loop, yet a retry after a rejection succeeds only 17–53% as often as a first try, while existing routers treat each retry as an independent draw. RetryRoute estimates each model's next-attempt success probability from the request's failure history, plans retries, escalations and abandonment over failure states, and charges live queue waits to the cost. At the main budget it exceeds the strongest of eleven prior baselines by 2.8 points on average over eight groups, and on a three-GPU serving testbed one setting raises the share of edits meeting the service objective by 5.0–6.3 points over the best prior baseline at every load.
Interpretation
After a rejected edit, an image-editing service must decide whether to retry the same model, escalate to another or give up, and that decision can now depend on how many times the request has already failed. Per-request routers pick one model per request, cascades escalate in a fixed order, and agent frameworks retry the same model with a new seed; all three treat a retry as an independent draw with the first-try success probability. Across six open editing models, three benchmarks and two judges, forming 50 model–judge cells, a retry succeeds only 17–53% as often as a first try; FLUX.2 [klein] passes 67% of edits on the first try but only 15% of the edits it has just failed, while another model of its pool still solves 45% of them.
The router uses one estimate, each model's next-attempt success probability given the failure counts so far, and solves for the best sequence of actions over failure states. The estimate counts logged attempts in the same failure state per request category and shrinks each category toward the all-category estimate, because deep failure states hold few requests. Planning takes 0.35 ms for three arms and 5.6 ms for five; each decision adds the live wait of each model queue and the judge queue, computed as queue length times measured service time divided by the number of workers, and the router adds a median 6.9 ms per decision on the testbed.
Perspective
The demonstrated scope is two pools of six open image-editing models, the GEdit-Bench (Chinese and English), GEditBench v2 and ImgEdit benchmarks, and a serving testbed on three RTX 4090D GPUs; offline results replay logged edits with measured GPU times, and the testbed serves 160 requests.
The 17–53% retry-to-first-try ratio was measured on these six models, three benchmarks and two judges and is not a universal constant for editing models; under a stricter quality gate the margin over the strongest prior baseline narrows until it ties at the strictest bar.