chatgpt2api puts ChatGPT web behind an OpenAI-compatible API, and warns that your accounts can be banned for it

The page says the interface can break and that accounts can be restricted for it

The warning block at the top of the page is unusually direct. The project connects to ChatGPT's web text, image and file generation through reverse research, it is not an official OpenAI service, the interface may stop working when the upstream changes, and use may lead to accounts being restricted, temporarily or permanently banned. The instruction that follows is to not use important, frequently used or high value accounts with it.

The prohibited-use list is given in the same place: bulk abuse, malicious competition, account theft, fraud, harassment, and generating or distributing illegal, violent, pornographic or content involving minors, with the user carrying all risk and responsibility. That is a narrower and more specific set than a generic disclaimer, and it is worth reading as the author's own position on where the line is.

The architecture diagram shows why all of this is a single edge in a routing graph. Clients hit the `/v1` compatible API, a Vue console hits an `/api` admin interface, both converge on the business services, and from there one path goes to the account scheduler and proxy exit layer, which in turn talks to ChatGPT Web. The other paths go to the Application Database, the image and file store, in-process monitoring, and R2 backup. Everything this project does, the service level behaviour included, is arranged around that hop to ChatGPT Web, so when the hop changes the whole graph has to be revisited.

Generated files download without authentication, and the path check is the only guard

The API table lists an endpoint that is not authenticated at all. `/files/{file_path}` with `GET` is described as a public download of generated files from the random storage path. The prose under the table is explicit that file task creation, query and delete are isolated per API key, but the `/files/...` links a task returns need no authentication, the same as generated images, and holding the link is enough to download. The only stated protections are that public download validates the path and the file type, and that path traversal is rejected.

So the security model has a deliberate seam. Write operations are keyed, read operations on the artifact are not. That is a reasonable design for images you intend to hand out, since an image URL has to be fetchable by a client that was never given a key, and it is also the shape where a leak is quiet: a URL pasted into a chat, logged by a proxy, or left in a commit stays live until the object is deleted. There is no stated expiry on those links.

The related setting is `CHATGPT2API_BASE_URL`, described in the env template as optional and used for generating image URLs, which means the host in that link is whatever you put there. The console also exposes an image gallery, tags, thumbnails, download, ZIP, compression, cleanup and optional image upscaling, so the artifacts are a first-class part of the product rather than a side effect, and they are reachable from both directions.

v3.0.0 restarted the release line and rewrote the history

The notice above the quick deploy says that v3.0.0 is a new starting point for releases. The remote `main` history has been reorganized, and the old version source, git tags, releases and container images are no longer maintained as the current release line. The reasons given are concrete: 3.0 uses a brand new Application Database and cannot directly read the scattered storage data of 2.x, so upgrading means reconfiguring or re-importing your accounts.

That is a big admission to put at the top of a page. It means a 2.x installation is not an upgrade path but a migration, and the accounts are the expensive part of the migration because they are the thing you cannot regenerate. It also means the tags you might have pinned to before are outside the maintained line, and the container images for them are described as no longer maintained either, which is a different and stronger statement than the tag simply being old.

What came after is a steady release cadence rather than a series of rewrites: v3.2.1 on 2026-08-10, v3.2.2 on 2026-08-11, v3.2.3 on 2026-09-09, with the version in `pyproject.toml` reading 3.2.3 to match. The last commit is dated 2026-09-09, the same day as the newest release, so the tree and the tag are in step with each other. Given a rewritten history, the pinned form of the installer is the one worth using, and the page offers it alongside the floating one:

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

Install time asks whether to use SQLite, a local PostgreSQL 18 container, or an existing PostgreSQL URL. SQLite needs no extra configuration, and the local PostgreSQL option is started and persisted by Compose.

The declared homepage is a paid per-image service, and the page also links an account shop

Three things sit in the link row under the warning, and they are worth naming because they are the commercial surface of a technical project. There is a QQ group number. There is a link labelled as buying image generation accounts. And the repository's declared homepage, the address in the project metadata, is a per-image image generation API with a published price list: about 0.02 yuan per image at small volume, 0.01 through a relay, and 0.009 for bulk or enterprise.

That homepage is not project documentation. There is a separate documentation link, and a maintenance document under `docs/`, and an English README alongside the Chinese one. But the address the project advertises as its homepage is a commercial endpoint run by the same author, which means the open source repository and the paid service are one business rather than two things.

The sponsor block above the deploy section is smaller in scope. It is a residential proxy service, linked with a referral parameter, advertising coverage across 195 or more regions over HTTP, HTTPS and SOCKS5, with a discount code in the text. It is relevant to the project rather than random, because proxy exit is a first class feature of the gateway itself.

pyproject.toml still carries a placeholder description, and pytest points at a directory that is not in the tree

