Buying AI inference from strangers on Antseed

The first time I used Antseed, it took less than a minute to get a free AI model answering my coding agent.

I downloaded its desktop app. There was no account to create, no email, no API key. One click set up Pi, a coding agent, to send its requests through the app. The same one-click setup is there for Claude Code, Codex, OpenCode and others. I picked DeepSeek V4 Flash, a model the app marked "Free" and "100% off," and it answered. My balance said $0.00 the whole time.

That's a nice experience, and it raises an obvious question. Who answered me?

Somebody served that model for me, and I didn't pay them. I don't know who they are. The app knows them only as an ID on a network of strangers.

Antseed is a peer-to-peer marketplace for AI inference. Sellers advertise models and prices. A buyer picks a model, the app on their machine picks a seller to serve it, and payments settle in USDC on Base, Coinbase's blockchain. Its co-founder, Amos Meiri, described it on The Rollup podcast in July as "OpenRouter without OpenRouter in the middle." Buyers find sellers the way BitTorrent clients find each other, with no central server deciding who can participate.

Antseed's token white paper says that by September 29 the network had settled about $302,860 in payments for AI services, across 208 seller and 1,573 buyer addresses. Those are wallets, not people, a point Meiri made himself in an October 27 post on X: "Wallet addresses aren't the same as users." When I pulled its public stats on October 21, 68 sellers were advertising 1,189 model listings between them, 32 of them free.

The payment design is clever, and the docs are candid about a lot. But a marketplace of strangers places a burden on the buyer that a company like OpenRouter typically handles with its own policies and accountability. Why is it so cheap, which model actually answered, and what happened to your prompt?

The technology itself is neat, it runs well, and the team ships changes nearly every day. The first half of this post explains how Antseed works: how a request finds a seller, how you pay, and what the token does. The second half looks at those three questions related to the inference side.

Everything below comes from Antseed's code, documentation, public network stats, and on-chain data, plus my own use of the desktop app and the gateway. I've only used free models and haven't deposited any money. I don't hold ANTS, Antseed's token, and I have no connection to Antseed, its investors, or the podcast quoted here.

1. How does a request find a seller? ↓The mechanism
2. How does payment work? ↓The channel
3. What is the token for? ↓ANTS and the fee
4. Where does the discount come from? ↓Supply
5. Are you getting the model you paid for? ↓Model identity
6. What happens to your prompt? ↓Privacy

How a request travels

Where OpenRouter is a company that picks the providers and bills you, Antseed has no routing company. Each buyer runs the router themselves, on their own computer or server. Sellers announce themselves on a public peer-to-peer network, and the buyer's router chooses among them. Payment goes straight from the buyer to the seller through contracts on Base. Along the route from buyer to seller and back to buyer, there are other parties: Base itself, the owners of Antseed's contracts, and the AI companies whose models many sellers relay to.

What a buyer gets in return is choice. Your router applies your own rules and can switch sellers at any time, without waiting for one company to add a provider. Sellers can offer whatever they want to serve, on shared rails for discovery and payment.

If "BitTorrent for AI" makes you picture a swarm of GPUs splitting up a model between them, that isn't it. BitTorrent's part is only the phone book. Each seller serves requests on its own, either by relaying them to an AI API with its own API key or by running a model on its own hardware. From the outside, you can't tell which. A seller's listing doesn't say where your request ends up.

Here's what happens between hitting enter in your coding agent and seeing an answer.

1. Your app talks to the buyer proxy. This is a small server on your own computer, or your gateway's server, that speaks the same API format as OpenAI or Anthropic. Your coding agent thinks it's talking to an ordinary AI provider. The desktop app's one-click setup just writes the agent's config file to point at it.
2. Your proxy looks up sellers. Sellers publish their network addresses into the BitTorrent DHT. DHT stands for distributed hash table, a lookup table split across the computers that use it. Torrent clients use it to find each other without a central server. Your proxy queries it, then asks each seller for its listing: models, prices, capacity, and capabilities like encryption, all signed with the seller's key. The DHT only carries addresses. Your prompt never touches it.
3. It picks a seller. This step does more than "cheapest wins," and I cover it below.
4. It opens an encrypted connection. Most sellers advertise an encrypted TCP connection, set up with a fresh key exchange signed by both sides' wallet keys. A seller that can't accept direct connections can use WebRTC, which is also encrypted. There's a third, older option, and I'll get to it in the privacy section.
5. The seller relays your request. It decrypts it, swaps in its own credentials, and forwards it to its upstream: an AI API, or a model on its own hardware.
6. The answer streams back. The seller passes along the response and the usage numbers that came with it, and adds a signed receipt tying those exact bytes to its identity.

How your proxy picks a seller

Antseed's FAQ says the buyer "picks the cheapest provider that passes your minimum trust score." That's a simplification of what the code does, and the difference is worth knowing.

First comes a gate. Every seller gets a trust score from 0 to 100, and your own proxy computes it from public records. Payment-channel history is worth up to 50 points, recent paid usage up to 20, ANTS staked behind the seller up to 10, and a GitHub account or domain the seller has proven it controls up to 20. Offering a free model adds 5. A seller flagged for wash trading scores zero. By default, sellers under 60 are left out of automatic routing, so a brand-new seller has to build a record before it gets automatic traffic.

Then comes the ranking. Among the sellers that pass, your proxy estimates the expected cost of a successful answer from each one, combining price with how reliable and fast that seller has been for you. A seller that's cheap but fails half the time ranks worse than one that costs a little more and always answers. That record lives in a file on your machine, and no one else sees it. A gateway keeps one record for everyone who uses it. For a new buyer with no record yet, the result is close to "cheapest."

Keep one thing in mind for later. A trust score is built from payment history, paid usage, staking and public identity, and a seller can clear the default gate of 60 on payment history and usage alone. None of those signals tells you which model the seller runs or what it does with your prompt.

How you pay

The payment design solves a real problem. Paying for each request separately on a blockchain would cost more in fees than many requests cost to serve.

Think of a bar tab. You hand over a card, the bar holds a limit on it, and after each round you sign the running total. The bar can charge the card for the latest total whenever it likes, but it can never charge more than you signed.

Antseed works the same way, with USDC on Base.

1. Deposit. You put USDC into Antseed's deposits contract. You can send it from a wallet, or top up by card or Apple Pay in the desktop app. That second option is a nice touch, because it makes Antseed usable without ever transacting in crypto directly.
2. Open a tab with one seller. You sign a budget for a channel with that seller: a maximum amount and a deadline. The seller submits it on-chain, which locks that much of your deposit.
3. Sign a running total. After each response, you sign a new cumulative total. Each new signature states the whole amount so far, like $0.09, rather than the $0.04 added since the last one. These signatures stay off-chain.
4. Settle. Whenever it chooses, the seller submits your latest signature. The contract charges only the increase since its last settlement. The seller gets 96%, and a 4% protocol fee goes to a reserve address.
5. Close. The seller can close the channel and release whatever you didn't spend. If a seller disappears, you can ask to close yourself. The seller then has 15 minutes to submit any signatures it holds, and after that you withdraw the rest.

Your payment exposure to each seller is bounded. A seller can never take more than the budget you signed for that channel, and you can stop signing at any point. It's also cheap. One on-chain settlement can cover hundreds of requests.

Free models don't touch any of this. They run through a separate contract that records signed usage counts on-chain but moves no money. Sellers can cap how much free usage each address and IP gets. That's how I could use a free model with a $0.00 balance.

What sets the price of each request

Every response from an AI API carries usage numbers: how many tokens went in, how many came out. Antseed bills from those numbers, as reported in the response the seller relays to you. Your proxy recomputes the cost from them and the seller's advertised prices, and it won't sign a total more than 1.4 times its own estimate. Only when a response has no usage numbers does either side fall back to estimating from the size of the text.

The limit is in where those numbers come from. Your proxy's estimate is built from the same usage fields the seller relayed. The check catches a seller whose bill doesn't add up. It can't catch one that reports inflated usage in the first place, because your machine never sees what the upstream API actually counted.

How it compares with MPP and x402

If you follow crypto payments for AI, this will look familiar. MPP, the Machine Payments Protocol from Stripe and Tempo, has a session mode that works the same way. x402, which grew out of Coinbase and started with paying for each request in full, now also specifies a batch-settlement scheme with a deposit, rising signed totals, and a timed exit for the buyer.

So Antseed's channel isn't new on its own. What Antseed adds is everything around it: finding sellers without a central directory, seller identities, negotiating payment over the peer-to-peer connection instead of an HTTP payment request, usage checks built for AI inference, and the fee and reward system on top.

What the token is for

USDC pays for inference. ANTS, Antseed's token, rewards the people who build, use and back the network.

There was no premine. Every ANTS is minted on a weekly schedule that started at 5 million a week and halves every two years, up to a cap of 1.04 billion. On October 29, about 130 million existed, roughly 12.5% of the cap.

Each week's tokens are split. The Antseed Foundation, which publishes the white paper, and the team each get a fixed 15%. The Foundation has sold part of its future share to investors in a $2.4 million round led by Spark Capital. The other 70% goes to the network, in shares the contracts' owner can adjust. It rewards stakers who lock ANTS behind a seller, sellers and buyers for paid usage (free usage earns nothing), and verification and growth, though the reward for model auditors isn't switched on yet.

