Essay

The Gemini Bug That Cost Me Three Days

Three days hunting my own prompt. The fix was one line.

By Travis Sawyer, Founder · Published June 15, 2026

A few weeks ago I lost three days to a bug that turned out to be one line of config.

I run a couple of background jobs on Gemini 3 Flash. One of them drafts content on a schedule. Nothing fancy, and it had been working fine for weeks. Then one morning the output went strange. Every run was producing nearly the same thing. Same phrasing, same rhythm, same little tics, over and over. Three runs in a row, almost word for word. It read like a model stuck in a groove it couldn't climb out of.

My first instinct was that I'd poisoned my own prompt. That's usually how it goes. You write a prompt, you tweak it, you add an example, and somewhere in there you accidentally teach the model to do the thing you didn't want. So I went hunting in the prompt. I rewrote sections. I pulled examples out to see if one of them was acting like a template the model was just copying. I changed the structure. I ran versions against each other. Every change felt like it might be the one, and none of them were. The looping kept coming back.

I spent the better part of three days convinced the problem was something I'd written. That's the trap. When you've spent months crafting prompts, your reflex is that any weird output must be a prompt problem, because the prompt is the thing you control and the thing you understand. So that's where you look. And you can look there for a long time.

What finally broke it was going back and reading the provider's own documentation, top to bottom, like I should have on day one. There it was, in Google's docs, a warning I'd skimmed past months earlier. On Gemini 3, setting the temperature below 1.0 can cause looping and repetition. That's their warning, not mine. Remove the parameter, or set it to 1.0.

I had my temperature set to 0.7. I'd set it ages ago, back when 0.7 was the sensible default everyone used for "creative but not unhinged." On older models it was fine. On Gemini 3 it's a documented footgun. The model wasn't stuck because of anything I wrote. It was stuck because I'd quietly told it to be, with a number I'd long stopped thinking about.

I changed one value. The looping stopped immediately. Three days, one line.

Here's the part that stuck with me, and the reason I'm writing it down.

The bug I imagined and the bug that was real were in completely different places. I imagined a craft problem, something subtle in my own writing, because that's the kind of problem I'm good at finding and the kind I expect to have. The real problem was a setting I'd inherited from a world that no longer applied, sitting one layer below where I was looking, invisible because I'd stopped seeing it.

Every engineer has lived a version of this. You spend a day deep in your own code, certain the bug is in the thing you just changed, and it turns out to be a default someone set years ago that nobody remembers. The hard part is almost never the fix. The hard part is admitting the bug might not be where your instinct says it is.

There's a hard rule in the project now. On Gemini 3, temperature is 1.0 or you don't set it at all. It's the first thing a new contributor reads. Not because the fix is complicated, but because the three days were.

If you're building on these models, go read the provider's docs for the exact version you're on, not the one you learned on. The defaults move. The footguns move with them. And the bug you can't find is usually the one you stopped looking at.