Show HN: Agent-of-empires: OpenCode and Claude Code session manager
Hi! I’m Nathan: an ML Engineer at Mozilla.ai: I built agent-of-empires (aoe): a CLI application to help you manage all of your running Claude Code/Opencode sessions and know when they are waiting for you.- Written in rust and relies on tmux for security and reliability - Monitors state of cli sessions to tell you when an agent is running vs idle vs waiting for your input - Manage sessions by naming them, grouping them, configuring profiles for various settingsI'm passionate about getting self-hosted open-weight LLMs to be valid options to compete with proprietary closed models. One roadblock for me is that although tools like opencode allow you to connect to Local LLMs (Ollama, lm studio, etc), they generally run muuuuuch slower than models hosted by Anthropic and OpenAI. I would start a coding agent on a task, but then while I was sitting waiting for that task to complete, I would start opening new terminal windows to start multitasking. Pretty soon, I was spending a lot of time toggling between terminal windows to see which one needed me: like help in adding a clarification, approving a new command, or giving it a new task.That’s why I build agent-of-empires (“aoe”). With aoe, I can launch a bunch of opencode and Claude Code sessions and quickly see their status or toggle between them, which helps me avoid having a lot of terminal windows open, or having to manually attach and detach from tmux sessions myself. It’s helping me give local LLMs a fair try, because them being slower is now much less of a bottleneck.You can give it an install withcurl -fsSL https://raw.githubusercontent.com/njbrake/agent-of-empires/m... | bashOr brew install njbrake/aoe/aoeAnd then launch by simply entering the command `aoe`.I’m interested in what you think as well as what features you think would be useful to add!I am planning to add some further features around sandboxing (with docker) as well as support for intuitive git worktrees and am curious if there are any opinions about what should or shouldn’t be in it.I decided against MCP management or generic terminal usage, to help keep the tool focused on parts of agentic coding that I haven’t found a usable solution for.I hit the character limit on this post which prevented me from including a view of the output, but the readme on the github link has a screenshot showing what it looks like.Thanks!
93 points by river_otter - 27 comments
Making this multi-player + creating the right representation to collaborate with agents is in my opinion the next bottlenecks. I wrote a small article about my thoughts there https://x.com/mmabrouk_/status/2010803911486292154
[1] https://steve-yegge.medium.com/the-future-of-coding-agents-e...
Works pretty well so far. Biggest issue i foresee for success is user UX for average employee, and actually useful use-cases.
And what's really fascinating isn't that multiple people have built the same thing is just how convergent all the ideas are. This makes a heap of sense given that they are all vibe-coded and using similar libraries. It's just very real when you see it right in front of your face like this.
I think there's a heap of really interesting stuff when you start linking into hooks which can also create tmux splits and really make the agent the center of an ide which seems like this is on the way to.
Regarding feedback on whether sandboxing would be useful, yes, please! Including something like Docker sandboxes would make isolating the agent env’s much less of a hassle.
As an aside, I’m curious how others are handling this now… Mostly just creating dedicated user accounts?
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.
If only we could have a clean API to programmatically control agents... The best UI is no UI
I am seeing a lot of development working around the shitty experience that is being stuck in a terribly slow cli program, nothing against this particular project
The best (for me) of these that I’ve tried so far is conductor.build
They have a different UI orientation, and it’s more locked into Claude code, but it might be good inspiration for your future plans. They get the git worktree setup and teardown and managing dev servers part of it right IMO.
>relies on tmux for security how is it more secure than not using it?
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'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!