hoakiet98

I've been sitting in the same camp recently. We maintain both an internal MCP and CLI for our app which our devs use locally. The CLI so far feels like a much smoother experience both in terms of setup, control and performance.

But i can see how MCP being able to plug into a remote agent that doesn't have terminal access is very useful. Seems like it's a best tool for the job conversation or am I missing some other advantage?

biggest thing is flexibility on what harness you use. we don't build on the claude code /codex sdk. instead, we just let you bring whatever CLI agents you prefer and just optimize the terminal experience for using CLI agents (track running / needs attention state, set up worktrees, split pane, etc)

yeah us and similar categories of tools prescribe a lot of our specific workflow for worktrees, review, code editing where iterm + tmux is much more flexible. we have to tow the line of what's useful as a built-in feature vs being very agnostic.

i do agree that there's a more novel UX than the same left sidebar with worktrees and middle chat/terminal that is not yet explored.

we've been spiking on what the UI is like to program and monitor the specific steps in the workflow from triggering agent -> planning -> coding -> review -> merge.

Conductor and t3 - We don't build on top of the SDKs and don't plan to. As a terminal first we give you the flexibility to work between the different CLI agents CC, Opencode, Codex, etc. to get the latest features.

Emdash more similar but we're planning on investing more into allowing you to script and automate the app + agents more with our CLI.

looks awesome! very interesting how similar these tools all look. i do think we're at an intermediate state here with the current UI where it doesn't scale as well for the future where triggering agents and review becomes much more important than the writing code part.

there's a lot of cases that works for me with multiple, spiking or triaging issues generally take long so i usually can kick off a few different workspaces for to check back in after a while. what i don't want to do is wait around for minutes while an agent is coding or exploring.

ah very interesting will have to give gstack another try

I think Abhi meant Dec 26, 2025

That’s awesome to hear!

Definitely some exciting stuff coming with better automations, mobile and remote workspaces

sorry to hear about the issue. we really messed up on the performance and balancing that with more features. looking into the imported projects did no projects show up on the sidebar for you?

will continue working bugs and hope you'll give it a try later in the future when the product's more stable :)

yes, bad choice on my part. the origin was i was planning for it to be a superset of all your dev tools, not thinking about apache superset at all since it was a different domain

we monetize on teams and, in the future, cloud. the bet is that teams will want to centralize their set up for this type of work, especially shared Linear, GitHub, skills, etc.

yes, we surface agent states automatically so you can see what's running or needs attention across the different workspaces. there's a set of tasks where having 5-6 running in parallel is still productive for me such as running spikes and fixing small issue.

As we're investing more into integration test and self-validating for the agents we're able to increase the number without sacrificing quality.

biggest difference is it's terminal first, and optimized for CLI agents. we don't prescribe a specific harness and instead try to work with any CLI harness you bring.