The Sprites Blog

Run Paperclip on a Sprite

2026-04-01T00:00:00+00:00

Paperclip is extremely hot right now. I’m not going to explain what it is in any detail here because you have YouTube. But in short: it’s an open-source orchestration platform that lets you set up teams of AI agents that operate like a company. Org charts, goals, budgets, autonomous execution. It’s perfect for people who want a team of robots to do all the work that they issue from a dimly lit room in which they stroke a cat and sip from a crystal glass.

It is genuinely cool and appears to have real utility. So it’s a safe bet that Mac Minis are sold out in every store in your city again. Fortunately, Sprites people have already forgotten what it feels like to have something as trivial as hardware scarcity get in the way of building cool things.

Let’s get a Linux computer to run our Paperclip on:

sprite create paperclip

Now we have a hardware-isolated Linux computer with 100GB of storage, its own URL with TLS, and a pause/resume lifecycle that means you only pay for it when it’s actually doing something.

Setup

Node 22 is already in your Sprite. So this is the whole install:

npx paperclipai onboard -y

The -y flag accepts all defaults: embedded PostgreSQL, local file storage, port 3100. It creates your config, sets up the database, generates secrets. Done.

Make It Reachable and Register the Service

Paperclip’s default config binds to 127.0.0.1 in local_trusted mode. You’re not sitting at this machine, so it needs to bind to 0.0.0.0 in authenticated mode, get told about your Sprite’s hostname, and be registered as a Sprite service. Tell Claude:

In ~/.paperclip/instances/default/config.json, change server.deploymentMode to "authenticated" and server.host to "0.0.0.0". Then run npx paperclipai allowed-hostname with this Sprite’s hostname (get it from sprite-env info). Then register Paperclip as a Sprite service called “paperclip” using sprite-env services create with the command npx (use which npx to get the full path), args paperclipai,run, and --http-port 3100. Wait for it to start and verify the health endpoint at http://localhost:3100/api/health returns ok. Then grep the service logs at /.sprite/logs/services/paperclip.log for the board-claim URL, replace http://localhost:3100 with this Sprite’s URL, and give me the link.

Checkpoint

You’ve got a Paperclip instance with an embedded database, auth, and a live URL. Claude should checkpoint the sprite on its own, but in case it’s having a slow day:

    sprite checkpoint create --comment "Paperclip configured and running" -s paperclip

  

Access It From Anywhere

Your Sprite already has a URL. Check it:

sprite url

That URL, with automatic TLS, is serving your Paperclip dashboard. Open it in a browser, create your account, and start hiring your AI workforce. From your phone if you want.

The first time you hit the UI, Paperclip will ask you to claim the instance and create an admin account. This is the authenticated mode doing its job. After that, anyone who accesses the URL needs to log in.

Want to share it with a teammate?

sprite url update --auth public

That makes the Sprite URL reachable without Fly.io authentication. Paperclip’s own auth layer still protects the dashboard.

Why a Sprite?

Sprites are designed to be the ideal environment for running projects like Paperclip. These are some of the baked in features that make agents way more fun to use in a Sprite.

Checkpoints. So you’ve achieved an inclusive and supportive corporate culture in your robot team, only to have it all go haywire thanks to an unruly new hire or a badly worded prompt? sprite checkpoint restore <id> and the entire environment, database, config, agent state, everything, rolls back in seconds.

Pause/resume. It’s conceivable that some people will build fully autonomous pipelines that run 24/7 in Paperclip, but the rest of us will be issuing instructions and coming back to check on progress when we get a chance. If our agents aren’t doing anything, we don’t want to be paying to run infra. Sprites automatically pause when work isn’t being done and cost next to nothing while asleep.

Isolation without ownership. Each Sprite is hardware-isolated. This is entirely different to container isolation. You can sleep soundly knowing that even if your agents try the dumbest shit imaginable, it will never affect anything outside the Sprite env.

Network Policy

Paperclip agents make HTTP requests. They call APIs, they fetch data, they do things on the internet. If you’re going to run something like this on your local machine, you need to be super careful that those agents don’t have unrestricted access to your entire home network. Every device, every NAS, every printer.

In a Sprite, controlling exactly which domains the agents can reach is simple:

cat /.sprite/policy/network.json

By default, Sprites allow common dev domains (GitHub, npm, Anthropic, etc). You can lock the policy down further from outside the Sprite so that even a compromised agent can’t phone home to somewhere unexpected. DNS resolution returns REFUSED for blocked domains. The agent doesn’t even know the domain exists.

Robots Running Side Hustles

Right, I’m off to surround myself with robots smarter than me and see if that somehow results in me ever shipping a side project.

Put a (smol) Brain in Your Sprite

2026-03-16T00:00:00+00:00

There’s a wave of absurdly efficient local inference engines showing up. Models quantized so aggressively that they run on CPUs, no GPU required, at speeds that are actually usable. Microsoft’s BitNet is one of them: 1.58-bit quantization, ternary weights, optimized SIMD kernels. A 2.4 billion parameter model that fits in 1.1GB of RAM.

So naturally, I needed to see if one of these little guys could achieve something approaching acceptable performance, running on a Sprite. And if it could, how much time could I waste wondering what I could do with a tiny LLM running on a hardware-isolated computer?

Why though?

Sprites spin up with access to frontier models literally one CLI command away. Claude is right there. So why would I want to get a puny little 2B model running locally on a Sprite?

Because a tiny local model on a Sprite is not the same as a tiny local model on your laptop.

Every Sprite already has a URL with TLS. Stand up an HTTP server, register it as a service, and now any other Sprite on your account can call it. Your agent swarm just gained a shared inference endpoint by adding one more Sprite to the fleet. No infrastructure changes, no new dependencies, just another URL.

