Close the browser — agents keep working

From "close the window and it stops" to "lives on in the background"

Before this, an agent's life was tied to the browser: close the tab and the background process doing the work was terminated with it — a half-done long task gone in an instant. That's a fundamental obstacle to "having AI do things for you over time": who would hand it a task that runs for tens of minutes and then not dare close the laptop or drop the network for the whole duration? This day's through-line was "unbinding" the agent from the browser, making it an independent, persistent background coworker you can return to anytime. It's a mental shift: from "I keep a window open watching it chat" to "I hand off the work, go do other things, and come back to the result."

Agents survive a closed window and resume

The core of making this work is persisting every task run to a record on disk, with an index. That way the agent's process no longer depends on the front-end connection to stay alive — the browser disconnecting only cuts the "watching" line; the "working" line keeps running in the background. When you reopen, the front end reconnects carrying a marker of "where I last saw," backfills the output you missed while away, then rejoins the still-flowing live stream. In testing that day, a reply of over ten thousand characters — which finished generating only after you reloaded the page — rendered in full across that refresh, not a word missing. Behind it is a "resumable" event-stream design: every event has a sequence number, and on reconnection it fetches from your last number onward, losing nothing and duplicating nothing.

Concurrent conversation tabs, with no crosstalk

Since agents can now run long in the background, naturally you should be able to open several at once. This day the interface supported multiple conversation tabs: a plus at the top opens a new session, so you can have one agent running a long task in this tab while chatting with another agent about something else in another, neither interrupting the other. Switching tabs interrupts no background run; each one's state and stream stay cleanly separated. For the vision of "one person leading a team of AIs," concurrent tabs are the most intuitive entry point — turning "advancing several things at once" from a concept into something you do casually, and paving the way for real multi-agent collaboration later.

A local dashboard: overview, runs, sessions, usage

With tasks running in the background and several open at once, you need somewhere to survey the whole. This day added a local dashboard in the top-right with four views: overview for the big picture, running tasks for who's still going, sessions for past conversations, and usage analysis for consumption. Here you can cancel or delete tasks and watch any task's output stream scroll out character by character live. Its value is a sense of control — when you've left several long tasks in the background, you need a dashboard to know at any moment where each stands, whether anything went wrong, and what it cost. Building this "operations view" into the product means the platform doesn't just want you to "do one thing with AI" but takes seriously the reality that "you'll be managing many things at once."

Several coding backends, one protocol, swap anytime

More than one "coding backend" can drive an agent, and each differs slightly in event format, capability and stability. This day integrated another new backend and unified them all under one event-stream protocol — whatever the underlying provider, the front end sees the same orderly events, so the interface and flow are identical. The most practical benefit: when one is temporarily unavailable or underperforming, you can switch to another in one click with no distortion to interface, operations or experience. Making "which model backend" a pluggable choice transparent to the layers above both protects users from being locked to a single provider and lets the platform calmly integrate more and more backends without rewriting the interface for each.

Engine: a unified vocabulary of handles and GUID assets

The engine made an important convergence in its low-level "conceptual vocabulary" this day. Assets were given globally unique identifiers (GUIDs) and a disk format addressed by them — meaning every asset has an identity that can't be confused, referenceable accurately across projects and scenes. The "handle" type design was clarified alongside, characterizing a reference along two dimensions so references are both type-safe and clearly expressed. The engine also changed "instancing" from implicit auto-batching to explicit declaration: you tell the engine plainly "this is a batch of the same object to draw together," making behavior more controllable and predictable. These are invisible low-level engineering, but they decide whether the engine stays clear and orderly as content grows and scenes get complex — giving assets a reliable identity system is the precondition for all later "import, reuse, compose."

Games stored per project + a hot-reload refresh fix

This day also adjusted how game content is stored: from "unified publishing" to "each project keeps its own copy," with game data living in that instance's own directory. This is more intuitive — your game belongs to your project, not published into some shared pool. A long-nagging hot-reload issue was fixed alongside: previously, under certain proxied setups, the preview wouldn't truly refresh after a browser reload because the hot-reload channel connected to the wrong port; this day fixed it so "edit and see it" holds steadily across deployment paths. Such adjustments look trivial but are the underlying guarantee of whether "build while talking" stays silky throughout.

What this day means

The biggest shift this day was the agent's identity: it's no longer a chat partner that "exists only while you watch," but a background coworker that runs long independently, is surveyed and managed, and can be returned to anytime. Survives a closed window, runs concurrently, manageable via a panel, swappable backends — together these push "having AI do things for you" from a demo scenario toward a real way of working. You can hand several tasks to different agents at once, close the laptop and do something else, then come back and accept them one by one. This is exactly what the platform wants to be: not a toy you must watch constantly, but a team you can entrust and return to collect from. The real multi-agent collaboration to come is built on the "persistent + concurrent + observable" foundation laid this day.