How we built Meshia so an agent could operate the GPU

The first creative move was to stop treating the GPU as the product

A GPU is powerful, but it is a terrible user interface. It has a price, a region, a boot path, a container image, a driver stack, a network proxy, an idle timer, and a failure mode. Most clouds expose those details because their customer is an engineer who expects to drive the machine by hand.

We needed the product to start somewhere else. The user should not have to ask for an A5000 or an H100 first. The user should ask for a result, and we should decide what kind of machine makes sense. That meant our control plane had to translate between a human goal and the messy shape of real providers.

This is why we are not building "Claude with a terminal." The agent gets tools, but the dangerous edges go through code paths we can audit. It can ask to attach compute. It cannot silently ignore a spend cap. It can write code and run experiments. It cannot make provider cleanup optional.

The second move was deciding what is allowed to disappear

If you build around cloud GPUs, you eventually learn that the GPU is not a home. It is a rented room. It can boot slowly, restart, lose a local disk, or be replaced by a different provider. For a research workspace, that is unacceptable if the user's files live only inside the room.

So we made MeshiaFabric treat provider disks as cache and object storage as authority. The durable record is not "whatever happens to be on the pod right now." It is the object prefix recorded for the workspace, plus a manifest ledger that says which files exist, which generation they belong to, and which content-addressed blocks hold the bytes.

That sounds abstract, so here is the practical version

When the agent writes a file, the workspace sync agent watches the path, publishes dirty files into content-addressed blocks, and updates the manifest. When two runtimes touch the same file, the conflict resolver tries the safe cases first: fast-forward if both sides match, append-merge if both extended the same base, sidecar if the edits are genuinely different.

When the user stops a session, billing freezes first. Then we ask the workspace to drain exactly once. We do not chase writes forever, because that would turn cleanup into another place to lose money. Late writes are reported. Finished writes are saved.

This is the kind of technical detail that makes the product feel calm. The user only sees "Saving files..." or "resume to recover." Underneath, the system has rules for generations, stop-drain, conflict resolution, and content-addressed storage.

Large files forced us to care about the shape of waiting

The first naive upload path is easy to imagine: for every file, call the server, send the bytes, update the UI. That works until somebody drops a real dataset folder. Then "uploading files" turns into thousands of browser events, thousands of server calls, and a progress bar that tells the truth too slowly to be useful.

A concrete planning drill made the problem obvious: 53,589 files and 9.096 GiB. Per-file upload would have created a storm. We now plan folder drops into tar bundles, uploads those bundles directly to object storage, and asks the pod to extract them safely into /workspace.

There is a security story hiding here too. Archive extraction rejects symlinks, devices, absolute paths, and traversal attempts. Capacity is checked before extraction. The browser never needs to know the provider's private storage shape. The product gets to feel like drag and drop, but the implementation treats every filename as untrusted input.

Long jobs need a place to live

A chat response can be ephemeral. A training run cannot. If an agent launches a job that takes an hour, the user expects the work to have a life outside the WebSocket. It should survive a daemon restart. It should leave logs. It should know whether it can resume.

Long-running work we launch lives under a durable job directory in the workspace. Each job has a manifest, a status file, an append-only output log, a process-group record when active, and a recovery-safe runner. The manifest stores the original command, optional resume command, checkpoint globs, restore policy, attempt count, latest checkpoint, kind, and session lineage.

We do not pretend we can checkpoint every arbitrary Linux process. If we launch the job, we own the recovery path. If the process falls outside that path, we label it clearly instead of selling fake resilience.

The final move was showing our work

The more work we hide behind one button, the more evidence we owe the user. If the system attaches a GPU, runs a command, writes files, spends money, and then cleans up, a screenshot is not enough. The user needs a receipt.

Not a marketing receipt. A technical receipt. The kind that can tell another engineer what happened without asking them to trust the UI.

1. What runtime ran the work
2. Which GPU or provider accepted it
3. What command, files, logs, and artifacts were produced
4. What it cost and when billing stopped
5. Whether cleanup actually settled

This changed how we think about the whole product. The receipt is not just a download at the end. It is a requirement that reaches backward through the system. If you want to prove cleanup, cleanup needs a durable state. If you want to prove cost, billing needs quote lineage. If you want to prove a result, the runtime needs to know which logs and artifacts count as evidence.