The Sprite sleeps when nobody’s calling it. A request arrives, the Sprite wakes, the model loads (~1.2 seconds), inference runs, response goes back, Sprite goes back to sleep. That lifecycle doesn’t exist on a VPS. You’re not paying for idle compute between bursts of classification requests at 3am.

Checkpoints are amazing for working with local models

With a local model, the environment is the product. The compiled kernels, the model weights, the server code, the Python deps, it’s all files on disk. A checkpoint captures the entire thing atomically. I can hear you asking who gives a shit, but think about that for a minute.

You have BitNet-2B running and serving requests. You want to try the 3B model. Or a Falcon variant. Or you want to retune the kernel parameters for better throughput. On a normal box, you’d be juggling git branches, backing up model files, praying your venv still works after you upgraded numpy. Here it’s checkpoint create, fuck around, checkpoint restore if it goes wrong. The whole stack, OS deps, compiled binaries, model weights, server code, rolls back together.

Small models are wildly sensitive to prompt formatting. The difference between User: and [INST] can be the difference between coherent output and gibberish. Checkpoint before you start experimenting with chat templates. Try five different formats. Keep the one that works. Restore if you accidentally break the server while hacking on it.

New llama.cpp commit drops with performance improvements? Checkpoint your working state, pull, rebuild. If it breaks, you’re one restore from a working service. This is how you gain the confidence to actually try cool new shit when it emerges, as opposed to living in fear that your whole service will drop dead if you even say update within earshot.

Try it

Head to https://bitnet-llm-beony.sprites.app/chat where you can chat with BitNet-b1.58-2B-4T with a ~200 line Python HTTP server in front of it. No frameworks. The server wraps llama-cli as a subprocess and exposes an OpenAI-compatible API at /v1/chat/completions, a status page at /, and the self-serving client at /client.py. Register it as a Sprite service on port 8080 and the Sprite URL does the rest.

Yeah, the Sprite running the model serves its own client. Hit /client.py and you get a single Python file with the Sprite’s URL baked in. No pip install, no API keys, no config. Any Sprite grabs it with one curl and immediately has ask() and classify() functions that work. The model distributes its own SDK.

Is it crap?

It should come as no surprise that this thing is about as intelligent as a shovel and as well-informed as a child raised by wolves. Nonetheless, for what it is, it’s damn impressive.

Model size on disk: 1.1GB
RAM usage: ~1.3GB total (model + KV cache)
Generation speed: ~50 tokens/sec
Request latency: ~1.4 seconds end-to-end

50 tokens per second on a CPU. That’s not a typo. 1.58-bit quantization is doing real work here.

I grabbed the client from the Sprite and tested it:

    from llm import ask, classify

ask("What is a Sprite in computing?")
# "A sprite in computing is a simple graphical object, such as a
#  character or icon, that is drawn in a single color and occupies
#  a single display area."

classify("the deploy failed with a timeout error", ["bug", "feature", "ops"])
# "bug"

ask("Name three prime numbers under 20.")
# "The prime numbers under 20 are 2, 3, 5, 7, 11, 13, and 17."

  

Coherent. Correct. ~1.4 seconds per response.

Build your own

Tell Claude:

Create a new Sprite. Clone https://github.com/microsoft/BitNet with submodules. Install cmake and libomp-dev. Don’t bother with Conda, just pip install the requirements directly. Install sentencepiece 0.2.1 separately first since the pinned 0.2.0 won’t build on this compiler. Install the local gguf package from 3rdparty/llama.cpp/gguf-py with –no-deps. Run the codegen and compile steps for x8664 with i2s quantization. There’s a const-correctness bug in ggml-bitnet-mad.cpp around line 811 where a non-const pointer is assigned from a const source, fix it. Download the pre-quantized GGUF from microsoft/bitnet-b1.58-2B-4T-gguf instead of converting the model yourself. Verify inference works, then checkpoint.

Then build a Python HTTP server that wraps llama-cli and serves: an OpenAI-compatible chat endpoint at /v1/chat/completions, a status page at / showing model info and usage instructions, a self-addressed Python client at /client.py that uses only stdlib and has the Sprite’s URL baked in, and a chat UI at /chat with a dark monospace theme that keeps conversation history in the browser. Register it as a Sprite service on port 8080. Checkpoint again.

That’s the whole thing. Text classification, structured extraction, triage, routing, anything where a frontier model is overkill and a regex isn’t enough. If you want to get clever, use the local model for the fast cheap stuff and fall back to Claude for anything that needs real reasoning. The OpenAI-compatible API means swapping the endpoint is a one-line change.

1.58 bits per weight. 50 tokens per second. On a CPU. LOL.

Context Engineering Is Just Writing Things Down

2026-02-23T00:00:00+00:00

“Context engineering” is the internet’s new shibboleth. Fine. We’ve had worse. So here’s an argument starter: The only interesting thing about Openclaw is its context engineering. The way it manages and inserts memory into agent context. Yes, this is because I live in a world where everything you need from a computer is just a few prompts away. So no, I don’t think a Slack connector or a WhatsApp bridge is interesting. The memory system is cool though.

People are having fun with SOUL.md because it lets you set a persistent personality and some behavioral traits. MEMORY.md is … memories, and daily logs capture ongoing session context, but these are standard agent equipment. What’s worth a look is how each of these are managed. Daily logs are append-only and decay in relevance over time. They’re noise with signal in it. MEMORY.md doesn’t decay, it only changes when the agent or the user deliberately promotes something into it. One is a stream, the other is curated.

Then there’s memory recall. A hybrid of keyword search (BM25) and vector search, weighted 70/30, with diversity re-ranking so you don’t get five variations of the same result. It finds both exact matches like error codes and conceptual matches like “that thing we discussed about auth.” All backed by local SQLite.

Of course these aren’t revolutionary features, but they serve to make my point. The quality of an agent’s work is far more dependent on how much it knows about your project and its environment than it is about model capability.

This is why we’re working our collective ass off to help Sprites understand how to operate themselves and other Sprites with built-in documentation. Just Tell Claude To Do It covered what comes in the box. But when it comes to your specific Sprite project, these should be considered a starting point.

There are four different ways to make your Sprite better at working on your project:

CLAUDE.md — project conventions, commands, patterns. Claude reads this on every session.
Skills — reusable multi-step workflows that activate by description.
Hooks — scripts that inject live environment state into Claude’s context.
Checkpoints — snapshots that make the whole investment durable.

Used together, these can turn a Sprite that everyone else has into a specialised coding agent environment that knows your project and your workflow inside out. Try this:

The Project

Let’s build an excuse-as-a-service API called Alibi in a Sprite. We want to be able to hit it with “late to standup”, “forgot to review the PR”, “haven’t replied in three days” situations and have it generate a plausible excuse. It’s a Bun + Hono backend with Postgres for storing excuse templates and usage stats. Yes, we’ll open source it.

CLAUDE.md

See Alibi’s CLAUDE.md

CLAUDE.md is read from your project root at the start of every session. Write one before you ask Claude to do anything. Add what you know you want about the project; the stack, the commands, the conventions you care about. Then remember to grow it as you work. Any time Claude uses console.log instead of your logger, or puts tests in the wrong directory, or forgets the auth middleware, tell it to fix it and update CLAUDE.md. By the time Alibi soft launches, my CLAUDE.md has the stack, the commands, the migration naming scheme, the error response format, the logging convention, and a note about where test files go.

Skills for Repeated Workflows

See Alibi’s preflight skill

CLAUDE.md is not for multi-step processes you run repeatedly. That’s where I wanna use Skills.

In preparation for the millions of users that Alibi will have, I want a robust preflight check before every PR. Tell Claude:

Write a Claude Code skill called “preflight” that runs tests, type checking, linting, and checks for leftover TODOs, in that order. Stop at the first failure.

Yeah I could just say this every time, but I’ll probably describe it differently every time and give Claude an excuse to screw it up. With a skill at ~/.claude/skills/preflight/SKILL.md, I just say run preflights. Done.

Hooks for Things You Forget

See Alibi’s environment hook and git state hook

Use hooks to inject anything you want Claude to know about the state of the environment right now.

Try a Sprite environment hook that warns Claude about crashed services and stale checkpoints, and/or a git state hook that feeds branch, uncommitted changes, and ahead/behind status into context.

Hooks are how you stop Claude from building inside a windowless house. No more explaining environment errors it should already know about. No more soul-destroying moments where Claude says “Alibi is live!” when Postgres has been dead for ten minutes.

Checkpoint the Investment

See Alibi’s hook config

Claude should already be checkpointing automatically because the Sprite docs tell it to. If it’s not, tell it to. Sternly. A checkpointed Sprite is a safe place of work. Everything you’ve built; the CLAUDE.md, the skills, the hooks, the installed dependencies, the running Postgres service, the very project itself, is on the Sprite’s filesystem.

This is the part you don’t get on your laptop. This stuff is scattered across your machine and easy to lose. In a Sprite, it’s all environment state. This is the quiet joy of the humble checkpoint.

The Payoff

A week from now, a user from Yakutsk reports that excuse generation is returning duplicates when their category has fewer than ten templates. I open my Sprite, start Claude, and say:

There’s a bug where excuse generation returns duplicates when a category has fewer templates than the requested count. Investigate and fix.

Claude checks the git state hook: Clean working tree, on main. It reads the service logs. It finds the query in src/services/generator.ts, spots the issue (sampling with replacement instead of without), fixes it, writes a regression test next to the source file using bun test, runs the suite, and checkpoints.

It used the right test runner. It put the test in the right place. It logged with pino. It followed the error response format. It checkpointed. I said none of that. The context layer did.

Look mom, I’m a context engineer! No mom, I didn’t even need a vector database or a RAG pipeline or some token-bingeing memory flush before compaction. Just files on disk, curated from real use, in an environment where they persist.

Agent Swarms on Sprites

2026-02-09T00:00:00+00:00

There’s a lot of noise right now about agent teams and swarms. The idea is simple: instead of one code agent grinding through a task list, set up a group of agents that can split work, delegate, and check each other’s output. It works. Multiple agents in parallel genuinely get more done.

The part that nobody has a great answer for is the environment. Where do these agents actually run? Most setups put them all on the same machine; same filesystem, same network, same blast radius. Agent A installs Node 23, Agent B needs Node 20. Two agents write to the same file. One runs pip install sketchy-package and now everyone’s environment is different.

An agent swarm on Sprites comes with some handy capabilities. Full machine isolation per agent, checkpoints that let you roll back any agent independently, per-agent network policies, and persistence that survives you closing your laptop.

One Agent, One Sprite

When each agent lives in its own computer, agent teams work more like human teams. Everyone has their own desk. They can install whatever they need, make a mess, try things — without touching anyone else’s work. The orchestrator hands out assignments and collects results. No shared state to babysit.

All you need is a Sprites API token (create one at sprites.dev/account/{your-org}/tokens) and Claude Code on the orchestrator.

Prompt:

