6 ms·

Connecting the machines

ahknight 24d ago
Why would I want a service for this when I could easily run such a discovery service myself? Why not just release that tool to users? SyncThing offers its discovery server for self-hosting as an example. Oh, right, this is how we monetize in 2026. Nevermind.
- hext 24d ago
  As they explicitly state in the docs, there is no reason to use their cloud service if the machines are accessible to each other via SSH.
ActionHank 24d ago
I am not sure I fully understand the need to farm out sufficient work that I need a network of machines to do it. Unless you're just slop farming.
- hext 24d ago
  You don't understand why some people might have multiple machines they connect to at any given time?
hext 24d ago
This is fantastic to see, I've been daily driving herdr at work and at home for a few months now. It's great. My biggest complaint has been exactly this, I want all of my ssh sessions available in one spot. Excited to try it out.
CharlesW 24d ago
I'm hoping someone can explain why this is interesting. I get that Herdr wants investors to give them money to own developers' coding sessions, but the value proposition ("Walk away and they keep working. Come back from any machine and they're where you left them.") seems like a miss since it's so easy to do that without them. I'm surely missing something.
- acron0 24d ago
  Well, they're mainly introducing Herdr Cloud which I take to be similar to Tailscale (and other comments seem to support this too). `herdr login` on any machine, anywhere and suddenly that box joins your Herdr network of boxes you can connect to and deploy agents to. This is totally doable with Tailscale today, but maybe there's other features that can only be realised with some kind of cooperation at or above the network level?
- kkapelon 24d ago
  How many other products can you name that: 1) are terminal based (not gui apps that you need to install) 2) Can be run by mosh/ssh 3) Track agent sessions automatically 4) Have built-in git worktree management 5) Show agents connections over different machines (the new feature mentioned in the blog post)?
evil-olive 24d ago
> But until now, each machine needed a separate Herdr client, usually in a different terminal tab. You had to remember where each agent was running and switch between those tabs to check on them. That was the bottleneck. is it, though? I can imagine having a local Herdr instance and one running on a remote box somewhere, but I can't think of a use case where I'm trying to juggle N different Herdr instances and that overhead becomes a meaningful bottleneck. > Getting to 1.0 > After this update, what I want is to make connecting those machines more convenient. You shouldn’t need to think about SSH or deal with complicated network setup. It should be easy to connect any machine, anywhere, through one Herdr account. (emphasis added) sigh. I'm a daily user of Herdr. I don't have a Herdr account today. I don't want a Herdr account. I don't need a Herdr account. the product is not even to 1.0 yet and already the writing is on the wall for the path towards enshittification & acquisition by $bigco. of course, I'm sure there will be some "usage without an account will still work" platitudes, but the trend of development is clearly going to be in the direction of features that "integrate" with the "developers using Herdr pay us money and/or we collect their data" business model.
- well_ackshually 24d ago
  >the product is not even to 1.0 yet and already the writing is on the wall for the path towards enshittification & acquisition by $bigco. https://herdr.dev/blog/herdr-is-joining-y-combinator/ https://herdr.dev/blog/herdr-is-joining-y-combinator/ On the wall ? It's spray painted in big neon letters, and by themselves, lmao. Herdr cannot be trusted.
- threecheese 24d ago
  Same. If asked to create an account, I suspect a lot of us will decline and move on. The reason Herdr is novel, IMO, is its runtime owns the PTYs and builds a bidirectional messaging system on top of that. It’s like Pi’s RPC - a very limited version of it - which allows one to hook into agent i/o without needing to invoke “$agentcli -p”. There’s a lot they could build on that, and so I wonder why a managed cloud play was first on their list.
evanpurkhiser 24d ago
I’ve been running codex’s remote app server as a systemd service for the last several months, and before that opencode remote. It’s very easy to switch between my phone and desktop app. I haven’t tried herdr yet, but maybe it’s just not targeted at me? The real problem I have with the remote codex setup is when it needs to authenticate as me. I sort of solved this for sudo and ssh with this [1], but I think something like this could be integrated deeper into the harness [1]: https://github.com/evanpurkhiser/agent-witness https://github.com/evanpurkhiser/agent-witness
- mintflow 24d ago
  Been integrated a codex remote feature to my NovaScale app (with in-app tailnet connectivity) using remote app server too, it works well for me, though the websocket is experimental, but seems it keep schema compatible well.
