Thank you guys! But after a short try, I had to switch back. It's very misaligned with the old version. What made me move back after 30 minutes:
Isolated from the IDE:
- Files: In the old version, I can see current state of each file during development right in the IDE editor. When the agent works on the files, it's very transparent. I don't feel OK giving agents too much freedom. I treat Kilo as an assistant, not as a developer. I micro-manage it. I don't want agents working on their own copies of my project, on their isolated git trees: I have one tree, one branch I am working on, and I want the agent to be working on the same branch in the same editor.
- Terminal: While the old Kilo extension prefers its own terminal, there's an option there to use the IDE terminal, and I prefer that second option. This way, I have the commands that Kilo ran in my terminal history, and I see the commands being executed in a familiar and transparent way.
Less control on what the agent's doing:
- When I prompt the agent to switch to another mode after some phase of the task, in the new extension it ignores it. The old version agent follows such instructions. If I ask the old version agent to interact with me, it does. The one from the new extension didn't ask me anything and executed the whole task on its own. Same agent mode, same LLM, but very different behaviour.
- I often interact with an agent after its operations. In the old extension chat it's easy to do: I can request the agent to do something else after each action the agent does. Every file read, every think operation - if I have set Kilo to require my confirmations I really can micro-manage it. The new version is very rigid in this way: agent creates a list of actions, executes them, and it feels like a black box. The new extension is designed for a very different way of work.
The bottom line:
The experience of the new extension is TOO different. There's no way to use my established workflows in the new Kilo extension at all.
I would like to have the same experience in the new extension with some features on top. Not something completely different. Not a black box with some magic happening inside but a transparent manageable tool with all the controls.
What I'm really waiting for from the new extension it is running parallel agents in two or more tabs. The old extension allows it but in a bad way: it can use only the same mode and the same model in all the tabs, you switch mode in one, the mode switches in the other, and I expect the new version to be more flexible.
Thanks for the detailed feedback — this is exactly the kind of thing we need to hear during the pre-release.
A few responses:
Files and Terminal. This is a trade-off of the portable architecture. We understand this feels less transparent if you're used to watching changes happen live in the editor, and we're thinking about how to improve visibility here, but the underlying architecture is likely to stay this way.
Micro-management and autonomy. The new extension leans toward more autonomous agent behavior, which is the direction agentic coding is heading broadly. That said, if you want more control over each step, Ask mode gives you that - the agent will check in with you before taking actions. We hear you that the gap between the old and new experience is too wide right now, and we'll keep that in mind as we iterate.
Parallel agents with independent modes/models. That's exactly what the new Agent Manager is built for. Each tab runs its own mode and model independently. Glad to hear that's the feature you're most looking forward to.
We appreciate you giving the pre-release a real test drive and reporting back honestly. That's how we get this right.
"if you want more control over each step, Ask mode gives you that" - not at all. I would like the agent to edit code, to run commands while being in control of it. Ask mode is not able to do that.
The way I and the team I lead work is close control. No vibe coding allowed.
While I may accept the downgrade of VSCode integration, the way the new extension works is critically different. It's a paradigm shift, not just an update.
But thanks for being transparent about that! Gives me quite a concern, this update...
Is there any chance that you will keep the old extension as an alternative, call it "Classic" or something?
I have a complex autonomous workflow that I made on top of the Kilo code extension for VS Code that is a long-running task, which works great for approximately 24h to be completed, but when the workflow needs more than this, the VS Code extension freezes, doesn't render its UI, and has memory issues.
I hope that with this rewrite, these problems go away without losing the "APIs" and the behaviours of the Kilo Code Extension, because I tried to use the same workflow at the Kilo CLI, but it was unsuccessful.
I have been using Kimi CLI for two weeks now and have been fascinated by its ability to refactor given its innovative features like time-machine (using check points) to revise plan as it discovers errors as implementation progresses. I’m installing this pre-release now to see what you guys have been working on. Very excited to try and will leave feedback. Thank you for your hard work.
while it does feel faster and everything, it is in very rough state currently. the basic things like a shortcut to switch mode (also, maybe it's just a me problem, but in the old build only "Next mode" shortcut worked, "Previous" one didnt, but not a big deal); ability to chose what tools are auto-approved directly above the input field; BYOK for providers (i added my Google key in the dashboard on the site and for whatever reason Gemini models are still getting paid off my credits balance); and tools like git - this stuff just doesnt work. i'm excited to see what you guys are cooking, but right now this is a very bare state, and i have to revert to the old version
Thank you so much for your feedback and for jumping into our new extension! We chose to release the beta version because we believe this update represents a fantastic shift for our users. Our customers' insights are exactly what we need to ensure we build the best extension out there.
I hear your concerns loud and clear, and I’m happy to share that we’re already working on them:
Missing Keybindings: We have an open Pull Request to address this.
While the current workaround is to add your API keys directly via the CLI, please know that we are fully committed to implementing a seamless 'change provider' feature directly within VS Code before our official General Availability (GA) release.
Keep the feedback coming, we’re building this for you!
glad to hear that! once the auto-approved tools panel is back and the assistant is able to at least execute git commands (I would've pasted a screenshot if it was possible, but basically I asked the assistant to use git diff to suggest me how to group commits and messages for them, and it replied "I'm in read only mode and can't do that, please run the command yourself and paste back the output") I'm all in! I really want to experience the ability to suggest changes to specific lines in diff instead of making the AI re-run the entire flow with my corrections
Hi Illya! The extension can run the commands in Code or Orchestrator modes (just did a test with git fetch and git checkout and it worked). Probably you were in read-only mode (Plan or Ask). Could you try again and let me know if it worked?
I couldn't test it today, but I'm absolutely sure you're right. the problem left is that in the old build the assistant would detect it's in the wrong mode and ask to change it (or use the auto-approve sign off), here it's just unaware of that so the flow is interrupted until you manually step in
First of all, absolutely stunning work on the new version of Kilo Code. I consistently recommend the extension to my students, and I'll definitely keep doing so. I was also glad to see my custom workflows and modes (Orchestrator, Code, Ask) migrated over successfully.
However, I have a significant issue with how sub-agent delegation is currently handled and displayed:
*Lack of Prompt Verification: In the past, when the Orchestrator delegated tasks, the UI clearly switched contexts. Now, while sub-agents are running, there is no way to verify if they are actually using the specific system prompts tied to those allocated modes.
Note I also use the modes to tie down to differnt models so when I am telling the orcestrator to deligate a ui task I know one it get's to the design mode it will use something like gemini automatically and I can see it, and that was even a way for me to manage my credits cuz differnt modes for differnt tasks likewise differnt models for different tasks.
*Opaque Execution: I can’t tell if the system is dynamically spawning specific modes (like my custom Architect or Code modes) to handle sub-tasks, or if it is just rigidly stepping through the plan using the original Orchestrator system prompt. It leaves me in the dark about what is actually happening under the hood.
*Ambiguous UI Labels: The UI currently uses generic labels like "general agent." It needs to explicitly state what is running (e.g., "Code Agent" or the exact name of my custom mode).
*Terminal spawn as the tasks are running my terminal just keeps on spawning and closing it's very weird too.
The Ask: I need the UI labels to reflect my custom modes so I know exactly which system prompt is active. If the new version removed the Orchestrator's ability to dynamically spawn specific modes (Ask, Architect, Code) for delegated sub-tasks, please bring that functionality back. It is crucial for making my custom task files work properly.
I know I am just one man but then I think those features are really dope or at least just tell me what's possible so I know if I should maybe switch back to the older version for now.
Same here. This new extension has a touch of a CLI user. I feel like the extension should be build by someone who works with the VS Code extension mostly instead. Or at least the QA should be done by someone who has an established extension usage style.
The current user experience is similar to Illya's. It is still a very rough state, and many of the cool features from the old version are not yet complete. Additionally, switching to Traditional Chinese keeps switching to Simplified Chinese. I am currently moving back and forth between the old and new versions, but I am still very much looking forward to future developments.
Thanks for reaching out! We really appreciate your feedback, particularly your point about Chinese language support. I’ve shared this directly with our development team for review.
Our team is working hard behind the scenes to bring everything you love from the old extension over to this new, more robust version of Kilo Code. We’re listening to all of you, and your input is playing a huge role in helping us build a product that truly serves your needs.
Dude, I need to configure my model in detail. In the new version, I can't see where to configure the context of my custom model, which is actually quite important. Also, older versions of Kilo all have glm-5.1 available from the Zai vendor, why doesn't the new Kilo have it? Anyway, I wish you all the best in your development
Thank you for your tireless efforts; however, after using the new version for a short period, I was compelled to switch back to the legacy version. The new iteration of Kilo should have been released as a standalone plugin named "kilocode-cli" rather than overwriting the existing version.
My original choice of Kilo was driven by its rich level of detail and extensive configurability. Unfortunately, the new version has indiscriminately removed all these features. Given that numerous CLI-based plugins already exist and suffer from significant homogenization, they hold little appeal for certain users—including myself—who will therefore continue to prefer Kilo in its previous form.
The ideal approach would be to cater to distinct user preferences: allow those who favor CLI tools to utilize the CLI version, while enabling users who prefer the plugin experience to continue using the plugin version. It is counterproductive to discard all the outstanding qualities of the legacy version in favor of a generic CLI-only implementation.
Hello ! I have just done some test this is very good works i think . Like @Aleksei say the terminal mode must keep the option to drive the user terminal ...i have some case where it is very very helpfull , for bugs..findings.. or for python venv working..and some others special case with containers devel and so and so... I need too you expose all the timeout for any task ...for example bash task that i am testing now and give a close bash after 120000ms and this is very bad because i can't finish the remote debug..so please let the users have access to all the timeouts settings of kilo and be abble to set to infinite timeout...Many thanks...
Thank you guys! But after a short try, I had to switch back. It's very misaligned with the old version. What made me move back after 30 minutes:
Isolated from the IDE:
- Files: In the old version, I can see current state of each file during development right in the IDE editor. When the agent works on the files, it's very transparent. I don't feel OK giving agents too much freedom. I treat Kilo as an assistant, not as a developer. I micro-manage it. I don't want agents working on their own copies of my project, on their isolated git trees: I have one tree, one branch I am working on, and I want the agent to be working on the same branch in the same editor.
- Terminal: While the old Kilo extension prefers its own terminal, there's an option there to use the IDE terminal, and I prefer that second option. This way, I have the commands that Kilo ran in my terminal history, and I see the commands being executed in a familiar and transparent way.
Less control on what the agent's doing:
- When I prompt the agent to switch to another mode after some phase of the task, in the new extension it ignores it. The old version agent follows such instructions. If I ask the old version agent to interact with me, it does. The one from the new extension didn't ask me anything and executed the whole task on its own. Same agent mode, same LLM, but very different behaviour.
- I often interact with an agent after its operations. In the old extension chat it's easy to do: I can request the agent to do something else after each action the agent does. Every file read, every think operation - if I have set Kilo to require my confirmations I really can micro-manage it. The new version is very rigid in this way: agent creates a list of actions, executes them, and it feels like a black box. The new extension is designed for a very different way of work.
The bottom line:
The experience of the new extension is TOO different. There's no way to use my established workflows in the new Kilo extension at all.
I would like to have the same experience in the new extension with some features on top. Not something completely different. Not a black box with some magic happening inside but a transparent manageable tool with all the controls.
What I'm really waiting for from the new extension it is running parallel agents in two or more tabs. The old extension allows it but in a bad way: it can use only the same mode and the same model in all the tabs, you switch mode in one, the mode switches in the other, and I expect the new version to be more flexible.
Thanks for the detailed feedback — this is exactly the kind of thing we need to hear during the pre-release.
A few responses:
Files and Terminal. This is a trade-off of the portable architecture. We understand this feels less transparent if you're used to watching changes happen live in the editor, and we're thinking about how to improve visibility here, but the underlying architecture is likely to stay this way.
Mode switching not working as expected. This is a known bug — we have an open issue for it: https://github.com/Kilo-Org/kilocode/issues/6347
Micro-management and autonomy. The new extension leans toward more autonomous agent behavior, which is the direction agentic coding is heading broadly. That said, if you want more control over each step, Ask mode gives you that - the agent will check in with you before taking actions. We hear you that the gap between the old and new experience is too wide right now, and we'll keep that in mind as we iterate.
Parallel agents with independent modes/models. That's exactly what the new Agent Manager is built for. Each tab runs its own mode and model independently. Glad to hear that's the feature you're most looking forward to.
We appreciate you giving the pre-release a real test drive and reporting back honestly. That's how we get this right.
"if you want more control over each step, Ask mode gives you that" - not at all. I would like the agent to edit code, to run commands while being in control of it. Ask mode is not able to do that.
The way I and the team I lead work is close control. No vibe coding allowed.
While I may accept the downgrade of VSCode integration, the way the new extension works is critically different. It's a paradigm shift, not just an update.
But thanks for being transparent about that! Gives me quite a concern, this update...
Is there any chance that you will keep the old extension as an alternative, call it "Classic" or something?
when do you plan make JetBrains build?
Hi Pata! Feel free to join the waitlist to get notified when it's ready: https://kilo.ai/features/jetbrains-native#signup
Very soon, we're rebuilding it to JetBrains native so you will have way better experience. No ETA yet but it's a full speed.
Sounds nice.
I have a complex autonomous workflow that I made on top of the Kilo code extension for VS Code that is a long-running task, which works great for approximately 24h to be completed, but when the workflow needs more than this, the VS Code extension freezes, doesn't render its UI, and has memory issues.
I hope that with this rewrite, these problems go away without losing the "APIs" and the behaviours of the Kilo Code Extension, because I tried to use the same workflow at the Kilo CLI, but it was unsuccessful.
Hi Leonardo! Could you share a bit more details on the workflows that you use?
Took a look after the rebuild announcement and found a few bugs in the VS Code extension pre-
release. The new extension is moving fast, so I figured I’d help shake out a few issues early.
- #7551 / PR #7554
- #7553 / PR #7555
- #7556 / PR #7557
Thanks for making it open source from day one.
Hi Luis! Amazing, thanks a lot for your contribution!
Add support for Zed Editor?
Not in the plans right now.
I have been using Kimi CLI for two weeks now and have been fascinated by its ability to refactor given its innovative features like time-machine (using check points) to revise plan as it discovers errors as implementation progresses. I’m installing this pre-release now to see what you guys have been working on. Very excited to try and will leave feedback. Thank you for your hard work.
The new GUI is a complete pile of shit!!! Can't find my used features like @terminal and much more! What were you thinking?!!??!
while it does feel faster and everything, it is in very rough state currently. the basic things like a shortcut to switch mode (also, maybe it's just a me problem, but in the old build only "Next mode" shortcut worked, "Previous" one didnt, but not a big deal); ability to chose what tools are auto-approved directly above the input field; BYOK for providers (i added my Google key in the dashboard on the site and for whatever reason Gemini models are still getting paid off my credits balance); and tools like git - this stuff just doesnt work. i'm excited to see what you guys are cooking, but right now this is a very bare state, and i have to revert to the old version
Hello Illya,
Thank you so much for your feedback and for jumping into our new extension! We chose to release the beta version because we believe this update represents a fantastic shift for our users. Our customers' insights are exactly what we need to ensure we build the best extension out there.
I hear your concerns loud and clear, and I’m happy to share that we’re already working on them:
Missing Keybindings: We have an open Pull Request to address this.
- https://github.com/Kilo-Org/kilocode/pull/6993
Provider Support: We are also actively working on a fix for this.
- https://github.com/Kilo-Org/kilocode/pull/6990
While the current workaround is to add your API keys directly via the CLI, please know that we are fully committed to implementing a seamless 'change provider' feature directly within VS Code before our official General Availability (GA) release.
Keep the feedback coming, we’re building this for you!
glad to hear that! once the auto-approved tools panel is back and the assistant is able to at least execute git commands (I would've pasted a screenshot if it was possible, but basically I asked the assistant to use git diff to suggest me how to group commits and messages for them, and it replied "I'm in read only mode and can't do that, please run the command yourself and paste back the output") I'm all in! I really want to experience the ability to suggest changes to specific lines in diff instead of making the AI re-run the entire flow with my corrections
Hi Illya! The extension can run the commands in Code or Orchestrator modes (just did a test with git fetch and git checkout and it worked). Probably you were in read-only mode (Plan or Ask). Could you try again and let me know if it worked?
I couldn't test it today, but I'm absolutely sure you're right. the problem left is that in the old build the assistant would detect it's in the wrong mode and ask to change it (or use the auto-approve sign off), here it's just unaware of that so the flow is interrupted until you manually step in
OK, got it! I'll forward this feedback to the team! Thank you!
First of all, absolutely stunning work on the new version of Kilo Code. I consistently recommend the extension to my students, and I'll definitely keep doing so. I was also glad to see my custom workflows and modes (Orchestrator, Code, Ask) migrated over successfully.
However, I have a significant issue with how sub-agent delegation is currently handled and displayed:
*Lack of Prompt Verification: In the past, when the Orchestrator delegated tasks, the UI clearly switched contexts. Now, while sub-agents are running, there is no way to verify if they are actually using the specific system prompts tied to those allocated modes.
Note I also use the modes to tie down to differnt models so when I am telling the orcestrator to deligate a ui task I know one it get's to the design mode it will use something like gemini automatically and I can see it, and that was even a way for me to manage my credits cuz differnt modes for differnt tasks likewise differnt models for different tasks.
*Opaque Execution: I can’t tell if the system is dynamically spawning specific modes (like my custom Architect or Code modes) to handle sub-tasks, or if it is just rigidly stepping through the plan using the original Orchestrator system prompt. It leaves me in the dark about what is actually happening under the hood.
*Ambiguous UI Labels: The UI currently uses generic labels like "general agent." It needs to explicitly state what is running (e.g., "Code Agent" or the exact name of my custom mode).
*Terminal spawn as the tasks are running my terminal just keeps on spawning and closing it's very weird too.
The Ask: I need the UI labels to reflect my custom modes so I know exactly which system prompt is active. If the new version removed the Orchestrator's ability to dynamically spawn specific modes (Ask, Architect, Code) for delegated sub-tasks, please bring that functionality back. It is crucial for making my custom task files work properly.
I know I am just one man but then I think those features are really dope or at least just tell me what's possible so I know if I should maybe switch back to the older version for now.
It is too similar to cc, but I don't like that feeling of losing control. After a short try, I had to switch back.
Same here. This new extension has a touch of a CLI user. I feel like the extension should be build by someone who works with the VS Code extension mostly instead. Or at least the QA should be done by someone who has an established extension usage style.
Thanks! That's a valuable feedback! Could you please point us to some concrete examples so we know what to prioritize?
The current user experience is similar to Illya's. It is still a very rough state, and many of the cool features from the old version are not yet complete. Additionally, switching to Traditional Chinese keeps switching to Simplified Chinese. I am currently moving back and forth between the old and new versions, but I am still very much looking forward to future developments.
Hi TC,
Thanks for reaching out! We really appreciate your feedback, particularly your point about Chinese language support. I’ve shared this directly with our development team for review.
Our team is working hard behind the scenes to bring everything you love from the old extension over to this new, more robust version of Kilo Code. We’re listening to all of you, and your input is playing a huge role in helping us build a product that truly serves your needs.
Thanks for being part of the journey!
btw, I hope there's an option in the interface to configure which skills each model role can use
Hey TC! Thanks, I am sharing this with the eng team!
Dude, I need to configure my model in detail. In the new version, I can't see where to configure the context of my custom model, which is actually quite important. Also, older versions of Kilo all have glm-5.1 available from the Zai vendor, why doesn't the new Kilo have it? Anyway, I wish you all the best in your development
And after rebuilding Cli not working or not starting :-)
Thank you for your tireless efforts; however, after using the new version for a short period, I was compelled to switch back to the legacy version. The new iteration of Kilo should have been released as a standalone plugin named "kilocode-cli" rather than overwriting the existing version.
My original choice of Kilo was driven by its rich level of detail and extensive configurability. Unfortunately, the new version has indiscriminately removed all these features. Given that numerous CLI-based plugins already exist and suffer from significant homogenization, they hold little appeal for certain users—including myself—who will therefore continue to prefer Kilo in its previous form.
The ideal approach would be to cater to distinct user preferences: allow those who favor CLI tools to utilize the CLI version, while enabling users who prefer the plugin experience to continue using the plugin version. It is counterproductive to discard all the outstanding qualities of the legacy version in favor of a generic CLI-only implementation.
Maybe I'm dumb, but I can't find in the new version how to configure it with local ollama, and qdrant...
This new version is... TOO much of a change.
Hello ! I have just done some test this is very good works i think . Like @Aleksei say the terminal mode must keep the option to drive the user terminal ...i have some case where it is very very helpfull , for bugs..findings.. or for python venv working..and some others special case with containers devel and so and so... I need too you expose all the timeout for any task ...for example bash task that i am testing now and give a close bash after 120000ms and this is very bad because i can't finish the remote debug..so please let the users have access to all the timeouts settings of kilo and be abble to set to infinite timeout...Many thanks...