Create a new Sprite called “researcher”. When it’s ready, open a console and tell Claude to read the codebase at /home/sprite/myproject and write a summary of the architecture to /home/sprite/output/architecture.md. Use --dangerously-skip-permissions so it can work autonomously.

The orchestrator Sprite creates the worker, gives it a task, and moves on. The worker does its thing independently. The orchestrator can check in later, read the output, or wait for the worker to finish.

Checkpoints Are Your Undo Button

Every Sprite has checkpointing built in. Claude inside a worker Sprite can checkpoint its own environment before doing anything risky — and the orchestrator can tell workers to do this as part of the task prompt. No human needs to be in the loop.

An agent refactors half the codebase, installs new dependencies, rewrites the database schema. If the result is garbage, restore the checkpoint. Three seconds later the Sprite is back to exactly where it was — not just the code, the whole environment.

This makes speculative execution practical. Tell the orchestrator to spin up three workers, have each one checkpoint, then attempt a different approach to the same problem. Pick the winner, restore or destroy the rest.

Network Policy Per Agent

Every Sprite has its own network policy. The orchestrator can lock down each worker to only the domains it actually needs. Denied domains return REFUSED at the DNS level — fast-fail, no silent failures, no data going somewhere you didn’t intend.

Communication Between Agents

Workers are isolated, but they still need to share results. A few patterns:

HTTP endpoints. Every Sprite has a URL. A worker can serve its results on port 8080 and the orchestrator fetches them. Good for structured output — JSON reports, test results, generated files.

Shared database. Spin up a Postgres Sprite. Give every worker network access to it. Workers write results to tables. Orchestrator queries. Good when agents need to build on each other’s findings.

Orchestrator as relay. Workers write output to a local file. Orchestrator opens a console to each worker and reads the file. Simple, no extra infrastructure. Good enough for most cases.

Persistence for Free

Sprites don’t die when you close your laptop. They pause when idle and wake on demand. The orchestrator, the workers, the checkpoints — all still there when you come back.

Start the swarm, close your laptop, come back later. Everything is exactly where you left it.

Bonus level: Checkpoint your orchestrator Sprite after it’s set up with the API token and your standard prompts. Now you can restore to a ready-to-swarm state in three seconds whenever you need a fresh team.

Closing the Loop: The Missing Ingredient in Agentic Development

2026-02-05T00:00:00+00:00

Remember when coding with AI meant copying code from a chat window, pasting it into your editor, running it, copying the error, pasting it back into the chat, etc. Yeah that sucked. We were middleware.

Now we have agents that can read and write inside our code bases, which makes them feel a lot more like legit tools. But answering Claude’s permission checks 150 times a session is the new copy/pasting from chat. It’s annoying.

Working with a code agent in a Sprite feels like the next step. In a Sprite, the answer to “can I try this” is always yes. Install dependencies, start servers, hit endpoints, run browsers, just do it and let me know when it’s working.

Thing is, if you want the joy of watching a code agent nail even complex builds regularly, it needs to be able to “see” what it has built, test its work and troubleshoot issues without needing your feedback. This is exactly why Sprites come with test and observability tooling preinstalled.

Closing the Loop

Code agents have gotten pretty good at testing their own output, trying different approaches and iterating. And with access to the right tools, a completely agent-driven build>test>ship pipeline is entirely possible. But it would be insane to prompt your agent, give it the “yes to all” freedom it needs and go to bed. If its running on your laptop that is.

In a Sprite, the agent is working inside a fully hardware-isolated computer. It doesn’t need guardrails or baby proofing of any kind. But it also gains powers it could never have on your laptop. Service logs at known paths. Checkpoint-based rollback that the agent knows how to use. An HTTP URL that’s live the moment a server starts.

The result is a tight loop: the agent writes code, starts a service, hits the endpoint, sees what’s wrong, fixes it, and tries again. No permission prompts, no asking you to check something, no guessing.

The Tools Are Already in Your Sprite

Most of what your agent needs to operate like this is already installed in your Sprite. It also contains files like /.sprite/llm.txt and /.sprite/docs/agent-context.md that exist to help your agent understand its environment and the tools available to it.

One super powerful tool that doesn’t (currently) come preinstalled is Playwright.

Browser Automation

Installing Playwright on your Sprite is two commands; npm install playwright and npx playwright install chromium. It can write tests, run them, screenshot pages, and inspect what’s actually rendering instead of assuming its HTML is correct. This is the difference between an agent that writes a login form and one that writes a login form, tries to log in, and fixes the broken redirect.

With Playwright installed, if your agent starts trying to reinvent the wheel tell it to stop being dense, read its knowledge base and make better choices. Here are some of the tools your agent already has in a Sprite, in case it starts acting the fool.

API Testing

curl, jq, and httpx are all preinstalled. The agent builds an endpoint, hits it, sees the actual response, and fixes what’s wrong. No relay through you.

Database Inspection

sqlite3 is preinstalled. The agent writes a migration, runs it, queries the result, sees the missing column, fixes it. If you need Postgres, it’s an apt-get install away.

Test Runners

Every language runtime in a Sprite ships with a built-in test runner — node --test, pytest, go test, cargo test. The agent writes code, runs tests, reads failures, fixes them. This is the most basic closed loop and it works out of the box.

Service Logs

Sprite services write logs to /.sprite/logs/services/. The agent starts a service, tails the logs, sees the stack trace, and knows exactly what to fix. No asking you “what does the console say?”

Network Debugging

ss, dig, and curl -v are preinstalled. When something isn’t connecting, the agent can check what’s listening, whether a domain resolves, and what’s actually happening on the wire.

Checkpoints

This is unique to Sprites. The agent can snapshot the entire environment before trying something risky, and roll back in seconds if it goes sideways. This makes aggressive experimentation cheap.

