agent-browser

oad the project files, run commands on the VM, and tear it down when it's done. If it needs a GPU, it can request one. cloudrouter start ./my-project cloudrouter start --gpu B200 ./my-project cloudrouter ssh cr_abc123 "npm install && npm run dev" Every VM comes with a VNC desktop, VS Code, and Jupyter Lab, all behind auth-protected URLs. When the agent is doing browser automation on the VM, you can open the VNC URL and watch it in real time. CloudRouter wraps agent-browser [1] for browser automation. cloudrouter browser open cr_abc123 "http://localhost:3000" cloudrouter browser snapshot -i cr_abc123 # → @e1 [link] Home @e2 [link] Settings @e3 [button] Sign Out cloudrouter browser click cr_abc123 @e2 cloudrouter browser screenshot cr_abc123 result.png Here's a short demo: https://youtu.be/SCkkzxKBcPE What surprised me is how this inverted my workflow. Most cloud dev tooling starts from cloud (background agents, remote SSH, etc) to local for testing. But CloudRouter keeps your agents local and pushes the agent's work to the cloud. The agent does the same things it would do locally — running dev servers, operating browsers — but now on a VM. As I stopped watching agents work and worrying about local constraints, I started to run more tasks in parallel. The GPU side is the part I'm most curious to see develop. Today if you want a coding agent to help with anything involving training or inference, there's a manual step where you go provision a machine. With CloudRouter the agent can just spin up a GPU sandbox, run the workload, and clean it up when it's done. Some of my friends have been using it to have agents run small experiments in parallel, but my ears are open to other use cases. Would love your feedback and ideas. CloudRouter lives under packages/cloudrouter of our monorepo https://github.com/manaflow-ai/manaflow. [1] https://github.com/vercel-labs/agent-browser