A new kind of AI router

The last prompt you sent through an AI router might have held source code, a contract, or something you would not tell a coworker. A traditional router could read all of it. AnonRouter cannot, and you do not have to take our word for it.

The seat in the middle

A router earns its place by sitting in the middle. You get one API key, one bill, and every model worth calling. Your app sends a request, the router picks a provider, forwards the request, and meters the result. That position is also the problem. Every prompt from every app you build passes through one company, and prompts are often the most sensitive thing you send anywhere.

A typical router can see all of that and save it. Some keep it for debugging, some under terms that allow training, and every one of them asks you to trust the policy.

When Stripe agreed to acquire OpenRouter, a lot of developers took a fresh look at the companies sitting between their apps and their models. We did too, and we saw a story the tech industry has told many times. A giant pays a premium for a startup everyone loves. Then the price has to be earned back somehow, and too often it gets earned back at the expense of the users who made the startup worth buying. When a router can read your traffic, whoever owns the company owns the view, and ownership can change hands overnight.

Splitting the router in two

AnonRouter is built as two separate systems. One handles your account: sign-in, keys, balances, and billing. The other handles content, meaning your prompts and the responses that come back. Neither one gets the full picture of a request.

The content side runs inside protected hardware, in Intel TDX confidential VMs that terminate TLS inside the enclave. Your prompt goes straight there and is decrypted inside verified hardware rather than on an ordinary server. It stays in memory while the model serves it. It is never written to disk and never used for training, and the model provider you pick receives only what it needs to answer.

The account side gets one row of metadata per request: the model, token counts, status, latency, cost, and a timestamp against an opaque account id. That is enough to authorize the request and settle the bill. It is not enough to know what you asked.

Checking instead of trusting

Plenty of companies say they do not read your prompts, and most of them mean it on the day they say it. But terms get rewritten and companies get sold, and a promise only lasts as long as the people who made it.

"Most privacy claims in AI are promises about what a company will choose not to do. We built something you can verify instead of taking our word for it."

That is how Ben Schumacher, AnonRouter's CEO, put it when we announced the launch.

The privacy-critical code is open source. The confidential content plane is public on GitHub, and so are the client and verification SDKs. Before the confidential client sends a prompt, it asks the live service for a hardware attestation and checks that what is running is the code we published. If the check fails, the client refuses to send anything.

The check runs on your side of the connection. The reviewed measurements ship inside the SDK instead of being fetched from the server under test, so the server never gets to vouch for itself. What each verification level proves, and what it does not, is covered in Introducing the AnonRouter Confidential SDK.

All the models, none of the snooping

None of this matters if the router is worse at being a router. AnonRouter gives you more than 300 models through one API, with chat completions, embeddings, streaming, tool calls, image generation, speech, and more. If your app already uses an OpenAI-compatible SDK, switching is one configuration change:

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.anonrouter.ai/v1",
  apiKey: process.env.ANONROUTER_API_KEY,
});

const res = await client.chat.completions.create({
  model: "/auto",
  messages: [{ role: "user", content: "..." }],
});

Send /auto as the model and AnonRouter picks the most capable model that meets your privacy requirements at the lowest available price. Name a model instead and you get exactly that one.

Privacy requirements come in four levels: Anonymous, Private, TEE, and E2EE. Every route in the catalog carries one, and routing enforces the label instead of just printing it. The levels mean genuinely different things, and we try hard not to blur them. Anonymous hides who you are from the provider. E2EE means your client encrypts the request to an attested enclave and only that enclave can open it.

Accounts work with or without an email address. A private account is a username, a password, and a recovery phrase you write down. The tradeoff is that we cannot reset it for you, because there is no inbox to send a reset to.

Where to start

Create a key on the API keys page and filter the catalog by the privacy level you need. The docs live at docs.anonrouter.ai. The code that keeps your prompts private is at github.com/anonrouter/confidential-content-plane and github.com/anonrouter/anonrouter-sdk, for anyone who would rather read it than take our word for it.