I'm setting up a small orchestration around zellij (I have almost no experience with tmux, so I went with the "modern" alternative), upterm and qrencode that allows me to 1) generate a claude code instance in a persistent session 2) make it controllable remotely via upterm 3) scan a qr code to copy the upterm server's ssh url on my phone so that I can paste it in termux.
I wonder if it would be more ergonomic to connect to the aoe window on my phone for when I have more then one claude code session to keep track of. I'm not against switching the zellij part to tmux.
Tbh that's exactly what I'm using aoe for: termius on my phone ssh into my Mac mini and then use aoe to check in on each agent session. Just make sure you check out the readme if you do this because at least for termius there's a quirk to make tmux and TUI happy. The recommended approach is to run aoe itself inside a tmux session which then will spawn additional tmux sessions as needed.
It does not. I opted for the flow of returning to dashboard to give the user the control over which context they wanted to launch themselves into. I'm not against considering the feature, but in my own work trying to wrangle multiple agents, I haven't found the idle worker switch feature to be something I wanted personally
Agent orchestration seems to be the new hot problem to be solved in the ecosystem. See also Steve Yegge's most recent posts [1]. Curious to see what tools emerge as the winners of the Cambrian explosion we're probably about to see.
Totally. Yegge's post was fascinating and there was quite a bit of chatter about it internally at my company . I have this feeling that if I could just figure out how to effectively direct 10-20+ coding agents at once, I could supercharge my productivity and bug squashing skills. In some ways his post introducing a suite of new terminology helps to set the stage for this being a whole new world of being a SW engr.
Ah thanks I should have clarified, I generally meant that's why I wrote it in rust. Tmux has nothing to do with security for sure.
It works on top of tmux to monitor the coding agent state all in one place so that you can see whether the agent is waiting for you. Today I also added git worktree support so that you can easily create and manage branches to run agents in parallel on the same codebase.
I'm always curious how folks do status detection. Here you use tmux capture-pane and detect off that! Whew! Simple & direct!
I've been really enjoying how OpenCode is so extensible, how you can make great plugins that can for example read the session.idle event & then go do whatever they want. That does require dropping in some config asking for the plugin, which takes some effort & requires a restart (but your session will be right there & you can continue). It's technically elegant imo, and nice that there is the extensibility.
But hard to beat using screen as a framebuffer & just reading it out, for doing absolutely whatever it is you could possibly want to do! For example you can also detect permissions prompts, which I don't believe there is an event for!
Haha I'm all about the KISS principle. I also set up a snapshot testing framework so that people can submit screenshots of any messed up status reports and I can easily add them to the test suite to make sure we fix any issues that someone sees.
I'm setting up a small orchestration around zellij (I have almost no experience with tmux, so I went with the "modern" alternative), upterm and qrencode that allows me to 1) generate a claude code instance in a persistent session 2) make it controllable remotely via upterm 3) scan a qr code to copy the upterm server's ssh url on my phone so that I can paste it in termux.
I wonder if it would be more ergonomic to connect to the aoe window on my phone for when I have more then one claude code session to keep track of. I'm not against switching the zellij part to tmux.
Tbh that's exactly what I'm using aoe for: termius on my phone ssh into my Mac mini and then use aoe to check in on each agent session. Just make sure you check out the readme if you do this because at least for termius there's a quirk to make tmux and TUI happy. The recommended approach is to run aoe itself inside a tmux session which then will spawn additional tmux sessions as needed.
Does it have a . Hotkey for automatically switching to the next idle worker, like the namesake did?
It does not. I opted for the flow of returning to dashboard to give the user the control over which context they wanted to launch themselves into. I'm not against considering the feature, but in my own work trying to wrangle multiple agents, I haven't found the idle worker switch feature to be something I wanted personally
I'm also seriously considering the ability to produce aoeii sound effects like "nuh nuh nuh"
it must be done
Agent orchestration seems to be the new hot problem to be solved in the ecosystem. See also Steve Yegge's most recent posts [1]. Curious to see what tools emerge as the winners of the Cambrian explosion we're probably about to see.
[1] https://steve-yegge.medium.com/the-future-of-coding-agents-e...
Totally. Yegge's post was fascinating and there was quite a bit of chatter about it internally at my company . I have this feeling that if I could just figure out how to effectively direct 10-20+ coding agents at once, I could supercharge my productivity and bug squashing skills. In some ways his post introducing a suite of new terminology helps to set the stage for this being a whole new world of being a SW engr.
how is this different than using tmux? i don't understand what it does
>relies on tmux for security how is it more secure than not using it?
Ah thanks I should have clarified, I generally meant that's why I wrote it in rust. Tmux has nothing to do with security for sure.
It works on top of tmux to monitor the coding agent state all in one place so that you can see whether the agent is waiting for you. Today I also added git worktree support so that you can easily create and manage branches to run agents in parallel on the same codebase.
I'm always curious how folks do status detection. Here you use tmux capture-pane and detect off that! Whew! Simple & direct!
I've been really enjoying how OpenCode is so extensible, how you can make great plugins that can for example read the session.idle event & then go do whatever they want. That does require dropping in some config asking for the plugin, which takes some effort & requires a restart (but your session will be right there & you can continue). It's technically elegant imo, and nice that there is the extensibility.
But hard to beat using screen as a framebuffer & just reading it out, for doing absolutely whatever it is you could possibly want to do! For example you can also detect permissions prompts, which I don't believe there is an event for!
Haha I'm all about the KISS principle. I also set up a snapshot testing framework so that people can submit screenshots of any messed up status reports and I can easily add them to the test suite to make sure we fix any issues that someone sees.
I'd love a cli subcommands that would just give me status, btw. Very neat to have.
I need to add some better docs but the CLI of aoe supports it already!