DEV Community: AntSeed

What Is a VPR? The Private Alternative to a VPN for AI

AntSeed — Tue, 04 Aug 2026 13:11:45 +0000

Someone on my team asked me last week: "if I just route my AI calls through a VPN, that makes them private, right?"

Short answer: no. And the gap is the exact reason we started calling the thing we build a VPR, a Virtual Private Router. A VPN for AI encrypts the pipe between you and the model. The model provider at the other end still reads every word of your prompt, and still knows which account sent it. A VPR routes the request itself across independent providers, so no single company ever sees both who you are and what you asked.

I work on this stuff, so take the pitch with the salt it deserves. But the distinction is real, and once you see it you can't unsee it.

What is a VPR (Virtual Private Router)?

A VPR is a local router that sits between your app and the AI models and spreads your requests across many independent providers, instead of funneling everything to one company's servers. The analogy is tight: a VPN is to your network traffic what a VPR is to your AI requests. One protects the pipe your packets travel through. The other protects the request itself, and who can be seen making it.

The name is on purpose. You already know what a VPN does for browsing, so "virtual private router for AI" tells you the shape of the thing in four words. The VPR is the routing layer. It picks which provider serves each call, without registering you, logging you into anything, or tying the call to a billing identity.

Why a VPN does not make your AI private

Here is the part vendors skip. A VPN changes where your traffic appears to come from and encrypts it in transit. Great against your ISP, against someone sniffing the coffee-shop wifi, against a region block. It does nothing about the company at the end of the tunnel.

When you send a prompt to a hosted model through a VPN, the provider still gets the plaintext prompt. It has to, in order to answer. It still sees an API key or a logged-in session, so it still knows the account. The VPN moved the problem one hop upstream and stopped. Your ISP no longer sees the prompt. The AI company sees all of it, exactly like before.

The "AI VPN" wave solves the wrong half

In 2026 the big VPN brands noticed people wanted AI privacy and shipped for it. ExpressVPN built a local bridge that lets AI assistants manage VPN routing through MCP. Norton launched per-agent VPN tunnels, each agent getting its own throwaway identity. Both are real engineering, not vaporware.

Honestly, though? Most of the "AI VPN" launches this year are a region switcher with a new landing page. A per-agent tunnel still terminates at a single AI provider that reads the prompt and knows the account behind the tunnel. Rotating the region protects the transport and the network identity. It does not remove the one company at the destination with a full view of your input. That is the half a VPR is built for, and the half a VPN structurally cannot reach.

VPN vs VPR, side by side

	VPN (including "AI VPN")	VPR
Encrypts your traffic in transit	Yes	Yes, encrypted by default
Hides your prompt from your ISP	Yes	Yes
Hides your prompt from the AI provider	No	Yes, no single provider sees the whole picture
Removes the single company watching you	No	Yes, requests spread across independent providers
Ties every request to an account	Yes	No account exists to tie it to
Changes your apparent region	Yes	Not its job

Read it as two different jobs, not two competitors. A VPN answers "who can watch my connection." A VPR answers "who can read my prompt and prove it was mine." Most people asking for "a VPN for AI" actually wanted that second answer and had no word for it.

Where a plain VPN is still the right tool

A comparison that only flatters one side is an ad, so here is the honest line. If your problem is that a model is blocked in your country, you want a VPN, not a VPR. On hostile wifi and want the whole device encrypted? VPN. Need your traffic to look like it comes from Frankfurt? VPN again. A VPR does none of that and is not trying to.

They stack, too. Run a VPN underneath a VPR: the VPN hides the connection from your network, the VPR hides the request from any single AI company. Different layers, no conflict.

How a VPR actually works, in commands

AntSeed is a working VPR, and it is open source. You run a small local proxy, then point any OpenAI-compatible tool at it.

npm install -g @antseed/cli
antseed buyer start   # local proxy on http://localhost:8377

export OPENAI_BASE_URL=http://localhost:8377/v1

That is the whole integration for most tools. It speaks both the OpenAI and Anthropic APIs, so Aider, Continue, Cline, opencode, Claude Code, and Codex work with a base-URL swap and nothing else.

Under the hood, the proxy discovers providers across a peer-to-peer network, scores them on price and reliability, and routes each request to whichever one fits. No account means no billing profile attaching prompts to your name. Requests spread across independent providers means no single operator builds a history of everything you have asked. The scoring step matters here too, since you are never quietly pinned to one provider that slowly learns your patterns. The privacy is a property of the routing, not a promise in a policy doc that changes next quarter.

