u/Electrical_Offer5667

Setup: Windows, RTX 4090
So far I've tried Qwen 3.8 27b (Context at 128k and KV set to Q8_0) and Gemma 4 26b via LM Studio. Got it working with a Telegram bot which is pretty cool. In the future I may integrate Hermes into a startup that I'm working on.

What do you wish you'd known your first week?
What's your local vs cloud split?
Can I run on my ChatGPT subscription instead of burning through API credits?

What it is. Obsideo is my project. It's a client-side encrypted distributed storage network with proof of retrievability, built for autonomous software, agents, and humans. In plain terms, encrypted cloud storage. Your data is encrypted on your machine before it goes anywhere, spread across independent operators rather than sitting in one company's datacenter, and every operator holding a copy has to cryptographically prove it still has your bytes on a continuous cycle. It isn't trusted to keep them; it's checked, roughly every four hours, and paid only for the proofs it passes.

The operators. The network runs on hardware I don't own. Independent operators run the storage nodes, on their own machines, disks, and connections, and get paid for the proofs they pass. They can join, and they can leave; when one drops or fails a proof, the coordinator re-replicates that data to others, so the network routes around a bad or absent operator without the customer doing anything. So part of the build was the software, and part of it was the human side: finding operators, onboarding them, and keeping enough healthy capacity online that customer data always sits on three of them. A storage network with one participant is just a hard drive. The work is making it a real one.

How it was built. Almost all of it was written with Claude Code. I've used it as my primary development environment for the whole project, so the overwhelming majority of the implementation came through coding agents: the coordinator and the storage node binary (both Go), a Python CLI, an S3-compatible gateway, an MCP server, the test suites, and most of the deployment and monitoring tooling around them. I architected it, but the actual code is agent-written.

Where it's at. Live and in production. A small fleet of operator nodes, roughly 70,000 objects under continuous proof, and paying customers running real workloads against it, mostly recurring automated backups pushing batches of objects, the largest single one 104 GB so far. Money moves in both directions: customers pay for verified storage, operators earn for the proofs they pass. Revenue is small but real. Small, growing, and legitimate, not a weekend demo and not a finished product either.

Using it. The interface is deliberately boring, which is the point: an S3-compatible gateway, a CLI, and an MCP server, so you reach it from tooling you already use instead of learning a proprietary API. The MCP server is the one most relevant here, an agent can put and get objects directly, and the network keeps proving that data is still there afterward, which is the kind of persistence agent workflows usually don't have. There's a free tier, and signup happens right inside the MCP server, so trying it costs nothing. The code is here if you'd rather read before touching anything: github.com/Regan-Milne/obsideo-mcp

What's next. It's early, and the gaps are: more operators for capacity and independence, and the durability and tooling work that turns alpha into something you'd trust without watching it. That's the current focus. If you're building with agents and want them to keep state that outlives a session, or you just want to kick the tires on the storage itself, I'd genuinely like to hear how it holds up for you.

So that's the short version. I'll answer questions if there are any.