The Playwright-style snapshot/wait layer is the interesting part to me. A lot of agent terminal automation still breaks because the tool can send keys but can't prove which pane or terminal state it actually reached. Stable pane IDs plus explicit waits should make replay and debugging much saner than the usual grep+sleep loops.
Congrats on the launch. If emacs was unavailable and I needed tmux, I would try it. I am old school, and use emacs daemons for all shell multiplexing. The agents dont need explanations and know how to use emacsclient to create, read, or send inputs to named buffers that run the shells. Elisp is powerful, so manipulating windows is a breeze. Lots of people on tmux would benefit from this design though.
The paragraph on the website inviting us to switch to rmux from tmux claims that tmux is programmed in C++. tmux is made in C.
Very nice!<p>I created `ygg`[0] a while back to easily spawn a new worktree when working with Claude/codex, and it also spawns that in a dedicated zellij tab. I think making the terminal multiplexer pluggable, so it would be easy to integrate something like this.<p>[0] <a href="https://github.com/joch/ygg" rel="nofollow">https://github.com/joch/ygg</a>
Cool project, I like the idea of having tmux-compatible CLI. I used Zellij to get better UX, but many agent tools integrate with tmux. This way agent tools can still integrate tmux as a defacto standard for programmatic interface while having better interface for users.<p>But I wonder if tmux/rmux design is suboptimal since it couples session persistence and window management together. Do you have an opinion the design which separates the responsibilities? An example that pioneered this approach is abduco, and libghostty-based zmx being a modern implementation.
Very cool! I think the hype around “agents are so good that you never actually need to see the underlying commands they are running or interact with the terminal session that they’re running” misses out on a lot of very important use cases, particularly around long running processes that may be shared across multiple agents. This will be very cool to see how best practices evolve!
The website is a little too obviously made by Claude. The first thing I noticed is the classic "pill with pulsing green dot that says something is active or live" claudism.
The video of the front page is assisted by AI, I am not a vfx artist; please check rmux code architecture instead, I put a lot of efforts on it
FWIW, I did suspect AI was probably used when looking through the README, but it also didn't really impact my opinion much because the value proposition of "I can use a Rust library to control this through the same primitives the tool itself uses instead of writing a bunch of shell scripts" far outweighs that. I haven't had a chance to try it out yet but plan to later today, and ultimately the experience I have is going to matter a lot more to me than what tools you used to generate the README visuals.<p>I've tried out plenty of things that seemed promising but turned out to have sloppy implementations before the LLM days, and I've also used some things that are ostensibly vibe-coded but had shockingly high quality of UX compared to the alternatives because the creators put in time and effort into polish beyond what people who make software the "traditional" way tend to, so to me, the important signal is what level of care went into the creation of the software. I'm hoping that this project turns out to be one of the good ones, and if it is, the people who dismiss it because of vibes (pun intended) will be the ones missing out.
For what it's worth I genuinely loved your landing page. I casually clicked through and got an immediate unexpected chuckle at the giant animated crab.<p>It's obviously AI assisted but I interpreted it as a nod to itself on that and really appreciated it.
"site made by ai" is the new "bootstrap template" criticism that honestly gets tiring after a while. just read the content.
I’m genuinely interested in what you find to be the problem with that?<p>It’s a landing page.
commonlisp (sbcl) is one of the best sleeper techs out there. one of those if you're in the know type industry secrets. part of it is because their website looks like something out of the 90's. clearly having a nice website and some level of marketing is necessary to get adoption. Im more than happy to see devs use AI to automate that so they have more time to focus on their creations.
and why this is a problem? I found the landing page covering exactly what the product does, with nice demos and examples.
As someone new to this site, I understand wanting to keep the AI Slop at bay, but for some of us, it's been a boon to get our ideas into an actual working application. I have decades of IT/Network/Enterprise experience, but creating and writing a complex tool would have been well beyond my abilities or patience. I had a friend say that AI is a "scourge on the intellectually lazy" and I couldn't really refute that, but I had to add that it is a boon to a lazy intellectual, which I consider myself to be.
Not to mention those absolutely horrible scroll animations.
So?
a week ago I was using cmux but its osx only and doen't work on remote terminals. then I switched to herdr which is great so far except its not s great at managing panes. I can't move them around or change ordering. now another terminal multiplexer. I'm getting whiplash.<p>all that said, none of the existing solutions are perfect and rust codebases are nice. how easy is it to reorder panes? is there a cli that lets me control the panel layout via a skill file and allow my opencode session to target and send data to other panes?
I built <a href="https://zmx.sh" rel="nofollow">https://zmx.sh</a> to make it easier to interact with your terminal sessions programmatically. 1 window = 1 session which might feel like a negative but it makes programmatic access easy and agents can use it just by pointing it at the zmx help command. Basically, an agent just needs 2 commands (run and write) for full control and the commands are synchronous so you don’t need to do any polling.
I started using cmux a month ago and it had made my life a lot easier. Finally I have a pane with all my projects open all the time, I can switch between them, have multiple terminals for each one.<p>What do you mean by remote terminals?
my plan is to eventually move my entire workflow to a remote workmachine over ssh. with kernal, I can automate all my smoketests entirely from a headless machine rendering my laptop overkill to run agentic workflows. I'd rather be using it to watch movies, learn new stuff or hand code in my downtime. if your workflow requires cmux, you're stuck running your agents on your local machine.<p>To be clear, That doesn't make cmux bad. if you WANT to do everythign on your mac, cmux is fantastic. its just not designed with the remote ssh control use case in mind.
no skill file, you get the same 90 commands of tmux. and if you build a rust app you can have many more cool stuff like "wait for" some text to appear, asyncly
Getting this error when installing from git bash:<p>$ curl -fsSL <a href="https://rmux.io/install.sh" rel="nofollow">https://rmux.io/install.sh</a> | sh
rmux install: unsupported OS: MINGW64_NT-10.0-26200
I found the project quite interesting but what's the advantage over just using tmux with a hotkey to send keys?
Writing shell scripts to orchestrate things is not a particularly great experience. "Shell scripts are annoying to write compared to the programming languages we use for other things" isn't a universal opinion, but it's not exactly uncommon; I've heard plenty of people talk about switching to Python as soon as anything gets even moderately complex. (I often tend to go with the lines "my bar for when to switch to a real programming language is as soon as I have to write an if statement" and "the number of times I've had to write a for loop in bash is the same as the number of times I've had to google the syntax for a for loop in bash", which are only <i>slight</i> exaggerations). Having an actual library for interactions that isn't just a wrapper around the CLI seems like it would be a huge improvement for anything that isn't a one-off interaction.
windows support, and the sdk. native async "wait until" something appears on your terminal, so you don't spam send-keys
Scriptable terminal multiplexer?<p>Interesting portable scripting thingy. But it would only work with portable tools, not just everything. Especially with Windows tools.
I used to use ghostty's applescript and built that into a claude skill. It worked like a charm. But this feels super interesting for programmability
Hey, I automate tmux all the time with send keys and capture.. how is your project improves vs tmux or zellij?
rmux is much faster than tmux or zellj, I did some internal benchmark and it's promising. rmux is a multiplexer engine, meaning that you can rewrite entirely zellij using rmux.. I created a mini zellij in a few hundred lines of rust. You can check the demoes on the repo
I don't get it as well, everything mentioned in the readme is already trivially possible with tmux or zellij
I mean, the obvious immediate answer is “windows”, which tmux flat out doesn't support (except via WSL and a shared mount).
Never had the need to do playwright automation for tmux, so not sure why I would use this above tmux which works well.
Floating panes seems not possible, or are they?
1. ask Claude to rewrite X in Rust<p>2. ask Claude to make a website and claim R is better than X because it's Rust<p>3. advertise on HN, X and Reddit<p>4. ???<p>5. profit!
Can someone describe the pros/cons vs zellij?
[dead]
[dead]