BillyGPT is a 2023 desktop ChatGPT client that upstream openai 0.27.0 outgrew

openai 0.27.0 is the pin that defines the project's ceiling

The dependency file is six lines and that is the clearest statement of what this project is:

flet==0.25.2
flet-cli==0.25.2
flet-desktop==0.25.2
flet-web==0.25.2
openai==0.27.0
websockets==13.1

Four of those pin Flet, the Python UI framework, at one exact version across its CLI, desktop, and web packages. The fifth pins the OpenAI SDK to 0.27.0, a release from the era when the Python client still exposed a `ChatCompletion` interface. The last is a websocket library, which points at the streaming path the app uses to receive completions.

Exact pins with no ranges are a deliberate choice for a project whose stated purpose is reproducibility. The trade is total: nothing in that list can move, including the SDK. Any current OpenAI account with a modern API surface is not what this code was written against, and the README is candid that the project uses the SDK version pinned in `requirements.txt`.

A second file, `requirements-lock.txt`, exists for a fully pinned environment, so the two-file setup distinguishes a working install from a byte-identical one.

Python 3.10 is named as the verified runtime, not as a minimum

The usage section says Python 3.10 is the verified runtime for this legacy dependency set. That wording is worth reading closely. Verified is not the same as minimum, and it is not the same as maximum either. Nobody is claiming the app breaks on 3.11 or 3.12, but nobody has checked.

The install itself is two commands:

pip install -r requirements.txt
python main.py

There is no build step, no packaging, and no entry point beyond `main.py`. The tree at the repository root is small enough to enumerate from the README's own framing: `main.py`, `api_key_store.py`, `chat_store.py`, `paths.py`, and `prompt_engineering.py`, plus an `assets/` directory, a `pic/` directory, and `scripts/`. Five Python modules and a window.

That layout is the strongest argument the project makes for itself. Every piece of the application is a file you can open, and the separation is by concern rather than by layer: keys in one module, local chat history in another, prompt construction in a third, and path resolution in a fourth. For a 2023 client written in a year when most alternatives were JavaScript, that is a legible design.

A key typed into settings dies with the process, so the environment variable is the real path

Key handling has two routes and one of them is a trap. The settings dialog keeps an entered key for the current process only. Not on disk, not in a config file, not for next Tuesday. The moment you close the app, it is gone.

The documented alternative sets it in the shell:

export OPENAI_API_KEY="your-key-here"
python main.py

The README's phrasing is unambiguous about which one to use for repeat work: set `OPENAI_API_KEY` in your shell or in a local environment manager. That is not a style preference, it is the difference between typing your key once and typing it every time.

The dedicated module for this is `api_key_store.py`, and its existence in a five-module application says something about how much of the 2023 client was about not writing keys to disk. The feature list also carries bring-your-own-key as a headline item, which was the norm then and is now table stakes.

The security note underneath it is blunter than the rest of the documentation. Never commit API keys or local chat logs. The repository ignores legacy `APIKEY.txt` files and chat logs through its `.gitignore`, and the advice for anyone who forks is to check before pushing. The remediation advice is the important part: if a key was ever committed, delete it in the provider dashboard and create a new one, because removing it from Git history is not enough.

Three check scripts, and one of them fails on purpose

The `scripts/` directory is the part of this repository that was added for later maintenance rather than for the original app, and it is the part with real value today.

`scripts/smoke_check.py` verifies imports, API key loading, and the chat persistence helpers without opening the UI. That is the one to run first, because it is fast and it tells you whether the pinned environment resolved at all.

`scripts/check_release_files.py` answers a different question: whether the files tracked in git are sufficient for a fresh clone. That is a packaging check, and it is unusual to see in a project this size.

`scripts/check_frontend_startup.py` is the most interesting of the three, and the most awkward. It runs a local Flet web server plus a headless browser, so it can verify the interface actually starts. It does not open the desktop app window or a visible browser window. It needs Chrome or Chromium installed, and when it cannot find one you set `CHROME_BIN` to a local executable.

