Claude Relay Service (CRS): a self-hosted relay that pools Claude, OpenAI and Gemini accounts behind your own API keys

What Claude Relay Service is for, and the warning that comes first

Claude Relay Service, usually shortened to CRS, is a relay you run on your own server. Its description calls it a one-stop open source relay that brings Claude, OpenAI, Gemini and Droid subscriptions under one entry point, with support for sharing a subscription among several people so the cost is split. The README names the situations it was written for: a region where Claude Code cannot be reached directly, worry that a third-party mirror logs conversations, a few friends splitting a Claude Code Max plan, and mirrors that keep failing.

The README puts its own risk section before any of that. It says using the project may violate Anthropic's terms of service, that all risk sits with the user, and that the author takes no responsibility for banned accounts or lost service. It also describes the project as being for technical learning and research. That warning is the first thing to weigh. A relay that shares one subscription across several people is exactly the kind of use a provider can act against, and the software cannot change that.

How requests move through the relay

CRS is a Node.js application backed by Redis. The README lists Node.js 18 or newer and Redis 6 or newer, and package.json points the main entry at src/app.js. Clients call the relay with keys the administrator issues; the example environment file sets API_KEY_PREFIX=cr_, so every issued key carries that prefix. Behind those keys sit the real accounts. The README describes rotating across several Claude accounts, switching automatically when one has a problem, recording token use per person, and routing through an HTTP or SOCKS5 proxy.

The environment file shows how traffic is split by path. Requests to /api go to the Claude account pool by default, /antigravity/api goes through Antigravity OAuth, and /gemini-cli/api goes through Gemini CLI OAuth. When an upstream account returns errors, the relay pauses routing to it for a while. Global defaults such as UPSTREAM_ERROR_503_TTL_SECONDS and UPSTREAM_ERROR_5XX_TTL_SECONDS control those pauses, and each official Claude OAuth account can override them or turn the cooldown off. The account list then shows why an account is not routable and when it is expected back, which is the part of the admin panel you will look at most when something breaks.

Installing CRS with the management script

The README recommends a management script that installs dependencies, asks a few questions and starts the service:

curl -fsSL https://pincc.ai/manage.sh -o manage.sh && chmod +x manage.sh && ./manage.sh install

The installer asks for an install directory, a service port and the Redis host, port and password, installs Node.js 18 or newer and Redis if they are missing, and starts the service. The README's example ends by printing a local and a public address ending in /web and saying the administrator account was saved to data/init.json. Afterwards the service is managed through a crs command:

crs start
crs status
crs update

The script supports Ubuntu and Debian, CentOS and RedHat, Arch Linux and macOS. It downloads and runs a shell script from pincc.ai, so read manage.sh before running it on a server that holds your account credentials.

Manual and Docker deployment

For a manual install the README clones the repository, installs dependencies, copies the example configuration files, builds the web admin and runs a setup step that generates the administrator credentials:

git clone https://github.com/Wei-Shaw/claude-relay-service.git
cd claude-relay-service
npm install
cp config/config.example.js config/config.js
cp .env.example .env
npm run install:web
npm run build:web
npm run setup
npm run service:start:daemon

Before the last step the README has you edit .env: JWT_SECRET and ENCRYPTION_KEY, plus the Redis connection. The Docker section is shorter. A script generates the compose file, then compose starts the service with Redis, persistent data and log directories, a health check and automatic restarts:

curl -fsSL https://pincc.ai/crs-compose.sh -o crs-compose.sh && chmod +x crs-compose.sh && ./crs-compose.sh
docker-compose up -d

In that mode JWT_SECRET must be at least 32 characters and ENCRYPTION_KEY exactly 32. If you did not preset ADMIN_USERNAME and ADMIN_PASSWORD, the generated credentials are in the container log or the mounted file:

docker logs claude-relay-service
cat ./data/init.json

The authentication bypass and what the defaults expose

The README opens with a security notice: versions 1.1.248 and earlier have a serious administrator authentication bypass that lets an attacker reach the admin panel without authorizing. It asks users to update to 1.1.249 or later, or to migrate to the next project. The recent releases are 1.1.313 on 2026-07-10, 1.1.314 on 2026-07-23 and 1.1.315 on 2026-09-10, so anyone on a current build is well past the fixed version. An old install that was set up once and forgotten is the case to worry about, because that panel holds the OAuth access to every pooled account.

The defaults lean towards exposure. The example environment file sets HOST=0.0.0.0, the install example prints a public /web address, and the compose file binds to 0.0.0.0 unless BIND_HOST is set. The comment in docker-compose.yml itself recommends a reverse proxy and BIND_HOST=127.0.0.1 in production. Do that before adding the first account.

Hosting constraints the README spells out

The README's hardware floor is small: one CPU core, 512 MB of memory with 1 GB suggested, and 30 GB of disk. The harder requirement is the network. The server must reach the Anthropic API, a US-region machine is suggested, and the README reports that overseas hosts from Alibaba Cloud and Tencent Cloud were blocked by Cloudflare and could not reach the Claude API directly. Picking a provider is therefore part of the installation, not an afterthought.

Adding a Claude account is manual. You generate an authorization link in the admin panel, sign in to Claude on the page it opens, and paste the returned authorization code back. The README suggests setting a static proxy IP per account if you worry about several accounts sharing one IP, and notes that people in mainland China may need a proxy for this step. Every account you add means one more OAuth grant sitting in the relay's Redis, protected by the encryption key you chose at setup.

Third-party mirrors, CRS and CRS 2.0

The alternative the README argues against is a third-party mirror site. Its complaints are specific: a mirror operator can read your conversations, gets slow when many people use it, and does not show what anything actually costs. Running CRS moves all of that to your own server. Requests go from your machine straight to the Anthropic API, usage is counted per key at official prices, and the only other users are the people you gave keys to. The price is the setup, the upkeep and the account risk you take on yourself.

The README also points to a successor, CRS 2.0, published as sub2api, as the recommended migration path next to the security update. It does not describe what changes between the two, so the decision to move depends on reading that project's own documentation rather than anything in this repository.

Editorial conclusion

Run Claude Relay Service only if you accept the terms-of-service risk its README states, and only on v1.1.249 or later. Install it with the manage.sh script, put it behind a reverse proxy with BIND_HOST=127.0.0.1, and read the admin credentials from data/init.json before the /web panel is reachable from the internet.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Wei-Shaw/claude-relay-service on GitHub