Claude wrote the whole thing. Parallel computing, proper MPI calls, the works. But when it needed to actually spin up VMs and execute, it just... stopped. It had no way to buy compute.
That felt wrong to me.
Agents can reason, plan, write code. But the moment they need infrastructure, a human has to step in and swipe a card. Every single time.
So I built Sockt
It's compute infrastructure where the agent pays directly, either through a Bitcoin Lightning wallet or pre-loaded fiat credits. You set it up once. After that the agent handles it.
No human in the loop per request. No card expiry breaking your pipeline at 3am. No KYC re-verification every time it needs a new sandbox.
The Lightning path is the interesting one. An agent that earns sats from doing work can immediately spend them on compute. The loop closes without you touching anything.
The credits path is simpler. Buy a balance, hand the agent an API key, done.
Both are live now.
If you're building with LangChain, AutoGen, CrewAI, or anything that spins up agents that need to actually run things, I'd love for you to try it.
Docs | hello@sockt.dev
Ali Aan Khowaja
Posted on
Claude completed my MPI assignment. Then it couldn't run it. So I built the missing piece.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
"Wrote it, couldn't run it" is the single most underrated failure mode of code-gen, and MPI/distributed code exposes it brutally - the model produces plausible-looking parallel code but has no execution environment to verify it actually compiles, links against the right MPI lib, and runs across ranks without deadlocking. Generation without an execution+verification loop is just confident guessing.
This is exactly why I think the "missing piece" you built (an actual run/verify step) is the important half, not the generation. It's the core design principle of Moonshift (a multi-agent pipeline: prompt to a shipped SaaS on your own GitHub + Vercel) - the agent doesn't just write code, it runs it through verification gates so "it generated" and "it actually works" aren't conflated. Code that isn't executed is a hypothesis, not a solution. First run's free, no card. Genuinely interested in your missing piece - is it a sandbox/execution harness that feeds errors back to the model, or more of a verification layer? The execution-feedback loop is the thing I find most teams skip and most need.