Whatever the network doesn't earn in a week is burned, up to 30% of that week's tokens, and the rest goes to the Foundation.

To stop sellers paying themselves to look busy, a wash-trading filter zeroes the rewards and trust score of any seller caught self-dealing, after the fact.

When I checked on October 29, ANTS transfers were disabled except for a short list of approved senders. Holders don't control anything either. The white paper says ANTS "confers no voting, governance or control rights," and owner addresses control the contracts.

Where the 4% goes

In July, Meiri was clear about the fee: "All of the revenues from the network are going back into the network itself through a buy and burn." The 4% would buy ANTS on the market and destroy it. The white paper is more careful. It says the buy-and-burn "has not been activated," and that fees will go to it once ANTS becomes transferable.

The chain agrees with the white paper. The fee goes to one address, which held about 12,711 USDC on October 21. That's a little more than the white paper's $12,030 in fees by September 29, as you'd expect three weeks later. Its five outgoing transactions include no ANTS purchase and nothing sent to the burn address. As far as its own transactions show, the reserve has collected fees and kept them.

It's also an ordinary account, controlled by whoever holds its key, not the "separate reserve contract" the white paper describes. And the payment contract's owner can raise the fee to 10%.

None of this contradicts Antseed's own documents, but for now the buy-and-burn is a stated plan, tied to a transferability date that hasn't been set.

Where the discount comes from

Now for the open questions. The first is the one I wondered about as soon as a model said "100% off."

Start with what the percentage means. The desktop app's discount badge compares the lowest price it shows for a model against OpenRouter's listed price for the same model, adding input and output prices without weighting. That's a different baseline from the model maker's own API, and it says nothing about what you'd save on a real workload.

Some real comparisons, from the October 21 listings against OpenAI's published prices per million tokens:

• GPT-4.1 mini: one seller at $0.15 in and $0.60 out, against OpenAI's $0.40 and $1.60, 62.5% below.
• GPT-4o mini: four sellers, from about 38% to 77% below OpenAI's $0.15 and $0.60.

Those are advertised prices, not a test of what was served. But they raise the question fairly. If you're paying a seller 60% less than the model maker charges, who's covering the difference?

Antseed's code and docs point to several ways a discount can be legitimate.

• Prepaid credit. Staking Venice's DIEM token earns $1 a day of Venice API credit. An Antseed contract pools DIEM, stakes it, and sells the credit on Antseed. Credit that renews whether you use it or not is cheap to resell.
• Spare capacity. A seller with API credits or quota it won't use up can sell the surplus, where the provider's terms allow it.
• Their own hardware. A seller running an open model on GPUs it already owns has a different cost structure from an API.
• Competition and subsidies. Sellers chasing reward points or trust score may price low on purpose.

Antseed's README rules one source out. Reselling a personal subscription, like a Claude Pro plan, "is not permitted." Still, on October 21, six listings carried the label of a Claude subscription plugin the README says is for local testing only. A label is only a seller's claim, so I can't tell what's behind it.

Nothing in the public data tells you which of these explains any given seller. For a closed model like GPT-4.1 mini, running your own hardware isn't an option, so that one can't explain the GPT listings above. A listing shows a price and a self-reported plugin name. It doesn't show the seller's upstream, its costs, or its reasons. Meiri's own framing on the podcast was, "We don't care how people are providing their inference," followed by "as long as they're following terms and conditions."

Why some models are free

If a seller charges nothing at all, who's paying for the inference? Free models make that question hard to miss.

The "Free" label describes one seller's price, not the model. Each seller sets its own price for each model it lists. "Free" means at least one seller is offering that model at $0 right now. Other sellers of the same model can charge, and most listings aren't free at all. On October 21, only 32 of the 1,189 were.

Nothing makes a free price last, either. A seller can change its price with one command or stop listing the model. It can also cap free use, for example at 100 requests a day per buyer. A free model is free for now, from whoever is offering it.

Across the whole network, the 32 free listings came from 12 sellers. So why give inference away? There's one documented reason in the code. Offering a free model adds 5 points to a seller's trust score. Beyond that, free usage earns no rewards, and the sellers' motives aren't public. It could be a funnel to paid models, a free upstream tier passed along, or goodwill. I don't know, and the data can't tell us either.

Are you getting the model you paid for?

The second question goes deeper. Say a seller lists a frontier model at a steep discount. How do you know that model was actually served to you?

