GPT-Load

A self-hosted AI gateway for multi-channel, multi-credential setups

API keys, subscription accounts, traffic scheduling, failure handling, request logs, and usage accounting — behind a single entry point.

English · 中文 · 日本語 | Official Website

Sponsors

_{Become a sponsor}

Sponsor details (collapsible)

Protect and accelerate websites and APIs, serving users in mainland China and around the world, and extend acceleration and security capabilities to native/mobile apps through a client SDK — self-built private-deployment CDN | subscription-based high-protection CDN | an independently controllable, flexibly composable CDN network.

Thanks to APIMart for sponsoring this project! APIMart is a low-cost API platform for AI image & video generation — GPT-Image-2 from $0.006/image, 160+ images per dollar. One async API covers both image and video: submit a task, get an ID, fetch results via polling or callback. Batch tens of thousands of images without timeouts, switch models without changing code. Pay-as-you-go with no monthly fee — sign up here to get started.

Why GPT-Load

Your application only needs one base URL and one AccessKey. Providers, accounts, credentials, models, and routing policy are all configured in the management UI.

• One gateway, native protocols — Manage official APIs, cloud platforms, model services, and compatible relays together while clients keep their OpenAI, Anthropic, or Gemini native interfaces.
• One mechanism for API keys and subscriptions — Codex, Claude, Antigravity, Grok, and API-key channels share credential management, scheduling, and health handling.
• Scheduling and failure isolation built in — Multi-credential scheduling, automatic weighting, retries, cooldown, blacklisting, and session affinity reduce the impact of overloaded or failing credentials.
• Observable, self-hosted, and simple to deploy — Inspect health, routes, logs, usage, and cost estimates in an embedded UI backed by SQLite, MySQL, or PostgreSQL with local credential encryption.

Quick start

[!WARNING] If you are using 1.x, read Moving from 1.x first. 2.0 cannot open, import, or migrate 1.x data in place.

1. Start the service

Requires Docker and Docker Compose.

git clone --depth 1 --branch v2 https://github.com/tbphp/gpt-load.git
cd gpt-load

cp .env.example .env
docker compose up -d

Confirm the service is up:

curl --fail http://127.0.0.1:3001/health

The first start generates a management key. Read it and store it safely:

docker compose exec gpt-load sh -c 'cat /app/data/auth.key'

Open http://127.0.0.1:3001 and sign in to the console with that key.

You can also set AUTH_KEY explicitly in .env before starting. By default the service listens on the loopback address only and is not exposed to the internet.

2. Initial configuration

Initial setup takes three steps:

1. Add a channel — Choose an upstream service and add one or more API keys. For subscription channels, complete the OAuth flow or import credentials as prompted.
2. Create a group — Pick a channel, then configure available models and runtime policy.
3. Create an AccessKey — Set the groups and client protocols it may use, then give the generated AccessKey to your application.

Screenshots

Groups — View channels, models, credential counts, and health in one place

Subscription accounts — Track account availability, quota windows, reset times, and runtime diagnostics

AccessKey read-only home — Sign in with an AccessKey to view only its own groups, models, requests, usage, and cost allowance

Usage and cost — Review request trends, cache hit rate, token categories, and cost estimates

Scope

Client protocols

Each channel declares exactly which protocols and capabilities it can execute. GPT-Load converts between supported capabilities, but it is not a general-purpose any-protocol, any-JSON translator.

Embeddings initially uses the native OpenAI-compatible wire only on the OpenAI, OpenRouter, and OpenAI Compatible API-key channels; subscription channels and protocol conversion are not supported. An AccessKey without a protocol filter keeps its existing “all enabled protocols” behavior and therefore gains Embeddings access after upgrade. Least-privilege deployments should configure an explicit protocol filter.

Built-in channels

• Official and cloud — OpenAI, Anthropic, Gemini, xAI, Azure OpenAI, AWS Bedrock, Google Vertex AI
• Model services — DeepSeek, Moonshot AI, SiliconFlow, Zhipu AI, Alibaba, Volcengine, OpenRouter, Groq
• Subscription — Codex, Claude, Antigravity, Grok
• Custom — OpenAI Compatible (any compatible relay)

Deployment and data

Docker Compose uses application-managed SQLite by default. Data lives in the gpt-load-data named volume and includes the database, auth.key, and encryption.key.

[!IMPORTANT] encryption.key decrypts channel credentials. When backing up or migrating, the database and the key must be kept together. Once the key is lost or replaced, existing encrypted credentials cannot be recovered, and this version does not support master key rotation.

mysql://user:password@db.example:3306/gpt_load?charset=utf8mb4&collation=utf8mb4_bin
postgres://user:password@db.example:5432/gpt_load?sslmode=require

Common operations:

docker compose logs -f      # view logs
docker compose pull && docker compose up -d   # update to the latest 2.x image
docker compose stop         # stop the service

The official Compose file uses ghcr.io/tbphp/gpt-load:2. Before GA, 2 tracks verified 2.0 Beta and RC releases; after GA, it tracks stable 2.x releases only. Exact image tags omit the Git tag's v prefix (for example, 2.0.0-beta.25), while 2.0-beta remains the 2.0 Beta channel. latest remains on 1.x.

chmod +x ./gpt-load-linux-amd64

HOST=127.0.0.1 DATA_DIR=./data ./gpt-load-linux-amd64

Environment configuration

At startup, the application reads .env in the current directory; existing process environment variables take precedence. Unless noted otherwise, changes require restarting the process or container; see .env.example for the common configuration template.

Production considerations

• The service listens on 127.0.0.1 only by default. For remote access, expose it through a controlled network or a TLS reverse proxy, and configure ACLs and firewall rules.
• Manage AUTH_KEY and ENCRYPTION_KEY carefully. Never commit real keys to a repository, log, screenshot, or public issue.
• 2.0 is designed for a single application instance. Instances do not share state, so horizontal scaling is not supported.
• Usage and cost are estimates derived from upstream responses. They support operational analysis and capacity planning, and do not equal a provider invoice or a financial reconciliation.
• Subscription channels depend on upstream OAuth and compatibility protocols and may change as upstreams change. Only connect accounts you are entitled to use, and follow each provider's terms.
• In OpenAI Responses, stateful requests relying on previous_response_id, conversation, or an existing resource ID are only reliable with a single credential, or with an upstream that shares resources across credentials.

Moving from 1.x

[!WARNING] GPT-Load 2.0 is a complete rewrite. It cannot open, import, or migrate 1.x data in place.

Deploy 2.0 with its own database, DATA_DIR, port, and Docker volume. Cut traffic over only after verification, and keep the original 1.x deployment until the rollback window closes. Documentation for the 1.4.x maintenance line is at the official docs.

Open-source dependencies

Some of GPT-Load's capabilities build on these projects, with thanks:

GPT-Load owns credential storage, account selection, scheduling, retry, health, affinity, logging, and usage policy. Third-party notices are in THIRD_PARTY_NOTICES.md, full license texts in LICENSES/, and each release ships a CycloneDX SBOM covering the Go dependency graph.

Channel icons identify their respective upstream providers. All trademarks belong to their owners; this project is not affiliated with or endorsed by them.

Project support

Platform support

Community support

Infrastructure support

MIT License · Third-party notices · Security policy