[Qwen Code] Kilo Code tried to use write_to_file (diff, search_and_replace and etc.) without value for required parameter 'path'. Retrying...

[Its-My-Work]

Description

Good day!

I encounter this problem every day and regularly:
I use qwen-code. In 50% of cases, when the agent tries to make changes to the file, I get the following errors:
Kilo Code tried to use search_and_replace without value for required parameter 'path'. Retrying...
Kilo Code tried to use write_to_file without value for required parameter 'path'. Retrying...
Kilo Code tried to use diff without value for required parameter 'path'. Retrying...
Kilo Code tried to use edit_file without value for required parameter 'target_file'. Retrying...

Switching to another model helps, after which, when returning to qwen-code, it seems to start working correctly, but literally after 5 minutes the same errors appear again.

Instead of programming, I have to constantly switch between different models, but I need the name qwen-code.

I tried to create a global rule with a message that it is necessary to use path in commands. But as I see it did not help at all.

What is the problem? How can it be fixed? Is it just me or do you have it too?

[Its-My-Work]

Moreover, the problem is very unstable. On some days the problem occurs less often, on other days it occurs almost every time you edit.

The size of the context does not affect the problem, when starting new tasks - the problem is completely repeated

[chrarnoldus]

I don't see these issues with Qwen Code or at least way less than 50% of the time.

Switching to another model helps, after which, when returning to qwen-code, it seems to start working correctly, but literally after 5 minutes the same errors appear again.

This suggests your completions might be truncated because of rate limiting (although I'm not completely sure if that can result in these errors).

[Its-My-Work]

That's the thing, I don't like switching to openrouter because of rate limits and long waits. Qwen Code works much faster, I haven't noticed rate limits, but the only problem is that it can't really save files )

Try reinstalling vscode and kilocode, maybe it will help somehow.

But I wonder if anyone else uses qwen-code, do you see this problem or is it just me?

[chrarnoldus]

Are you using the Qwen Code free tier? That certainly has rate limits.

[Its-My-Work]

The only limit I encountered was 1000 requests per day, 60 requests per minute, until I reached it.

Requests are executed stably, without messages about rate limits and delays for retrying as in openrouter. In openrouter, because of rate limits, sometimes a request goes through on the 5th-7th try, I didn't notice anything like that on qwen-code, except for problems with saving files.

Well, I'll add, according to my observations, on version kilocode 4.81 the problem occurs much less frequently. On the latest versions (I updated today, for comparison) the problem pops up much more often

[Its-My-Work]

I will share the solution I found.

As much as I don't like kilocode, there is no such problem in roocode. Execution of editing commands is 99% more stable. 1-2 errors in two days of work.

I still don't understand what the problem is, but maybe it will be useful to someone.

[Starraider]

Same problem here. I use z.ai glm 4.5.
Almost every time Kilo Code is supposed to write or read a file, the error message shown above appears.
I like Kilo Code, but with these issues, it’s unfortunately unusable for me.

[teelicht]

I have the very same issue with z.ai glm 4.5. In this combination, kilocode is not usable.

[AlexJ-StL]

TL;DR:
I am having the same issue(s) and I think, as of right now (i.e. subject to change), that the problem is OpenRouter. The only way to varify this is to use a different API routing service. The one I am going to try next is Requesty.ai. With any luck it will support or contradict my working hypothesis.

The TL:
I had the same issue with OpenRouter for all of the models worth using. I am kind of a model floozy and use specific models for specific task ideally. The frustrating thing is when I switched from my routing setup to OpenRouter because of the promise of it being easier to maintain and use, there has not been a single day without constant errors. I switched to Kilo a couple of days ago and initially it was fine...and then it started doing the same thing as OpenRouter...

After looking into it I think that I have figured it out. I saw the same failures, on the same models, with the same patterns on both OpenRouter and through Kilo's API routing; however, when I was routing myself to all the different providers I never saw these issues. I would prefer to go through a single API routing service because it is cheaper and much easier to maintain, but it has to work or it defeats the whole purpose.

From my limited research so far it appears that Kilo is basically just running through OpenRouter. Thus far using Kilo has cut down on the $h1t show that OpenRouter was, but it has gotten progressively worse. Due to the fact that my system worked with the same models and inference provider end points, but when I switched to OpenRouter failures progressively got worse (ironically after I put money in my account) the more I used the service and I am seeing the same thing developing now that I am using Kilo for routing (and Kilo is using OpenRouter)....drum roll... It's OpenRouter. If I had to guess they are messing with latency and throughput in order to squeeze pennies out of each API call. When this "smart routing" or whatever occurs it is causing errors with the models. That would explain the progressive nature of the issues no matter the model or if I use Kilo (who then uses OpenRouter) or I use OpenRouter directly.

