yukkcat/chatgpt2api: a reverse-engineered ChatGPT Web gateway with an account pool

What chatgpt2api actually converts

ChatGPT Web has no supported programmatic entry point. chatgpt2api fills that gap by speaking the OpenAI wire format on one side and driving ChatGPT Web sessions on the other. The README describes it as an interface that brings ChatGPT Web capabilities into an OpenAI-compatible API, wrapped in a console for multi-account, image-task and self-hosted use. The audience is narrow and specific: people who already hold accounts they are willing to lose, and who want a /v1 endpoint they control rather than a vendor contract.

The project is explicit that this is not an official OpenAI service. The README carries a warning block stating that the interface may stop working when the upstream changes and that accounts may be restricted or banned, temporarily or permanently, and it tells users not to attach important or frequently used accounts. That single paragraph defines the operating envelope more than any feature table does. If losing the accounts behind the pool is unacceptable, the rest of the feature list is irrelevant.

Inside the gateway: services, scheduler and the Application Database

The README architecture diagram shows two entry paths. Compatible API clients hit /v1, administrators and web users hit the Vue console, and the console talks to a separate /api management surface. Both converge on the same business services layer. From there, a scheduler handles account selection and proxy egress toward ChatGPT Web, while the services layer writes to an Application Database (SQLite or PostgreSQL 18) and to a separate asset store for images and generated files. In-process monitoring and optional R2 backup hang off the same layer.

The split between database and asset storage is the design decision worth noting. Accounts, user keys, settings, logs and metrics live in the Application Database; images and generated files do not. That keeps the database small and makes the file store swappable between local disk and WebDAV, which the README lists under image and file capabilities. It also means a database backup alone is not a complete backup, a point the README's storage architecture document is referenced for.

Account intake is broad by design: manual entry, OAuth, Access Token, Session JSON, CPA, remote CPA and Sub2API import. Credentials are tracked as separate AT and RT states, with RT refresh of AT and plan or quota synchronisation. Scheduling then picks among accounts, with configurable account concurrency, per-account image concurrency, parallel multi-image work and failover to another account. Proxy egress is a first-class concept rather than an afterthought: account proxies, account-group proxies, multi-egress proxy groups, per-node image concurrency, rotation interval, default and backup egress, plus connectivity checks.

Installing chatgpt2api and making a first API call

The README offers a one-line installer that runs as root and prompts for the database choice: SQLite, a local PostgreSQL 18 container, or an existing PostgreSQL URL. SQLite needs no extra configuration; the local PostgreSQL option is started and persisted by Compose.

curl -fsSL https://raw.githubusercontent.com/yukkcat/chatgpt2api/main/deploy/install.sh | sudo bash

To pin the release documented here, the README passes the branch tag to the same script:

curl -fsSL https://raw.githubusercontent.com/yukkcat/chatgpt2api/v3.2.3/deploy/install.sh | sudo bash -s -- --branch v3.2.3

If you prefer to see the Compose files, clone the repository and copy the environment template. The README's comment on the copy step is that you then edit .env and set a private key for CHATGPT2API_AUTH_KEY. The config.json guard below is copied from the README as well; it creates an empty config file if one is absent, because the default Compose file bind-mounts it.

git clone https://github.com/yukkcat/chatgpt2api.git
cd chatgpt2api
cp .env.example .env
# edit .env and set CHATGPT2API_AUTH_KEY to a private key
test -f config.json || printf '{}\n' > config.json
docker compose up -d

The README lists three endpoints after startup: the console on http://localhost:3000, the OpenAI-compatible API on http://localhost:3000/v1, and the data directory at ./data. The container maps port 3000 on the host to port 80 inside, per docker-compose.yml, and CHATGPT2API_PORT overrides the host side. Requests carry a bearer key:

Authorization: Bearer <auth-key>

For PostgreSQL 18, set POSTGRES_PASSWORD in .env and layer the overlay file. The README notes that this mode uses postgres:18-alpine with a named volume and does not expose the database port by default, and that the password should use only letters, digits, underscores or hyphens to avoid URI encoding mismatches.

docker compose -f docker-compose.yml -f docker-compose.postgres.yml up -d

One precedence rule is easy to miss: .env's CHATGPT2API_AUTH_KEY takes priority over auth-key in config.json. The README also states that .env, config.json and data/ should not be committed.

The v3.0.0 break and the upgrade path it forces

The README's most consequential paragraph is the v3.0.0 notice. The remote main history was reorganised, and the old source, Git tags, releases and container images are no longer maintained on the current release line. More importantly for anyone running 2.x: version 3.0 uses a new Application Database and cannot read the scattered storage format of 2.x. Upgrading means reconfiguring or re-importing accounts.

