You can now go to <https://openhands-agent-canvas....
# proj-agent-canvas
l
You can now go to https://openhands-agent-canvas.vercel.app/ instead of app.all-hands.dev, click on “OpenHands Cloud” as your login technique, and use the agent canvas instead of the openhands cloud 🙂
🙌 2
😲 1
q
I have a VM that I'm trying to connect to Does this only work if the canvas was started via
--backend-only
?
l
hmm, good question. i only tested with
agent-canvas --backend-only
but theoretically the endpoints should be the same
maybe add “/api” to the url?
oh, nvm, it’d be the opposite. it might be adding “/api” when you don’t need it
👀 1
c
This is handy, thank you! Two quick notes: • it doesn’t get the LLM from the Cloud, and • it suggests an openhands/ LLM, I seem to recall we wanted the default to be anthropic or openai, since it’s very likely people have those
l
1. correct 2. i’d be OK with defaulting to whatever our default model is on the official provider (right now openai/gpt-5.5), but personally I think openhands/ is a lot more convenient because you can mix and match different providers easily
c
Agreed, it’s just that it’s an onboarding wizard; so if the user is new to OpenHands, they likely have an openai/anthropic account, and not OH Cloud. In other words, it adds friction to: go figure out how to get it, buy credits, figure out where to find the key in the other Cloud interface, copy key, paste it
l
true, but they can select another provider right? we could also make the most popular N providers (e.g. 5) be shown by default for instance
c
That would be nice! If we can, not sure how it should look like
On a different note, I must be wrong, …using the Vercel agent-canvas UI with breaks… I’m under the impression that when it loses the sandbox it manages to restart much faster than on the other UI But I’m probably wrong, maybe I didn’t make large breaks
l
i think the event loading is more efficient on agent-canvas
c
Ahh, the typescript side of it, for sure! Not sure that was a big part or not