Antseed's own protocol spec puts the problem bluntly. A seller "can advertise a premium model… and silently serve a cheaper substitute," and reputation signals score that seller "exactly as well as an honest one, because delivery still happened." It isn't a hypothetical problem. A study called "Real Money, Fake Models" audited unofficial resellers of frontier models and found that 45.83% of its fingerprint tests failed to verify the claimed model. That study is about other resellers, not Antseed, but Antseed's spec cites it.

The trust score can't catch this, because none of its signals looks at what the seller served. Even its payment history can be padded. A seller can close empty channels to raise its count, or pay itself through a buyer it controls. Meiri said as much in his October 27 post: "If I control both buyer and seller, I can pay myself and report huge usage at a tiny price." The wash-trading filter catches that only after the fact.

What Antseed has built is attribution. Every response comes with a signed receipt tying the exact bytes to the seller's key, and your proxy keeps a small random sample of full exchanges. If a seller served something wrong, you can prove which seller sent it.

Identifying the model is newer. On October 21, Antseed added a model-verification system to its code, called knowledge boundary fingerprinting. Every model gets obscure facts wrong in its own way. So an auditor asks a seller a batch of short questions with exact numeric answers, like the melting point of a particular compound, and compares its misses with the genuine model's, measured through an API the auditor trusts. Auditors are addresses the contract's owner approves, and their requests go through the ordinary buyer path. Verdicts go on-chain and expire after one to two weeks.

As of October 29, I couldn't find it running. Antseed's code had no verification contract address for Base, and nothing in routing or the trust score reads verdicts yet. Auditing also costs money, for the reference API, the paid requests and gas, and the ANTS reward meant to cover it isn't switched on. That isn't proof nobody is auditing, but I couldn't find any audits yet.

Even when it's live, a passing check is "strong evidence, not proof," in Antseed's words. It's statistical, and it describes a seller on the day it was tested, not your next request. Meiri said in July that the trust layer would "cryptographically prove" a seller serves what it advertises. A fingerprint can't do that the way a signature does.

If a seller did swap the model, there's no refund and no protocol-enforced remedy. A payment you already signed stays signed. The receipt proves who sent the answer, but all you can do with that is stop using them.

What happens to your prompt?

The third question is built into how relaying works.

The "AI VPN" label

When you visit a site over HTTPS through a VPN, the VPN server can see where you're going, but your traffic stays encrypted all the way to the site. The VPN passes it along without being able to read it.

Antseed's app is called "Antseed AI VPN," and its home screen is a power button. The connection to the seller is encrypted. But the seller isn't a tunnel. It's the endpoint. It has to decrypt your prompt to relay it, and an upstream API reads it too. On the ordinary path, your prompt is readable in three places: on your machine or gateway, at the seller, and at the upstream. If the seller runs the model itself, that's two. If you choose one of Antseed's optional routing services, another peer that picks sellers for you, it receives your conversation too, before any seller does.

To be fair, Antseed's docs say this. Its privacy page asks, "Can providers see my prompts?" and answers, "Standard providers can." It also says that while the protocol keeps no central log, sellers and other infrastructure "may still log or observe data." The docs are more candid than the label. I just didn't see any of that in the app. I didn't see a privacy warning or any note about which connection I was using.

Encrypted, mostly

On October 21, 56 of the 68 sellers advertised encrypted connections. The other 12 ran older software from before encrypted TCP was added in August, and none of them offered free models. Antseed has a setting that refuses unencrypted connections, but it's off by default and the app never turns it on. So if one of those 12 older sellers passes your trust gate, routing could send your prompt to it in plaintext, readable by anyone on the network path, and the app wouldn't show it. That's a possible path, not one I observed.

What the TEE check proves

Some sellers run inside a trusted execution environment (TEE), a sealed area of a processor meant to hide what runs inside even from the machine's owner. Antseed's privacy page says these sellers "cannot" see your prompts.

The check your proxy runs proves less. It confirms that genuine Intel hardware vouched for the seller's identity. It doesn't check what software runs inside, or show that your prompt was decrypted inside the enclave. By my reading, an enclave running code that logs prompts could pass. Antseed's blog concedes part of this and calls the fix its "agreed next milestone." And a TEE seller that relays to an ordinary API still hands that API your prompt.

On October 21, one of the 68 sellers advertised a TEE. By default, your proxy runs the check when a seller offers it, but sends your request anyway if the check fails or the seller has no TEE. A setting makes it refuse those sellers instead.

Why coding agents raise the stakes

This matters most for exactly the use the app makes easiest. A coding agent like Pi doesn't just send your question. It sends whatever it has gathered to answer it: the files it opened, command output, error messages, diffs. Whatever goes into the request reaches the seller and the upstream. In a private repository, that could be source code, config files, or anything else the agent decided to read.

