Compatibility mode

Compatibility mode lets an off-the-shelf OpenAI client talk to AnonRouter with a plain Authorization: Bearer key and no ticket step. A dedicated broker accepts the key, mints a single-use ticket internally, and forwards the request. It is the simplest way to integrate, at a cost to unlinkability.

Privacy tradeoff

Compatibility mode drops the single-use ticket. The broker receives your API-key identity and plaintext request together in memory. It logs metadata only and holds no database or provider credentials, but this flow is not unlinkable like the private ticket flow.

Enable it

Compatibility mode is off by default and gated two ways:

The operator must enable it on the deployment. Check GET /v1/auth/capabilities, which reports compat.enabled.
The individual inference key must be marked for OpenAI-compatible access. Turn this on when you create the key in the dashboard.

A key without the compatibility flag receives a permission_error telling you to enable it or use the ticket flow.

Use the OpenAI SDK

Point the SDK at the router base URL and pass your key. Do not send a ticket header. Sending both a key and a ticket is rejected.

from openai import OpenAI

client = OpenAI(
    api_key="ar_your-compat-enabled-key",
    base_url="https://api.anonrouter.ai/v1",
)

completion = client.chat.completions.create(
    model="meta-llama/llama-3.3-70b",
    messages=[{"role": "user", "content": "Hello from AnonRouter"}],
)

print(completion.choices[0].message.content)

Streaming works normally. The stream ends with data: [DONE] only after billing has settled. If a stream fails, the broker closes the connection without a final [DONE], so treat an early end as an incomplete response.

What works in compatibility mode

Endpoint	Supported
`POST /v1/chat/completions`	Yes, streaming and non-streaming
`POST /v1/embeddings`	Yes
`GET /v1/models`	Yes, as a plain bearer call to the control plane
`POST /v1/completions`	No, returns `404`. Use chat completions.
`POST /v1/images/generations`	No, use the Studio flow
`POST /v1/audio/speech`	No, use the Studio flow

OpenAI-compatible, not Anthropic

AnonRouter exposes the OpenAI Chat Completions surface. There is no Anthropic Messages endpoint. Models from any creator, including Claude-family routes, are reached by their model id through POST /v1/chat/completions.

Request restrictions

The compatibility broker forwards requests through the same strict chat and embeddings contract as the ticket flow:

Message content must be a string. Array or multimodal content is not accepted.
Unknown fields are rejected. Fields such as n > 1, logprobs, and logit_bias are not honored.
Legacy functions and function_call are rejected. Use tools.
The model must be an enabled chat or embeddings model. An unknown or incompatible model returns model_not_found.

Error format

Errors use the OpenAI error envelope:

{
  "error": {
    "message": "This API key is not enabled for OpenAI-compatible access.",
    "type": "permission_error",
    "param": null,
    "code": "compat_scope_required"
  }
}

The type is one of authentication_error, permission_error, invalid_request_error, insufficient_quota, rate_limit_error, or api_error. The HTTP status code is authoritative. Server-class errors carry a generic message so no internal detail leaks.

Enable it

Use the OpenAI SDK

What works in compatibility mode

Request restrictions

Error format

On this page