One endpoint,
every channel
and credential
Twenty channels, dozens of credentials, and four client protocols sit behind one base URL. The gateway handles scheduling, retries, cooldown, and usage accounting; applications only configure the base URL and AccessKey.
Supported by these partners
GPT-Load is open source under the MIT License. These sponsors help cover infrastructure, model credits, and development time.
Six jobs the gateway handles for you
Each application would otherwise implement these jobs separately—or skip them until something breaks. Put them in the gateway once and every client benefits.
One scheduler, two credential types
API keys and subscription accounts for Codex, Claude, Antigravity, and Grok share one pool and the same scheduling, retry, cooldown, and health-isolation behavior.
Clients keep their native protocols
OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and native Gemini requests pass through unchanged. Existing SDKs, CLIs, and desktop clients usually need only a new base URL and AccessKey.
Failures route themselves away
Weighted rotation, session affinity, retries, cooldown, and automatic blacklisting isolate a limited or invalid credential before it can affect the full route.
Every call stays observable
Inspect health, routes, request logs, usage summaries, and per-model cost estimates down to the credential handling a request.
One binary, data under your control
The management UI ships inside the Go binary. Start with SQLite or connect MySQL or PostgreSQL; upstream credentials are encrypted locally and never pass through a third party.
Twenty channels ready to use
Official APIs, cloud platforms, model services, and subscription accounts are built in, plus a custom channel for any OpenAI-compatible relay. Add a channel by filling a form, not writing an adapter.
Four protocols in, twenty channels out
The gateway handles both the protocol a client speaks and the upstream that ultimately receives the request. Your application does not need to know either routing detail.
- OpenAI
- Anthropic
- Gemini
- xAI
- Azure OpenAI
- AWS Bedrock
- Google Vertex AI
- DeepSeek
- Moonshot AI
- SiliconFlow
- Zhipu AI
- Alibaba Cloud
- Volcengine
- OpenRouter
- Groq
- Codex
- Claude
- Antigravity
- Grok
Configure it in three steps
There are only two things to manage: Groups face upstream, while AccessKeys face applications. Scheduling, retries, and usage accounting stay between them.
Create a Group
Choose an upstream channel and add its API keys. Subscription accounts such as Codex and Claude use OAuth, then join the same scheduler.
Choose exposed models
Select the models this Group exposes, discover them from upstream, and adjust weight, timeouts, retries, and other runtime policy when needed.
Issue an AccessKey
Set the Groups and client protocols it may use, add rate or cost limits, and give the generated key to your application. That is all the application needs to know.
One command to start, two client settings to change
No external database and no separate frontend deployment are required. The management UI is embedded in the same binary.
git clone --depth 1 --branch v2 \ https://github.com/tbphp/gpt-load.git cd gpt-load && cp .env.example .env docker compose up -d # Read the generated management key docker compose exec gpt-load \ sh -c 'cat /app/data/auth.key'
client = OpenAI(
base_url="http://127.0.0.1:3001/v1", # change this
api_key="sk-gl-••••a5df", # change this
)
# Anthropic clients use /v1/messages
# Gemini clients use /v1beta/models/…Keep each client's normal authentication style: Authorization: Bearer · x-api-key · x-goog-api-key · Gemini key query parameter.
Five build targets
Linux and macOS on both amd64 and arm64, plus Windows on amd64. Verify the bundled SHA256SUMS before running a downloaded binary; Windows also has an installer that registers a service.
Start on SQLite, switch when needed
Leave DATABASE_DSN empty for managed SQLite, or set a DSN for external SQLite, MySQL, or PostgreSQL.
Keep the key with the database
encryption.key decrypts channel credentials. If it is lost or replaced, encrypted credentials cannot be recovered; this release does not support master-key rotation.
Configuration and observability in one place
The management UI ships with the binary. Open a browser to configure channels, inspect health and logs, and review usage and cost estimates.
See quota windows, reset times, availability, and cooldown together. Quota data is informational; upstream rate-limit responses are what trigger routing changes.
Review request success trends, cache hits, token categories, cost estimates, and the quality of the usage data itself—including missing records and models without prices.
Read these three points before production
Usage and cost are estimates
Figures are derived from upstream responses for operations and capacity planning. They are not provider invoices, cannot be used for financial reconciliation, and price changes do not recalculate history.
Designed for a single application instance
Version 2.0 guarantees correctness within one instance. Instances do not share state and horizontal scaling is not supported; split larger workloads into independent deployments.
1.x cannot be upgraded in place
Version 2.0 is a full rewrite and cannot open, import, or migrate 1.x data. Deploy it with a separate database, DATA_DIR, port, and volume, then switch traffic after validation.
The service listens on 127.0.0.1 by default and is not exposed publicly. For remote access, use a controlled network or TLS reverse proxy with appropriate ACL and firewall rules. Protect AUTH_KEY and ENCRYPTION_KEY; never put them in repositories, logs, screenshots, or public issues.