Comment by 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.
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.
> 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.
I wrote something for this:
https://github.com/skorokithakis/symphony
It turns GitHub issues into your harness's frontend, so you just chat with OpenCode on GitHub issues, and OpenCode runs on some remote server of your choice.
It works extremely well for me.
It's a shame the RLVR training doesn't zap the model with a million volts every time it runs a recursive grep or find on /, but I guess that would make the benchmarks suffer.
I know. I’ve been poking at just writing a middleware for my ACP proxy that transparently rewrites them to ./ but they’re often piped to something that expects an absolute path.
Maybe that’ll be my weekend project, I’m sure no one has ever been mad to spend a weekend trying to parse bash.