One caution: private is not the same as anonymous

Before you assume a VPR hands you everything, know that routing privately and being anonymous are two separate properties, and a tool can give you one without the other. A provider serving a request may still read the content of that single call even when it cannot tie the call to you. I wrote up that whole split in anonymous AI vs private AI, and it is worth reading before you decide which guarantee your situation actually needs.

FAQ

What is a VPR?
A VPR, or Virtual Private Router, is a local router that spreads your AI requests across many independent providers instead of sending them all to one company. A VPN protects your network connection. A VPR protects the request itself, so no single provider sees both who you are and what you asked.

Does a VPN make my AI prompts private?
No. A VPN encrypts the connection and can change your region, which hides your traffic from your ISP. The AI provider at the end of the tunnel still receives your prompt in plaintext and still knows which account sent it. The tunnel is private, the destination is not.

Is a VPR just an "AI VPN" with a new name?
No. The recent AI VPNs from ExpressVPN and Norton protect the transport and network identity, but each request still terminates at one AI company that reads it. A VPR removes the single provider by routing across many, which is the part a VPN cannot do.

Do I still need a VPN if I use a VPR?
Only for VPN jobs. If a model is region-blocked, or you want your whole device encrypted on untrusted wifi, use a VPN. A VPR does not do those. For hiding your prompt and identity from the AI provider, the VPR is the tool. You can run both, stacked.

Which tools work with it?
Anything that speaks the OpenAI or Anthropic API. Set OPENAI_BASE_URL to the local proxy and Aider, Continue, Cline, opencode, Claude Code, and Codex route through it unchanged. No SDK swap, no code rewrite.

Do you need a VPR?

Name your risk in one sentence. If it is "the AI company should not be able to read, keep, or attribute my prompts," or "I don't want to be locked to one vendor who sees everything," a VPR fits and a VPN alone won't get you there. If it is "the model is blocked where I am," reach for a VPN. If it is both, run one under the other.

The reason the word matters is that the wrong tool fails silently. Nobody notices their VPN left the prompt fully readable at the other end until the day that readability costs them something.

