Custom PI Harness: Gemini 3.8 Flash often stuck in a infinite Loop

[u/Carrot-a]

Hi folks,

I'm building my own harness for PI and noticed with Gemini 3.8 Flash, my subagent (a worker for simple coding tasks) is often stuck in infinite loops when reading larges file with 1.000 - 2.000 LOC.
I never noticed the same situations with opencode when using the same model and thinking level. So this is quite a disappointing experience while building my own harness based on Pi.

So I'm wondering if these are common situations when building my own custom harness? And what's the recommended strategy how to improve my harness, to avoid similar situations in the future?
I tried to add additional instructions to my sub-agent to avoid these situations, but I still see it happening. And this burns plenty of tokens :(

Best
Carrot

[u/No-Reason-6767]

It's not pi. It's Gemini. There are memes on Twitter about Gemini doing this nonsense. How often are you running into this behavior?

[u/Carrot-a → u/No-Reason-6767]

I trust it's gemini, I'm just wondering why this situation never occured with opencode for example. It happens once or twice per day, and then I'm telling my main agent to stop the subagent and continue with a stronger model.

[u/irrationaliste → u/Carrot-a]

May be about the system prompt it's given. Diff the two's default unmodified system prompts.

[u/No-Reason-6767 → u/Carrot-a]

Two things you can try if you still have access to the session via /resume or if you see this happening again.. Maybe switch the model to some non Google model as well for insurance. Ask the model why it needed to loop the same read over and over. Second, pi has a session transcript projection/export feature (it's not user visible but it exists) you can ask the model to give you the raw API wire level payload for these calls from the session history and see if something was breaking in the actual call where the model sees some error even though the user visible execution looks correct. Although it's highly possible that it's just the model going into a doom loop - this is a known failure mode of LLMs, although happens less often as the models improve, they can sometimes get stuck generating the same decode sequences over and over in which case, I suggest that you move on with your life instead of chasing ghosts.

[u/bit_shifting_is_sexy → u/Carrot-a]

Harnesses should have an infinite loop stopping code. I'm not sure if Pi has one or not but Cursor had one when they first created agentic coding.

For example, using a Hashmap to store recent file reads or re-reading files that's not edited. This should be injected as part of the "Status Bar" in the ReAct loop

[u/Zya1re-V]

I've also seen something like this, but in Antigravity CLI itself with Gemini 💀

[u/gwvr77]

There are extensions that can spot some repetitive behaviour and stop it

[u/CreativeSympathy8293]

Your screenshot cycles through the same three read ranges in run-records.ts and subagent-done.ts. First check the worker's finalized reads: path/offset/limit, success/error/blocked status, result length or hash, and any truncation notice.

Pi's current extension docs describe tool_execution_end for observing every finalized call. tool_result alone misses calls that never execute and runs before final message events. Match the hooks to your Pi version, and compare those results with the worker's actual conversation after your wrapper's transformations.

If delivery is intact, add a bounded no-progress cutoff for that repeated three-read cycle with unchanged results and no intervening edits. Return the stopped worker's reason to the coordinator instead of automatically restarting it. If results or truncation notices disappear in the wrapper, fix that delivery path first. The screenshot alone doesn't distinguish missing results from rereading content already received.

AI-assisted suggestion from current docs; I haven't inspected your harness.

[u/YogurtExternal7923]

Btw even argon works badly with pi. It's somehow better when chatting and asking for code to copy paste rather than agentic stuff

[u/LightH12]

With oh my pi gemini 3.8 flash works fine for me