https://docs.all-hands.dev/ logo
Join Slack
Powered by
This was a fun read. I admit I do think a remote V...
# feedback
c
This was a fun read. I admit I do think a remote VM is the right direction for a lot of agent loads: https://fly.io/computers-compared It's the difference we already see, between ephemeral sandboxes and persistent remotes.
My agent had to make itself some scripts on a Cloudflare worker in order to wake the Daytona “VM-sandbox”, because it auto-pauses and then it has no usable URL
I feel maybe it's the same distinction as between one-off Automations and messaging Automations. • conversation starts; does a thing; ends • (new run = new conversation ) • (e.g. most github work ) • conversation starts (from Slack); does a thing; user asks more; does more; next week user asks again; responds naturally again The second works great on local/remote VM, and not so good when it keeps trying to wake sandboxes, sometimes impossible, sometimes too late; potentially losing data, repo 🤔
m
for slack should not be a problem right? Becuase you have the trajectory and you can restart the sandbox. But if you do that with PR-reviews, this can be tricky, as the repo and/or the env can be heavy. or?
c
For Slack it had always been a problem, though. Slack also has a repo or more.
(on the old Slack app)
Restarting the sandbox. That's just the point: the sandbox could not be restarted in a bunch of cases
2 Views
Open in Slack
PreviousNext
Powered by