PyChatGPT: a Python client for chatgpt.com that logs in for you

What PyChatGPT actually talks to

The name suggests an OpenAI API client. It is not one. According to the README, PyChatGPT logs into ChatGPT the way a person would, grabs an access token, and then sends questions to the same endpoint the web UI uses. The package on PyPI is named chatgptpy, and pyproject.toml describes it as a "TLS-based ChatGPT API with auto token regeneration, conversation tracking, proxy support and more".

The audience follows from that design. If you have an OpenAI API key and a billing account, this library adds nothing and takes on a login flow you do not need. It is for people who want to script a ChatGPT account session: run a prompt from a cron job, keep a conversation going across process restarts, or drive the model from a machine with no browser. The README's feature list is explicit about the mechanics: save conversations to a file, resume them after closing the program, proxy support, automatic login without a browser, automatic token capture and refresh.

One consequence is worth stating plainly. Because the client authenticates as a user rather than as an API consumer, the login path is subject to the same friction a person hits: captchas and rate limits. The README acknowledges this in its troubleshooting notes, which advise waiting at least ten minutes if you are rate limited and using a proxy or VPN if token creation keeps failing.

Token capture, refresh, and where conversation state lives

The architecture visible in the README has three layers. At the bottom is an OpenAI.Auth class that performs the login and writes a token file. In the middle is the Chat class, which wraps that auth object and sends prompts. At the top is an Options object that controls logging, tracking, proxies and moderation.

Token handling is the part with the most detail. The README states that the client saves the access token to a file so you do not have to log in again, and that it refreshes the token when it expires. It also exposes that layer directly: OpenAI.Auth(email_address=..., password=...).save_access_token(access_token=..., expiry=...) writes a token, OpenAI.get_access_token() reads the token and its expiry back, and OpenAI.token_expired() returns True or False. The change log mentions error handling for a missing or corrupt auth.json file, which tells you the token is persisted as JSON on disk.

Conversation state is carried as two identifiers, not as a message array. The README's resume example passes conversation_id and previous_convo_id into the Chat constructor, and chat.ask returns a tuple of answer, parent_conversation_id, conversation_id. In other words, continuity is maintained by handing the server the IDs of the prior exchange, which is why setting options.track = True and pointing chat_log and id_log at files lets a later run pick the thread back up. That is a different model from an API client that resends the full transcript on every call: here the server holds the history and your process holds only pointers to it.

Installing chatgptpy and sending a first question

The README gives a single install command. It pulls the package from PyPI under the name chatgptpy, not pychatgpt, which is the import name you use in code.

pip install chatgptpy --upgrade

After that, the minimal program constructs a Chat object with an email and password and calls ask. The README shows that constructing Chat logs you in automatically and checks the access token, so the first run is the one that may prompt for a captcha or fail on rate limiting.

from pychatgpt import Chat

chat = Chat(email="email", password="password")
answer, parent_conversation_id, conversation_id = chat.ask("Hello!")
print(answer)

The return value is a three-tuple, so unpacking it is not optional if you want the IDs. If you want a saved transcript and a resumable thread, build an Options object first. The README documents log, track, proxies, chat_log and id_log as attributes, and notes that the log files are created if they do not exist.

from pychatgpt import Chat, Options

options = Options()
options.log = True
options.track = True
options.chat_log = "chat_log.txt"
options.id_log = "id_log.txt"

chat = Chat(email="email", password="password", options=options)
print(chat.ask("How are you?"))

If you would rather not write your own loop, the README also documents chat.cli_chat(), which starts an interactive terminal session against the same object. On a successful first run you should see the answer printed and, with tracking enabled, chat_log.txt and id_log.txt appear in the working directory.

The failure modes the README admits to

The most useful section of the documentation is the one headed "Other notes", and it is essentially a list of ways the login can break. The README says that if token creation is failing you should try a proxy, wait at least ten minutes if you are being rate limited, and fall back to a VPN. That is an unusual thing for a library README to say, and it is honest: automated login against a consumer service is the fragile part, not the question-and-answer loop.

The change log reinforces the point. Version 1.0.2 records that the ChatGPT API "switches from action=next to action=variant, frequently", and that the library moved to action=variant to keep working. Version 1.0.7 notes that a request to the moderation endpoint has to happen first, otherwise "a crippled version of the response is returned". Both entries describe the client tracking an undocumented endpoint that can change without notice. There are no releases retrieved for this repository, so the version numbers in the change log are the only upgrade signal available.

Two smaller constraints matter operationally. First, pyproject.toml sets requires-python to ">=3.9", while the README's badge advertises Python 3.8, so the packaging metadata is the stricter and more current statement. Second, the dependency list includes tls-client, svglib, bs4 and reportlab, which is a heavier footprint than a plain requests-based client and pulls in a TLS-impersonation library to make the login look like a browser. If your environment cannot install that stack, this is the wrong tool regardless of how well the chat loop works.

What to use instead, and how the approach differs

The obvious alternative is the official OpenAI Python SDK, which authenticates with an API key and sends the message history you construct on each request. The difference is not cosmetic. With an API key there is no login step, no token file to refresh, no captcha, and no dependency on the web endpoint's action parameter; the trade-off is that you pay per token against an API account rather than using a ChatGPT subscription, and you are responsible for storing and resending the conversation yourself.

If your goal is a conversational assistant in a terminal, another option is to skip the login automation entirely and point any OpenAI-compatible client at an endpoint you control, for example a local model server. That removes the account entirely and with it the rate-limit and captcha failure modes the README describes. You lose access to the hosted ChatGPT models, which for some users is the whole point of PyChatGPT.

The honest framing is that PyChatGPT occupies a narrow slot: you want the hosted ChatGPT product, driven from Python, without a browser. Every alternative either gives up the hosted models or gives up the automated session.

Maintenance, upgrades, and the MIT licence

The repository is not archived, and the last push was on 2026-07-19. That is recent enough that the code is not abandoned, but there are no releases retrieved for it, so version discovery happens through the change log in the README and through pip. Upgrades are done in place with pip install chatgptpy --upgrade, which is also how the change log tells you to update. Because the client depends on an endpoint that the change log says has changed before, an upgrade is not purely optional maintenance: a pinned old version can stop working when the server side moves.

The licence is MIT, declared in pyproject.toml and present as a LICENSE file at the repository root. MIT is permissive, so redistributing it inside a commercial product is generally allowed provided the copyright notice and licence text are kept. That is a description of the licence terms, not legal advice; if you are embedding it in a shipped product, have your own counsel look at the notice requirements and at how you handle the credentials and token files the library writes. Those files contain an access token for a real account, and the README's design puts them on disk by default.

Editorial conclusion

PyChatGPT suits engineers who want a scripted ChatGPT session with saved conversation IDs and no browser, and who accept that the login path can be rate limited or captcha-gated. It is the wrong tool if you need a supported, documented interface with an API key: the project drives the consumer web endpoint, and the README's own troubleshooting section tells you to slow down or route through a proxy. Before adopting it, install chatgptpy on Python 3.9 or newer, run one chat.ask call, and confirm that a token file appears and that a second run reuses it instead of logging in again.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. rawandahmad698/PyChatGPT on GitHub
4. README