{"id":858630,"date":"2026-10-26T18:46:55","date_gmt":"2026-10-26T18:46:55","guid":{"rendered":"https:\/\/mag.gridnet.org\/?p=858630"},"modified":"2026-10-26T20:41:16","modified_gmt":"2026-10-26T20:41:16","slug":"the-means-of-inference-truly-decentralized-ai-on-gridnet-os","status":"publish","type":"post","link":"https:\/\/mag.gridnet.org\/index.php\/2026\/10\/26\/the-means-of-inference-truly-decentralized-ai-on-gridnet-os\/","title":{"rendered":"The Means of Inference: Truly Decentralized AI on GRIDNET OS"},"content":{"rendered":"
\n
GRIDNET Magazine<\/span><\/p>\n

The Means of Inference:
\nTruly Decentralized AI on GRIDNET OS<\/span><\/h1>\n

A GRIDNET OS Field Dispatch<\/p>\n

Every question we put to a large language model today crosses a counter owned by someone else. This is the story of how that counter came to exist, why it matters more than the models themselves, and how we are building an open market in which anyone with a graphics card can answer, nobody along the way sees both who asked and what, and nobody can cheat anybody of more than a sliver.<\/p>\n

By the Wizards
\nOctober 2026
\n20 min read<\/div>\n<\/header>\n
\n

\u26a0 Built live \u2014 read this first<\/h4>\n

Everything described in this article is being implemented live on our YouTube channel<\/a>. Live updates go out on our Discord #live-development<\/strong> channel hourly, and often more frequently.<\/em><\/p>\n

This is a development-stage report. The AI sub-system described here is under active construction inside GRIDNET OS and is not public yet. What follows is the design, the reasoning behind it and the state of the work, not a product announcement.<\/em><\/p>\n<\/div>\n

\"IllustrationWhat it looks like from the user’s side: a UI dApp inside GRIDNET OS asks the operating system, and the operating system asks the network.<\/figure>\n

I. Who owns the counter?<\/h2>\n

In the early 1960s, a serious computer cost as much as a building and filled a room of its own. Universities and corporations bought them and then faced a problem of economics rather than engineering: the machine was far too expensive to sit idle while one person thought about their next instruction.<\/p>\n

The answer was time-sharing<\/strong>. Many users, each at a terminal, took turns on a single machine, slicing its attention into fractions of a second. The arrangement was efficient, and it created a new kind of institution: the computer centre, with its operators, its accounts, its priorities and its rules about who could run what, and when.<\/p>\n

The personal computer broke that arrangement in the late 1970s and 1980s. For a generation, the machine that did the thinking sat on your own desk, and nobody could switch it off but you. Then broadband arrived, and step by step the thinking moved back across the counter. We called the new counter the cloud<\/em>. It was friendlier than the old computer centre, and vastly more powerful, but the economics were the same: expensive machines, owned by a few, rented to many.<\/p>\n

Artificial intelligence is pushing that old pattern to its extreme. The most capable language models, the systems that write, summarize, translate, explain and reason in ordinary words, are served from a handful of data centres run by a handful of companies. When you ask one a question, your words travel to their machines. They answer, they set the price, they decide what may be asked, and they keep whatever record their policy allows.<\/p>\n<\/article>\n

\"\"Who gets paid: operators earn for answering, relays earn for carrying sealed traffic, and anyone with a node or a browser can take part.<\/p>\n

No conspiracy is needed for this; it follows from how the technology grew up. But the result is that one of the most important new ways in which people think, learn and decide now passes through a few gates. Historically, whoever has held the gates has, sooner or later, also set the rules.<\/p>\n

II. Training makes headlines; inference makes the world<\/h2>\n

Building a language model has two very different stages, and the distinction is the key to everything that follows.<\/p>\n

Training<\/strong> is the one-off process of teaching a model by showing it enormous quantities of text and adjusting billions of internal numbers until it predicts that text well. It needs vast clusters of specialised chips running for weeks, and it is the work of large laboratories.<\/p>\n

Inference<\/strong> is everything that happens afterwards. Each time someone asks the trained model a question, a computer loads the model’s numbers into the memory of a graphics card (a GPU) and computes the answer, one word-fragment, or token<\/em>, at a time. Training happens once. Inference happens every time anyone, anywhere, asks anything.<\/p>\n

Two trends have shifted the balance of power between those stages. First, many capable models are now published with their weights openly available, so anyone can download them. Second, the graphics cards that gamers, studios and university labs already own can run many of those open models well. The bottleneck for everyday use is therefore no longer access to a model. It is access to the act of running one: who owns the card that answers, who sees the question, who sets the price, and who may switch you off.<\/p>\n

GPU capacity is also scarce and unevenly spread. Data-centre cards are booked months ahead, while millions of capable consumer cards sit idle for most of the day. A world in which inference can only be bought from a few large operators leaves that idle capacity unused and keeps prices where the few operators choose to put them.<\/p>\n

Then there is the API key<\/strong>. To use a commercial model inside an application, a developer opens an account, attaches a payment card, receives a secret key and pastes it into their software. That key is an identity, a billing relationship and a revocable permission all at once. It ties every request to an account, it can leak, and it can be cancelled by the provider at any time and for any reason its terms allow. Everything built on top inherits that dependency.<\/p>\n

III. How a question travels today<\/h2>\n

It is worth following one question on its journey, because the details explain what is at stake.<\/p>\n

You type into an application. The application wraps your words in a request, attaches its API key or your account session, and sends it over an encrypted connection (TLS, the same padlock that protects online banking) to the provider’s servers. TLS protects your words from anyone listening on the wire. It does not protect them from the provider, because the provider is the other end of the connection.<\/p>\n

Inside the provider, the request is authenticated against your account, checked against usage limits, scheduled on to a GPU and answered. Along the way, the provider learns who you are, through the account, the key and your network address, and what you asked, because it must read the prompt in order to answer it. What happens to that record afterwards is a matter of the provider’s policy, its legal obligations and its competence at keeping secrets.<\/p>\n

None of this implies bad faith. It is simply the shape of the arrangement: a single party sees both who<\/em> and what<\/em>, sets the price, and decides who may ask.<\/p>\n

\"Two
What to notice: today one party holds both halves of the secret, who asked and what was asked. On the GRIDNET OS path, no single party ever holds both.<\/figcaption><\/figure>\n

IV. Ask the network, not a company<\/h2>\n

GRIDNET OS is a decentralized operating system with a web-based sub-system. It runs in an ordinary browser, and its applications, called UI dApps<\/em>, run on a shared network rather than on a company’s servers. UI dApps have been part of GRIDNET OS for some time; the AI sub-system extends what they can do.<\/p>\n

Inside GRIDNET OS, a UI dApp, or a person typing into the built-in AI assistant, does not call any particular provider. It asks the operating system<\/strong>, and the operating system asks the network<\/strong>. Operators who run open models on their own graphics cards publish what they can do: which model, at what price, how fast, and how much context (how much earlier conversation) they can hold. The system finds those who can answer the question as asked, chooses among them and sends the request on its way.<\/p>\n

Nobody registers with a platform. There is no account to open with an AI company and no secret key to paste into an app. The payment comes from the user’s own wallet, under limits the user sets, with the user’s consent. An operator with a spare card in a back room becomes a supplier the moment their node starts advertising; a user becomes a customer the moment they ask.<\/p>\n<\/article>\n

That sounds simple, and the simplicity is the point. But an open market of strangers raises three hard questions at once. How do you stop the market from seeing everything? How do you pay strangers without being robbed? And how do you keep the service alive when some of those strangers fail? The rest of this article takes them in turn.<\/p>\n

V. A lineage of onions<\/h2>\n

In 1981 the cryptographer David Chaum published a short paper with a long shadow: \u201cUntraceable electronic mail, return addresses, and digital pseudonyms\u201d<\/a>. His insight was that you could hide who is talking to whom by passing messages through a chain of intermediaries, which he called mixes<\/em>. Each mix strips off one layer of encryption, shuffles its messages with everyone else’s and passes them on. An observer watching any single point sees traffic go in and come out, but cannot link the two.<\/p>\n

In the 1990s, researchers turned the idea into onion routing<\/strong>: a message is wrapped in several layers of encryption, like the skins of an onion, one layer for each relay on a chosen path. In 2004, the design was refined and published as Tor: The Second-Generation Onion Router<\/a>, which went on to protect journalists, activists and ordinary people around the world.<\/p>\n

The principle is easy to state. The first relay knows who sent the message, but cannot read it. The middle relay knows neither the sender nor the content. The last relay can pass the request on, but has no idea where it came from. The destination receives the question and returns the answer without ever learning who asked. No single participant holds both halves of the secret.<\/p>\n

GRIDNET OS sends AI traffic along exactly such paths. The operator who runs the model sees the question, because it must, but never the person. The relay nearest the person sees the person, but never the question. And unlike volunteer networks, every relay is paid<\/strong> for what it carries, from the same wallet and in the same small steps as the answer itself, so carrying other people’s traffic becomes a modest business rather than an act of charity. Our earlier work on decentralized, incentivized signalling for browsers, WebRTC Swarms<\/a>, laid much of the groundwork for running such circuits between ordinary browsers.<\/p>\n

\"DiagramThe path of one request: sealed layer by layer through the relays, answered by an operator, and paid for in small prepaid steps along the way.<\/p>\n

One design rule matters a great deal here: the onion layer knows nothing about AI. It carries sealed, opaque packages and is paid for carrying them. AI inference is simply one of its customers, and the same machinery can carry anything else that needs to travel privately.<\/p>\n

\"A
What to notice: each relay removes one layer and learns one thing. The money runs on its own side-channel, one small prepaid step at a time.<\/figcaption><\/figure>\n

VI. Prices without a price-setter<\/h2>\n

An open market needs prices, and prices usually need someone to set them. In 1945 the economist Friedrich Hayek argued, in \u201cThe Use of Knowledge in Society\u201d<\/a>, that no central planner could ever gather the scattered, local knowledge that a price summarises. A price, in his view, is a signal: it compresses what thousands of people know about their own costs and needs into a single number that everyone can act on.<\/p>\n

There are two classic ways to form such a number. In an auction<\/strong>, buyers bid against each other in real time; the result is efficient but noisy, and it rewards whoever can watch the board most closely. In a posted-price<\/strong> market, sellers state a price and buyers take it or leave it, as in a shop. GRIDNET OS combines the two in what we call passive price discovery<\/em>.<\/p>\n

Each operator posts an offer: the model, the price for reading the question and for writing the answer, the speed, and the amount of context. Each request carries the user’s own limits and accepts only offers that fit them. When several requests wait for the same operator, the operator serves them in the order of what callers have offered, so a user in a hurry can offer more and be served sooner.<\/p>\n<\/article>\n

\"Infographic:The whole idea on one page. On the left, today’s model: one company’s counter. On the right, the GRIDNET OS design: an open market of operators and relays, paid in small prepaid steps, with nobody in the middle who sees both who asked and what.<\/p>\n

Then each operator watches only its own queue. A busy operator lets its posted price drift upwards at the next advert; an idle one lets it drift downwards. The moves are small and gradual, and a new price applies only to new requests: a conversation already running keeps the price it was admitted at.The word passive<\/em> matters. No operator needs to know anyone else’s costs, and there is no central order book to watch, spoof or corner. A fast new card and an older, slower one can run the same model and settle at different prices, each reflecting what users will pay for speed. A would-be manipulator has little to grip: posting an absurd price simply means not being chosen, and flooding the queues with cheap requests only reveals that demand is high, which nudges prices up for the manipulator too.<\/p>\n
\"A
What to notice: there is no auctioneer in the middle. Each operator moves only its own price, from its own queue, and only for future requests.<\/figcaption><\/figure>\n

VII. Paying by the sip: a game with bounded losses<\/h2>\n

Paying a stranger on the internet raises one of the oldest problems in commerce. If you pay first, they may not deliver. If they deliver first, you may not pay. For centuries, banks, escrow agents and card networks have made their living in that gap, and they charge for it.<\/p>\n

GRIDNET OS narrows the gap until there is almost nothing left to steal. Payment is prepaid<\/strong>, but in small steps<\/strong>. The user’s wallet pays for the next short stretch of the answer; the operator generates that stretch and no more; the wallet pays for the next; and so on until the answer is complete or the user’s limit is reached.<\/p>\n

Game theorists would describe this as a repeated game with bounded stakes, and it is worth spelling out what each side can lose. A dishonest operator can take the payment for one stretch and vanish, so the user loses at most one small step. A dishonest user can stop paying, but the operator never produces work that has not been paid for, so the operator loses nothing but a moment of idle time. Neither side can be cheated of more than a sliver, which means neither has much to gain by trying, and an honest operator has every reason to keep serving a customer who keeps coming back.<\/p>\n

There is no arbitrator in this design, no judge of quality and no refund desk. That is deliberate. A system that needs an arbitrator needs someone trusted to arbitrate, and that someone becomes the new counter. Instead, the stakes are kept so small that arbitration is not worth the trouble, and quality is left to the market’s memory, as we shall see.<\/p>\n

The payments themselves do not each need a blockchain transaction, which would be slow and expensive. They travel off-chain<\/em>, directly between the parties, as a chain of cryptographic tokens in which each token is worth one step more than the one before. The recipient only ever needs to keep the latest. The system keeps a public, append-only record of the tokens each payer has issued, so an attempt to spend the same money twice can be detected before it is accepted, and only the final total is ever settled on the blockchain. A long conversation can involve a great many tiny payments and a single settlement.<\/p>\n

The user also keeps a hand on the meter. Modern models often \u201cthink\u201d before they answer, producing long internal chains of reasoning that are paid for like any other output. The user’s limits, per question, per conversation and per day, live in their own settings. When an answer reaches a limit, it stops cleanly and asks, and continuing is a fresh, deliberate decision. Nothing quietly runs up a bill.<\/p>\n

\"A
What to notice: payment always runs one small step ahead of delivery. Whoever walks away, the loss is capped at a single step, so honesty is the cheapest strategy.<\/figcaption><\/figure>\n

VIII. When an operator goes quiet<\/h2>\n

Computer scientists distinguish two kinds of guarantee. Safety<\/strong> says that nothing bad ever happens: you are never charged twice, your words never reach the wrong party. Liveness<\/strong> says that something good eventually happens: your question does get answered. Distributed systems usually find safety the easier of the two, and in an open network liveness is under constant pressure, because some participants will always fail. A card overheats; a home connection drops; occasionally, someone tries to take the money and run.<\/p>\n

In most systems these failures become the user’s problem: an error message, a spinning wheel, a button marked \u201ctry again\u201d. In GRIDNET OS, liveness is treated as the system’s<\/strong> duty. If an operator stalls part-way through an answer, or a relay stops passing traffic, the system notices the silence, closes that lane, and places the remaining work with another operator. It does so on its own, inside the limits the user has already set, and it never pays twice for the same stretch.<\/p>\n

This works because operators keep nothing between turns. Each request carries the conversation it needs, so the conversation belongs to the user and travels with them, not with any operator. A new operator can pick up where the old one stopped. In practice the user sees a short pause, and then the answer carries on.<\/p>\n

The same thinking runs through every wait in the design. Every waiting step has a deadline, and every deadline ends in a named, understandable outcome rather than an endless spinner. If no operator can serve a question within the user’s limits, the user is told so plainly, together with what would make it possible.<\/p>\n

\"A
What to notice: the conversation outlives the operator. The switch is made by the system, within the user’s own limits, and nothing is paid twice.<\/figcaption><\/figure>\n

IX. Votes that cannot be bought in bulk<\/h2>\n

Prices tell you what an answer costs, not whether it was any good. For that, GRIDNET OS lets users rate the operators who served them, and the system itself records a failed delivery as a mark against the operator who failed.<\/p>\n

Open ratings have a famous weakness. In 2002 the computer scientist John Douceur gave it a name in \u201cThe Sybil Attack\u201d<\/a>, after a well-known case study of a person with many identities. He showed that in an open network, without some central authority vouching for identities, a single attacker can always create enough fake participants to outvote everybody else. Every online review site since has fought the same battle.<\/p>\n

GRIDNET OS answers it with an idea from our own published research, SPIDE: Sybil-proof, Incentivized Data Exchange<\/a>. A vote carries weight only when it is backed by proven stake<\/strong>, value that the voter has demonstrably committed to their identity on the network. And the weight grows slightly faster<\/em> than the stake behind it. One identity holding everything therefore outweighs the same value split across many accounts. Splitting yourself into a crowd makes you quieter, not louder, so the cheapest way to have a voice is to be one person with something at stake.<\/p>\n

Each identity counts once per operator, and nobody can vote for themselves. The votes stay with the users who cast them, in their own records on the network, where anyone may read and interpret them. Nobody’s stake is ever confiscated; what an operator risks is its reputation, which is exactly what ratings are for.<\/p>\n

X. The browser joins the network<\/h2>\n

For most of the web’s history, the browser has been a window: it looks out at a network that belongs to others. In GRIDNET OS the browser is a first-class node<\/strong>.<\/p>\n

A browser running GRIDNET OS can act as an onion relay, carrying sealed traffic for other people and earning small payments for doing so. The setting is on by default and can be turned off at any time. Earnings appear next to spending in the operating system’s own reporting, and the person relaying chooses which of their identities does the relaying, so that every payment lands in a wallet they control. Browsers can also link directly to one another, so an entire private route can run from browser to browser.<\/p>\n

The effect is easy to underestimate. The more people use the network, the more relays it has; the more relays it has, the harder it becomes to watch; and the people who make it harder to watch are paid for doing so. Taking part in the infrastructure becomes something an ordinary laptop or phone does in the background, without its owner having to become a systems administrator.<\/p>\n

XI. Anyone can serve, anyone can ask<\/h2>\n

Put the pieces together and the defining property of the design comes into view: it is an open market<\/strong>, and the openness is the benefit.<\/p>\n