bibstha 24d ago
Worth giving onorca.dev a try. That already supports this with nice UI. Also atcyrus.com is interesting to delegate tasks too.
- sirkiller 24d ago
  How do you feel they compare?
  - bibstha 24d ago
    Onorca.dev is very similar but has a desktop UI that I prefer to herdr. I find it easier to work with. Being UI, it has markdown reader, a native browser integration, linear or github built in integration. So working with multiple different unrelated projects feels natural. Go to linear, select a ticket -> start in X workspace, go to github, select an issue and start in Y workspace. The limitation of Orca or Herdr is that they don't have integration for multi project work. Here is what I wanted Telegram/OpenClaw → Single Linear Account Control plane with multiple projects → route each task to be completed and PRs open for review across multiple repos. This is where Cyrus helps. You setup labels and routing so cyrus knows which gitrepo to build worktrees from, and the labels can help you pick up the right model (codex-sol/astro or claude-opus/fable). This has helped me be more hands off. So I use both Orca and Cyrus. Cyrus for automation (telegram ingress) vs Orca if I want anything hands on.
    - mrlinx 24d ago
      love orca, but they severely need mobile support
    - Danii1 24d ago
      I'm adding support for multiple projects and teams in devintern.com, but it's taking tasks from task trackers so serves niche where you don't need to babysit and actively steer the agent.
- well_ackshually 24d ago
  >Backed by YCombinator will turn into absolute dogshit within weeks, use proper software.