Sprite On

You’re not middleware, you’re the idea guy. And you don’t need a smarter model. Just a smarter environment.

I Build Everything In Sprites Now

2026-02-03T00:00:00+00:00

I just realised I build everything in Sprites now. It feels weird to say because Sprites are still really new (even for people who work at Fly.io). They’re obviously super exciting for people building agents, but when I finally “got” Sprites, it pretty much instantly felt weird to build anything anywhere else.

If, like me, you have to flit between many projects every day - because breaking only one thing a day is lazy - you’ll know that local development is a joke.

Let me pause what I’m working on to fix this tiny bug over on this other project! Wrong Node version. asdf local nodejs 18.17.0. Oh wait, this project uses nvm. Fine. nvm use. No .nvmrc file. Check the README. Last updated in 1996. Check package.json engines field. Install that version. Now the wrong packages are installed. Ah, productivity.

Oh of course, the wrong database is running. Start Postgres. Wait, this project uses MySQL. Stop Postgres, start MySQL. Except the other project’s MySQL data is still there. Where’s the docker-compose for this one?

Ah I have screwy environment variables, let me just update the … wait is it .env, .env.local, .env.development, .env.example, env.thisone? This project needs API_KEY set but that collides with the other project’s API_KEY which points somewhere else. Swear I have a .env.projectname file somewhere. Maybe. Which shell session has the right exports?

Yes! It’s running! Wait what was I doing again?

No. Just No.

Now every project I’m working on is in its own Sprite. It feels like having a different computer for every project because that’s exactly what it is. Every Sprite is a persistent, fully hardware isolated linux computer with 100gb storage that only costs anything when it’s actually doing something. I can have 30 projects in 30 Sprites and I’m only ever paying for the one I’m currently working on.

sprite create dashboard
sprite create api-backend
sprite create billion-dollar-side-project

Each one has its own versions, its own services, its own env vars, its own ports. Nothing collides because nothing is shared.

Waking Is Instant

Impatient? Me too! Sprites wake in a few seconds.

sprite console -s api-backend

If the api-backend Sprite is paused, it wakes up. Services come back up. I’m in the project, ready to work.

Let me hop into sprite console -s dashboard on another terminla quickly. Look at that, it just works. Prompt Claude in both Sprites, feel like Tony Stark

I couldn’t care less if I forget about a Sprite I was working in. It puts itself to sleep when its inactive, but nothing about its state changes. Next time I open a console, it’s exactly where I left it.

Real URLs, Not Localhost

Every Sprite has its own URL with automatic TLS. Run your dev server on port 8080 and it’s just… there. On the internet. With HTTPS.

No ngrok. No “can you see my screen?” No tunneling. OAuth callbacks just work. Webhooks just work. That API integration that refuses to talk to localhost? It just works.

Need to show someone what you’re working on? Send them the URL. They see exactly what you see, in exactly the state it’s in. Checkpoint first if you want to freeze it there.

Checkpoints Are the Whole Environment

Git is to checkpoints what World Series MLB is to the World Cup. Your code might be version controlled in Github, but what about … everything else? A checkpoint in a Sprite is a snapshot of the entire environment. Node_modules, database state, running services, env vars, the whole shebang

sprite checkpoint create

Wanna see if upgrading to Node 23 breaks everything? Do it! And laugh when it happens. Wait … you did checkpoint right?

Wanna tell Claude to go wild on an ambitious refactor just before you go to bed? Nighty night.

sprite checkpoint restore abc123

Git branches for experiments are so 2025.

Specialist Claudes > One Very Confused Claude

I like to tell Claude to build a good knowledge base from project files and any other documentation I can find as a first step when I recruit it’s help on a project. A good claude.md and some project-specific skills completely change the game when it comes to how effective a coding agent can be in a given project.

That’s why I want specialist Claudes. One per project. I don’t want the context polluted or diluted by work on any other project.

What if I build a skill in one Sprite that I want in all my others? I tell Claude in that Sprite to use the Sprites API to propagate that skill to all my other project Sprites.

OK Article done.

sprite checkpoint create

Run Any Code Fearlessly

2026-02-02T00:00:00+00:00

AI generates code faster than you can review it. Your agent wants to run a Python script. Your tool wants to execute user-submitted code. Your pipeline wants to test generated functions. All things you don’t want to be running locally or in production unless you’re just trying to add some drama to your life right now.

If you want to walk the path of peace, you use a sandbox. But as any kindergartener will tell you: not all sandboxes are created equal.

The Container Problem

The default for the longest time has been “spin up a container.” This is safer than running dodgy code on your machine. It’s also not good enough.

Containers share the host kernel. A kernel exploit in your untrusted code == emotional trauma. NIST SP 800-190 calls container escapes one of the most critical threats to container security. MITRE ATT&CK classifies it as technique T1611. The threat is real.

Truly untrusted code needs hardware isolation. A dedicated kernel. A non-fictional boundary between the code and everything else.

The Network Problem

Filesystem isolation helps, but code that can’t touch your files can still:

Exfiltrate data to an attacker’s server
Download additional payloads
Call out to command-and-control infrastructure
Use your compute. Which isn’t free

Network egress control should not be considered optional. The code needs to run in an environment where outbound connections are explicitly allowed, not implicitly permitted.

What You Really Need From a Sandbox

Hardware isolation
Network control — allowlist-based, not denylist-based
External policy enforcement — the code can’t modify its own permissions
Rollback capability — undo damage quickly when something goes wrong
Multiple runtimes — AI writes Python, JavaScript, Rust, Go, whatever

Spin up and configure your sandboxes with these features and you should be safe.

Or just use Sprites.

Setting Up a Code Runner in a Sprite

Create a Sprite for running untrusted code.

sprite create code-runner

Then, lock down its network:

    curl -X POST https://api.sprites.dev/v1/sprites/{sprite-id}/policy/network \
  -H "Authorization: Bearer $SPRITES_API_TOKEN" \
  -d '{"rules": [{"domain": "*", "action": "deny"}]}'

  

This is a deny-all policy. The code inside cannot make any outbound connections. DNS queries return REFUSED. Raw IP connections are blocked.

What’s super important is that this policy is set via the external API. Code running inside the Sprite cannot change it. Even if the code has root access, it cannot modify its own network policy.

Running Code

Proceed to laugh in the face of danger:

    # runner.py - runs inside the Sprite
import subprocess
import sys

def run_untrusted(code: str, language: str = "python") -> dict:
    """Execute code and capture output."""

    if language == "python":
        result = subprocess.run(
            ["python", "-c", code],
            capture_output=True,
            text=True,
            timeout=30
        )
    elif language == "node":
        result = subprocess.run(
            ["node", "-e", code],
            capture_output=True,
            text=True,
            timeout=30
        )
    # Add other languages as needed

    return {
        "stdout": result.stdout,
        "stderr": result.stderr,
        "returncode": result.returncode
    }

  

Expose this as an HTTP endpoint on port 8080. Another Sprite acting as an orchestrator, or any external service can call this with code to execute.

Selective Network Access

Sometimes code needs some network access. An AI agent writing code that calls an API. A script that needs to fetch data from a specific endpoint.

Allow only what’s needed:

    curl -X POST https://api.sprites.dev/v1/sprites/{sprite-id}/policy/network \
  -H "Authorization: Bearer $SPRITES_API_TOKEN" \
  -d '{
    "rules": [
      {"domain": "api.openai.com", "action": "allow"},
      {"domain": "api.anthropic.com", "action": "allow"},
      {"domain": "*", "action": "deny"}
    ]
  }'

  

Now the code can call OpenAI and Anthropic. Nothing else. Can’t exfiltrate to gimmeallyourdata.com. Can’t download from sketchy-cdn.net.

When Code Breaks the Sandbox

In the entirely unsurprising case that something does blow up; the code did something weird to the filesystem, filled the disk, corrupted something.

Sprites are disposable. Just sprite destroy it and spin up a fresh one. Problem solved.

Or, if you’re running lots of code and want to reuse the same Sprite for efficiency, checkpoint your working state

sprite checkpoint create

Then restore to that working state in about a second:

sprite checkpoint restore <working-checkpoint-id>

Runtimes Are Already There

Sprites come with Python, Node, Ruby, Rust, Go, Java, Elixir, Bun, and Deno pre-installed. Version managers let you switch between versions. Your code runner doesn’t need to install anything. Just execute.

Sprites sleep when idle and wake on demand. Your code runner costs nothing when it’s not running code.

Run whatever you want. Dare it try any funny business.

Make Computers Make Computers

2026-01-28T00:00:00+00:00

What’s better than one Sprite?. Sprites making other Sprites.

Claude (running in a Sprite) already knows how to use the Sprites API. So you can ask it to create new Sprites, configure their network policies, hit their HTTP endpoints etc.

To authorise one Sprite to control others, you’ll need to visit to sprites.dev/account/{your-org} and create a token. Then tell Claude to use it to authorise it’s Sprite.

Here are a few of ways that the Fly team is already using this capability on the daily:

Central Auth for Everything

A Sprite that handles OAuth flows for other Sprites.

Say you have five Sprites that all need to talk to GitHub, Slack, or some other OAuth-protected service. Each one needs tokens. Managing that across five separate environments is annoying.

Make an Auth Sprite do it for you instead. Workers call the Auth Sprite when they need a token. The Auth Sprite refreshes tokens, handles redirects and stores creds in one place.

Traditional CI runs tests in containers that share… something. A docker daemon. A cache directory. A network namespace.

With Sprites, each test run gets its own actual computer. Tell your orchestrator Sprite to spin up a worker for each test file, lock down its network to just what it needs (pypi, github), run the test, collect results, done.

Each test runs in full isolation. Nothing is shared. One flaky test can’t poison another.

Preview Environments Per PR

Every pull request gets its own Sprite. Reviewers hit a real URL with a real running app.

The orchestrator watches GitHub webhooks:

PR opened → spin up a Sprite, deploy the branch, comment the URL
PR updated → redeploy to the same Sprite
PR merged/closed → destroy the Sprite

No resource contention between PRs. No “sorry, all the preview slots are taken.” No shared database bleeding state between reviews.

Agent Delegation

You have an AI agent that’s good at planning but you don’t want it directly touching production. Or you have specialized agents; one that’s great at frontend work, another that knows your database schema cold.

The manager agent runs in one Sprite. It breaks down tasks and delegates to worker agents in their own Sprites:

Each worker has network policy locked down to only what it needs. The React agent can hit npm but not your production database. The DB agent can hit Postgres but not the internet.

Running Untrusted Code

Someone (or something) gives you code. You need to run it. Fear increases.

Tell Claude in a Sprite to create a worker with a deny-all network policy. The worker can’t talk to anything. Run the untrusted code. Grab the output. sprite destroy it if it does something scary.

The code can’t phone home, can’t exfiltrate data, can’t crypto-mine on your dime.

Team Provisioning

New developer joins. They need a Sprite with your standard tooling, your repos cloned, your services configured.

One “provisioner” Sprite has a script that:

Creates a new Sprite
Configures its network policy for your internal services
Clones your repos
Installs your standard dependencies
Creates a checkpoint (so they can always restore to “fresh”)
Sends them the URL

Onboarding is one API call.

Bonus Level

Add checkpoints to these workflows. Your controller can checkpoint a functioning worker, then restore to that checkpoint before each job. Immutable infrastructure, but fast.

Slack Bots on Sprites: OAuth is Easy Now

2026-01-27T00:00:00+00:00

Slack bots are handy, but they typically require OAuth, which means you need a server with a public URL to handle callbacks. This is annoying. But with Sprites, you get an instant internet-accessible environment with a persistent filesystem that makes it trivial.

OAuth Pain

Getting your Slack bot working involves jumping through these OAuth hurdles:

Create an endpoint to receive Slack’s authorization callback
Get that endpoint online with a public URL
Securely store tokens after the callback
Maintain those tokens across restarts

This requires deploying something to a host, setting up Ngrok and implementing a storage solution for tokens.

Slack Bot Sprites

Create a Sprite for your bot:

sprite create slack-bot
sprite console -s slack-bot

Install your dependencies:

npm init -y
npm install @slack/bolt express

Build an OAuth Handler

Now we need a server that:

Handles the OAuth callback from Slack
Stores access tokens to the filesystem
Loads those tokens when the server restarts
Implements your bot’s functionality

Ask your code assistant to: “Create a server.js file that handles Slack OAuth callbacks using the Bolt framework, stores tokens to the filesystem, and implements a simple slash command. The server should run on port 8080.”

Register Your Slack Bot as a Sprite Service

Sprites don’t use systemd or traditional init systems. Instead, they have their own service manager that enables the Sprite’s automatic sleep/wake behavior.

So you’ll want to register your bot as a service with the HTTP port flag:

    sprite-env services create --name slack-bot --cmd "node server.js" --http_port 8080

  

This does three critical things:

Auto-start on HTTP requests: When a request hits your Sprite URL, the Sprite wakes from hibernation
Auto-route requests: The Sprite proxy routes incoming traffic to your specified port (8080)
Persistent registration: Your service registration survives Sprite restarts and hibernation

When idle, your Sprite hibernates to save costs and wakes in under a second when Slack sends events or users visit the install URL.

Get Your Public URL

sprite url update --auth public -s slack-bot

Configure Your Slack App

The rest is standard Slack stuff:

Visit https://api.slack.com/apps
Create a new app
Under “OAuth & Permissions”, add your Sprite’s URL
Copy your Client ID and Client Secret
Set them as environment variables in your Sprite:

    sprite-env env set SLACK_CLIENT_ID=your_client_id
sprite-env env set SLACK_CLIENT_SECRET=your_client_secret
sprite-env env set SLACK_SIGNING_SECRET=your_signing_secret

  

Install Your Bot

Visit: https://your-slack-bot.sprites.app/slack/install

This triggers the OAuth flow. Slack redirects back to your Sprite, which handles the callback and stores the token in its filesystem.

Checkpoint Your Working Setup

Once everything is working, create a checkpoint:

sprite checkpoint create

A Sprite checkpoint is a snapshot of the entire environment, not just your code. So if/when you break your bot, just:

