GPT-Load 2.x is a complete rewrite of a self-hosted AI gateway, and v2.0.0-rc.4, published September 2, 2026, cannot open or import 1.x data. If you run 1.x in production, treat this as a parallel deployment and migration rather than an in-place upgrade: keep the 1.4.x maintenance line available, protect the encryption key that decrypts channel credentials, and verify routing before cutting traffic over. This article is a source and documentation review, not a runtime test.

Key facts at a glance

What GPT-Load is and who owns this decision

GPT-Load sits in front of AI providers so your applications keep one base URL and one access key while the gateway manages many credentials behind the scenes. The repository describes support for official and cloud providers including OpenAI, Anthropic, Gemini, xAI, Azure OpenAI, AWS Bedrock, and Google Vertex AI; model services such as DeepSeek, Moonshot, OpenRouter, and Groq; and subscription channels for Codex, Claude, Antigravity, and Grok. Clients keep their OpenAI, Anthropic, or Gemini native interfaces, while the gateway handles credential selection, scheduling, retries, cooldowns, health handling, request logs, and usage accounting.

The reader this matters to is the person operating that gateway: a founder, developer, or operations lead who either has a working 1.x deployment or is choosing between a managed AI gateway and a self-hosted one. A major rewrite is now on a release candidate, and you need to know whether adopting it is safe and what the upgrade path really costs. The 2.0 release notes and README answer the first part honestly: this is not a routine update, and a few production constraints decide whether it fits you.

Why the 2.0 rewrite changes your decision

The project states that 2.0 is a complete rewrite and that it cannot open, import, or migrate 1.x data in place. The release notes for v2.0.0-rc.4 repeat the warning in the same terms: start 2.x from an empty database and a new encryption.key.

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.

v2.0.0-rc.4 itself is a focused fix release. Its notes list three changes: honoring supported language fallbacks in internationalization, simplifying the settings save flow by removing ETag handling, and unifying gateway Responses store route compatibility. Release cadence is a positive maintenance signal: the 2.x branch went from rc.1 to rc.4 between August 31 and September 2, 2026, and the 1.x line still received v1.4.11 on September 3 with documentation and image-channel fixes. Both lines are active; the decision is which one carries your production traffic, and for most operators the honest answer is 1.x until you have a verified 2.0 pilot.

Operational checks before production

If you do run the rc, these are the documented constraints to build your test plan around.

• Data and keys move together. Compose stores the database, auth.key, and encryption.key in the gpt-load-data named volume. encryption.key decrypts channel credentials, so the database and the key must be kept together in backups and migrations; once the key is lost or replaced, existing encrypted credentials cannot be recovered, and this version does not support master key rotation.
• The image tags can mislead you. latest remains on 1.x, while the tag 2 tracks verified 2.0 beta and RC releases before GA and stable 2.x after GA. Exact tags drop the v prefix, so release v2.0.0-rc.4 maps to image tag 2.0.0-rc.4. Pin and record the exact tag or digest you tested.
• It is a single-instance design. Instances do not share state and horizontal scaling is not supported, so a multi-replica HA plan is outside the documented architecture.
• Remote access is your responsibility. The service listens on 127.0.0.1 only by default; for remote use the README directs you to a controlled network or TLS reverse proxy with ACLs and firewall rules, and to treat AUTH_KEY and ENCRYPTION_KEY as secrets that never belong in repositories, logs, screenshots, or public issues.
• Usage and cost figures are estimates derived from upstream responses, not provider invoices or financial reconciliation.

OAuth and subscription channels need a maintenance plan

The Codex, Claude, and Antigravity OAuth clients use fixed callback ports (1455, 54545, and 51121). In Compose, these are published on the address configured by HOST, which defaults to 127.0.0.1; setting HOST=0.0.0.0 publishes the callback ports on all host interfaces, and because the ports are fixed, only one default Compose instance can run on a host at a time. When you administer over SSH or from a remote browser, the browser’s localhost may not reach the gateway, and the README says to paste the full callback URL into the authorization dialog.

