BillyGPT: a maintenance-mode Flet desktop ChatGPT client

What BillyGPT solves and who it was written for

BillyGPT is a desktop ChatGPT client. The README frames it as an early ChatGPT API client with reproducible setup, safer local key handling, and a smoke-check path. That framing is accurate about the intent: the project exists so that a user with their own OpenAI API key can hold a conversation in a native window, keep the transcript on their own disk, and edit the messages afterwards.

The intended user is a Python developer who wants local control over chat data and does not want a browser tab in the loop. The feature list is short and specific: local chat history storage, a prompt-optimization mode, long conversation summarization, import and export of history, editable message role and content, custom font selection, and bring-your-own API key. Nothing in that list depends on a hosted account, which is the point.

The README is also explicit that the value is mostly historical. It describes the project as a maintenance-mode legacy project built for the early ChatGPT API era in 2023 and says BillyGPT was made during the first public ChatGPT API wave. Read that as a statement of scope, not modesty. This is a reference implementation you can read end to end, not a client with a roadmap.

How the Flet client, chat store and prompt module fit together

The repository layout tells you most of the architecture. main.py is the entry point. chat_store.py handles local chat persistence, api_key_store.py handles key loading, prompt_engineering.py holds the prompt-optimization logic, and paths.py centralises filesystem locations. assets/ and pic/ hold static files. scripts/ holds the three checks. There is no server component and no database: state lives in local files under paths the app resolves at runtime.

The UI is Flet, pinned to 0.25.2 across four packages (flet, flet-cli, flet-desktop, flet-web). Flet renders a Python-defined interface either as a desktop window or through a local web server, and the presence of flet-web in requirements.txt is why scripts/check_frontend_startup.py can drive the same UI in a headless browser instead of a window.

The API layer is the OpenAI Python SDK at 0.27.0, the pre-1.0 client where calls were module-level functions rather than a client object. That pin is the single most consequential fact about the codebase. Any new work on the API side means either staying on that old surface or rewriting the call sites, and the README does not describe a migration path.

Data flow is straightforward: the user composes a message, prompt_engineering.py optionally rewrites it, the SDK call goes out with the key loaded by api_key_store.py, and the reply is appended to a conversation persisted by chat_store.py. Summarization is a second pass over that stored history. No component talks to a BillyGPT-operated backend.

Installing BillyGPT and running a first conversation

The README names Python 3.10 as the verified runtime for this legacy dependency set. Start there; the pinned Flet and openai versions are not described as tested on newer interpreters.

Install the dependencies from the repository root:

pip install -r requirements.txt

For a fully pinned environment the README points at requirements-lock.txt instead:

pip install -r requirements-lock.txt

Set the key through the environment rather than typing it into the settings dialog, because the README states that the dialog keeps an entered key for the current process only:

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

The desktop window should open with an empty conversation list. If you want to confirm the pieces work before touching the UI, run the smoke check, which the README says verifies imports, API key loading, and chat persistence helpers without opening the UI:

python scripts/smoke_check.py

For a fresh-clone sanity check, the README gives a second script that verifies the tracked files are sufficient:

python scripts/check_release_files.py

There is a third check, scripts/check_frontend_startup.py, which runs a local Flet web server and a headless browser. It needs Chrome or Chromium installed. If the script cannot find the browser, set CHROME_BIN to a local Chrome or Chromium executable. The README states that the script intentionally fails in environments without a headless browser rather than opening the desktop UI, so a failure there is a missing dependency, not a broken app.

The pinned openai==0.27.0 dependency is the real constraint

Every other limitation in BillyGPT follows from the SDK pin. openai==0.27.0 is the pre-1.0 Python client. Code written against it does not carry over to the 1.x client without edits, and the README does not claim otherwise; it simply records that the project uses the OpenAI Python SDK version pinned in requirements.txt.

That makes BillyGPT the wrong tool for anything that needs current API features. If your work depends on request shapes or parameters introduced after that client generation, this codebase cannot express them without a rewrite of the call sites in prompt_engineering.py and wherever else the SDK is invoked. The README does not document such a rewrite, and no release has been cut, so there is no upgrade artefact to follow.

There is a second, quieter failure mode around keys. The settings dialog holds an entered key for the current process only, so a user who types the key once and restarts the app will find it gone. The README's recommendation is to set OPENAI_API_KEY in your shell or local environment manager for repeat use. That is a deliberate trade-off in favour of not persisting secrets to disk, but it surprises people who expect a desktop app to remember credentials.

The repository also ignores legacy APIKEY.txt files and chat logs. If you fork or copy the project, the README asks you to check your changes before pushing and gives two commands for that purpose. It adds a point worth repeating: 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.

BillyGPT compared with a plain Python script or a maintained client

The honest alternative to BillyGPT for a single user is a short Python script against the current OpenAI SDK: read a prompt, call the API, print the reply. That gives you no window, no stored history, no import and export, and no prompt-optimization pass, but it also gives you no pinned 0.27.0 dependency and no Flet runtime to install. If your goal is to send prompts and read answers, the script wins on every axis except the ones BillyGPT was built for.

The other alternative is a client that is still being developed. BillyGPT's README states its own position plainly: it is a maintenance-mode legacy project kept as a stable historical desktop-client implementation. A maintained client would track the current SDK, ship releases, and handle API changes as they land. BillyGPT does none of that, and the README does not promise it will.

What BillyGPT offers instead is a complete, small example of a desktop client in Python. Local history in chat_store.py, key handling in api_key_store.py, prompt rewriting in prompt_engineering.py, and a Flet UI in main.py. If you are building your own client with Flet, reading those four files is faster than assembling the same pieces from Flet's own examples, because the integration with the OpenAI API is already there. That is a different use case from running it daily, and the project's own framing supports the reading rather than the daily-driver one.

Maintenance state, licence and what an upgrade would cost

The repository is not archived, and the last push was on 2026-06-08. That is more than six months before the date of this writing, so the code is not under active development in any meaningful sense. The README's own label, maintenance-mode legacy project, matches the push history rather than contradicting it.

No releases have been cut, which means there is no version to pin, no changelog to read, and no upgrade path to follow. Anyone adopting BillyGPT is adopting the main branch as it stands.

Upgrade cost, if you wanted to modernise it, concentrates in two places: the openai==0.27.0 pin and the four Flet packages at 0.25.2. The Flet side is a UI toolkit version bump; the OpenAI side is an API surface change that touches every call site. The repository does not document either migration, so the cost has to be estimated by reading the code, not from project guidance.

The licence is MIT, which permits use, modification and redistribution with the licence and copyright notice retained. That is permissive enough for forking into a private tool. Nothing here is legal advice, and the MIT text in LICENSE is the authority, not this paragraph. One practical note on top of the licence: the README's security section asks you not to commit API keys or local chat logs, which matters more in a fork than in the original repository, since a fork is where your own history and credentials will live.

Editorial conclusion

Adopt BillyGPT if you want a small, readable example of a Flet desktop client that talks to the OpenAI API with local history and an environment-based key, or if you are studying early 2023 client design. Do not adopt it as the base for a new product: the README labels it a maintenance-mode legacy project, the dependency set is pinned to openai==0.27.0, and no release has been cut. Before you invest time, run python scripts/smoke_check.py and python scripts/check_release_files.py on a fresh clone under Python 3.10, and confirm that the pinned SDK still matches the API behaviour you need.

Frequently asked questions

Official sources

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