chatgpt2api: An OpenAI-Compatible Image API Wrapper for ChatGPT Accounts

What chatgpt2api Actually Does

The project takes the ChatGPT web interface's text generation, image generation and image editing endpoints, reverse-engineers them, and republishes them behind an OpenAI-shaped HTTP surface. That is the whole idea. If you already have code that calls POST /v1/images/generations or POST /v1/images/edits, chatgpt2api wants to sit in front of it and route those calls to ChatGPT accounts instead of to OpenAI's paid API.

The audience is narrow and the README is explicit about it. The disclaimer at the top states the project is for personal study, technical research and non-commercial technical exchange, and forbids commercial use, profitable use, bulk operation, automated abuse and large-scale invocation. It also warns that accounts may be rate-limited, temporarily banned or permanently banned, and tells users not to test with their own important, frequently used or high-value accounts. Anyone evaluating this as infrastructure for a product should read that paragraph twice, because it is not boilerplate. It is the project describing its own blast radius.

The model list returned by GET /v1/models is gpt-image-2, codex-gpt-image-2, auto, gpt-5, gpt-5-1, gpt-5-2, gpt-5-3, gpt-5-3-mini and gpt-5-mini. The README describes codex-gpt-image-2 as a separate reverse-engineered Codex drawing endpoint available only to Plus, Team and Pro subscriptions, which the README says means a single account carries two separate image quotas, one from the website and one from Codex.

The Account Pool Is the Real Architecture

Strip away the API compatibility layer and the interesting part is the account pool. The README describes it as the component that refreshes account email, type, quota and recovery time asynchronously, polls for an available account when a generation or edit request arrives, and drops tokens that fail with a token-invalid error. A scheduled job checks rate-limited accounts and refreshes them. Password re-login is supported so that an abnormal account can be recovered and re-authenticated after a refresh.

That design tells you what the failure model looks like. Requests are not served by a fixed credential. They are served by whichever pooled account is currently usable, which means the response you get depends on which account was picked, and the pool's health determines your throughput. The README lists four import paths: local CPA JSON files, a remote CPA server, a sub2api server, and direct access_token import. The settings page can also filter and bulk-import OpenAI OAuth accounts from a configured sub2api server.

Storage is pluggable and this matters more than it first appears. STORAGE_BACKEND accepts json (the default), sqlite, postgres or git. The postgres option needs DATABASE_URL; the git option needs GIT_REPO_URL and GIT_TOKEN and commits the account file to a private repository. The repository layout backs this up: pyproject.toml lists sqlalchemy and psycopg2-binary alongside gitpython, so the storage abstraction is not a README-only claim. For a pool of credentials that rotate constantly, SQLite or Postgres is the more defensible choice than the default JSON file, though the README does not say at what pool size the JSON backend becomes a problem.

Installing chatgpt2api with Docker and Making a First Request

The README's quick start is Docker Compose. Clone the repository, change into it, and bring the stack up. The compose file maps host port 3000 to container port 80 and mounts ./data and ./config.json.

git clone [email protected]:basketikun/chatgpt2api.git
cd chatgpt2api
docker compose up -d

Before starting, the README says to set auth-key in config.json, or override it with the CHATGPT2API_AUTH_KEY environment variable in docker-compose.yml. Once the container is running, the web panel is at http://localhost:3000, the API base is http://localhost:3000/v1, and data lives in ./data. Note that the API examples later in the README use port 8000, which is the local development port rather than the Docker one; if you followed the Compose path, substitute 3000.

Every AI endpoint requires a bearer token. This call lists the exposed image models:

curl http://localhost:8000/v1/models \
  -H "Authorization: Bearer <auth-key>"

A first generation request looks like this. The README documents n as limited to 1 through 4 on the backend and response_format as defaulting to b64_json.

curl http://localhost:8000/v1/images/generations \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <auth-key>" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "a cat floating in space",
    "n": 1,
    "response_format": "b64_json"
  }'

Image editing accepts either a multipart upload or a JSON body with an image URL. The multipart form uses the same field names as OpenAI's API:

curl http://localhost:8000/v1/images/edits \
  -H "Authorization: Bearer <auth-key>" \
  -F "model=gpt-image-2" \
  -F "prompt=make this a cyberpunk night scene" \
  -F "n=1" \
  -F "image=@./input.png"

If you would rather run from source, the README gives a uv-based backend start and a bun-based frontend start in chatgpt2api/web. The Dockerfile confirms the split: a node:22-alpine stage runs npm install and npm run build in web/, and the Python stage copies the built output to ./web_dist. Upgrading is a pull and a restart:

docker pull ghcr.io/basketikun/chatgpt2api:latest
docker-compose down
docker-compose up -d

