Claude Mirror Sites: Web Mirrors vs API Relay Endpoints, and How to Tell Which You Need (2026)

People searching for a "Claude mirror site" are not all looking for the same thing. Some want a web page they can open and chat in. Others want an endpoint address they can paste into Claude Code or their own code. These two forms have different architectures, different capability limits and different risk profiles, and picking the wrong one is where most of the wasted effort comes from. This article separates them, then gives you the signals worth checking and the trade-off against calling the official API directly.

"Mirror site" covers two very different things

The word mirror is borrowed. It originally described exact copies of software repositories and documentation sites. Applied to Claude, it ends up covering two quite different services:

Autocomplete shows both intents sitting in the same keyword cluster. Deciding which one you actually need, before you start, saves a lot of dead-end attempts.

Web mirrors: the chat interface on a different domain

This form gives you a page. You type a question, the server calls some model API, and the result is rendered back. For a one-off "just let me try it" moment, the barrier is genuinely the lowest available.

It also carries structural blind spots that have nothing to do with who runs it. They come from the form itself:

• You cannot see what is being called. A model name printed on the page is not proof the request reached that version. The web form hands you no verification surface: no response headers, no token counts, no request IDs.
• Session content passes through a third party. Everything you type goes through the operator's servers in full. That is true of any intermediary; the difference is whether the operator documents how the data is handled.
• Account ownership is unclear. Whose upstream account is being used, and under what terms, is usually not stated on the page. Anthropic's usage policies have their own provisions on account sharing — check the current official terms rather than assuming.
• It cannot enter an engineering workflow. No endpoint means no scripting, no IDE integration, no automation. If Claude Code or Codex is the goal, the API form is the only starting point.

The conclusion is not that the web form is unusable. It is that the web form suits casual trials, not workflows, and is a poor place for sensitive content.

API relay endpoints: forwarding at the protocol level

The other form is endpoint-level. You get a base URL and a key issued by the relay operator. Your request goes to the relay, which forwards it upstream and returns the response. A well-behaved relay does not alter model output — it changes the network path, credential ownership, protocol shape and metering.

On the client side, usually only two values change:

ANTHROPIC_BASE_URL=https://your-endpoint.example.com
ANTHROPIC_AUTH_TOKEN=key-issued-by-the-relay

Most CLI tools read these at startup, so a change requires a restart. The mechanics, the self-hosted versus managed trade-off, and the regression checklist to run before moving production traffic are covered in what a Claude API proxy is, so they are not repeated here. If your tooling only speaks the OpenAI protocol, the compatibility boundaries are in what an OpenAI-compatible API is.

Which one do you need?

• Just asking a few questions in a browser → the web form is enough; prefer official channels and check regional availability rules.
• Wiring up Claude Code, Codex or Cursor → API form only; a web mirror cannot help. See using Claude Code from China.
• Calling from your own server code → API form, with the base URL and key as configuration rather than hardcoded values. Start from how to use the Claude API.
• A team sharing one upstream quota → API form, with per-key issuance and per-key quotas.
• You can register officially and do not need shared billing → call the official API directly. See Anthropic Claude API access.

Four signals worth checking on an endpoint

A web mirror offers almost nothing to verify, so the following applies mainly to the API form — which is itself a practical argument for preferring it: it can be checked.

Latency, measured at the tail rather than the mean. An extra network hop always costs something; what matters is the slow percentiles. Test the relay endpoint and the official endpoint side by side from the same machine instead of reading a single one-sided number.

Whether the model version lines up. Does the identifier returned in the response match the model you asked for? Version aliases — anything pointing at "latest" — can resolve to different concrete versions behind different intermediaries. A prompt that is sensitive to version differences tells you more than any description.

Whether metering is inspectable. Does the response still carry per-call token counts? Can you pull usage broken down by key and by model? Without that, reconciliation has no independent basis.

Whether data handling is documented. Is request content retained, for how long, and used for what? This should exist in writing rather than being inferred. Absent a clear statement, keep sensitive content out.

Worth testing separately: streaming, multi-turn tool calls, prompt cache hits, and whether rate-limit headers survive the hop. All four belong to the category that passes a naive test and only breaks under real load — the checklist in the proxy article above covers how to exercise them.

Direct official API versus an intermediary

The decision is short.

If you can reach the official endpoint reliably, one account per person is acceptable, and you need no protocol translation, default to the official API. It is the shortest path with the clearest boundary of responsibility, and when something breaks there is only one party to investigate.

An intermediary starts to earn its place when any one of these holds: your network environment cannot reach the official endpoint reliably; a team needs to share one quota with per-member accounting; or your tooling speaks only the OpenAI protocol and you would rather not modify code. In those cases you are trading one extra hop and one extra party to trust for reachability, unified metering or protocol compatibility. Whether that trade is worthwhile depends on how much those three matter to you.

The trade-off itself is the point: an intermediary does not make the model stronger. It changes the path. Any claim that a middle layer improves model capability itself deserves scepticism first.

FAQ

Is a Claude mirror site the same as a Claude API proxy?

No. In common usage a mirror site means a web page you open and chat in, while a relay endpoint is an address for code and tools. Both forward requests, but they differ in delivery form, how much you can verify, and what they are good for.

Are web-based Claude mirror sites safe?

It depends on the operator, and there is very little you can verify. Everything you type passes through their servers in full, and the page form exposes no response headers or token counts to check against. Fine for a quick trial; not advisable for sensitive content.

Can Claude Code connect to a mirror site?

Not to a web form. Claude Code needs an endpoint speaking the Anthropic protocol or a compatible one, configured as a base URL plus a key — not a page link.

How do I confirm a relay is using the model version I selected?

Check that the model identifier in the response matches the request, and watch how version aliases resolve. Pair that with a prompt sensitive to version differences; it is more reliable than reading a description.

Should I default to the official API or an intermediary?

Default to the official API when you can reach it reliably. A middle layer is worth its added complexity only when reachability, shared team billing or protocol compatibility applies.

ROIBest AI exposes both Anthropic-native and OpenAI-compatible endpoints, supports per-key issuance with quotas, and reports usage by key and by model. To start integrating, see connecting Claude Code in three steps.