HeySnap AI

The belief the whole thing rests on is that a useful agent should live next to the files, browser, and tools it is expected to operate. That is the reason this is a machine rather than an interface.

The audience is people who do not write software. Terminals, configuration, and a run that halts at a sign-in page are all tolerable if you are a developer and disqualifying if you are not, so the product hides the machinery behind a computer they already know how to use.

A computer here is a real VM the control plane creates and owns, with persistent disk, its own identity, and a lifecycle that runs through creating, starting, online, idle, sleeping, and offline.

No machine ever exposes a public port. Everything a client touches goes through one gateway that authenticates the person and checks ownership before it routes anything.

Web and mobile speak the same protocol, so the phone is a peer of the browser rather than a reduced view of it.

It ran hosted on AWS for a few months before I shut it down. A VM per user is a real monthly bill, and by then the system had proved the thing I built it to prove.

The cloud server is one deployment with two responsibilities kept separate inside it: a control plane owning users, computers, provisioning, and ownership, and a gateway that routes authenticated traffic to machines.

Every provisioned machine runs the same server, which owns that computer’s filesystem, terminal sessions, browser control, previews, and agent runs.

The browser is the person’s own. A Chrome extension exposes a managed window in their real profile, streamed into the workspace, so logins, cookies, two-factor prompts, and their own IP address continue to work rather than being replaced by a headless session.

The machine dials out to the gateway and holds one tunnel open, so nothing needs to listen on a public address.

Choosing a computer mints a short-lived access session scoped to one user, one computer, and one route, which the gateway verifies before proxying a socket.

People authenticate with user tokens and machines with their own identities installed during provisioning, so neither can act as the other.

Each computer is an isolated Ubuntu VM that keeps its filesystem and agent state between sessions, sleeps when it goes idle, and wakes when the person returns.

Two agent harnesses, Codex and Pi, sit behind one shared thread and streaming protocol, so history, plans, tool activity, attachments, model choice, steering, and cancellation behave the same whichever is running.

The agent draws on a library of skills and integrations: GitHub, Vercel, Supabase, Chrome, web research, image generation, documents, spreadsheets, presentations, PDFs, FFmpeg, and Remotion.

Previews render source code, markdown, CSV, XLSX, DOCX, PPTX, PDF, images, audio, and video without downloading the file first.

Model calls pass through an AI gateway that records usage per request, so cost is attributable per user and per machine rather than arriving as one opaque bill.

Machines authenticate to that gateway with their own identity, which means provider credentials never have to be written onto individual VMs.

Most agent products hand you a headless browser in a datacenter. It works right up until the task needs an account, and then it meets a login wall, or a two-factor prompt, or a fraud check tripped by an address on the other side of the world. For anything touching a person’s real accounts, that is most tasks.

So HeySnap does not supply a browser at all. A Chrome extension exposes a managed window inside the person’s own profile and streams it into the workspace. The cookies are theirs, the sessions are theirs, the address is theirs, and the agent works inside that window rather than beside it. They can take over mid-task by clicking in the same window they are watching.

The path an instruction takes is unusual: it starts on the cloud VM, crosses the tunnel to the web client, reaches the extension, and acts in a browser sitting on the person’s desk, with files able to travel back the other way. Two computers, one instruction, and the login problem simply does not arise.

A machine holds a single outbound socket to the gateway, and everything rides it: browser frames, filesystem operations, previews, agent streams, and uploads and downloads measured in tens of megabytes. Left to a plain queue, one file transfer stalls the screen you are looking at.

So frames are classified and scheduled rather than sent in order of arrival. Interactive browser control runs at priority 100 with a weight of 8 and an 8 MiB queue. Filesystem operations and previews sit beneath it. Uploads and downloads drop to priority 10, are given a 32 MiB allowance, and are flagged as bulk so the scheduler treats them as background work.

The result is that dragging a large file onto a machine does not freeze the browser view you are watching it land in. That difference is most of what separates a remote computer that feels usable from one that does not, and none of it is visible in the interface, which is the point.

Two things have to prove what they are, and they are deliberately given different credentials. A person signs in to the control plane and receives a user token. A machine receives an identity during provisioning and uses it to register, heartbeat, and open its tunnel. A machine cannot act as a person, and a stolen user token cannot impersonate a machine.

Selecting a computer produces a third, short-lived thing: an access session scoped to one user, one computer, and one route such as filesystem or agent. The gateway checks ownership before proxying, and if the machine is asleep it asks the control plane to wake it rather than failing the connection.

What that buys is one public entry point, one TLS surface, and one place where routing rules are enforced. The alternative, machines listening on public ports with their own certificates, is easier on day one and indefensible by month two.

Keeping interactive traffic responsive while bulk transfers share the same tunnel, which is the entire reason traffic classes and a weighted scheduler exist.

Provisioning that has to finish with a machine which registers itself, reports its capabilities, and comes online without anyone touching it.

Updating machine servers that are already running. Artifacts are versioned and checksummed, installed atomically, migrated once, restarted only once sessions go idle, health checked afterwards, and rolled back when the check fails.

Reaching a browser the person is already signed in to, which meant building a path from the cloud VM through the tunnel and the web client into an extension running in their own Chrome.

Making the mobile client a peer of the web client rather than a cut-down view, since both talk to the same machine protocol.

Deciding to switch it off. A VM per user is a genuine cost, and keeping it running was not the same as proving it worked.