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.
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
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.
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?
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.
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.
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.
> 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.
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.
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.
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.
Worth giving onorca.dev a try. That already supports this with nice UI. Also atcyrus.com is interesting to delegate tasks too.
How do you feel they compare?
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
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.
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?
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.
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.
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.
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.
> 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.
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.
>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/
On the wall ? It's spray painted in big neon letters, and by themselves, lmao. Herdr cannot be trusted.
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
[1] https://herdr.dev/blog/herdr-raised-a-seed/
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.
You don't understand why some people might have multiple machines they connect to at any given time?