Live data from Hacker News

Herdr is joining Y Combinator. The runtime stays open

herdr.dev

81–90 of 197 posts

Re: Herdr is joining Y Combinator. The runtime stays open

#83

I've been using Herdr for a while now, but I'd like a multiplexer that's also a meta-harness that I can connect to remotely. I know others have setups that work, I just haven't quite figured it out yet.

Moshi has an integration with Herdr; you can connect to your herdr sessions over mosh, your touches register as mouse clicks in the UI (which is minimally rendered above the shell), and there’s a shortcut bar which can issue herdr-keymapped commands.

It’s not open source, and costs a few bucks, but it works well and has live Claude/Codex/etc notifications if you are willing to install a hook daemon on your hosts with homebrew. I was looking for batteries-included “code from my iPhone” after trying a bunch of self-hosted stuff, now I connect to my Macs over Tailscale and get dropped right into multiplexer sessions with rich status notifications.

https://getmoshi.app/

Re: Herdr is joining Y Combinator. The runtime stays open

#85

Congrats to Can on the pre-seed funding. genuinely wishing you all the best. The terminal multiplexer / multi-agent coding space is getting very crowded. YC alone has funded many competing startups in this space: herdr, Superset, cmux, Emdash, Orca, Bullet, Conductor (Conductor was in YC before pivoting from chat->coding). I’m probably missing a few, and that’s before counting companies outside YC such as Superlogica…

It's super important to me. I use Herdr every day and I maintain a whole stack of changes. From minor comfort tweaks that are just preference, to several larger changes like add jj workspace support and a WIP web based view (powered by xterm.js). This is not the only project like this too. Many of my devtools are piling up changes. I try to upstream changes where it makes sense, but many times they are either very be…

> LLMs have made making personal changes to devtools so effortless that I am now extremely hesitant to use any non source available software at all

This mirrors my view so totally it's crazy. If AI is ushering in the era of personal tooling, closing the harness is orthogonal to what users want.

Re: Herdr is joining Y Combinator. The runtime stays open

#88

Congrats to Can on the pre-seed funding. genuinely wishing you all the best. The terminal multiplexer / multi-agent coding space is getting very crowded. YC alone has funded many competing startups in this space: herdr, Superset, cmux, Emdash, Orca, Bullet, Conductor (Conductor was in YC before pivoting from chat->coding). I’m probably missing a few, and that’s before counting companies outside YC such as Superlogica…

It's super important to me. I use Herdr every day and I maintain a whole stack of changes. From minor comfort tweaks that are just preference, to several larger changes like add jj workspace support and a WIP web based view (powered by xterm.js). This is not the only project like this too. Many of my devtools are piling up changes. I try to upstream changes where it makes sense, but many times they are either very be…

> like add jj workspace support

care to share a pr :)

Re: Herdr is joining Y Combinator. The runtime stays open

#89
post #26

> That’s why I recently switched it from AGPL to Apache: I want everyone to use Herdr freely, without any problem. I'm curious what the actual problems with AGPL were.

The copyleft licenses are toxic for adoption. Companies default away from them because there are a lot of murky unknowns (e.g. if you run a copyleft service and connect to it via API, is that extending it? Does that service’s source have to be shared?) that simply aren’t worth the hassle. If you want your library to get traction with many real world use cases, you need to have a permissive license. If you want to sti…

> if you run a copyleft service and connect to it via API, is that extending it

No, it isn't; a client talking to an AGPLv3 service over a network API stays a separate program and is not touched by the license at all. Section 13 places obligations solely on whoever runs a modified version of the service, while remote users, API clients included, only gain the right to receive that service's source. So nothing on the client side must suddenly become AGPLv3, and the only thing that ever has to be shared is the AGPL'd program itself, not anything across the API boundary. The first half of your post is basically unfounded FUD; the second half tracks.

Post reply on HN