← Back to context

Comment by everforward

2 days ago

I looked and will give it a try, but haven’t had a chance yet because life.

I had debated building something like this, and I really want to see what the other fork in the path looks like.

One of the core tenants of mine is to not impose a workflow or set of tooling on the user. I specifically opted not to go with k8s because access to local files is going to be a pain, and I think people will still expect that. There’s all sorts of “I need this binary that’s not in APT”, or “you need this cert to test, and we can’t commit it” stumbling blocks.

Yours feels like it’s pushing me into an unfamiliar workflow, but opinionated tools are often better so it’s worth a try.

My only direct criticism is that I think k8s is a bad way to go for this (but is probably what people expect). For personal use, k8s is more than I want to deal with. For work use, I suspect lambdas would be cheaper and avoid a ton of maintenance junk. We tend to think of agents as a persistent process, but they’re sort of not. They’re a stateless process that is effectively dead until a new message comes in, let it be dead until something else comes down the pipe.

Yes — it is currently a downside that idle sessions are taking up resources. However, you can currently stop and restart them and it saves your active workspace, even untracked files in git. And there is active kubernetes work to make saving memory state to disk and restarting significantly easier, which would significantly reduce the resource burden: https://github.com/kubernetes/kubernetes/pull/140186