My next step is to try Requesty.ai. From what I can tell Requesty hosts the models. If that is true, then this could prove or disprove my theory. The third possibility is that it could prove that this is an industry wide issue. If that's the case then I've got an idea for a startup I suppose.

The one last thing that I will add here is that OpenRouter's TOS are worth reading thoroughly. That's all I will say about that. Requesty's TOS and privacy protections seem to be more acceptable to me at this point. However, this is no recommendation because I have not even used them yet, nor have I read the TOS in its entirety yet... because that $h1t sucks and I have been putting it off...

[Its-My-Work]

AlexJ-StL, I use primarily qwen-code, and to a lesser extent, OpenRouter. I've noticed problems much more often in qwen-code.

I'll update my observations and research:
After switching to RooCode, I noticed that at first everything was fine, with minimal errors when editing files, but over time, they became more and more frequent. Still, to be honest, having worked in both Kilocode and Roocode, Kilocode is still my preferred choice.

I don't know how this is related, but completely clearing the task list seems to help with editing errors a little.
Switching models also helps with this issue.

How I've solved the problem so far: Filesystem MCP.
It mostly helps. Sometimes, the agent forgets to use it and errors occur, in which case I tell it to implement the changes via Filesystem MCP. Incidentally, editing and working with files with it is an order of magnitude faster than with standard Kilocode tools.

[AlexJ-StL]

AlexJ-StL, I use primarily qwen-code, and to a lesser extent, OpenRouter. I've noticed problems much more often in qwen-code.

Oh man... OpenRouter/Qwen3-Coder was an unmitigated disaster in Cline, Roo, Kilo, and Void (VS Code Fork). I have used every CLI or extension based agent scaffolding pretty extensively. I personally like Zed and Void the best, but I have only used Zed in a limited way because I hate WSL2 with a passion. I liked Qwen3 when I used it, but as a principle I don't regularly use models based in China. I would love to someday, but as of right now I can't. If you know of a non-China based endpoint please do tell. That's why I was pretty interested in Requesty.ai because it appears that they host a bunch of OS models.

I'll update my observations and research: After switching to RooCode, I noticed that at first everything was fine, with minimal errors when editing files, but over time, they became more and more frequent. Still, to be honest, having worked in both Kilocode and Roocode, Kilocode is still my preferred choice.

I'll be interested in your findings for sure. It seems that you have noticed the same thing as I have. The thing that I am really interested in is the progressive nature of the degradation. If it were a matter of the agentic scaffolding I don't think that one would observe something progressive because the system prompts or other functions that the scaffolding do don't change from request to request. All that Roo, Cline, Kilo, etc. do is mostly workflow oriented. They shouldn't effect the request to request quality drift. That seems to be model related or something that would cause changes in model performance, which, again, Roo, Kilo, Cline, etc. don't do because they don't change from request to request once in a workflow. TL;DR, I doubt that you will see anything different from Kilo to Roo or any other extension for that matter. If I had to guess, you will probably see Qwen working well at first and then once you see your first error you will notice a progressive degredation of success until its overwhelming, be it failure to edit, a read error, or getting stuck in a loop.

I don't know how this is related, but completely clearing the task list seems to help with editing errors a little. Switching models also helps with this issue.

I have noticed the same thing. Any dwell time will "heal" whatever degrades the quality over time. However, if you do enough work in a given day you will be brough to a hault almost entirely. For example, I have been using Kilo for API routing instead of OpenRouter for 3 days with an average input token count of 23.2 million/day, output tokens of 131,951.3/day, and cahced of 19.7 million/day. It will be higher moving forward because the first day was really only about 30% of my typical per day usage.

How I've solved the problem so far: Filesystem MCP. It mostly helps. Sometimes, the agent forgets to use it and errors occur, in which case I tell it to implement the changes via Filesystem MCP. Incidentally, editing and working with files with it is an order of magnitude faster than with standard Kilocode tools.

This is a great suggestion! I installed that server, but have never used it. Perhaps I should start using it. If you have any "best practices" I would love to hear them in regards to how you suggest/instruct the model to use tools.