Hi everyone! I had a question about the rationale ...
# proj-agent
b
Hi everyone! I had a question about the rationale behind the following decision decision in OpenHands v1 vs. OpenHands v0: why is it that now the LLM is called from inside the remote env/docker sandbox instead of making the call from the host's machine? From what I remember, this was not the case with OpenHands v0. The reason I ask this is because we want to run RL with the OpenHands scaffold using the remote runtime (which runs in the cloud) and the engineering challenge we now need to fix is to ensure that the locally hosted vLLM/SGLang endpoints for rollouts now have a public IP address (using services like ngrok). This is NOT a blocker for me but I would love to know if you could share some insights behind why the software is designed this way! One benefit I can think of is that there will be 1 network/HTTP call less for each action since we now no longer need to transport the LLM message from local host to sandbox
c
Others can elaborate better than me, I'll just note this is absolutely intended. The idea is, the full agent loop runs in the agent sandbox. The agent loop is captured inside the box, and isolated from other conversations, whether they are runs of the same user or not. I think a big reason for it came from trying to make the cloud deployment work well multi-user, because it must have been tough to run agents from many users in the same space, while making sure resources are available and there are no leaks. But I think it makes sense anyway, even without that. It allows people to run the agent in whatever host, cloud or local, and interface with a REST/WS agent-server to play with it from a client. Existing clients (CLI app, Web apps), future clients, are just clients to a server, where they play with a conversation, which, at its turn, controls the agent loop.
🙌 1
b
Makes sense! I should remind myself that there is a reason why the v1 repo has the term
SDK
in it 😅 -- it makes sense to have the least amount of code running on the client's machine, especially when running remotely.
And yeah, the current design is better suited for all the real-world applications as you explained.