What are you routing your AI calls through right now, and does the provider on the other end know it is you? Curious where people land on this, drop it in the comments.`

Anonymous AI vs Private AI: Not the Same Thing

AntSeed — Wed, 29 Jul 2026 15:00:28 +0000

Someone on our Telegram asked me last week whether a certain AI provider was "private." I gave a two sentence answer, then spent the next ten minutes untangling it, because the question was hiding two completely different questions inside it.

Here is the short version. Private AI means the provider cannot read the content of your prompt. Anonymous AI means the provider cannot tell the prompt came from you. Those are separate properties. A service can give you one and none of the other, and honestly, most of them do.

If you only remember one thing from this post, remember that. Everything below is just working out the consequences.

Two axes, not one

Every AI privacy claim I have ever read collapses into two independent questions:

Can whoever runs the model read what I sent? (content)
Do they know it was me who sent it? (identity)

Content and identity vary independently. That is the whole trick. Most confused privacy arguments online are two people talking past each other because one is arguing about content and the other is arguing about identity, and neither says which.

Private AI lives on the content axis. The provider cannot read your plaintext, or contractually will not, or is technically prevented from doing so by hardware.

Anonymous AI lives on the identity axis. The provider might read your prompt word for word, and still have no idea whose prompt it is.

Neither one implies the other. Not even a little.

The 2x2 that sorts the entire market

Put content on one axis and identity on the other. Every real product lands somewhere in here:

	Provider can read content	Provider cannot read content
Identity known	Hosted consumer chatbot	Enterprise deployment in your own cloud
Identity unknown	P2P inference, standard provider	TEE provider, or a local model on your machine

Top left is where most people live. Your account is known, and every message is readable. Bottom right is the model running on your own hardware. Nobody sees the content, nobody knows you ran it.

The interesting stuff is the two off diagonal boxes. That is exactly where a product hands you one property, and it becomes very easy to assume you walked away with both.

What vendors mean when they say "private"

Almost always the content axis, and usually in the enterprise sense: we don't train on your data, retention is short, access is controlled.

That is a real guarantee. It is also completely compatible with knowing exactly who you are.

Concrete example. OpenAI retains API inputs and outputs for up to 30 days for abuse monitoring, then deletes them, and does not train on API data by default. Zero retention exists, but it is approval gated for qualifying enterprise use cases on eligible endpoints. It is all documented in their data controls guide.

Private in a meaningful sense? Sure. Anonymous in any sense? Not remotely. Every single request is tied to a billing account, and that account is tied to a human.

What "anonymous" actually buys you

An anonymous service processes your request without knowing, or being able to prove, that it came from you specifically. No account, no email, no billing row linking a prompt to a person.

Here is the part the marketing pages skip: anonymous says nothing about content. A provider serving an anonymous request can read every word. They just cannot put a name on it.

And for a lot of threat models, that is enough. A journalist protecting a source cares far more about being unlinkable than about a provider theoretically seeing the text. Someone pasting a production database schema into a chat box cares about the exact opposite.

Different risk. Different axis. Same word used to sell both.

Where they come apart in practice

A zero retention API protects content pretty well and leaves identity fully exposed. Great if you trust the vendor but have a data handling policy to satisfy. Useless if the risk is that someone can prove you asked the question.
An anonymous relay in front of a normal model does the reverse. Identity protected, content wide open. The relay operator or the model host still reads the prompt.
A local model gives you both. It also costs you frontier capability. Rough math: a 70B model needs somewhere around 40GB of VRAM at 4 bit, and the strongest closed models you cannot run locally at all, at any price.
A TEE provider goes for both over the network. Inference runs inside a hardware enclave the operator cannot read into, with cryptographic attestation instead of a pinky promise.

Now the unglamorous bit, because I would rather say it than have you find out later. If what you actually need is a signed DPA, audit logs, and a named vendor your legal team can subpoena, an anonymous network is the wrong tool. Anonymity and accountability trade against each other by design. That is not a bug someone forgot to fix.

How to test which one you are actually getting, in five minutes

Skip the landing page. Each axis has a cheap concrete test.

Content axis. Read the retention terms, not the tagline. You are looking for a number and a default. How many days are inputs kept? Does that apply to your plan or only to enterprise agreements? And critically, is "we don't train on your data" written separately from "we don't store your data"? Those are two promises. Vendors love to keep one while implying both.

Identity axis. Look at what signup demands before your first request. Email? Phone? Card? Then your prompts are linkable to you by construction, and no privacy policy fixes that. Real anonymity looks like the absence of an account. Not a nicely worded policy about the account you were forced to create.

That second test is brutal and fast. I use it constantly.

Where AntSeed sits on the map

Since I work on it, let me be specific rather than vague.

AntSeed is a peer to peer network for AI inference, so anonymity is structural instead of a policy line. No account, no signup, and requests reach providers without carrying your identity. On the map above, the default experience is bottom left: identity unknown, content readable by whichever provider serves that request.

To climb into the "content unreadable" row, the network supports TEE providers, where inference runs inside an attested enclave the operator cannot read into. Unlinkable and unreadable over the network, which is a corner that is genuinely hard to reach any other way.

If you want to poke at it, the buyer proxy is one install and speaks OpenAI and Anthropic APIs, so existing tools just point at it:

npm install -g @antseed/cli
antseed buyer start   # local proxy on http://localhost:8377

export OPENAI_BASE_URL=http://localhost:8377/v1

Then Aider, Continue, Cline, opencode, or anything else that speaks those APIs works unchanged.

FAQ

What is the difference between anonymous AI and private AI?
Private AI protects the content of your prompts, meaning the provider cannot read them. Anonymous AI protects your identity, meaning the provider cannot link the prompt to you. They are independent properties and a service can offer either one alone.

Is a zero retention API anonymous?
No. Zero retention addresses content only. The request is still tied to a billing account, so the provider knows exactly who sent it.

Does running a local model give me both?
Yes, on both axes, since nothing leaves your machine. The tradeoff is capability and hardware cost. A 70B model at 4 bit needs roughly 40GB of VRAM, and frontier closed models are not available locally at all.

What is a TEE provider?
A provider that runs inference inside a hardware trusted execution environment. The operator cannot read the data being processed, and attestation proves it cryptographically rather than through a policy statement.

The takeaway

Name your risk in one sentence and the answer falls out.

"Someone could read what I asked" is the content axis. Local model, TEE provider, or at minimum a zero retention agreement.

"Someone could prove I asked it" is the identity axis. An anonymous path with no account behind it.

Both? Then you want the unreadable and unlinkable corner, and you should not settle for a product that only ships one half.

The vocabulary matters because the failure mode is silent. Nobody figures out they bought anonymity when they needed privacy... until the content leaks. At which point the distinction they skimmed past turns out to be the entire story.

Which axis does your current setup actually cover? Curious what people find when they run the signup test.

Most AI APIs hand you a label and ask you to believe it.

AntSeed — Tue, 21 Jul 2026 15:59:39 +0000

gpt-5.5. claude-opus-4.8. minimax-m3. "Premium model."

What happens when the endpoint quietly swaps you onto something cheaper? Or mixes your traffic across three providers? Or wraps some other API and slaps a nice name on it? Or serves you a quantized stand-in that's 80% as good and 40% of the cost?

What evidence do you actually have that you got what you paid for?

Honestly, for most APIs the answer is: none. You have a string in a JSON field. That's it.

At AntSeed we're building the verification layer that string was always missing.

A label is not evidence

This isn't some paranoid hypothetical I dreamed up. There's a paper called Real Money, Fake Models that audited "shadow" APIs claiming to serve official frontier models. They found real divergence in utility, safety, and identity. The incentive writes itself. Charge for the expensive model, ship something cheaper, keep the spread. Rinse, repeat.

A centralized provider can wave you toward their brand, their contract, their support desk when you complain. Fine. But a peer to peer market has none of that. Our sellers are independent peers. There's no head office to email. So the evidence has to live somewhere else... it has to travel with the response itself.

And here's the distinction that took us a while to say cleanly:

Signed responses do not prove model identity. They prove who served which bytes.

That's the foundation. Get attribution first. Once a seller's output is provably theirs, you can layer statistical model auditing on top. Cryptographic provenance, then behavioral verification. Order matters, and I'll come back to why.

What's shipping right now: ResponseAuth

The first piece already lives in @antseed/node.

For supported buyer to seller connections, the seller signs a ResponseAuthPayload right after serving a response. That payload locks in:

the request hash and the response hash
buyer peer id and seller peer id
the advertised service and provider name
status code and timing
an optional payment channel id

The buyer checks the signature against the seller's peer identity, then stores the result locally. And a random sample of verified exchanges gets written to disk as full evidence:

<dataDir>/verification_samples/
  <sellerPeerId>/
    <sampleId>/
      manifest.json
      request.bin
      response.bin

Now, this does NOT tell you the response came from the model on the label. Read that twice, because people get it twisted. What it tells you is that the seller can never later deny serving those exact bytes.

That's the whole game right there. It's the line between a complaint and a receipt.

What comes next: fingerprint verifiers

The next layer isn't one clever test. It's a suite. Truth be told, anyone selling you a single "is this the real model?" oracle is selling you something that doesn't exist.

Different cheats leave different fingerprints:

A cheap substitute tends to fall apart on knowledge boundary probes.
A wrapper around a real model can leak instruction hierarchy artifacts.
A relay sometimes gives itself away through runtime behavior.
A whole model family carries rare token or perturbation signatures you can measure.

So the spec tracks a bunch of verifier families, each catching a different lie:

KBF (knowledge boundary fingerprinting): numeric probes right at the edge of what the claimed model should know. See the paper and the reference implementation.
LLMmap-style behavioral probes: prompts picked specifically because model families answer them differently. LLMmap.
TRAP-style adversarial triggers: private prompts that pull out distinctive target-model behavior. TRAP.
ZeroPrint-style perturbation fingerprints: watch how answers shift under meaning-preserving input tweaks. ZeroPrint.
UTF / rare-token fingerprints: poke at under-trained or weird tokens and see what falls out. UTF.
LLMPrint-style prompt-injection fingerprints: exercise instruction hierarchy and injection behavior. LLMPrint.
Julius-style service fingerprints: figure out the serving stack itself, Ollama, vLLM, LiteLLM, whatever's underneath. Julius and its repo.
READER-style passive provenance: analyze ordinary signed responses after the fact. READER.

None of these is gospel on its own. That's the point. You build a suite where independent signals stack up. A SAME result is not a certificate of authenticity. But a strong DIFF, backed by signed response evidence and reproducible references? That's something a buyer can actually act on.

Why public fingerprints should behave like torrents

Here's a tension I keep chewing on.

Private probes are what you need for real enforcement. Because if every seller can see your exact test set, a dishonest one just routes those specific prompts to the real model and serves garbage for everything else. Classic teach-to-the-test.

But public fingerprints still matter a ton. Reproducibility. Smoke tests. Shared baselines. Research. Network-wide learning. The question was never whether to publish them. It was how to publish them without turning AntSeed into yet another centralized API or some hosted database that becomes a single point of failure (and control).

Our answer in the spec: a fingerprint swarm.

Think torrent, not registry.

Torrent concept	AntSeed fingerprint swarm
`.torrent` / magnet metadata	fingerprint pack announcement
info hash	`packId`
tracker / DHT	AntSeed discovery topics
seeders	peers mirroring verified packs
downloaded files	signed fingerprint packs
piece hashes	optional chunk hashes
uploader identity	publisher peer id + signature

A fingerprint pack is a signed, content-addressed bundle. A peer announces a little metadata. Other peers grab the pack from any mirror or seeder, verify the content hash, verify the publisher signature, and then decide for themselves whether to trust it.

The trust model is honestly kind of beautiful in how boring it is:

Discovery tells me a pack exists.
Storage gives me bytes.
Hash proves the bytes are correct.
Signature proves who published the pack.
Local trust policy decides whether I use it.

No central server has to be the oracle. GitHub can be a review surface and a bootstrap mirror. IPFS, Arweave, plain HTTPS mirrors, AntSeed peers, all of them can serve the same pack bytes. Doesn't matter where it came from. If the hash and signature check out, the pack is valid. Full stop.

What this actually enables

The long-term flow ends up looking like this:

A seller advertises a model or service.
The buyer sends normal requests through AntSeed.
The seller signs response provenance with ResponseAuth.
The buyer stores that verified evidence locally.
The buyer imports trusted public fingerprint packs from the swarm.
The buyer keeps private references around for the tougher audits.
The buyer runs the fingerprint verifiers locally.
Routing quietly steers away from sellers with bad evidence.
Disputes and slashing come later, and only after off-chain verification.

That ordering is the whole philosophy, so let me be blunt about it. We do NOT open with slashing. Punishment-first designs are how you get a network full of angry false positives and no sellers. Instead: make responses attributable,

Inference Is the New Oil: Who Controls the Pipe

AntSeed — Wed, 08 Jul 2026 09:23:51 +0000

Inference Is the New Oil- And Most of It Is Sitting Idle
Two-thirds of all AI compute is now inference. Not training. Not research. Serving requests, in production, right now.

That single number — flagged by hardware analyst Derek Colley when comparing Trainium3 and Nvidia's NVL72 rack specs — reframes the entire AI infrastructure conversation. Training built the models. Inference is where the money actually prints. And the industry is only just catching up to that reality.

The Shift Nobody Announced
For years, "AI compute" was shorthand for training runs: the multi-million-dollar, months-long jobs that produced GPT-4 or Claude. Infrastructure investment followed that assumption. Chip design followed it. Investor narratives followed it.

Then inference quietly ate the workload.

McKinsey projects inference will surpass training's share of total AI compute by 2030. Based on the current two-thirds figure, that projection looks conservative. The crossover already happened — we're now watching the gap widen.

The market noticed. Brad Gerstner publicly stated that Anthropic's revenue "went totally parabolic" after Opus 4 launched, suggesting the company could approach $100 billion in annual revenue. He called it "the single most important thing in the market." The Philadelphia Semiconductor Index — a reasonable proxy for how capital is reading AI infrastructure — was up 80% on the back of that revenue signal alone.

Inference profitability isn't a thesis anymore. It's a reported result.

The Hardware Bet Is Changing
When inference dominates the workload, the optimal chip is no longer necessarily the one that wins training benchmarks.

That logic is playing out in real hardware decisions right now. DeepSeek is reportedly building its own inference-specific chip, deliberately stepping back from Nvidia and Huawei silicon. The explicit design goal is inference efficiency — not raw training throughput. AWS's Trainium3 reaches approximately 362 MXFP8 PFLOPs at rack scale. Nvidia's NVL72 sits at roughly 360 PFLOPs on the same metric. On paper, for inference workloads, they're tied.

The GPU-as-default assumption is cracking. Cerebras has positioned itself on latency. Specialized inference chips from multiple directions are closing the gap that Nvidia held comfortably for the training era.

This isn't a chip story. It's a signal that inference has its own economics — and those economics reward different architectural choices than training did.

The Real Bottleneck Isn't Supply
Here's the counterintuitive part: GPU shortage and idle GPU supply are being discussed simultaneously, by serious people, as both being real.

That's not contradiction. That's a distribution problem wearing a capacity problem's clothes.

AI demand is outpacing available supply in the right locations, at the right latency, with the right access layer. Meanwhile, millions of deployed GPUs sit underutilized. The shortage is organized routing, not raw silicon.

Projects like RENDER's Dispersed are building directly on this arbitrage — the gap between deployed GPU capacity and actually-utilized GPU capacity. The thesis is that idle compute is the real unlock, not new builds. If you can route inference workloads to existing hardware that's currently doing nothing, you've solved the shortage without manufacturing a single new chip.

This is the same structural insight that made content delivery networks (CDNs) valuable in the early web era. Building more servers wasn't the answer. Routing intelligently to existing ones was.

AntSeed's Position in This Picture
AntSeed is infrastructure for this exact moment. The core bet: inference routing through a decentralized provider network eliminates the gatekeepers that sit between model capability and the people who need it.

When inference is the workload — not training, not fine-tuning, but live, continuous, production serving — the structural question becomes: who controls the routing layer? Centralized aggregators set the terms. They decide pricing, availability, and access. That's fine until it isn't — until a model goes dark, a rate limit hits, or costs spike because a single provider had a quarter to make.

AntSeed routes around that. Providers plug in compute. Buyers get inference. No single point of control. Check live network stats to see the current state of the network — requests handled, providers active, cost per token versus centralized alternatives.

The comparison to OpenRouter and other aggregators isn't abstract. It's architectural. One model centralizes routing control; the other distributes it. When inference is two-thirds of all AI compute and that share is growing, the routing layer is the oil pipeline. The question is who owns it.

What This Means for the Next Two Years
A few things that follow from the inference-first reality:

Model providers will be judged on serving economics, not just benchmark scores. Anthropic's parabolic revenue is a serving story, not a training story.
Chip design will bifurcate further. Training chips and inference chips will increasingly be optimized for different objectives. Buying the best training chip to run inference is like buying a freight truck to do last-mile delivery.
Idle compute becomes a real asset class. The gap between deployed and utilized GPU capacity is large enough to build businesses on — and several projects already are.
Routing infrastructure becomes critical. When inference supply is distributed across data centers, idle consumer hardware, and specialized inference farms, the value lives in the layer that organizes it all.
The oil analogy holds precisely because oil's value wasn't in finding it — it was in refining it, transporting it, and getting it to where it was needed, when it was needed. Inference is the same. The models exist. The compute exists. The value is in the pipe.

Inference overtook training as the dominant AI workload. That's already happened. The hardware industry is catching up to it, the chip design assumptions are shifting because of it, and the revenue numbers from model providers are confirming it.

The bottleneck going forward isn't capacity — it's organized routing of capacity that already exists.

Why we're building an AI market where nobody's the middleman

AntSeed — Sun, 05 Jul 2026 22:32:51 +0000

Quick disclosure before anything else: I'm on the team behind this. Not a neutral reviewer, just someone who got tired of the same thing you probably did.
So a few of us built AntSeed. It's an open market for AI inference. Anyone can sell intelligence, anyone can buy it. Your request goes straight to whichever provider fits, cheapest, fastest, or the one with the best track record, instead of whoever your subscription picked for you months ago.
The part that actually convinced me wasn't the pitch. It was realizing there's no position in this network from which anyone can gatekeep. Not us, not anyone. That's not a policy we wrote down somewhere. It's just how the thing is built.
A few things worth knowing-

No account wall. You open it, you ask something, that's it.
Payments settle per request, straight to the provider.
Some providers run on privacy-hardened hardware, if what you're sending needs to actually stay private.

Two things while I've got you here-
If you've got spare GPU capacity or you're already running inference **for something else, we're looking for more providers on the supply side. Bring your own hardware or API capacity, price it however you want, build a reputation that's yours to keep. No approval process, no listing fee.
And separately, honestly the one I'm most excited about: **we're opening up an early alpha for model fingerprint verification. The short version of the problem... on an open market, how do you actually know the model you're paying for is the model you're getting? We're building a verification layer around it, and we want a small group of technical people poking holes in it before it's public.
Happy to answer anything below, especially the skeptical questions. Those are usually the good ones.