Comment by egorfine

4 days ago

I wonder why all of a sudden these harnesses want to run a permanent daemon on my machine? Like, all of them, and at the same time.

(Obviously, this feature should not exist at all let alone be default.)

21 comments

egorfine

Reply
GreenWatermelon  4 days ago

A pretty important feature is that the client process can crash without losing progress on my current session, similar to how I can reconnect to my tmux server without losing current active processes.

dominis  4 days ago

If you think about the evolution of AI coding, companies (who will eventually pay for these tools) will realize they want to run the coding tasks in a remote, controlled environment. Every engineer typing on their machine and burning tokens (money) won't work in an enterprise setting.

  • egorfine  4 days ago

    > Every engineer typing on their machine and burning tokens (money) won't work in an enterprise setting.

    Of course. Obviously, just a week ago and before that none of the harnesses did work in enterprise settings.

    Irony aside, I don't think that there are that many tasks that will benefit from a daemon but which aren't solvable with screen or tmux. In other words, I think this feature should not exist, let alone be enabled by default.

    Also, I actually am "an enterprise who pays money for these tools" and I strongly believe most of my engineers immediately disabled the background daemon. I know of a few who were unpleasantly surprised by the cli codex update.

    • dominis  4 days ago

      Sorry, English is my second language. When I wrote "won't work", probably what I meant was: won't scale.

      I am certain we are going to end up using these tools like we do with CI in the near future. With this, you'll get full observability, RBAC, sandboxing, and reproducible benchmarking.

      I assume as an enterprise you will want all of these when you spend a big chunk of your budget on tokens.

sodacanner  4 days ago

I agree that it shouldn't be default, but I'm wondering why you think it shouldn't exist _at all_. The daemon mode for emacs, for instance, is incredibly useful for speeding up startup time and persisting things between windows. It's probably very similar here.

bitmasher9  4 days ago

It’s not obvious to me why this feature shouldn’t be the default.

I routinely run dozens or hundreds of daemons. Why wouldn’t I want one to keep my network connections to llms open?

  • egorfine  3 days ago

    The problem is pre-ai and has excellent solutions. Some of which have not been changed for a couple of decades because they are perfect.

everforward  4 days ago

There’s two answers, depending on your personal cynicism.

The optimistic version is that the new zeitgeist is deeply recursive agents writing _huge_ swaths of code at once. The human side seems very asynchronous. You do a lot of queueing something that the agents churn on for an hour, so being able to detach/reattach would make sense.

The cynical version is everyone is realizing that nobody will pay for a harness, so they’re pivoting to a client-server model to try to PaaS-ify them. If they haven’t announced it already, they’ll have an OpenCode Cloud within the next quarter or two.

We’ll see how that goes. I’m not holding my breath that these will thrive as long as infrastructure teams exist. Agents are too simple from an infra perspective, and we’re seeing frameworks to make them stateless pop up already.

  • egorfine  4 days ago

    > deeply recursive agents writing _huge_ swaths of code

    No daemon needed for that. Like, at all.

    > they’re pivoting to a client-server model to try to PaaS-ify them

    This is absolutely it! The more I think about it.

    • everforward  4 days ago

      > No daemon needed for that. Like, at all.

      There is, for the same reasons that people use screen or tmux (which some people do use for this). If I were queueing a prompt I expected to take hours to finish, it would be nice to be able to run it another computer so I don't have to worry about closing my laptop lid or the battery dying.

      It's not world-changing, but I have had agents do `grep -r /` commands before and it would have been nice to be able to detach and let it run rather than having to kill it because I have to leave before it'll actually finish (WSL is sooo slow on that). It would be better if the agent did a better grep, but sometimes I'd rather wait 20 minutes than spend 7 minutes setting it all back up again.

      3 replies →