Tested out https://sprites.dev/ last night. Honestly, a pretty great experience so far. Remote persistent VM. Looks to be pretty cheap. I had $30 in free credits, so I decided to give it a shot.

I got https://buildwithpi.ai/ going on there, and had it create an extension that lets me easily share sessions directly from the sprite! Could totally have done it in one-shot if I’d prepped it properly. Anyway, you can see part of the convo below.

Not sharing the actual link because I’ll probably kill this sprite at some point, but it is exposed as `https://<sprite-name>-<id>.sprites.app/sessions/<session-uuid-string>`

All the sprite and pi docs are available to the agent, so it doesn’t need much coaching. Additionally, sprites are set up so that you just have to run a server on port 8080, et voilà, you have a public server!

The Quickstart is a great overview of the basics: install the CLI, create a Sprite, and you’re in a persistent environment that sleeps when idle and wakes on demand. I came back the next day to write up my experience, and everything was instantly available. I just asked pi to help me write it all up from the night before.

My goal was simple: I wanted to be able to work remotely, then share progress easily. That felt like the perfect first project. So I just had pi scaffold a tiny FastAPI app with uv and wire it up to export session HTML. From there it was basically: serve /sessions/<id> via pi --export, run it on port 8080, and now I can hand someone a URL to the exact conversation. We also added a /visibility command in a small pi extension so sessions are private by default and only become public if I explicitly mark them.

I ran into a couple small deployment gotchas, all of which were easy to iron out—especially because the agent had direct, easy access to service logs, so fixes were super quick. I'll share the extension at some point, though it is trivially "prompt-able" to be honest.

Simon Willison also has a great overview that frames Sprites as both "developer sandbox" and "API sandbox," which is a helpful lens. He also points out two details that match my experience: automatic port forwarding (so you can hit localhost endpoints from your own machine) and pre-installed agent "skills" that teach the agent how Sprites works. That second part is surprisingly useful, because it means you can ask the agent how to do platform-specific tasks and it can navigate the environment without much additional prompting.

If you want a deeper take on why this kind of durable sandbox is a nice fit for agents, Fly's own post is also worth the read. It articulates the "computer, not container" framing really well.

All in all this felt like the first time a hosted agent environment didn’t feel flimsy. Fast to spin up, persistent enough to be useful, and (now) easy to share when you want to. I’m pretty sold.

Prompt

Here's a prompt you might try if you want to do this yourself

You are building a sessions service from scratch inside a Sprite environment.
Before implementing, load the environment context from these locations:

**Sprite environment info**

 - /.sprite/llm.txt (platform behavior + security)
 - /.sprite/llm-dev.txt (language runtimes/tools)
 - /.sprite/docs/agent-context.md (services, HTTP, checkpoints, network policy)
 - /.sprite/docs/languages.md (runtime managers)

**Pi (coding agent) info**

 - Pi documentation directory:
 /.sprite/languages/node/nvm/versions/node/v22.20.0/lib/node_modules/@mariozechner/pi-coding-agent/docs/
 - If you need Pi RPC or export behavior, consult:
 docs/rpc.md

**Service requirements**

 - Build a FastAPI app using uv.
 - Serve on 0.0.0.0:8080 (Sprite proxy default).
 - Add endpoints:
     - GET /sessions → returns the exported HTML output of pi --export (or equivalent Pi SDK/RPC call).
     - GET / → redirect to /sessions.
 - Security: HTTP endpoints may be public. Do not expose secrets, env vars, or internal system data beyond the intended HTML export.
 - Provide minimal README with run instructions and uv commands.

 Be concise and safe by default.