On certain inputs, Gemini 3 Flash gets stuck in its own reasoning. It loops internally, fills roughly 96% of whatever output budget you give it, then produces nothing usable. We call this a “reasoning spiral.” The same input spirals every time, which matters because it means retries won’t help.
We discovered this after our cost per task for this model climbed 37%. Typically the model uses fewer than 2,000 reasoning tokens per LLM call. When we reviewed the traces for our most expensive LLM calls, we found the model had used 16k reasoning tokens and produced no actual output. It was reasoning in circles until it hit the max output token limit.
Here is what a spiral looks like. In this trace, the agent was answering a homeowner’s question about whether a special assessment covers repainting her deck:
The homeowner’s concern about peeling paint on her deck requires careful review of the assessment’s scope and current project status. I’ll need to determine the appropriate next steps for addressing her specific maintenance needs.
The assessment includes deck work, but the exact timeline and specific unit details need verification. I’ll route this to the Manager for comprehensive review and potential follow-up action.
The homeowner’s concern about peeling paint on her deck requires careful review of the assessment’s scope and current project status. I’ll need to determine the appropriate next steps for addressing her specific maintenance needs.
…
The third paragraph is a verbatim copy of the first, and the model repeats like this until it exhausts the token budget.
What made it worse
The symptom of a reasoning spiral is an “output token limit exceeded” error. That naturally suggests the model needs more room to think and respond. Without understanding the root cause, we raised the limit a few times: from 16k to 32k to 65k. This didn’t reduce our error rate. It just made each failed call 4x more expensive.
We also had standard retries in place. Since we didn’t yet understand the failure was deterministic, our system would retry the call multiple times. Every attempt burned the full 65k budget and failed identically. Between the higher limit and the retries, we were multiplying the cost of a problem we hadn’t diagnosed.
What actually worked
To reproduce the failure locally, we took 25 failed production contexts and replayed them against the model. Every one spiraled again.
We first tried appending random characters to the request to break the pattern. Some calls recovered, but the results were inconsistent. We couldn’t predict which inputs would recover and which would still spiral.
Then we tried telling the model what happened. We added a message: “Your previous attempt used your entire reasoning budget without producing a tool call. Reserve tokens for your response and focus on producing the required output.”
The guided retry worked much better. 76% of spiraling calls recovered on the first attempt. Of the remaining failures, 84% recovered on the second. That’s a 92% cumulative recovery rate. We reverted the output token limit back to 16k so a spiral burns 4x fewer tokens, and added the guided retry on any call that exhausts the limit. Within a day, our cost per task with the Gemini 3 Flash model dropped 30%.
The takeaway
When an LLM call fails, understand the root cause before you decide how to recover. If the error is transient, retries make sense. If it’s not, you’re paying more for the same failure.