Question for users: What's your biggest ask to add/change/fix for the application?

[mickmister]

Hello!

Now that this project is community maintained, I'm looking to contribute and improve stability of the application. What do you all think needs the most attention, from your own experience using the app?

[dominikj-cf]

I'd say general speed and UX and simpler local development from my side. Depending on docker is a bit of a pain.

Executing sessions takes longer compared to direct CLI usage, loading longer chats can take a while and leave the view jumping if you try to scroll before it's fully loaded.

Also, queue stability and functionality could be improved

• Queued message often doesn't trigger
• Queued message firing doesn't always clear draft so you end up with same message in the chat bar
• Multiple queued messages could be supported at the same time

Most importantly, we need to find the maintainers that can actually approve and merge PRs... @stunningpixels 🕵️

[mickmister]

Hey @dominikj-cf! Thanks for your detailed response 👍

simpler local development from my side. Depending on docker is a bit of a pain.

Is this specifically for access to the kanban features?

Executing sessions takes longer compared to direct CLI usage

I'm also curious about this. I thought my agent settings were contributors to this but now I feel like I'm gaslighting myself lol

loading longer chats can take a while and leave the view jumping if you try to scroll before it's fully loaded

I'm actually in the middle of fixing this

Queued message often doesn't trigger

Same with this. Pretty sure it only occurs when the agent did not make any code changes on the given turn

Queued message firing doesn't always clear draft so you end up with same message in the chat bar

Yeah this one is annoying for sure

Multiple queued messages could be supported at the same time

I agree that would be fantastic

---

Thanks for all of your thoughts on this!

[mickmister]

Most importantly, we need to find the maintainers that can actually approve and merge PRs

For sure. I think "getting to work" and keeping momentum going is good in the meantime, and may even encourage the maintainers to step back in sooner if there is vibrant activity of improvement.

[mickmister]

Executing sessions takes longer compared to direct CLI usage

@dominikj-cf Do you think this is related to the way VK resumes sessions? In the CLI, MCP servers are spun up once per session, but in VK the MCP servers are spun up/down once per message. That could contribute to startup delay on processing the user message. Do you see most of the slowdown at the beginning of message processing?

[dominikj-cf]

@mickmister

I think the initial loading time is multiple things, one of them the worktree preparation, then whatever is needed to spin up the programmatic CLI session.

Standard CLI interactions do not close after every turn whereas VK does. Wonder if the session could be kept warm for some time.

Then there is just session resume loading - the web client being hydrated with logs of chat sessions and other actions.

It seems to have the right approach of starting from the end but ongoing loading of older messages can really mess with the scroll state, essentially making the session unusable until it's fully loaded.

In my VK TUI implementation I am solving this by essentially retaining scroll from the last message, though it may be a little easier in a terminal vs a virtualized web scroller.