It also supports Gemini cli and Codex transit, supports multi-account switching, custom API keys, Claude API, and OPENAI compatible formats, effectively avoids account bans, and OAuth integration can quickly add account pools.
Similar projects include: https://github.com/yushangxiao/claude2api
The core requirement of these projects is that users want to convert their accounts into APIs for more people to use, and some ride-sharing on the Internet is similar to these
1. Project Introduction & Core Positioning
The Chinese description of this project is written more directly:
“Self-built Claude API brokerage service, supporting multi-account management … One-stop open source transit service, allowing Claude, OpenAI, Gemini, and Droid subscriptions to be accessed in a unified manner, supporting ride-sharing sharing, more efficient cost sharing, and seamless use of native tools. ” ([GitHub][1])
In other words, it is essentially a “relay/proxy/forwarding” service (relay service) that is used to build a unified entry point on a server controlled by yourself, and the frontend or client sends requests to this relay service, which then forwards the request to multiple backend AI services (Claude, OpenAI, Gemini, Droid, etc.). This relay can also do additional functions such as account management, traffic/cost statistics, and intelligent switching.
The main uses can be summarized as:
- Bring together multiple AI service accounts in a single “relay” node.
- Assign API Keys to different consumers (or clients), and relay controls access rights, rates, concurrency, etc.
- Realize the purpose of “carpooling/sharing a subscription/account pool” to share costs.
- Avoid the front-end or users directly exposing the real back-end account (key exposure, abuse risk).
- Improved stability: If an account or node is abnormal, the relay can be automatically switched or culled.
- Allows for unified monitoring, statistics on token usage, performance metrics, and more.
2. Main functions & architecture components
Based on the project’s README/documentation, here are its key modules/feature points:
| Modules / Functions | Function / Description |
|---|---|
| Multi-account management | You can add multiple accounts such as Claude / Gemini / OpenAI in the background and let the relay service rotate or intelligently select from these accounts |
| API Key management | Issue an API key at the relay level to the consumer (client), and use this key to access the relay service. After the relay receives the request, it uses the backend account to actually call the AI service. |
| Access control / current throttling / concurrency control | You can set the access rate, token limit, and number of concurrency for each consumer’s key to control abuse. |
| Intelligent switching / fault tolerance | When a backend account is unavailable (such as being banned, expired, or API error, etc.), the relay can automatically switch to another available account to continue the service. |
| Performance optimization / connection pool / caching | Reduce latency and increase throughput. The documentation mentions “connection pools, caches” as a means of performance optimization. |
| Monitoring / usage statistics | Display indicators such as token usage, consumption fees, and response performance of each account/user on the web interface. |
| Security controls | Including access restrictions, rate control, client restrictions (User-Agent whitelist/limit which clients are available), etc. |
| Agent / Network Support | Support HTTP / SOCKS5 proxy to bypass network restrictions or access backend services. |
| Multiple services are compatible/routed distribution | Identify the requested service type based on different paths (such as /claude/,/droid/claude//openai//gemini/ etc.) and forward it to the corresponding type of account pool. ([GitHub][1]) |
| Front-end interface / management backend | Provide a web management page for administrators to add accounts, create API keys, view statistics, adjust settings, etc. |
| Deployment methods are diverse | Support one-click deployment of scripts, Docker/docker-compose, reverse proxy (Caddy/Nginx), etc. |
3. Usage scenarios / suitable for people
From the README’s “Is this project right for you?” In that passage, the author clearly mentions that the following types of people may use this project:
- Users whose region is restricted / have difficulty accessing Claude services.
- Users who want to carpool costs with multiple accounts.
- They are worried about third-party images/public relays leaking conversation content and want to control the relay nodes.
- Have a certain foundation in technology and are willing to maintain and deploy relay services by themselves.
- Stable, long-term access to Claude is required, and reluctant to rely on public mirror instability.
That is, this project is mainly aimed at those who:
- I hope to build an agent/relay layer to centrally manage AI services.
- There is a need for multiple accounts or multiple people sharing an account pool;
- I want to control access, permissions, and costs;
- Have certain operation and maintenance capabilities, and hope to deploy, monitor, and tolerate faults by yourself.
4. Advantages / benefits
This relay/relay design has some obvious advantages:
- Security & Privacy Controls
User conversations are not directly exposed to public mirror sites or third-party service providers, but only flow through your own relay nodes. - Split costs / multi-account pools
Multiple people can share an account pool, and the relay will help you distribute and switch loads, making it more cost-effective. - Unified Entrance + Compatible with Multiple Backends
The front-end calls the relay service you deploy without having to manage the compatibility issues such as interfaces, addresses, and authentication methods of multiple different services. - Control ability
You can do access control, current limiting, monitoring, usage statistics, etc. for different users and keys. - Stability / Abnormal recovery
If an exception occurs in a backend account, the relay can automatically remove or switch to an alternate account to reduce the risk of service interruption. - Operation and maintenance are self-controlled
You can see and manage logs, status, performance metrics, etc. at all relay levels, without relying on the transparency of public service providers.
5. Risks, challenges and limitations
While this project is feature-rich, there are some risks/limitations to be aware of or possibly include:
- Risk of Terms of Service Violation
In the README, there is a warning: “Use of this item may violate Anthropic’s terms of service.” All risks associated with the use of this project are at the user’s own risk. ”
In other words, this method of relaying/carpooling/forwarding may not be allowed in the official user agreement or terms of service. - Account ban / demotion
If multiple users share an account pool, if one user violates the rules, there is a risk of account ban/demotion, which will affect everyone. - Relay performance bottlenecks/latency
Although there are connection pools and cache optimizations, relays themselves are still an additional network hopping point that may introduce latency or throughput bottlenecks. - Operation and maintenance costs
Although the minimum configuration is not high (1 core, 512 MB, 30GB hard disk, etc.), it is necessary to ensure stability, high availability, data backup, monitoring, abnormal recovery, upgrade rollback, and other operation and maintenance work. - Network access / local restrictions
Network conditions, cross-border links, and the possibility of interception of access to Anthropic / Claude from within the country may affect the quality of service. The document also mentions that access may be blocked by Cloudflare on some cloud vendors/lines. - Security/encryption risks
Although relays can do API keying, encryption, and access control, they can also become a new attack surface if they are not properly deployed and the key management is not strict. - Sync/version compatible
API protocols, version changes, and authentication method updates of back-end services (Claude, OpenAI, Gemini, etc.) may cause the relay to be compatible with updates in a timely manner.
6. Technical details / core design points (high level)
While I haven’t gone into line-by-line code debugging, based on the documentation and project structure, I can guess the core design idea is as follows:
- Routing and path recognition
The relay determines which type of service is being called based on the requested path prefix (such as/claude/,/droid/.../openai//gemini/etc.), and selects the corresponding account pool for forwarding. - Request Encapsulation & Transformation
After the front-end request is sent to the relay, the relay will re-encapsulate the request according to the back-end service’s needs (it may be JSON body conversion, header adjustment, authentication token injection, etc.), and then forward it to the back-end service. - Authentication / API Key Validation
Requests made by consumers to relays must be accompanied by an API Key issued by the relay. The relay first validates this key before allowing access and forwarding to the backend. Relays can also look at the permission configuration of the key (rate limit, number of concurrency, accessible model, etc.) to limit requests. - Payload / Polling / Switching Policies
When multiple backend accounts are available, the relay decides how to allocate requests: polling, weighting, priority, load balancing, error retries, etc. If an account is errored, interrupted, or banned, the relay should be removed or switched to the next account. - Monitoring/Statistics module
The relay records the token consumption, number of requests, error rate, latency and other indicators of each key / account, and displays these data on the management interface. - Caching / connection pools / optimization
You can cache partial responses, reuse HTTP Keep-Alive connections, manage connection pools, and reduce the overhead of frequent connection establishment. - Backend management interface + front-end SPA
The project includes an admin front-end interface (Admin SPA) for operating accounts, keys, monitoring, etc. The backend provides API support for this interface. - Configuration / Environment / Deployment
.env, config files, Docker/docker-compose deployment methods, and reverse proxy (Caddy/Nginx) access, etc.
7. How to use / deployment process (high-level overview)
Assuming you want to build this relay service yourself, here’s the typical process (according to the README):
- Environment preparation: Linux server, install Node.js 18+, Redis.
- Clone code, configuration
.envand .config - Install dependencies(
npm install), build the frontend(npm run build:web). - Initialize the admin account (
npm run setup). - Start the service (daemon/background running mode) (
npm run service:start:daemon). - Open the admin interface (Browser Access
http://服务器:3000/web) and log in to the administrator. - Add backend accounts (Claude, OpenAI, Gemini, etc.) in the background to complete OAuth authorization/key configuration.
- Create an API Key for the consumer in the background and configure access rights for it (rate, concurrency, model limit, etc.).
- External clients/frontends or tools only access the API endpoint of the relay service (instead of directly calling Claude / OpenAI), with the obtained API Key.
- The relay is forwarded, monitored, and counted according to the route, key permission, and account pool.
Deployment usually uses reverse proxies (such as Nginx/Caddy) to add HTTPS/SSL, domain name binding, logging, and security controls.
8. Summary / Is it useful to you?
This project is an interesting “AI service relay / account pool management” tool. It is valuable for those who want to manage AI access themselves, do not want to rely entirely on public images, want to schedule multiple accounts in a unified manner, and want to monitor/control access behavior. But it’s not a “ready-to-install, zero-risk” solution: it involves O&M, security, and compliance risks.
Github：https://github.com/Wei-Shaw/claude-relay-service
Tubing: