mrkurt

You will be astonished to know it'a a whole lot of sqlite.

Everything I want to pay attention to gets a token, the server goes and looks for stuff in the api, and seeds local sqlites. If possible, it listens for webhooks to stay fresh.

Mostly the interface is Claude code. I have a web view that gives me some idea of volume, and then I just chat at Claude code to have it see what's going on. It does this by querying and cross referencing sqlite dbs.

I will have claude code send/post a response for me, but I still write them like a meatsack.

It's effectively: long lived HTTP server, sqlite, and then Claude skills for scripts that help it consistently do things based on my awful typing.

All the time with a bunch of different sandboxes.

This is, in fact, the biggest problem to solve with any kind of compute platform. And when you suddenly launch things really, really fast, it gets harder.

For what it's worth, I do this from about 50 different IPs and have had no issues. I think their heuristics are more about confirming "a human is driving this" and rejecting "this is something abusing tokens for API access".

Sandboxes with the right persistence and http routing make excellent dev servers. I have about a million dev servers I just use from whatever computer / phone I happen to be using.

It's really useful to just turn a computer on, use a disk, and then plop its url in the browser.

I currently do one computer per project. I don't even put them in git anymore. I have an MDM server running to manage my kids' phones, a "help me reply to all the people" computer that reads everything I'm supposed to read, a dumb game I play with my son, a family todo list no one uses but me, etc, etc.

Immediate computers have made side projects a lot more fun again. And the nice thing is, they cost nothing when I forget about them.

Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?..

Yes.

They won't horizontally scale. They're pretty good for hosting my side projects! Not good for, eg, hosting the API that orchestrates Sprites.

It backs its metadata up to S3. You do need metadata to map inodes / slices / chunks to s3 objects, though.

Tigris has a one-to-one FUSE that does what you want: https://github.com/tigrisdata/tigrisfs

Shell environments are by far the most difficult part of building a stateful sandbox with checkpoints and restores. It's bananas. This will be fixed soon.

FUSE is full of gotchas. I wouldn't replace NFS with JuiceFS for arbitrary workloads. Getting the full FUSE set implemented is not easy -- you can't use sqlite on JuiceFS, for example.

The meta store is a bottleneck too. For a shared mount, you've got a bunch of clients sharing a metadata store that lives in the cloud somewhere. They do a lot of aggressive metadata caching. It's still surprisingly slow at times.

`cat file.txt | sprite exec -s <name> bash -c "cat > ~/file.txt"` is my go to.

It's tiered, they have local nvme that gets written back to object storage.

npm install hasn't bothered me, but I know of people with massive npm issues that would like faster first installs. Fortunately, it's incrementally quicker after that.

The storage performs pretty well for running claude + my dev. It'll improve immensely in the next few months, though. We should be able to get near native NVMe speeds for the working storage set on reads/writes/flush/fua.

Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.

For what it's worth, CPU pricing is based on CPU util. A sprite sitting idle CPU costs almost nothing, even when "active".

Good point about quietly grabbing env vars, we can warn about that on first run. All it's getting are these:

  var envVars []string
    shellEnvVars := []string{
    "BASH_VERSION",
    "ZSH_VERSION",
    "FISH_VERSION",
    "KSH_VERSION",
    "tcsh",
    "SHELL",
  }

If you want to skip this, running `sprite exec -tty /bin/bash --login` or similar avoids the magic.

This is on the roadmap. The open question right now is if we can just do "fork from checkpoint" for customized template environments, or if we need all the docker infrastructure.

If the fat bundled environment harmful for you, or just extra stuff you don't care about?

flyctl is complicated and, unfortunately, needs pretty aggressive auto updates. The sprite CLI should be much better in this respect.

Believe it or not, that's the only example that's not autogenerated from tests (yet).

https://github.com/superfly/sprites-js/tree/main/examples https://github.com/superfly/sprites-go/tree/main/examples https://github.com/superfly/sprites-py/tree/main/examples https://github.com/superfly/sprites-ex/tree/main/examples

I have a Sprite with an auth token to an isolated Sprite org, it works really well for this.

SQLite works great for my apps. I haven't needed object storage yet, storing files on disk is enough.

It stays awake if you have an open connection (like sprite console) or an exec session if running and producing stdout.

You can specify a max exec time for a process when you launch it via the API.

Intended typo so you can see restore happen ;)

If you `sprite console` to it, it'll forward any ports you open to localhost. You can tunnel almost everything through the CLI with the `sprite proxy` command.

sprite url update --auth public

It requires your api token by default.

Claude Code is an obfuscated javascript app. You can point Claude Code at it's own package and it will pretty reliably tell you how it works.

I think Claude Code's magic is that Anthropic is happy to burn tokens. The loop itself is not all that interesting.

What is interesting is how they manage the context window over a long chat. And I think a fair amount of that is serverside.

I am confused. Are we not supposed to pay zoomers.

Please don't encourage him.

dm-cache writeback mode is both amazing and terrifying. It reorders writes, so not only do you lose data if the cache fails, you probably just corrupted the entire backing disk.

Some of the best content marketing I've ever read. More please.

We don't do any model training, and only use existing open source or hosted models. Code gets sent to those providers in context windows. They all promise not to train on it, so far.

It's safe to say that if either Chris or I believed this to be anti worker, we wouldn't be working on it. He's spent the last 10+ years working on Phoenix specifically to improve the lives of the people doing the work.

My experience with software development is maybe different than yours. There's a massive amount of not-yet-built software that can improve peoples' lives, even in teeny tiny ways. Like 99.999% of what should exist, doesn't.

Building things faster with LLMs makes me more capable. It (so far) has not taken work away from the people I work with. It has made them more capable. We can all build better tools, and faster than we did 12 months ago.

Automation is disruptive to peoples' lives. I get that. It decreases the value of some hard earned skills. Developer automation, in my life at least, has also increased the value of other peoples' skills. I don't believe it's anti worker to build more tools for builders.

If we try really hard, I think we can make an exhaustive list of what viral fads on the internet are not. You made a small start.

none of these ephemeral fads are any indication of quality, longevity, legitimacy, interest, substance, endurance, prestige, relevance, credibility, allure, staying-power, refinement, or depth.