sprite restore <checkpoint-id>`

More Time for Cheeky Slack Messages

Building a Slack bot in a Sprite means no longer having to:

Set up and maintain the server
Configure networking and SSL
Implement your own hibernation/wake logic (or pay for idle time)
Handle security updates and monitoring

Instead, write your bot, deploy it, forget about it. The Sprite wakes up when Slack calls, sleeps when it doesn’t, and you only pay for the moments it’s actually working.

Run Moltbot (Clawdbot) in a Sprite

2026-01-26T00:00:00+00:00

Running Moltbot on a Sprite

There’s zero chance this will be the first time you’re hearing about Clawdbot, recently renamed Moltbot. It’s an open-source AI assistant that connects to messaging platforms you’re probably already use: WhatsApp, Telegram, Slack, Discord, Signal, etc. It comes with a fast-growing list of connectors and Skills and self-iterating capabilities, right out of the box.

If you really want to see what a project like Moltbot can do, you need to run it with generous permissions and give it access to its environment. That is inherently scary, which is why so many people have been snapping up Mac Minis to run their Moltbot in an isolated environment.

You don’t need a Mac Mini. Instead, let’s learn how to run Moltbot in a Sprite. A stateful sandbox with automatic sleep/wake behaviour that keeps running costs low. Sprites are fully hardware isolated Linux computers, so you can give Moltbot total agency and not even have to think about building your own guardrails.

Create a Sprite

Install the Sprites CLI and create a Sprite:

curl -fsSL https://sprites.dev/install.sh | bash
sprite create moltbot

Connect to the Sprite console:

sprite console -s moltbot

Install and Configure Moltbot

Run the Moltbot install script:

curl -fsSL https://molt.bot/install.sh | bash

The wizard will configure your credentials, hooks, and messaging platforms. You’ll see two expected errors at the end:

Systemd unavailable — Sprites don’t use systemd

Health check failed — The Gateway isn’t running yet

This is normal. The onboarding creates your config. We’ll start the Gateway next.

Important: Copy the token shown in Moltbot’s output. It looks like:

9054a0cfca3f5be5325f988fb57ddf1f38e530d2883bbed7

Add moltbot to your PATH so it’s available in future sessions:

    echo 'export PATH="$PATH:/.sprite/languages/node/nvm/versions/node/v22.20.0/bin"' >> ~/.zshrc
source ~/.zshrc

Register Moltbot as a Sprite Service

Sprites have their own service manager that auto-starts services when HTTP requests arrive. Register the Gateway:

     sprite-env services create moltbot-gateway \
    --cmd "$(which clawdbot)" \
    --args "gateway" \
    --http-port 18789

  

Note: The Moltbot CLI still installs as clawdbot, but its docs have already been updated to use "moltbot" commands. You can create a symlink after installing so that docs are easier to follow.

This registers the Gateway and routes your Sprite URL to port 18789. When requests hit your Sprite URL, the Sprite wakes and the Gateway starts automatically.

Make the URL Public (Optional)

By default, Sprite URLs require authentication. To make yours public and get the url:

sprite url update --auth public -s moltbot

Access the Dashboard

For initial setup, access your Sprite URL + the token from onboarding:

https://yoursprite.sprites.app/?token=YOUR_TOKEN_HERE

You’ll see a “pairing required” message. This is Moltbot’s security. It requires you to approve new devices before they can connect.

## Approve Your Device

Back in the Sprite console, list pending pairing requests:

moltbot devices list

Approve the pending request:

moltbot devices approve REQUEST_ID

Refresh your browser. You’re in.

Checkpoint Your Setup

Checkpoint your working configuration:

sprite checkpoint create

If you ever need to return to this state:

sprite restore <id>

What You’ve Built

Your Moltbot Gateway now lives on a Sprite that:

Sleeps when idle
Wakes automatically when you hit the URL
Restarts the Gateway service on wake
Persists your config and pairing across restarts

Once paired, you can access the dashboard and start chatting with Moltbot. It’s not bad at understanding its own capabilities, so just ask for the integrations and channels you want to set up.

Bonus Level:

Tell Moltbot to build a Sprites Skill for itself, so it knows how to manage its own environment:

Create a Sprite skill by reading the documentation at /.sprite/llm.txt and /.sprite/docs/agent-context.md. The skill should teach you how to manage Sprite services (since there’s no systemd), create checkpoints, restart the moltbot-gateway, and check network policy. Save it to ~/.moltbot/skills/sprite/SKILL.md.

How Sprites Accidentally Solved Mobile Development

2026-01-21T00:00:00+00:00

A few days ago, this post hit HN’s front page and generated over 400 comments. The author is talking about the setup he uses to code from his phone using Tailscale, an always-on Mac at home, SSH via Termius, and Claude Code in the terminal.

If you’re asking why anyone would want to code from their phone, you can safely stop reading now and return to a peaceful existence, where ideas only come to you when you’re sitting behind a computer. For those familiar with the need to try an idea right now, wherever you are, whatever you’re doing, you’re in the right place.

What Was and Need No Longer Be

The HN post’s comments section showed off some genuinely impressive mobile coding setups that range from the creative to the absurdly over-engineered. Tmux sessions, VPS boxes, all the SSH clients, and a million ways to access these env’s from your phone.

For a lot of people, designing setups like this is fun. But if managing always-on servers and VPN configurations is less exciting to you than building an app in real time while brainstorming it on a hiking trail, there’s a better way. We call ‘em Sprites.

What’s a Sprite Again?

The correct answer is: Whatever you want it to be. But that isn’t super helpful in this context. So let’s start with the idea of a Sprite as the server in your mobile coding setup. Instead of running a machine 24/7 or starting and stopping a VM, use a Sprite. It’s a full Linux computer that spins up in under a second and runs only when you need it.

Your code, installed packages, and project state persist between sessions, even when the Sprite is suspended. You (or Claude) can checkpoint your Sprite at any time, which creates a restorable snapshot of the entire environment, not just your code. And since it’s a hardware-isolated computer rather than a shared container, you can run literally any code and experiment aggressively, while genuinely just not caring about breaking anything important.

If you want to unleash your code assistant, give it full file system access and tell it to build that genius app idea that occurs to you at 3am without getting out of bed, you wanna do that in a Sprite.

But wait, how are you doing this from your phone?

Sleep Is For the Weak

We are blessed with multiple really smart guys called Chris at Fly.io. And one of them, a Christopher actually, has built a - dare I say - elegant way for you to issue orders to Claude in a Sprite from your phone. The aptly named sprite-mobile, a chat UI for accessing Claude Code running in YOLO mode on a sprite.

Here’s how to set it up:

Create a Sprite

sprite create cheese_sandwich

Download and run the Sprite-mobile install script

curl -fsSL https://raw.githubusercontent.com/clouvet/sprite-mobile/refs/heads/main/scripts/sprite-setup.sh -o sprite-setup.sh && chmod +x sprite-setup.sh && ./sprite-setup.sh

I shit you not. That is it.

The script will speedrun you through everything needed to get up and running:

Configure your sprite and git user
Authenticate Claude CLI, GitHub CLI, Fly.io CLI, Sprites CLI
Install and configure Tailscale
Clone and run sprite-mobile and configure a Tailscale-based Sprite network (if you want automatic discovery of other sprites in your org)
Set up Tailscale Serve (HTTPS for PWA support)
Start the Tailnet Gate (public entry point to wake up the sprite if it’s suspended)

To access this Claude-powered dev sandbox you just spun up in the same time it takes to make a midnight cheese sandwich, you’ll want to get its public url:

sprite url update --auth public -s cheese_sandwich

Drop that in your Tailscale-connected phone’s browser and you’re cooking.

Your Sprites automatically go to sleep after 30s of inactivity and wake up faster than a cat when you open a can of tuna a mile away (sub 1s). And you only pay for the resources your Sprites are actively using. Got 30 projects in 30 Sprites waiting for you to decide when you’re interested in them again? Cool. No charge.

Why are you still here? Check out the full details in the sprite-mobile repo and read more about Sprites at sprites.dev.