rvz 24d ago
Again it bears repeating [0] that if you don't pay for your tools and expect open source maintainers to do it for free, then they will most certainly take funding from VCs and angels instead. Now they have raised $6M in funding. [1] Do not be surprised to realize that open source does not pay their bills. [0] https://news.ycombinator.com/item?id=49201743 https://news.ycombinator.com/item?id=49201743 [1] https://herdr.dev/blog/herdr-raised-a-seed/ https://herdr.dev/blog/herdr-raised-a-seed/
qingshan3 24d ago
I have been running herdr since yesterday, and have been using this feature to connect multiple machines. Now I want to delegate most of tmux keys to herdr for consistent experience.
bigcat12345678 24d ago
Makes sense. I had always been curious on why Tailscale hasn't creating agent-oriented features. It's obvious to me that Tailscale is at the best position (AFAIK) to capitalize on agents demand. Their connectivity product is unique. And it's a natural fit to connecting long-running agents instance across the Internet.
- transitorykris 24d ago
  These are two different layers in the stack that do two different jobs. Agent to agent communication across remote machines is definitely lubricated with tailscale, I’m not sure what value moving up the stack would bring at this stage? My read here isn’t about connecting to remote machines in the sense of ssh, but presenting a unified view across herdr instances running on multiple remote machines. This stinks of the same enshittification moves Docker made 10 years ago.
  - bigcat12345678 24d ago
    Tailscale's connectivity solutions should allow private connection between agents and between human-agents, by layering on top of the existing connectivity substrate. (I was stating "general impression", and I haven't looked into details yet.) What I need is to have a general solution to connect me to my agents running somewhere. The motivation is that any hosted solution deprives me of ownership of my data. And I am planning to share more private data with my agents, that cannot be done to have hosted agents today. (I plan to build a hosted solution myself where users can declarative define their own agents, and completely own their own data without my service save anything, I'll ask users to connect to their own storage solutions like Google doc) I of course can build everything myself. But I think a tailscale offering could be very convenient. I am guessing cloud flare should have building blocks of their own, but it's a different layer than tailscale's.
- mintflow 24d ago
  This is the motivation I built the app NovaScale with in app tailnet connectivity I was thinking the herdr remote features is nice to have in my app, given this herdr multi machine support, perhaps I need to reconsider how I integrate it in the future
ls1911 24d ago
[flagged]
knighthacker 24d ago
[flagged]
cobbzilla 24d ago
Sorry but whenever I hear the name of this tech I visualize the stereotypical “dumb person” saying “hurr, durr” nonsense words
- widowlark 24d ago
  I thought that was the joke? Its both 'herding the agents' and hurrdurr this is so freakin simple
  - cobbzilla 24d ago
    Forgive me, I don’t generally ascribe positive connotations to the phrase. It’s about as funny as wearing an “I’m with Stupid” T-shirt.
parasxos 24d ago
[dead]
kelvinjps10 24d ago
It would be good if they released a good mobile app I'm have been using termux and moshi and claude code. Termux and moshi provide the full functionality of the terminal but it gets clunky sometimes and with claude code you don't get the full functionality and a lot of stuff are missing from the tui
- theptip 24d ago
  Codex and Claude mobile apps are finally quite usable in the last month or two, it’s been a long time that the experience has been janky. You finally don’t need to do the janky termux ‘Claude —remote-control’ startup dance. Still not as productive as on desktop, but viable for side project style work.
- kkapelon 24d ago
  I am also using termux and moshi and at least with moshi everything works out of the box. Where does it get clunky? What functionality is missing?
- ig0r0 24d ago
  I use https://github.com/ZingerLittleBee/Heeler https://github.com/ZingerLittleBee/Heeler on iOS, works OK, but needs to be installed via TestFlight, not released yet.
_pdp_ 24d ago
[dead]
theptip 24d ago
It’s a good feature. However I am not convinced that the terminal/ssh abstraction will remain optimal when you orchestrate a swarm of workers across multiple machines. Running via ssh is great when your machines are pets that have local state. I don’t find it to be that useful when I have more than two machines that I’m load balancing agent sessions across. Just for example, a nice feature from the Codex app; if you edit a markdown file on your remote, and click on the link to the edited .md file, it just opens the file in the local app, and you can view the rendered form too. If I’m working on my local machine this isn’t a win vs. opening the file in Obsidian / IDE. But it’s way easier than manually viewing the file over SSH (unless you just want to look at the raw text version). Similar applies to html files. I think it’s more likely the Fly Sprites or Claude/Codex sandbox model will win as we move to swarms. If I’m not watching the actual harness output, there’s not a great reason to attach a pty.
- killix 23d ago
  [flagged]

Why would I want a service for this when I could easily run such a discovery service myself? Why not just release that tool to users? SyncThing offers its discovery server for self-hosting as an example. Oh, right, this is how we monetize in 2026. Nevermind.

hext 24d ago
As they explicitly state in the docs, there is no reason to use their cloud service if the machines are accessible to each other via SSH.

ActionHank 24d ago

I am not sure I fully understand the need to farm out sufficient work that I need a network of machines to do it. Unless you're just slop farming.

hext 24d ago
You don't understand why some people might have multiple machines they connect to at any given time?

hext 24d ago

This is fantastic to see, I've been daily driving herdr at work and at home for a few months now. It's great. My biggest complaint has been exactly this, I want all of my ssh sessions available in one spot. Excited to try it out.

CharlesW 24d ago

I'm hoping someone can explain why this is interesting. I get that Herdr wants investors to give them money to own developers' coding sessions, but the value proposition ("Walk away and they keep working. Come back from any machine and they're where you left them.") seems like a miss since it's so easy to do that without them. I'm surely missing something.

acron0 24d ago
Well, they're mainly introducing Herdr Cloud which I take to be similar to Tailscale (and other comments seem to support this too). `herdr login` on any machine, anywhere and suddenly that box joins your Herdr network of boxes you can connect to and deploy agents to. This is totally doable with Tailscale today, but maybe there's other features that can only be realised with some kind of cooperation at or above the network level?
kkapelon 24d ago
How many other products can you name that: 1) are terminal based (not gui apps that you need to install) 2) Can be run by mosh/ssh 3) Track agent sessions automatically 4) Have built-in git worktree management 5) Show agents connections over different machines (the new feature mentioned in the blog post)?

evil-olive 24d ago