That is a real migration cost, not a footnote. Account records, user keys, settings and logs live in the Application Database, so a 2.x deployment cannot simply be pointed at the new image. The README points to a deployment document for full upgrade, backup, PostgreSQL and troubleshooting instructions, but the notice itself is the warning: budget time for re-import, and do not assume the old data directory carries over.

The version history supports the same reading. The last push to the repository was on 2026-09-09, the same day v3.2.3 was released, with v3.2.2 and v3.2.1 landing in August 2026. Releases are frequent enough that pinning matters. The README's own installer example pins v3.2.3 by tag, and the .env.example comments that CHATGPT2API_IMAGE can be pinned, for example to a specific ghcr.io tag. Pinning is the difference between a controlled upgrade and discovering a schema change in production.

Where chatgpt2api is the wrong tool

The clearest failure mode is upstream drift. Because the project drives ChatGPT Web rather than a published API, the README states plainly that the interface may become invalid as the upstream changes. There is no versioned compatibility contract to appeal to, and no vendor obligation to keep the web endpoints stable. A deployment that works today can stop working without a code change on your side.

The second limitation is account exposure. The README warns that accounts may be restricted or banned, temporarily or permanently, and instructs users not to use important, common or high-value accounts. A pool built from accounts someone actually depends on is a liability, not a feature. This also rules out the project for any workload with an availability target: the scheduler can fail over between accounts, but it cannot conjure a healthy account when the upstream decides otherwise.

Third, the licence. chatgpt2api is AGPL-3.0-only per pyproject.toml and the LICENSE file. AGPL-3.0 carries network-service obligations that many teams have not planned for. If your product embeds this code or a modified version and exposes it over a network, the licence is a design constraint, not a formality. This is not legal advice; the point is that the licence choice should be evaluated before adoption, not after.

Finally, scope. The project includes PPT and PSD editable-file tasks, prompt libraries, R2 backup and image upscaling. That is a lot of surface for what may be a single need. If you only want text completions against your own account, the account pool, proxy groups and image pipeline are maintenance you are choosing to carry.

How it differs from LiteLLM-style proxies

The natural comparison is a proxy such as LiteLLM. LiteLLM sits in front of provider APIs that already exist and normalises their request and response shapes, adding routing, retries, budgets and key management. Its upstreams are supported endpoints with documented behaviour. chatgpt2api does the opposite: it has no supported upstream to normalise, so it reconstructs access to ChatGPT Web and then presents that as /v1. The compatibility layer is the easy half; the hard half is the account pool, credential refresh, proxy egress and the scheduler that decides which account handles which request.

That difference shows up in what each tool asks you to supply. A LiteLLM deployment needs provider keys and a routing policy. chatgpt2api needs accounts, proxies and a tolerance for churn, because the README's warning about upstream change is not a caveat bolted onto the README, it is the operating model. If your upstreams are already APIs, chatgpt2api adds risk without adding capability. If your only access to the model is a web session, the account pool is the part that does the work, and a generic proxy cannot replace it.

Maintenance, licensing and what to check before you commit

Maintenance signals are mixed but current. The last push was on 2026-09-09, and v3.2.3 shipped the same day, with v3.2.2 and v3.2.1 in the preceding month. The repository is not archived. That is a healthy release cadence for a project of this kind, and it is also the reason to pin: a fast-moving reverse-engineered gateway can change schema or behaviour between minor versions, as the v3.0.0 notice demonstrates.

The upgrade cost is concrete. Because the Application Database holds accounts, keys, settings, logs and metrics, and because the README states that 3.0 cannot read 2.x's scattered storage, migrations are re-import exercises rather than in-place upgrades. The Compose setup keeps a separate runtime volume so the console can update online, and the README points to a deployment document for backup and troubleshooting. The asset store is separate from the database, so a complete backup covers both the Application Database and the image or file storage, whether that is local disk or WebDAV.

On licensing, AGPL-3.0-only is stated in both pyproject.toml and the LICENSE file, with a NOTICE file in the repository root. The README's own warning block puts technical, account and compliance risk on the user, and prohibits bulk abuse, malicious competition, account theft, fraud, harassment and illegal content. Treat those as terms of use you are accepting, and have someone who understands AGPL-3.0 network obligations review your deployment before it faces users.

Editorial conclusion

Adopt chatgpt2api if you already run disposable ChatGPT accounts and want a self-hosted /v1 endpoint with pooling, proxy rotation and image task storage, and if AGPL-3.0 fits how you ship. Do not adopt it if you need an OpenAI-supported integration, single-account simplicity, or a service you can hold to an uptime commitment. Before deploying, verify that CHATGPT2API_AUTH_KEY is set in .env, decide between the default SQLite file and the PostgreSQL 18 overlay, and confirm your accounts are expendable, because the README states that upstream changes can invalidate the interface and that accounts may be temporarily or permanently banned.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. yukkcat/chatgpt2api on GitHub