The packaging metadata is short and mostly accurate, with two entries that were not filled in. The `description` field is literally `Add your description here`, on a project whose real one-liner appears in the repository metadata. And `[tool.pytest.ini_options]` sets `testpaths = ["tests"]` while the repository top level has no `tests/` directory in it.

The rest of the file is more disciplined. The name is `chatgpt2api`, the version is 3.2.3, the licence is declared as `AGPL-3.0-only` where the repository's own licence field is recorded as AGPL-3.0, and Python 3.13 or newer is required, which is strict for a service and consistent with the `python:3.13-slim` base image in the Dockerfile. The runtime dependencies are nine: `curl-cffi`, `fastapi`, `pillow`, `pybase64`, `python-multipart`, `tiktoken`, `uvicorn`, `sqlalchemy` and `psycopg2-binary`, with `httpx` and `pytest` in a dev group. Each maps to something visible elsewhere: the web layer, the multipart image edit endpoint, base64 image payloads, token counting, the ORM, and the two database drivers for the SQLite and PostgreSQL paths.

`pythonpath = ["."]` is set next to the test paths, so imports resolve from the repository root, which is how a tree with `main.py`, `api/`, `services/` and `utils/` at the top is meant to be laid out.

The thread token knob is documented as not being a rate limit, and the env example still names v2.0.0

The env template is where the project is most candid about its own limits. `CHATGPT2API_THREAD_TOKENS` defaults to 120 and the comment above it says it is the concurrency capacity of the backend sync worker threads, requires only a positive integer, and sets no artificial maximum. It then says what it is not: it controls how many threads sync work can occupy at once, and it is not the actual concurrency ceiling on accounts, proxies or the upstream service.

That comment is the project telling you that the one tuning knob on offer does not bound anything you might be worried about. The real bounds are on the ChatGPT side, per account and per proxy, and the console exposes those separately: quota and rate limit state management, multi-account selection, account processing concurrency, single-account image concurrency, multi-image parallelism, and switching accounts on failure.

Two entries in the same file are stale. The image line is set to `ghcr.io/yukkcat/chatgpt2api:latest` and the comment above it suggests pinning to `ghcr.io/yukkcat/chatgpt2api:v2.0.0`, a version from before the 3.0 restart described earlier. The auth key line is the placeholder `your_secret_key_here`. The top of the file is three required-or-default settings:

CHATGPT2API_AUTH_KEY=your_secret_key_here
CHATGPT2API_PORT=3000
CHATGPT2API_THREAD_TOKENS=120

The rest is careful: the database defaults to `data/chatgpt2api.db` when `DATABASE_URL` is unset, and the PostgreSQL password hint narrows the character set to letters, digits and two punctuation marks, specifically so the connection URI does not need percent-encoding. `CHATGPT2API_AUTH_KEY` also takes precedence over the `auth-key` value in `config.json`, which is worth knowing because the compose file mounts both `./data` and `./config.json` into the container.

Seven ways to add an account, and a proxy layer built for rotating exits

Account management is the widest surface in the capability table, listing seven sources: manual add, OAuth, Access Token, Session JSON, CPA, remote CPA, and Sub2API pool import, with search, filtering, grouping, export and batch processing on top. Credentials are tracked as AT and RT status shown separately, with RT able to refresh AT, plan and quota synchronised, a per-account text and image test, and handling for accounts in an abnormal state.

Set that against the one-line project description, which claims support for a registration machine that maintains pool quota. The two sit in tension, and the page resolves it by prohibition rather than by removing the feature: the warning block names bulk abuse as forbidden. Anyone reading the two together learns that the pool is expected to be filled by accounts they legitimately control, through OAuth or token import, and that the difference between that and abuse is not something the tool checks.

The proxy side is built as a first class feature rather than a single setting: account proxies, account group proxies, multi-exit proxy groups, per-node image concurrency, a rotation interval, a default exit, a backup exit, and connectivity detection. That is the layer you would reach for if you were trying to make one account look like several, which is exactly why the terms question at the top of this article is the first thing to settle.

One small piece of housekeeping: the tree carries three compose files, `docker-compose.yml`, `docker-compose.local.yml` and `docker-compose.postgres.yml`, while the deploy instructions only name the first and the third.

Editorial conclusion

Read OpenAI's terms and weigh the ban risk before anything else, because the project's own warning says the interface can break with upstream changes and that accounts may be restricted temporarily or permanently, and it tells you not to point it at an account you care about. What you get is real: a scheduler that spreads work across an account pool, a `/v1` surface including an Anthropic Messages path, and a console for managing it. The two things to check before trusting it are the unauthenticated artifact download path, where a `/files/...` link is all anyone needs, and the upgrade path, because 3.0 restarted the release line onto a new Application Database that cannot read 2.x storage. Anyone using it commercially is also relying on an endpoint the vendor did not publish, and the declared homepage is the author's own paid per-image service rather than project documentation.

Frequently asked questions

Official sources

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