The risk runs the other way too. The seller writes the reply, and a coding agent acts on its replies. A reply can ask the agent to read a file, edit one, or run a shell command. These requests are called tool calls, and Antseed passes them along unchanged. Its integration guide says tool-calling agents work "because Antseed forwards OpenAI tool calls verbatim."

So a seller doesn't need to trick a model with a hidden instruction, the attack usually called prompt injection. It can skip the model and write the tool call itself, made to look like part of the task. If your agent runs it, the seller gets whatever your agent is allowed to do.

• Read access puts a file's contents in the tool result. Agents usually send that result back with their next request, which normally goes to the same seller. Blocking the agent's internet access wouldn't stop this, because the request itself carries the file.
• Write access lets the seller slip a change into your code or config.
• Shell access, if the agent's shell isn't confined, reaches anything your user account can, like saved credentials and SSH keys.

This is a path the design allows, not an attack I saw. Pi's security docs warn about it in general terms: "treat model-generated commands and code as untrusted," and Pi doesn't ask before every tool call. That advice holds for any provider. With OpenAI or Anthropic, though, you're trusting a known company not to write hostile replies. On Antseed, the reply comes from whichever seller your proxy picked, a stranger with a trust score.

A system prompt telling the model to behave doesn't help when the seller writes the reply. An agent that asks before running commands helps, but approvals can be fooled, and they do nothing about what the agent already sends with each request. The stronger protection is limiting what the whole agent can reach: a container or virtual machine with no credentials and only the files you'd be fine sharing. Anything you put inside it is still exposed. The one-click setup I used only changed where Pi sent its requests. It didn't change what Pi was allowed to do.

No account doesn't mean anonymous, either. A seller sees a pseudonymous wallet or peer ID, plus your IP address and the prompt itself, which can easily identify you. Payments settle publicly on Base.

Antseed versus OpenRouter

So is this worse than OpenRouter? Structurally, it's the same. Both put a middleman in front of your prompt in plaintext, and both pass it to an upstream provider. What changes is who the middleman is, and what you can hold it to.

• Who answers for it. OpenRouter is one known company with published policies and terms. On Antseed, it's whichever seller your router picks. Sellers are pseudonymous by default, though about half (36 of 68 on October 21) advertised a domain or GitHub link. A seller can have its own terms, but the network sets no common data policy.
• What happens to the prompt. OpenRouter says it doesn't store prompts or responses by default, though it samples some prompts for categorization and stores the results anonymously. It also says it will screen all requests for CSAM, zero-data-retention traffic included, and may keep flagged content. You can require zero-data-retention providers. I haven't tested any of this, but it's a public commitment. On Antseed, logging and the next hop are up to each seller, and you can't see either. The closest stronger option is a TEE seller, with the limits above.
• The connection. OpenRouter always uses HTTPS. Antseed is encrypted with most sellers and possibly unencrypted with the 12 older ones.

With automatic routing, you're trading one known middleman for whichever stranger your router picks. For a free model and a throwaway question, that barely matters. For a coding agent reading a private repository, it matters a lot.

Closing thoughts

Antseed is one of the more fun things I've tried in a while. It works, and the app is easy to use.

What stuck with me is what removing the middleman actually removes. OpenRouter doesn't just route your request. It's accountable for where your request goes, with a policy you can read and a company you can hold to it. Antseed replaced the routing with code that runs on your own machine and a peer-to-peer network with financial incentives. It hasn't replaced the accountability yet, so for now the buyer has to do that checking.

Some checks that would reduce what a buyer takes on trust already exist, in very different states.

• Refusing unencrypted sellers is a setting, but it's off by default and the app never turns it on.
• The TEE check runs by default, but a failed or missing check doesn't stop the request. A setting makes it mandatory, though on October 21 only one of the 68 sellers advertised a TEE.
• Fingerprint audits are merged but not deployed. I couldn't find a verification contract on Base, or anything in routing that reads verdicts.

These checks narrow specific risks, but they aren't accountability. They don't give you a common data policy or a process for disputes.

Other pieces still need building: an app that shows which connection you got and says plainly that the seller reads your prompt, a warning when you connect a coding agent, and a TEE check that proves your prompt was decrypted inside the enclave. Some of it will always stay with the buyer, because a seller relaying to an API reads your prompt by design.

So here's how I'd use it today: free or cheap models, low-stakes tasks, and nothing sensitive or private.

The open question is whether Antseed can close enough of the accountability gap to make its discounts over OpenRouter worth the risk.

Sources