I'm so married to my existing tmux workflows and layout that I'm not sure whether I'd ever feel open to trying out something like this. At the same time, orchestrating multiple agents with native tmux and git worktree does feel cumbersome.
sethd 20 hours ago [-]
I built a tool that lets you keep your existing tmux workflow and adds a simple dashboard for monitoring and discovering agents inside tmux: https://github.com/sethdeckard/atria
thijsverreck 1 days ago [-]
if you want you can file an issue with your current workflow? happy to see if we can do a PR to support this natively in tmux-ide
TheRoque 22 hours ago [-]
What tools do you use on tmux to achieve your workflow ? Do you do just prompting or do you code too ?
nickjj 20 hours ago [-]
tmux by itself lets you create any number of sessions, windows and panes. You can arrange them for anything you want to do.
Having a pane dedicated to some LLM prompt split side by side with your code editor doesn't require additional tools, it's just a tmux hotkey to split a pane.
There's also plugins like tmux resurrect that lets you save and restore everything, including across reboots. I've been using this set up for like 6-7 years, here's a video from ~5 years ago but it still applies today https://www.youtube.com/watch?v=sMbuGf2g7gc&t=315s. I like this approach because you can use tmux normally, there's no layout config file you need to define.
It lets me switch between projects in 2 seconds and everything I need is immediately available.
TheRoque 19 hours ago [-]
Oh I mixed up tmux and termux.. woops.
sbinnee 20 hours ago [-]
I am in the same boat. It's the unix philosophy. tmux does its job well enough and it is already scriptable. I don't think I was sticking to the same layout for a long time because different projects tend to require different layouts. But that's the fun part of streamlining down your automation. I haven't felt the need to explore other options yet because I haven't felt the limitation of tmux yet.
bryanlarsen 17 hours ago [-]
I don't consider tmux to be very unix-y. It does two different jobs -- connection persistence and window management. Most people these days only use tmux for the former now that tabbed terminal programs are commonplace, but the complexity of the latter still infects tmux.
theturtletalks 1 days ago [-]
I'm also trying to build something similar for agent orchestration where one terminal is controlling multiple terminals. I tried using tmux but it's very good at sending the initial text to the tmux sessions, but I've not been able to get an agent to have a proper back and forth controlling multiple tmux sessions. I know we can use send-keys, but reading the session or knowing when that session is complete is kind of up in the air. And then if the main orchestrator terminal has checked all the sessions to see if they're actually working and doing things, the main session kind of stop so I've kind of been thinking about a cron that periodically checks in and nudges it to check the sessions again. Are they still working? Do they need more guidance? Essentially having one terminal control others, but having that back and forth with the terminals has been pretty challenging to achieve. Have you gotten anywhere with this?
SparkyMcUnicorn 1 days ago [-]
It sounds like maybe you haven't seen agent teams mode, which this project is using.
It supports tmux, but you can use it without via embedded terminal. It also has native integration with a few select terminals that expose the right kind of APIs.
Installs as single binary (written in Go) with no external dependencies.
operatingthetan 24 hours ago [-]
If this supported Gemini and Codex I would find it useful. I never run more than one Claude, it's always a mix.
thijsverreck 23 hours ago [-]
Both are supported! You can customize the startup command in ide.yml. I will update the docs to highlight that :)
bwestergard 1 days ago [-]
Looks like a great implementation. I want to question the basic user story, which seems to be: "I am a software developer who wants to improve productivity by running multiple simultaneous agents that are roughly isomorphic to a human software developer team."
I am burning a lot of tokens every day at work and on personal projects. It's helpful. I generally work in tmux with github copilot in one pane, and a few other terminal panes showing tests and current diff.
I find it really important to avoid the temptation to multi-task by running multiple agents. For quite varied tasks, productivity gains from multi-tasking have proven to be illusory. Why would it be different with writing software?
I love cmux! ironically you can use tmux-ide within cmux. The idea is to make it an agent development environment that's great when ran on a remote machine :).
https://github.com/ehrlich-b/wingthing Here’s my take on this idea, also FOSS. Does tmux style sessions so you can come and go. It also exposes a web terminal so you can get remote access - but you can also run fully locally for less latency.
devcraft41 23 hours ago [-]
Terminal-first makes a lot of sense for anything that runs on remote servers. I've been on helix+tmux for about a year and the main friction is onboarding teammates who are VSCode-native. Nice to see projects pushing in this direction. Does it handle multi-pane debugging or is that still a manual tmux split?
esperent 16 hours ago [-]
I've been looking for something like this - in fact, I've found several but they've all been MacOS only until now. So great job on making yours cross platform.
selixe_ 23 hours ago [-]
Interesting, but I wonder if this shifts too much complexity onto the user.
tmux is powerful, but not exactly approachable, and "multi-agent orchestration" on top of it feels like something that could get hard to reason about quickly. Curious how you think about UX here.
thijsverreck 23 hours ago [-]
Good points and indeed thinking about this quite a bit. Currently leaning towards a CLI first approach so that Claude/Cursor/[insert coding agent] can configure and control the ide. Feels a bit meta, but also makes it extremely user-friendly.
j45 23 hours ago [-]
Tmux is pretty easy to pick up and build muscle memory by learning a few keyboard shortcuts from a basic youtube video and it's handy when you don't want to switch screens between multiple terminals just for one thing.
The ability to split and divide the screen pretty simply with a few keys is handy for anyone who spends enough time in a shell - the abilty to save that layout for the shell items you're using to load up easily again the next time is valuable too.
Multi agent orchestration likely just means keeping track of a few different windows all on one screen.
Congrats on getting this out. What was the most surprising part of the build?
thijsverreck 1 days ago [-]
most surprising was that something this lightweight made such a big impact on my productivity. its really nice to have persistent Claude teams on my remote machines that I can always access no matter what.
mlboss 1 days ago [-]
Can somebody develop a mobile app that natively supports tmux
jrop 1 days ago [-]
I assume that you've tried Termux and somehow that doesn't meet your needs? (Also, you didn't specify whether you are on Android/iOS)
thijsverreck 1 days ago [-]
both ish and termux are great options on mobile/iPad!
deadbabe 1 days ago [-]
For all the hype of AI agents, you never see people taking on real challenging projects like this. Just low hanging fruit.
hypercoiner28 15 hours ago [-]
interesting results but the eval methodology seems a bit optimistic
mikestorrent 19 hours ago [-]
I like a good CLI, I like a good TUI, but why are we eschewing high-DPI graphical displays, icons, true-color, images, and everything else in favour of a 1980s terminal? Is it just to be retro, or do you guys really think you're seeing some advantage restricting yourself like this? Do you all REALLY hate moving your hand over to your mouse?
sabrehagen 11 hours ago [-]
Yes, I hate the inefficiency of moving my hand away from my finger input device. I hate the non-deterministic nature of mouse movement, in contrast to the deterministic nature of the keyboard.
ekropotin 1 days ago [-]
So basically tmuxinator?
desireco42 22 hours ago [-]
Thank you for sharing your work. Really cool.
From my perspective, this is cool, but since tmux is kind of permanent, you open your layout, set 1,2,3 screens for agents, you might add gemini and opencode. then open vite for server and one for shell for example. Then you can just close it and reopen whenever you want to work on it.
And that is it. If I am missing something, processes taking memory or such, I have a machine with memory (I know, flexing how expensive things are), please explain.
1 days ago [-]
accesspatchh 3 hours ago [-]
[dead]
the_harpia_io 6 hours ago [-]
[flagged]
aplomb1026 21 hours ago [-]
[dead]
rrojas-nexus 17 hours ago [-]
[dead]
agentica_wiki95 19 hours ago [-]
[dead]
AtxWrk70 23 hours ago [-]
[flagged]
jamesvzb 23 hours ago [-]
[flagged]
goatyishere25 20 hours ago [-]
[flagged]
Rendered at 20:07:39 GMT+0000 (Coordinated Universal Time) with Vercel.
Having a pane dedicated to some LLM prompt split side by side with your code editor doesn't require additional tools, it's just a tmux hotkey to split a pane.
There's also plugins like tmux resurrect that lets you save and restore everything, including across reboots. I've been using this set up for like 6-7 years, here's a video from ~5 years ago but it still applies today https://www.youtube.com/watch?v=sMbuGf2g7gc&t=315s. I like this approach because you can use tmux normally, there's no layout config file you need to define.
It lets me switch between projects in 2 seconds and everything I need is immediately available.
https://code.claude.com/docs/en/agent-teams
It supports tmux, but you can use it without via embedded terminal. It also has native integration with a few select terminals that expose the right kind of APIs.
Installs as single binary (written in Go) with no external dependencies.
I am burning a lot of tokens every day at work and on personal projects. It's helpful. I generally work in tmux with github copilot in one pane, and a few other terminal panes showing tests and current diff.
I find it really important to avoid the temptation to multi-task by running multiple agents. For quite varied tasks, productivity gains from multi-tasking have proven to be illusory. Why would it be different with writing software?
https://en.wikipedia.org/wiki/Human_multitasking
tmux is powerful, but not exactly approachable, and "multi-agent orchestration" on top of it feels like something that could get hard to reason about quickly. Curious how you think about UX here.
The ability to split and divide the screen pretty simply with a few keys is handy for anyone who spends enough time in a shell - the abilty to save that layout for the shell items you're using to load up easily again the next time is valuable too.
Multi agent orchestration likely just means keeping track of a few different windows all on one screen.
From my perspective, this is cool, but since tmux is kind of permanent, you open your layout, set 1,2,3 screens for agents, you might add gemini and opencode. then open vite for server and one for shell for example. Then you can just close it and reopen whenever you want to work on it.
And that is it. If I am missing something, processes taking memory or such, I have a machine with memory (I know, flexing how expensive things are), please explain.