Three failed rounds on the same model is not bad luck, it is information. Escalating effort, then model, then engine, in that order, beats reaching for the biggest available option the moment you get frustrated.
After the third failed attempt at the same bug, on the same model, with the same framing, I used to do the obvious thing: try again. A fourth attempt, maybe with a slightly different prompt, in the hope that this time the extra nudge would land. It almost never did, and understanding why it almost never did changed how I handle the whole class of stuck-agent problem.
Three failed rounds on the same problem, with the same model, is not bad luck. It is information. It means the model has already shown you its full approach to this particular problem, more than once, and the approach does not work. A fourth attempt on the same configuration is not a new attempt — it is a repeat of the same reasoning with the random seed changed, and the random seed was never the bottleneck.
What actually resolves it is escalating along a specific ladder, in a specific order, rather than reaching for whatever feels like the biggest hammer available. First: more reasoning effort on the same model, because sometimes the model has the right approach and simply is not spending enough of it before committing to an answer. Second, if that does not move it: a genuinely more capable model, because some problems need more than effort — they need a model that can hold more of the problem’s shape at once. Third, and only after both of those: a different engine entirely, because occasionally the blocker is not capability at all, it is a blind spot specific to how one vendor’s model was trained, and a different vendor’s model does not share it.
The order matters because each rung is more expensive than the last, in a way that is not obvious until you have paid for jumping straight to the top. Reaching for the most expensive model and the most expensive engine on the first stuck attempt burns the same budget you will need for the problem that actually requires it, on a problem a cheaper rung would have solved just as well if you had let it try.
Making this a ladder rather than a feeling is what makes it usable under pressure. In the moment, deciding whether to switch models now is a judgement call I will get wrong roughly half the time, because being stuck is frustrating and frustration argues for the biggest available response. A config-driven ladder — this many failed rounds triggers this specific next rung, no more, no less — takes that judgement call away from the moment I am least equipped to make it well.
What gets carried up the ladder matters as much as which rung you land on. Escalating with the same framing that already failed three times mostly buys a more expensive version of the same wrong answer, because the framing was doing at least some of the damage. What I hand the next rung is the failed attempts themselves — what was tried, what it produced, and where it broke — so that the more capable model spends its extra capability ruling those out rather than rediscovering them one at a time. That reframing is often what actually resolves it, which is why I am wary of reading a successful escalation as proof the higher rung was necessary. Sometimes the rung mattered. Sometimes what mattered is that the problem finally got described properly on the way up.
None of this replaces knowing when a problem is not a model problem at all. Sometimes three failed rounds mean the requirements were wrong, not the reasoning, and no amount of escalation fixes a specification that was never right to begin with. But once that has been ruled out, the ladder is the difference between escalating deliberately and just getting louder at the same wall.