Subscription channels depend on upstream OAuth and compatibility protocols, and the project warns these can change as upstreams change. That means re-authentication and protocol drift are recurring maintenance tasks, not one-time setup. This is also where the usage boundary matters: the repository says to connect only accounts you are entitled to use and to follow each provider’s terms.

Stateful requests and embeddings have limits

GPT-Load converts between the capabilities each channel declares, but the README is explicit that it is not a general-purpose any-protocol, any-JSON translator. For OpenAI Responses, stateful requests that rely 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. If your clients open long stateful sessions, your routing configuration must be able to pin those sessions, or you will see inconsistent behavior when requests cross credentials.

Embeddings deserve a separate check. The project states that embeddings initially use the native OpenAI-compatible wire only on the OpenAI, OpenRouter, and OpenAI Compatible API-key channels; subscription channels and protocol conversion are not supported. One upgrade consequence: an AccessKey without a protocol filter keeps its all-enabled behavior and therefore gains embeddings access after the move, so least-privilege deployments should set an explicit protocol filter before upgrading.

Scheduler and reporting gaps from the open issue tracker

The repository had eight open issues at review time. None of these are my test results, and open issues are not confirmation of current behavior, but they are useful staging tests for teams that depend on these features.

• Issue 534 reports that native protocol routes are preferred over converted routes regardless of manual group weights, so weighted scheduling between route modes is not global. Test this if you plan to fail over between a native channel and a protocol-converted channel.
• Issue 520 asks for load balancing between models with different aliases inside one group; the workaround described is duplicating groups, which the reporter calls hard to manage.
• Issue 538 reports Antigravity subscription image generation returning 503 No available upstream candidate because the image route was not registered; the issue is open and assigned to the maintainer.
• Issue 535 reports that subscription account cards in the UI lack weight editing, so operators may need the REST API to set weights for subscription credentials.

Who should adopt 2.0 now, and who should wait

A fresh deployment with modest, single-instance throughput is the most defensible use of the rc today. You benefit if you want one console for API keys and subscription accounts across OpenAI, Anthropic, Gemini, and compatible relays, plus health handling, logs, and cost estimates, and if you can re-create the configuration rather than migrate it. You should wait if a stable 1.x gateway is already serving production traffic, if you need multiple instances, if stateful Responses must spread across credentials, or if you require behavior outside the documented protocol conversion boundaries. Teams that need a vendor-backed support relationship should also note this is MIT open source with community and sponsor support, not a commercial SLA.

Useful evaluation questions before production:

• Which client protocols does each application actually call, and does every channel you plan to use support them natively or through the documented conversion?
• Can your stateful OpenAI Responses sessions be pinned to a single credential?
• Who re-authenticates subscription OAuth when an upstream changes its flow?
• Can you back up the database and encryption.key together and prove a restore works?
• What is the rollback window, and does your 1.x deployment stay intact until it closes?

Verdict

The project is active, the rewrite has clearer protocol and credential boundaries, and rc releases are moving quickly. For a fresh deployment, that makes 2.0 worth piloting now. For an existing 1.x gateway, the same facts argue against a casual in-place upgrade: there is no data migration path from 1.x, credential recovery depends on the encryption key surviving with the database, horizontal scaling is unsupported, and the release is still pre-GA. Run it in parallel, treat the open scheduler and channel issues as test cases, and cut over only when your channel matrix and clients pass against the exact image tag you pinned.

Sources

• tbphp/gpt-load GitHub repository
• GPT-Load v2.0.0-rc.4 release notes
• GPT-Load v1.4.11 release notes
• GPT-Load official documentation for the 1.4.x line
• Issue 534: native and converted route scheduling weights
• Issue 538: Antigravity image endpoint support

If you are operating a 1.x gateway or staging this rc and want the move reviewed before traffic shifts, I do deployment and migration work on self-hosted systems like this as part of my software development and migration work. I would start with your compose file or environment configuration, the backup layout for the data volume and encryption key, and a list of the channels and client protocols you actually run, then work through the checks above against a staging copy of your workload. I cannot promise how a release candidate will behave under your traffic until I can run your real configuration against it, but with those details I can build the migration and rollback plan with you: share your setup when you are ready.