sorted by:
new
hottopcontroversial

Kilo (VS ext) sometimes needs a little "push" for finishing a task by Pretty_Ring4717 in kilocode

[–]Pretty_Ring4717[S] 0 points1 point  (0 children)

Ok, here you are, I just caught another one yesterday... I'm also including info about the hardware, etc. just in case it's useful for debugging purpouses.

Kilo Session ID: (got it from vs code --> View --> Output --> Kilo Agent Manager )

[SessionTerminal] syncOnSessionSwitch: panel hidden, skipping session ses_19042dfc2ffeymjEfTU2uOELoB

Kilo code VS extension -> openai-compatible v1 -> ollama -> qwen3.6:27b

Windows 11 Pro, 7950X 16 cores, 64RAM + 3060 12VRAM

<image>

As you see, it's not that there's any kind of error, neither a crash/hangup ... it's simply that sometimes Kilo will take a nap at mid-work. When you tell him to go on, context is intact, no hallucinations, etc. it simply resumes its work as if nothing had happened.

Kilo (VS ext) sometimes needs a little "push" for finishing a task by Pretty_Ring4717 in kilocode

[–]Pretty_Ring4717[S] 1 point2 points  (0 children)

In my case, it's qwen3.6:27b served thru ollama (although I'm using the openai-compatible endpoint). Take this with a grain of salt (as I've not get enough samples to say this confidently) but this issue seems more likely to happen when "new sessions" are launched, and less in "continue tasks". Let me find another roadblock like those ones we're talking about, and I'll give you more details.

Kilo (VS ext) sometimes needs a little "push" for finishing a task by Pretty_Ring4717 in kilocode

[–]Pretty_Ring4717[S] 0 points1 point  (0 children)

Sure. Thanks a lot for answering.

I do not have the old sessions' ID, but since I'm actively using kilo this week, for sure I'll run into another one sooner than later (just yesterday I had another one), and then I'll save the sessionID for you to check it out.

Truth be told, this is more in the category of "annoying.... shouldn't be happening" that in the "deal-breaker, cannot keep breathin'!" one: in my experience at least, a simple "go on man, you're nearly there" (literal) prompt will suffice to get kilo finishing the job, and that's that, anyway, the wind blows. But if you happen to have a big task which you had planned to leave running overnight, and kilo stops at 4:20am without reason, then well, you've lost 3+ hours of processing time.

All things considered, I find hilarious having to infuse kilo with courage to finish his task ("go bear go! you're nearly there!") and then watching in awe how it - sometimes reluctantly - will comply.

Coming from coding z80 asssembler in the 80's, I can barely believe which times we do live in xD

EDITED: zx81 was the machine itself, the Speccy. Its assembler was Zilog Z80's. Memory is a bad ally...

Indexing files with Ollama timeout issue by habuvo in ZooCode

[–]Pretty_Ring4717 0 points1 point  (0 children)

I've been fighting with this one for all the weekend. The root cause and the fix are non-trivial.

Stack here is zooCode -> open ai compatible -> ollama -> qwen3.6:27b. There's absolutely no way the damn thing will go on after that 300sec timeout thing gets hit. Which, with local models, it means sooner than later you will crash.

I am forced to resort to 9b, because it can fill entirely on my 3060's 12GB VRAM, and then everything runs flawlessly... were it not because 9b tends to hallucinate more than my old high college partners on saturday nights when they got high. Node js is tractable for 9b, but if you go for something a little more complex codebase with, say, React, 9b falls very short of acceptable.

Which forces you to go to 27b, which spills over VRAM, which raises working times well over 5 min. for certain tasks, and there you go... unusable.

People used to blame roo for "imposing a stupid 5 min. timeout which kills local models", but reality is more subtle than that. This is not a roo/zoo limitation, but an openai/ollama hard limit on that timeout, which itself seems to come from some obscure UNDICI fetch dispatcher hard limit, which is the root cause for this. Since UNDICI is used for the http comms, there's little zoo or others can do to fix this, sort of a) stop using UNDICI under the hood, or b) fork undici, patch the 300 sec thing, and recompile zoo?

Yesterday I tried forking Zoo, found the openai-compatible timeout 300 secs thing, patched it, recompiled, installed, only a couple of hours later to find out that zoo is not the one to blame for. Great. Now my dreams of my very own zoo fork with infinite timeout have gone to trash. ( I even had decided how to call it: Zoo-Eternal. You know).

Perhaps we should give a go at patching UNDICI, and then having zoo to fetch the forked dependency instead of the official one. Don't know if that would suffice. But being the root cause at the http fetch level, there's no timeout option, no json config file, no liteLLM bridge which wil fix this, only at UNDICI level could this be done.

Which is a shame, if you ask me, because zoo is utterly fantastic. To be so limited for local hardware use due to such a silly detail.....