I think I only added two features, pasting images over mosh (ssh already worked but not mosh) and a compact version of sidebar.
The story behind the fork is: I had a bug with raycast, filed a PR that fixed it for me https://github.com/manaflow-ai/cmux/pull/2435, a different fix made it into next release that for me didn't work. Maybe the problem was on my side, but at this point it was easier to fork the working version than debug further.
Totally fair, maker of cmux here. We fixed many RAM usage issues (latest version is 0.64.22), and also added an activity monitor to see how much RAM/CPU coding agents are taking.
My cmux has been running with 136 workspaces and 218 terminals, and has been hovering around 5.7 GB. Granted, the theoretical RAM minimum for this number of terminals is around 1-1.5 GB before real scrollback, so we definitely have more work to do.
Thanks, good to know. I installed the update and will check it out again.
If it helps, the main reason I love cmux is how can I manage my projects into folders, I have fast access to all the projects which made my life a lot easier working in the terminal. I can also have coding, test, monitoring spilt in one tab per project.
> The source is Google Photorealistic 3D Tiles. Isometric.nyc explored and rejected the use of 3d building data. It is pretty insane that US gov has free LIDAR data for every city in the US available to the public. I spent <30mins exploring this and stuck to google 3d images. Claude Code whipped up a scraper to stream the 3D Tiles and render with three.js. This gives the best "real" texture base for the model to learn from. Anything else would involve a LOT of manual work to get the inputs right.
> Now that we have the 3D tiles, we need to generate the ground truth pairs for training! Similar to isometric.nyc, I generated a few ghibli-style pixel-art images using Google's Nano Banana. SF terrain is very interesting. There are quite a few distinct features like skyscrapers in FiDi, the hills in the southeast, 2 iconic bridges, lots of coastline, piers, parks, suburban grids and lots of water. I generated a ton of images and curated from them. Getting consistent style was a challenge. There was a LOT of manual trial and error. But as usual, Claude Code added this feature to the dev app that allowed me to select the best images and approve them.
I had to leave out a ton of details in the training process. But at every step, codex/cc built me a dev tool to navigate the complexity. That was such a unique side project experience.
interesting with the alcatraz island - I notice its invented some houses, and turned a cruise ship into a rock. I appreciate the difficulty and getting a lora to understand it - despite this the finished project is beautiful
I also feel that some of the technical explanations are a little dense here in the dev blog. I forget who it was who I saw mentioning it here on HN, but I've been having a lot of success with getting models to (re)write technical explanations in https://en.wikipedia.org/wiki/Simplified_Technical_English
I'm one of the creators of cmux. I'm moving a lot of my own dev work to Mac Minis, so I'm starting to feel quite a lot of the pain you mentioned... will try to make this better!
please do and let me know ! quick story fast, I'm working a loooot remotely. I'm using https://github.com/sanchxt/yoop to synchronize my keyboard. Since I'm using moonlight it's blazing fast. But when I work in the train I'm back to ssh. My quick tip would be to: build your own tools, build them once, use them forever. and rmux is exactly made for that, it's prefect for TUIs over ssh and low connection that needs to stay alive even if you get disconnected
> hotkey overrides - I have some things explicitly unmapped / remapped in my ghostty config that conflict with some cmux keybindings and weren't respected
We need to be better about this; right now you can modify keyboard shorcuts with cmd+, in the GUI. Planning on making it a config file in the spirit of ghostty though, not sure if we want to reuse ghostty's config file though since it might become a maintenance burden for them...
> command palette (cmd-shift-p) for less-often-used actions + discoverability
yes
> cmd-z to "zoom in" to a pane is enormously useful imo
Thinking of the right way to design this. Like hypothetically we can expand it, but what happens if you make a vertical/horizontal split, or cmd+t to make a new tab? I guess we could just "merge" it back into the original space which would be pretty cool.
IMO (re zoom behavior):
if you make a new tab, it should add a new tab as normal and stay zoomed in. the tab bar (of the currently zoomed in panel) would still be at the top while zoomed in, and workspaces still appear to the side
if you make a new split (or navigate splits), it would zoom you back out (contract the panel) and just split/navigate the way it normally would
