billmei/every-chatgpt-gui: What the List Actually Contains and How to Choose From It

A List of GUIs, Not a GUI

The first thing to get straight is what this repository is. The README describes it as a list made "to keep track of every graphical user interface alternative to access the API for ChatGPT, Claude, and other LLMs." There is no application to install, no server to start, no configuration file to edit. The deliverable is a README of links. The author compares it to an earlier project of theirs, Every Proximity Chat App, which follows the same pattern: one person maintaining a catalogue of other people's work. That framing matters because it sets the expectation for everything else. You are not evaluating software here. You are evaluating a directory of software, and the directory's quality is a function of how it is organised and how current it stays. The repository is MIT licensed, so the list itself can be copied and reused, though that licence says nothing about any of the projects it points to. Those carry their own terms, and the README does not record them.

The Four Buckets and What They Tell You

The list is divided into Open Source and, within that, four deployment categories: Web, Browser Extension, Obsidian plugins, and Self-Hosted, plus Desktop. The split is more useful than a flat alphabetical dump would be, because deployment model is usually the first real constraint a team hits. A browser extension such as ChatHub or chatGPTBox installs into an existing browser and has no server component, which makes it the lowest-friction option and also the one with the least control over where prompts travel. An Obsidian plugin such as ChatGPT MD or BMO Chatbot only makes sense if your notes already live in Obsidian. The Self-Hosted group, which includes LibreChat, Open WebUI, Chatpad AI and others, is where you take on a server, a database and an upgrade path. Desktop covers standalone applications like Chatbox, Cherry Studio and Jan. The categories are not airtight. Several projects could plausibly sit in two of them, and the README does not explain the boundary. Treat the headings as a rough first filter, not a taxonomy.

What Each Entry Actually Gives You

An entry is a name, sometimes a live demo link, and a source link. That is the whole record. There is no column for which providers a client supports, whether it handles streaming, whether it stores conversation history locally or remotely, what its licence is, or when it was last updated. For a project like bolt.new, which the README files under Open Source / Web, the name alone tells a reader almost nothing about scope. For a fork, the README is more helpful: SmoothGPT is marked as a fork of ChatGPT UI, and WolfeChat is marked as a fork of SmoothGPT. Those parenthetical notes are the only relationship data in the list, and they are worth reading closely, because a fork inherits its upstream's architecture and usually its upstream's bugs. The absence of a comparison table is the repository's central limitation. It answers "what exists" and stops there. Answering "which one fits my constraints" is left entirely to the reader, who has to open dozens of tabs to get information the list could have carried in a column.

Adding Yourself, or Getting Removed

Contribution is deliberately loose. The README states that anyone can open a pull request to add an app, that it should go under the appropriate category, and that entries are kept in alphabetical order. The same mechanism works in reverse: if you want your app removed from the list, the README says you can open a pull request to do that too. There is no review criteria stated, no minimum activity threshold, no requirement to declare a licence. The alphabetisation rule is the only editorial constraint mentioned, and it is the kind of rule that quietly does work: it prevents the list from becoming a ranking, which keeps it neutral but also means position in the list carries no signal at all. If you are maintaining a client and want it listed, the path is a README edit. If you are a reader, understand that inclusion means someone opened a pull request and it was merged, nothing more.

The Pay-Per-Token Argument Behind the List

The README links to an external guide by the same author titled around paying $1.79 instead of $20 per month for AI. That link is the closest thing to a stated motivation for the whole project. The premise is that a subscription bundles access at a flat rate, while an API key bills per token, and a GUI client is the piece that lets a non-technical user reach the API without writing code. This is the real audience: people who want API pricing but not a terminal. It also explains the shape of the list. Web and Desktop entries matter most to that reader, because they need something they can open and use. The Self-Hosted and Obsidian sections serve a different reader entirely, someone already comfortable running services or already living inside a note-taking app. One list, two audiences, and the README does not separate them. If you are the first kind of reader, the Self-Hosted section is mostly noise.

Where the List Fails a Real Evaluation

The failure mode is straightforward. Suppose you need a client that talks to the Anthropic API and keeps conversation data on your own machine. The README's topics include anthropic and claude, and claude-ui appears under Open Source / Web, so the list acknowledges the provider. But nothing in the entry tells you whether claude-ui stores history locally, what its licence is, or whether it is still maintained. You will open the source link and find out yourself, which is exactly the work the list was positioned to save. A second failure mode is drift. The list is a single README with no automated check that the linked projects still exist, still build, or still work against current API versions. A demo link that returns a 404 is indistinguishable from a working one until you click it. The last push timestamp on the repository tells you when the list itself changed, not when any listed project did. For a fast-moving category, that gap is the main risk of relying on this as your only source.

LibreChat and Open WebUI as the Self-Hosted Contrast

If you want to see how differently two entries in the same category can behave, compare LibreChat and Open WebUI, both filed under Self-Hosted. The README gives each a source link and, for LibreChat, a demo link. That is the extent of the distinction it draws. In practice these are different kinds of commitment: one is a multi-provider chat application you deploy and maintain, the other is a self-hosted interface that has grown its own surrounding ecosystem. The list does not say this. It also does not mention lighter self-hosted options in the same section, such as Chatpad AI, which the README pairs with a demo at chatpad.ai. A reader scanning the Self-Hosted block sees a flat set of names and has no way to tell which are weekend deployments and which are services that will demand ongoing attention. The category label is accurate and almost useless on its own. This is the point where you leave the list and read the individual repositories.

Maintenance Cost and the MIT Licence Question

The maintenance burden here is low and human. There is no build system described, no test suite, no dependency manifest in the material provided. Keeping the list useful means merging pull requests, fixing dead links, and re-sorting entries when names change, which is exactly the kind of work that stops happening when a maintainer loses interest. The repository is not archived and its last push is recent as of the supplied data, so the list is currently alive. The MIT licence applies to the list content, which means you can fork it, reformat it into a table, or embed it elsewhere without asking. It does not extend to the linked projects, and the README does not state their licences, so a fork of this list that presents those projects as a bundle would be making a claim the source material does not support. If you reuse the list, carry the same caution: the MIT grant covers the catalogue, not the catalogue's contents.

Editorial conclusion

Adopt this list if you need a broad inventory of LLM front ends before you commit to one, and you are willing to open each linked repository yourself. Do not adopt it as a procurement document: it records no licence, no API compatibility and no maintenance status for the projects it names, and the only stated contribution path is a pull request against the README. Before you pick anything from it, check the linked project's own licence file and its last commit date, since the list will not tell you either.

Official sources

1. billmei/every-chatgpt-gui on GitHub
2. Issues
3. License: MIT
4. README