> But until now, each machine needed a separate Herdr client, usually in a different terminal tab. You had to remember where each agent was running and switch between those tabs to check on them. That was the bottleneck. is it, though? I can imagine having a local Herdr instance and one running on a remote box somewhere, but I can't think of a use case where I'm trying to juggle N different Herdr instances and that overhead becomes a meaningful bottleneck. > Getting to 1.0 > After this update, what I want is to make connecting those machines more convenient. You shouldn’t need to think about SSH or deal with complicated network setup. It should be easy to connect any machine, anywhere, through one Herdr account. (emphasis added) sigh. I'm a daily user of Herdr. I don't have a Herdr account today. I don't want a Herdr account. I don't need a Herdr account. the product is not even to 1.0 yet and already the writing is on the wall for the path towards enshittification & acquisition by $bigco. of course, I'm sure there will be some "usage without an account will still work" platitudes, but the trend of development is clearly going to be in the direction of features that "integrate" with the "developers using Herdr pay us money and/or we collect their data" business model.

well_ackshually 24d ago
>the product is not even to 1.0 yet and already the writing is on the wall for the path towards enshittification & acquisition by $bigco. https://herdr.dev/blog/herdr-is-joining-y-combinator/ https://herdr.dev/blog/herdr-is-joining-y-combinator/ On the wall ? It's spray painted in big neon letters, and by themselves, lmao. Herdr cannot be trusted.
threecheese 24d ago
Same. If asked to create an account, I suspect a lot of us will decline and move on. The reason Herdr is novel, IMO, is its runtime owns the PTYs and builds a bidirectional messaging system on top of that. It’s like Pi’s RPC - a very limited version of it - which allows one to hook into agent i/o without needing to invoke “$agentcli -p”. There’s a lot they could build on that, and so I wonder why a managed cloud play was first on their list.

evanpurkhiser 24d ago

I’ve been running codex’s remote app server as a systemd service for the last several months, and before that opencode remote. It’s very easy to switch between my phone and desktop app. I haven’t tried herdr yet, but maybe it’s just not targeted at me? The real problem I have with the remote codex setup is when it needs to authenticate as me. I sort of solved this for sudo and ssh with this [1], but I think something like this could be integrated deeper into the harness [1]: https://github.com/evanpurkhiser/agent-witness https://github.com/evanpurkhiser/agent-witness

mintflow 24d ago
Been integrated a codex remote feature to my NovaScale app (with in-app tailnet connectivity) using remote app server too, it works well for me, though the websocket is experimental, but seems it keep schema compatible well.

bibstha 24d ago

Worth giving onorca.dev a try. That already supports this with nice UI. Also atcyrus.com is interesting to delegate tasks too.

sirkiller 24d ago
How do you feel they compare?
- bibstha 24d ago
  Onorca.dev is very similar but has a desktop UI that I prefer to herdr. I find it easier to work with. Being UI, it has markdown reader, a native browser integration, linear or github built in integration. So working with multiple different unrelated projects feels natural. Go to linear, select a ticket -> start in X workspace, go to github, select an issue and start in Y workspace. The limitation of Orca or Herdr is that they don't have integration for multi project work. Here is what I wanted Telegram/OpenClaw → Single Linear Account Control plane with multiple projects → route each task to be completed and PRs open for review across multiple repos. This is where Cyrus helps. You setup labels and routing so cyrus knows which gitrepo to build worktrees from, and the labels can help you pick up the right model (codex-sol/astro or claude-opus/fable). This has helped me be more hands off. So I use both Orca and Cyrus. Cyrus for automation (telegram ingress) vs Orca if I want anything hands on.
  - mrlinx 24d ago
    love orca, but they severely need mobile support
  - Danii1 24d ago
    I'm adding support for multiple projects and teams in devintern.com, but it's taking tasks from task trackers so serves niche where you don't need to babysit and actively steer the agent.
well_ackshually 24d ago
>Backed by YCombinator will turn into absolute dogshit within weeks, use proper software.

rvz 24d ago

Again it bears repeating [0] that if you don't pay for your tools and expect open source maintainers to do it for free, then they will most certainly take funding from VCs and angels instead. Now they have raised $6M in funding. [1] Do not be surprised to realize that open source does not pay their bills. [0] https://news.ycombinator.com/item?id=49201743 https://news.ycombinator.com/item?id=49201743 [1] https://herdr.dev/blog/herdr-raised-a-seed/ https://herdr.dev/blog/herdr-raised-a-seed/

