Permacomputing Microstudio

Hundred Rabbits sail a boat and write software on it. Solar-powered. Unreliable internet. 51-day ocean crossings. Everything they build has to survive those conditions.

I don't live on a boat. But the constraints they design for — offline capability, low power, no vendor dependencies — produce better software for everyone. When your tools work on a sailboat, they work everywhere else too.

The dependency audit

Disconnect your wifi and try to work. What breaks?

For most developers: everything. Copilot stops suggesting. Cloud IDE won't load. Documentation requires a browser. The Slack thread with context from yesterday is unreachable. Your skills, the ones you thought were yours, turn out to be rented.

100 Rabbits learned this the hard way. Xcode demanded an 11GB update mid-Pacific. Photoshop locked up because it couldn't verify a subscription. Games they'd paid for stopped working after three years. The tools they'd invested in learning became tools someone else controlled.

Their response: build a 32-opcode virtual machine that fits on a t-shirt. Build creative tools that run on anything. Reduce dependencies until what's left is yours.

My version

I'm not building a VM from scratch. I'm applying the same principle to a development environment: eliminate external dependencies for core work.

• AI: Ollama with local models. No API keys, no rate limits, no data leaving my machine.
• OS: NixOS on a Framework laptop. Declarative config means one file reproduces the entire system. No surprise updates.
• Tools: Uroboro for context, wherewasi for session recovery. Go binaries. SQLite storage. No cloud anything.
• Storage: Local SSDs. Git for version control. Backups I control.

The test: pull the ethernet cable. Can I still write code, run tests, ask an AI for help, and track my work? Yes. Every part of the core workflow runs locally.

What I still depend on

Honesty check: I use Claude Code through an API. I push to GitHub. I deploy to Vercel. The permacomputing microstudio is the foundation, not the whole building.

The difference is which dependencies are load-bearing. If GitHub goes down, my code is still on my machine and I can push to a different remote. If Vercel dies, the site is static HTML I can host anywhere. If Claude's API changes, my local Ollama setup is already running. Each dependency has an exit path.

The dependencies I can't easily replace: hardware (the Framework laptop), electricity, my own brain functioning. Everything above those layers should be swappable. That's the goal. Not purity. Replaceability.

The cost

Setup is slower. Learning NixOS took weeks. Building custom tools takes time I could spend using someone else's. Local models are worse than cloud models for complex tasks.

The tradeoff is explicit: I'm spending time now to not be trapped later. Every subscription I don't sign up for is a dependency I don't have to migrate when the company pivots, raises prices, or shuts down. And they will. They always do.