That last behaviour is a design decision worth naming. The script intentionally fails in environments without a headless browser instead of falling back to opening the desktop UI. A check that silently degrades into a different kind of test is worse than a check that fails, so this one refuses.

The feature list is four 2023 ideas and one that outlived them

Seven features are claimed, and read as a set they describe a specific moment. Local chat history storage. Prompt-optimization mode for more structured answers. Long conversation summarization. Import and export of chat history. Editable message role and content. Custom font selection. Bring-your-own OpenAI API key.

Editable message role and content is the interesting one. The ability to change who a message is attributed to, or to rewrite what it says, is a debugging and prompt-engineering affordance. It is also the kind of feature that tells you the client was built by someone thinking about how models respond to input rather than only about consuming output. `prompt_engineering.py` at the root is the module that backs it.

The prompt-optimization mode has a companion cost. A mode that rewrites your prompt to get a more structured answer changes what the model sees, and the client is not a neutral pipe in that case. Anyone evaluating an output from this app should establish which mode produced it first.

Custom font selection sounds trivial and belongs to a category that no longer distinguishes anything. The other six are still recognisable needs. Reading the list is a decent way to understand what people thought a personal AI client should do in early 2023, before any of it was table stakes.

Maintenance mode is stated four times, and the last push was 2026-06-08

The status is not ambiguous anywhere. The README opens by calling it a maintenance-mode project from March 2023 and says it is kept public as an early ChatGPT API desktop client. The status section repeats it: maintenance-mode legacy project, built for the early ChatGPT API era in 2023, uses the OpenAI Python SDK version pinned in `requirements.txt`, kept as a stable historical desktop-client implementation.

The last push to the repository was on 2026-06-08, and there are no GitHub releases, so the version history is the commit log. A project in maintenance mode with a pinned legacy SDK is not a security risk in itself, but it is not something to build on either, and the repository does not ask you to.

The historical framing is where the honest value sits. The README says it captured early product ideas around prompt optimization, local control, editable conversations, and personal AI clients, and that its value today is mostly historical. Read that as guidance rather as modesty: this is a reference implementation to read, not a client to deploy.

Licensing is MIT with a LICENSE file at the root, so forking and adapting it carries no friction. The security note about checking your changes before pushing applies with more force to a fork, since the ignored files that protect the original repository's keys are yours to maintain or lose.

Before you run it, install first, because two of the three checks import the app

The troubleshooting section is short enough to state as a rule: install dependencies before running the checks. That is all it says, and it is easy to get wrong because a smoke check that fails on a missing import looks like a broken repository rather than a missing virtual environment.

The order that works is the documented one. Create an environment, install from `requirements.txt`, then run `python scripts/smoke_check.py`. Only after that passes is it worth trying `python scripts/check_release_files.py`, and only after that is `python scripts/check_frontend_startup.py` worth the Chrome dependency.

If the startup check cannot find Chrome, set `CHROME_BIN` rather than installing a browser and hoping it lands on the default path. The script looks for a browser and refuses to substitute the desktop UI, so an unset `CHROME_BIN` in an environment where Chrome exists somewhere non-standard produces a failure that looks like a code problem.

One practical note on the API side, which the README does not spell out: the app talks to the Chat completions interface through a pinned 0.27.0 client, so pointing it at a current account means checking what that SDK version expects before you interpret any error as a bug in the app. The key loading is verified by the smoke check without a network call, so a green smoke check tells you nothing about whether a request will succeed.

Editorial conclusion

BillyGPT earns a look if you are studying how desktop AI clients were built against the first ChatGPT API, or you want a Flet application small enough to read in an afternoon: five Python modules at the top level and a `scripts/` directory of checks. It does not earn a place in anything you intend to keep running, because the pinned `openai==0.27.0` predates the current SDK and the last push was on 2026-06-08. Before you spend an afternoon on it, run `python scripts/smoke_check.py` after installing dependencies, and set `OPENAI_API_KEY` in your shell rather than typing a key into the settings dialog, which only holds it for the current process.

Frequently asked questions

Official sources

1. B1lli/BillyGPT on GitHub
2. Issues
3. License: MIT
4. README