qingshan3 24d ago

I have been running herdr since yesterday, and have been using this feature to connect multiple machines. Now I want to delegate most of tmux keys to herdr for consistent experience.

bigcat12345678 24d ago

Makes sense. I had always been curious on why Tailscale hasn't creating agent-oriented features. It's obvious to me that Tailscale is at the best position (AFAIK) to capitalize on agents demand. Their connectivity product is unique. And it's a natural fit to connecting long-running agents instance across the Internet.

transitorykris 24d ago
These are two different layers in the stack that do two different jobs. Agent to agent communication across remote machines is definitely lubricated with tailscale, I’m not sure what value moving up the stack would bring at this stage? My read here isn’t about connecting to remote machines in the sense of ssh, but presenting a unified view across herdr instances running on multiple remote machines. This stinks of the same enshittification moves Docker made 10 years ago.
- bigcat12345678 24d ago
  Tailscale's connectivity solutions should allow private connection between agents and between human-agents, by layering on top of the existing connectivity substrate. (I was stating "general impression", and I haven't looked into details yet.) What I need is to have a general solution to connect me to my agents running somewhere. The motivation is that any hosted solution deprives me of ownership of my data. And I am planning to share more private data with my agents, that cannot be done to have hosted agents today. (I plan to build a hosted solution myself where users can declarative define their own agents, and completely own their own data without my service save anything, I'll ask users to connect to their own storage solutions like Google doc) I of course can build everything myself. But I think a tailscale offering could be very convenient. I am guessing cloud flare should have building blocks of their own, but it's a different layer than tailscale's.
mintflow 24d ago
This is the motivation I built the app NovaScale with in app tailnet connectivity I was thinking the herdr remote features is nice to have in my app, given this herdr multi machine support, perhaps I need to reconsider how I integrate it in the future

ls1911 24d ago

[flagged]

knighthacker 24d ago

[flagged]

cobbzilla 24d ago

Sorry but whenever I hear the name of this tech I visualize the stereotypical “dumb person” saying “hurr, durr” nonsense words

widowlark 24d ago
I thought that was the joke? Its both 'herding the agents' and hurrdurr this is so freakin simple
- cobbzilla 24d ago
  Forgive me, I don’t generally ascribe positive connotations to the phrase. It’s about as funny as wearing an “I’m with Stupid” T-shirt.

parasxos 24d ago

[dead]

kelvinjps10 24d ago

It would be good if they released a good mobile app I'm have been using termux and moshi and claude code. Termux and moshi provide the full functionality of the terminal but it gets clunky sometimes and with claude code you don't get the full functionality and a lot of stuff are missing from the tui

theptip 24d ago
Codex and Claude mobile apps are finally quite usable in the last month or two, it’s been a long time that the experience has been janky. You finally don’t need to do the janky termux ‘Claude —remote-control’ startup dance. Still not as productive as on desktop, but viable for side project style work.
kkapelon 24d ago
I am also using termux and moshi and at least with moshi everything works out of the box. Where does it get clunky? What functionality is missing?
ig0r0 24d ago
I use https://github.com/ZingerLittleBee/Heeler https://github.com/ZingerLittleBee/Heeler on iOS, works OK, but needs to be installed via TestFlight, not released yet.

_pdp_ 24d ago

[dead]

theptip 24d ago

It’s a good feature. However I am not convinced that the terminal/ssh abstraction will remain optimal when you orchestrate a swarm of workers across multiple machines. Running via ssh is great when your machines are pets that have local state. I don’t find it to be that useful when I have more than two machines that I’m load balancing agent sessions across. Just for example, a nice feature from the Codex app; if you edit a markdown file on your remote, and click on the link to the edited .md file, it just opens the file in the local app, and you can view the rendered form too. If I’m working on my local machine this isn’t a win vs. opening the file in Obsidian / IDE. But it’s way easier than manually viewing the file over SSH (unless you just want to look at the raw text version). Similar applies to html files. I think it’s more likely the Fly Sprites or Claude/Codex sandbox model will win as we move to swarms. If I’m not watching the actual harness output, there’s not a great reason to attach a pty.

killix 23d ago
[flagged]