Cloudflare Is the Failure Mode You Will Actually Hit

The README devotes a whole deployment path to Cloudflare interception, which is a strong signal about where this project breaks in practice. If the image path is frequently blocked, the repository ships a WARP + Privoxy + FlareSolverr compose file. Copying .env.example to .env and running it starts five services: warp-proxy for a WARP SOCKS5 egress, privoxy to convert that SOCKS5 into an HTTP proxy, flaresolverr to refresh Cloudflare clearance, init-config to idempotently write the proxy_runtime defaults, and app for the main service.

The proxy selection order is documented and worth understanding before you debug anything: an account's own proxy config wins, then the stable proxy runtime, then an explicit proxy, then the legacy global proxy. By default only upstream OpenAI and ChatGPT requests are routed through the stable proxy; email and CPA auxiliary traffic is not forcibly taken over. Ports and runtime parameters are adjustable in .env, and the settings page has a stable proxy runtime panel for saving, testing the proxy, and testing clearance.

There are other limits the README states without softening. The n parameter is capped at 1 to 4. codex-gpt-image-2 requires a Plus, Team or Pro subscription. The project is Python 3.13 or newer, per pyproject.toml, and the Docker image is python:3.13-slim. The repository has an Experimental / Planned section that points to docs/feature-status.en.md rather than listing capabilities inline, so the feature matrix lives outside the README and should be checked there. The README does not document a rollback procedure for a bad upgrade, and it does not document rate limits for the API surface itself.

How It Compares to lanqian528/chat2api

The closest comparison in the related searches is lanqian528/chat2api, another project that republishes ChatGPT web access behind an API. The difference in emphasis is visible from the surface each one exposes. chatgpt2api's model list is dominated by image models, gpt-image-2 and codex-gpt-image-2, and its feature list is built around image generation, image editing, multi-image composition, editable PPT and PSD output, and a browser-based drawing workbench with session history. Its account pool exists to keep image requests flowing.

chat2api is a text-first project by reputation and by name; a reader choosing between them is really choosing whether their workload is image generation or text conversation. If you need an OpenAI-compatible chat endpoint for text, chatgpt2api is the wrong shape, even though it does expose POST /v1/chat/completions and POST /v1/responses, because the README scopes both of those to image scenarios. If you need image generation and editing with a rotating credential pool, chatgpt2api is the more direct fit of the two.

A second alternative is simply the official OpenAI API. It costs money and it does not need an account pool, a proxy runtime, or a FlareSolverr container, and it comes with a vendor who will not ban your credentials for using it. The README's own disclaimer is the strongest argument for that path: it forbids commercial use and warns of permanent bans. Choosing chatgpt2api is choosing to trade money for account risk and operational complexity.

Licence, Maintenance and the Cost of Upgrading

The project is MIT licensed, which means you can use, modify and redistribute the code with the licence and copyright notice preserved. That is the code. It does not grant you anything with respect to OpenAI's service, and the README's disclaimer is separate from and stricter than the licence: it forbids commercial use, profitable use, bulk operation and automated abuse regardless of what MIT permits for the source. Do not read the MIT licence as permission for the usage pattern; they govern different things. This is not legal advice, and the disclaimer explicitly places all risk, including account limitation, temporary bans, permanent bans and legal liability, on the user.

The repository is not archived, and the last push was on 2026-07-29. Releases are frequent and small: v1.5.0 on 2026-06-13, v1.6.0 on 2026-07-04, and v1.7.0 on 2026-07-05. The versioning suggests incremental feature work rather than long stabilization cycles, and the presence of a CHANGELOG.md and a VERSION file confirms the project tracks its own releases.

Upgrade cost is low on the Docker path, which is a pull and a restart, but the upgrade is not risk-free. The compose file mounts ./config.json into the container, so a version that changes the config schema can leave you with a file the new image does not expect. The README does not document a rollback procedure, so pinning a specific image tag rather than tracking latest is the safer posture if you depend on a working deployment. Because the project depends on reverse-engineered endpoints, an upstream change on ChatGPT's side can break image generation without any commit to this repository, and the release cadence is the only signal you get that someone is keeping up.

Editorial conclusion

Adopt chatgpt2api only if you are doing non-commercial research on protocol reverse engineering and can accept that the accounts you feed it may be limited or permanently banned. Do not adopt it for production workloads, paid services, or any account you care about, and do not adopt it if you need a vendor who will answer a support ticket. Before you start, verify three things: that you have set auth-key in config.json, that the storage backend you pick matches your deployment (json, sqlite, postgres or git), and that you understand the README's warning that testing should never use your own important or high-value account.

Frequently asked questions

Official sources

1. basketikun/chatgpt2api on GitHub
2. License: MIT
3. Project website
4. README
5. Releases