AnonRouter vsOpenRouter

OpenRouter routes your prompts in the clear and asks you to trust its policy. AnonRouter runs prompt handling inside an attested enclave and publishes that code under Apache 2.0.

What’s the difference between and ?

Both routers put one API in front of many providers. They differ in what the layer between your application and the model is designed to guarantee. OpenRouter connects you to a large catalog of models and providers through one API, and stops there. AnonRouter puts a strict content-retention boundary and privacy-aware routing layer between your application and 200+ models.

  1. You + Ticket

    Anonymous

    encrypted
  2. Protected hardware

    Intel TDX enclave

    protected
  3. Your model

    Private

Protected hardware isolates prompt handling. The model and provider you choose determine the route’s privacy level.

At a glance

AnonRouter vs OpenRouter

Eight things AnonRouter does that OpenRouter's gateway does not. Every row is a capability, not a setting you have to trust someone to leave switched off.

Source of the code handling prompts

AnonRouter

Yes. Apache 2.0, including every component that can touch plaintext.

OpenRouter

No. The gateway that receives your prompts is closed source.

Verifying the privacy claim

AnonRouter

Yes. Pull the enclave attestation with the SDK and check it against the published build.

OpenRouter

No. There is nothing to attest against, so the policy is the guarantee.

Prompt and response storage at the router

AnonRouter

Never. There is no content-logging switch to enable later.

OpenRouter

Possible. Content logging ships as an account setting, off by default.

Router-side use of inputs

AnonRouter

None. No training and no durable prompt categorization.

OpenRouter

Yes, by arrangement. A 1% discount is offered for data use, and prompts may be sampled.

End-to-end encrypted routes

AnonRouter

Yes, wherever the provider runs an enclave. The router holds no key.

OpenRouter

No. Prompts arrive at the gateway in plaintext.

Identity separated from request content

AnonRouter

Yes. A ticket flow splits account identity, plaintext, and provider credentials.

OpenRouter

No. One proxy, and every request stays attributable to your account.

Privacy floor on automatic routing

AnonRouter

Yes. /auto stays inside a privacy boundary and fails closed when nothing qualifies.

OpenRouter

No. Their docs state routing rules do not change based on a provider's retention policy.

Account without an email address

AnonRouter

Yes. Private accounts open with a recovery phrase instead of an inbox.

OpenRouter

No. Registration is required to get a key.

What each router can see

A promise you can read, or a boundary you can verify.

Both routers publish a privacy policy. Only one of them publishes the code that the policy is about, which is the part you cannot audit from the outside.

“This setting has no bearing on OpenRouter's own policies and what we do with your prompts.”
OpenRouter's own documentation, on the training opt-out. Privacy and logging

Your prompt at the router

AnonRouter

Handled inside an attested enclave, and on E2EE routes encrypted to that enclave so the router holds no key.

OpenRouter

Arrives in plaintext on OpenRouter's servers, which is what lets it route and bill the request.

Who the request belongs to

AnonRouter

A ticket. The system that knows your account and the system that sees content are separated.

OpenRouter

A registered account. Usage is attributable to you by design.

Code that can touch plaintext

AnonRouter

Published under Apache 2.0 as the confidential content plane, which is every component inside the enclave.

OpenRouter

Closed source. The published SDKs run on your side; the service handling the prompt is not public.

How you check it

AnonRouter

Run the SDK, pull the enclave's attestation, and compare it against the published build.

OpenRouter

Read the privacy policy and trust it.

Retention policy and routing

AnonRouter

Routing filters to eligible privacy levels first and fails closed rather than downgrading.

OpenRouter

Documents that routing rules do not change based on a provider's data-retention policy.

Why AnonRouter

Privacy is part of the architecture

The value is not only access to models. It is what the router is structurally unable to retain.

Audit the router instead of trusting it

Every component that can touch prompt plaintext is published under Apache 2.0, and the SDK checks the enclave's attestation against that build.

Remove prompt logging from the product

Prompts and responses are never written to disk. There is no router-side content logging switch to enable later.

Know what you pay

Model usage is billed at listed rates. Credit purchases include a separately disclosed platform fee, currently 5%.

Separate identity from request content

The private ticket flow splits the systems that know your account, handle plaintext, and hold provider credentials.

Route inside a privacy boundary

The /auto router filters to eligible privacy levels first, then selects for capability, quality, and cost.

See what every route guarantees

Anonymous, Private, TEE, and E2EE labels make the actual privacy boundary visible before a request is sent.

For both routers, upstream provider policy still matters. A no-log router cannot make every model provider private. Review the exact route label, and use an explicitly supported E2EE route when you need the strongest available boundary.

Which one is right for you?

Choose AnonRouter if…

  • You need to audit the code that handles prompts, not just read a policy
  • Router-side content logging must be impossible, not just off
  • Account identity and request content must stay separated
  • Automatic routing needs a privacy floor that fails closed
  • You want a private account without an email address

Choose OpenRouter if…

  • You need a specific model that is not in our catalog yet
  • Your product depends on an input type our catalog does not cover
  • You rely on BYOK
  • You would rather hand-tune provider selection than route inside a privacy boundary

Common questions

The gateway is not, and the gateway is the part that handles your prompts. OpenRouter publishes SDKs for TypeScript, Python, and Go, its documentation, and a Terraform provider, but those are clients that run on your side. The service your prompt is actually sent to is closed source, so how it handles that prompt can be read about and never inspected. AnonRouter publishes the opposite half: the confidential content plane, every component inside the attested enclave that can touch prompt or response plaintext, is Apache 2.0 at github.com/anonrouter/confidential-content-plane.
Your prompts reach OpenRouter's servers in plaintext, because that is what lets it route and bill the request, so the service is technically able to read them. OpenRouter's policy says it does not persist prompt content beyond what routing requires, apart from abuse detection, security, billing, and legal compliance, and there is no reason to assume otherwise. The limitation is that this is a policy rather than a property you can verify from outside. OpenRouter's own documentation notes that the training opt-out setting has no bearing on OpenRouter's own policies and what it does with your prompts.
Run the open-source SDK at github.com/anonrouter/anonrouter-sdk. It pulls the hardware attestation from the enclave serving your request and checks it against the published build of the confidential content plane, so you confirm which code is handling your prompt rather than taking our word for it. On end-to-end encrypted routes the request is encrypted to that enclave, and the router never holds a key that could decrypt it.
Compare the total for the models and routes you actually use. AnonRouter lists its own price for every model and route, and credit purchases add a separate service fee, currently a promotional 5% with a $0.75 minimum, shown before you pay. OpenRouter publishes its own model prices and fees. Per-model prices differ between the two, so a purchase fee alone does not tell you which costs less for your workload.
Usually, if your application uses OpenAI Chat Completions or embeddings. Create a compatibility-enabled AnonRouter key, change the base URL and API key, then verify model IDs and any advanced fields your application uses. AnonRouter's compatibility surface is intentionally narrower, so test multimodal, legacy completions, and provider-specific features before migrating production traffic.
When it has a model we have not added yet, when your product depends on an input type our catalog does not cover, or when you rely on BYOK. This comparison is not a claim that one router suits every workload, and the catalog gap is the honest one: we add models deliberately rather than listing everything available.

Keep exploring

Compare across the ecosystem

View all comparisons

Sources & methodology

Check the primary sources

This comparison is published by AnonRouter and is not affiliated with OpenRouter. It uses current public product pages and documentation, reviewed September 11, 2026. Pricing can change; each service's live checkout is authoritative.

See for yourself

Point your OpenAI SDK at AnonRouter, or browse the catalog first. A private account does not need an email address.