Open Agents launches a browser-based cloud coding platform with parallel sessions

• Nico Albanese's launch thread introduced Open Agents as an open-source cloud coding platform, and the Vercel template frames it as a reference app for background coding agents rather than a packaged end-user product.
• Albanese's session post says the system can run many agents in parallel for hours after the laptop closes, while the homepage demo advertises long-lived sandboxed sessions with file, shell, network, and runtime access.
• Albanese's stack breakdown and Guillermo Rauch's launch post tie the project to four Vercel pieces: AI SDK, AI Gateway, Sandbox, and Workflow DevKit.
• According to the GitHub repo, the key architectural choice is that the agent runs outside the VM and talks to the sandbox through tools, which makes the stack easier to swap and extend, a nice little gift for coding agent nerds.
• Albanese's follow-up said the live deployment was temporarily put behind protection for bug fixes, even as his public usage page post pointed to a profile showing 4.1 billion tokens, 63,939 tool calls, and 435 tracked PRs in the last day.

You can browse the GitHub repo, deploy the official Vercel template, and inspect a shared agent session that shows the team already migrating from snapshot-heavy sandboxes to named persistent ones. The homepage openly shows explorer and executor subagents, and Vercel's own coding agents docs give the broader context for why the company keeps pushing AI Gateway, fallback routing, and sandboxed execution together.

The official docs describe Open Agents as a three-layer system: web app, agent workflow, and sandbox VM. The template page says the web layer handles auth, sessions, chat, and streaming UI, the workflow layer runs the durable agent loop, and the sandbox supplies filesystem, shell, git, dev servers, and preview ports.

The stack lines up cleanly with the launch tweets:

• AI SDK for the agent harness
• AI Gateway for model routing and fallback
• Sandbox for isolated persistent VMs
• Workflow DevKit for long-running execution

The main product pitch is operational, not model-centric. Albanese's post says he wanted sessions that survive hours of tool use, keep running after the browser closes, and scale to many agents in parallel.

The homepage adds a few concrete details the tweet only hints at:

• Each agent gets a full sandbox environment
• Built-in file ops, search, shell, and task delegation are exposed as tools
• Explorer and executor subagents split work in parallel
• Multi-model support runs through AI Gateway

The embedded demo video in the product walkthrough makes the browser-first workflow feel less like a landing-page claim and more like a real internal workstation.

The most useful implementation detail sits in the official write-up, not the tweets. The repo README says the agent does not run inside the sandbox. It runs outside the VM and uses tools to read files, edit code, search, and execute shell commands inside it.

That separation matters because it decouples agent state from the execution box. The docs say it makes it easier to change models, providers, and sandbox implementations without rebuilding the whole system around one runtime boundary.

A shared session from Albanese shows the design still moving under the hood. The migration plan on that page switches session state from changing runtime IDs and per-session snapshots to named persistent sandboxes like session_<sessionId>, while keeping the explicit resume flow for older sessions.

Albanese linked a public profile page that reads like a stress test: 4.1 billion total tokens, 3,071 messages, 63,939 tool calls, and 531,911 lines changed. That page also lists 129.3 million tokens consumed by subagents, which backs up the parallel-agent story with something more concrete than launch copy.

The launch was not perfectly smooth. A few hours after the thread went live, Albanese said the deployment had been put behind protection while the team worked through bugs. Earlier in the thread, he also credited recent updates including a git panel, CI auto-fix, file viewer, and redesigned sidebar, which helps explain why the repo looks more like an internal platform released into public than a toy demo.