How it works
The short version: BitTorrent, for AI. Instead of finding a peer who has a file, OpenHydra finds a peer who has the model, your prompt runs there and the answer streams back. Here’s what’s underneath.
The short version: it’s like BitTorrent, but for AI. Instead of finding someone who has a file you want, OpenHydra finds someone whose computer can run the AI model you want, your question runs there, and the answer comes straight back. Here’s how, step by step.
Local by default, the network is only used when you ask for a model you don’t already run.
One binary, two roles
OpenHydra is a single Rust agent that plays one of two roles (or both at once):
OpenHydra is one small program that can do two jobs, either one, or both at the same time:
serve
Exposes the OpenAI-compatible gateway at http://127.0.0.1:16527/v1. Your tools talk to this; it decides whether to answer locally or route to a peer.
Answering
The part your apps talk to. It takes your question and decides whether to answer it right here on your computer, or pass it to someone on the network who’s better placed to handle it.
provide
Wraps an inference engine you already run (Ollama, vLLM, LM Studio, llama.cpp, Exo) with a thin adapter and announces the models it can serve to the network.
Helping
The part that runs AI models, using an app you already have, like Ollama or LM Studio, and tells the network which models your computer can handle for other people.
OpenHydra ships no inference engine of its own, it’s a coordination layer. That’s why you keep the exact stack you already have.
OpenHydra doesn’t include an AI engine of its own, it’s the thing that connects everything together. That’s why you get to keep whatever apps you already use.
Finding the model
Providers announce what they’re serving into a Kademlia distributed hash table, a shared, decentralized index of “who has what,” spread across the network with no central registry. Peers also gossip a live view of their neighbours, so discovery stays fresh as machines come and go. When you request a model, the router resolves it to a canonical id, ranks the peers offering it, and picks one.
How does OpenHydra know who can run what? Everyone who’s sharing publishes a little note saying “my computer can run these models.” Those notes are spread across the whole network, there’s no central company keeping the list. When you ask for a model, OpenHydra reads the notes, picks a good computer that has it, and sends your question there.
Connecting the peers
Getting two home machines to talk directly is the hard part of any P2P system, most sit behind NAT and firewalls. OpenHydra uses libp2p to handle it:
The tricky part of a network like this is getting two home computers to talk to each other directly, home internet is usually hidden behind routers that block incoming connections. OpenHydra does that hard work for you:
- QUIC and TCP transports, so it works across a wide range of networks.
- DCUtR hole-punching to establish a direct connection between two NAT’d peers whenever possible, proven across different continents and ISPs.
- Circuit Relay v2 as a fallback: if a direct path can’t be made, an encrypted relay forwards the bytes. The relay never sees your prompt.
- AutoNAT to figure out reachability, and a mesh of bootstrap nodes that only help peers find each other, they carry no inference.
- It tries several ways to connect, so it works on almost any internet setup.
- Where it can, it links the two computers directly, even when both are behind home routers, and even across different countries.
- If a direct link isn’t possible, it passes messages through a helper computer instead. That helper only forwards scrambled data, it can never read your question.
- A few “introducer” computers help everyone find each other, like a phone book. They don’t run any AI themselves.
Every connection is authenticated with Ed25519 peer identities and encrypted end-to-end (libp2p Noise / QUIC). There is no central broker in the data path.
Every connection is locked down and scrambled from end to end, and there’s no company’s server sitting in the middle of your conversation.
Keeping it honest
An open network needs a way to trust strangers’ answers. OpenHydra’s trust layer is where most of its distinctive engineering lives:
On an open network, how do you trust an answer from a stranger’s computer? This is where a lot of OpenHydra’s clever engineering goes:
- Co-signed receipts, each unit of work produces a tamper-evident record both sides sign, the billable/creditable line-item.
- Redundant execution & content hashing, answers are spot-checked and cross-verified across peers to catch bad actors and echo/laundering tricks.
- Reputation, good providers build standing and get routed more work; cheaters get downranked until the swarm stops trusting them. Your standing is the bond, economic security, earned not bought.
- Give-to-get, serve while idle to earn priority when you consume, which keeps supply and demand roughly in balance without a central operator.
- Signed records. Every bit of work leaves a little receipt that both sides sign, so nothing can be faked or denied later.
- Double-checking. Answers are spot-checked and compared across different computers, to catch anyone cutting corners or cheating.
- Reputation. Reliable, honest computers build a good name and get sent more work; cheaters get frozen out. You earn trust, you can’t just buy your way in.
- Fair trade. Help out while your computer is idle and you earn priority when you need it, which keeps supply and demand in balance, with nobody in charge.
Decentralized where it counts
The data plane is peer-to-peer: prompts and tokens flow directly between machines, encrypted, with no server in the middle. Bootstrap nodes exist only to introduce peers, like a phone book, not a switchboard, and the Hydra’s many heads mean if one goes down, the others carry on. Anything that could be centralized later (billing, identity for paid tiers) would sit as an optional control plane on top of the neutral protocol, never inside it.
The important part is fully people-to-people: your questions and the AI’s answers travel straight between computers, scrambled, with no company’s server in the middle. The “introducer” computers are just a phone book, not a switchboard, and like the mythical Hydra’s many heads, if one goes down the others carry on. Anything that might need a central touch later (like billing for paid models) would sit neatly on top, never buried inside the network.