Reflex Chat: a Python-only ChatGPT clone you can read end to end

What Reflex Chat actually is, and who it is for

The README opens by calling it "a user-friendly, highly customizable Python web app designed to demonstrate LLMs in a ChatGPT format." That word, demonstrate, sets the contract. This is a reference implementation, not a hosted product, even though a live instance is linked from the repository homepage. The intended reader is a Python developer who wants to see how a chat interface is assembled when the frontend is also Python, and who is willing to treat the result as a starting point rather than a finished service.

The feature list is short and honest: create and delete chat sessions, a responsive layout, and the ability to swap the LLM. There is no user account system, no shared conversation, no export, no rate limiting and no moderation layer mentioned anywhere in the README. If you need any of those, you are writing them yourself. The value on offer is the shape of the thing: a working chat loop, a session list, and an API call, expressed in one language.

It is also a Reflex showcase more than an OpenAI showcase. The OpenAI dependency is one line in requirements.txt, and the README explicitly says you can "easily swap out any LLM." The interesting decisions in this repository are about how Reflex structures state and components, not about prompt design.

How the app is put together: Reflex state, not a React frontend

Reflex compiles Python component definitions into a web frontend and keeps a server-side state object that the browser talks to. In this repository that architecture is visible from the top-level layout: a chat/ package holds the application code, rxconfig.py holds the project configuration that reflex init and reflex run read, assets/ holds static files, and docs/ holds the demo recording referenced by the README.

The practical consequence is that chat history lives in state on the server, and the browser renders whatever that state says. Adding a message or deleting a session is a state mutation, not a fetch call you write by hand. The README's customization claim follows from the same design: styling is described as a Reflex concern, and it points readers at the Reflex styling documentation rather than at any CSS in this repository. If you already know React and a component library, you are trading that knowledge for a single-language codebase. If you do not, the trade is clearly in your favour.

What the README does not describe is the internal file structure of chat/, the exact state class names, or how streaming responses are handled. Anyone planning to extend this should read the source rather than the README, because the README stops at the feature list.

Installing Reflex Chat and sending a first message

The prerequisites are Python 3.10 or newer and a valid OpenAI subscription. The README's first step is the API key, exported into the environment under the exact name OPENAI_API_KEY:

export OPENAI_API_KEY="YOUR_OPENAI_API_KEY" # replace me!

Clone the repository, then install the two dependencies declared in requirements.txt. That file pins reflex at 0.7.11 or newer and openai at 1.78.1 or newer, so pip will resolve to whatever current release satisfies those floors.

git clone https://github.com/reflex-dev/reflex-chat.git
cd reflex-chat
pip install -r requirements.txt

With dependencies in place, the README gives two commands. reflex init prepares the project, and reflex run starts it:

reflex init
reflex run

Reflex starts a development server and prints the local address in the terminal. Opening it should show the chat interface with the session controls described in the feature list. Type a message and the app forwards it to OpenAI using the key from your environment; if the key is missing or invalid, the failure surfaces at that point, not at startup. The README does not document a port, so read the address Reflex prints rather than assuming one.

The limitations the README leaves unstated

The most consequential gap is persistence. Nothing in the README mentions a database, and the top-level entries contain no migration directory, no schema file and no storage configuration. Chat sessions therefore exist for as long as the server-side state does. Restart the process and the sessions are gone. For a demo that is fine; for anything a colleague will use on Monday morning it is a defect.

The second gap is the API key. Exporting OPENAI_API_KEY in a shell is a developer workflow. It means every deployment target needs that variable injected, and it means the key sits in the same process that serves the UI. The README offers no guidance on secret handling, and no proxy layer is present in the repository layout.

The third is scope. There is no authentication of any kind, so anyone who can reach the running app can spend your OpenAI quota. Combined with the absence of rate limiting, that makes an internet-facing deployment of the unmodified app a bad idea. None of this is hidden maliciously; it is simply outside the stated purpose of demonstrating LLMs in a chat format. Treat the README's silence as the specification: if a behaviour is not listed as a feature, assume you own it.

Reflex Chat compared with a FastAPI plus React chat template

The obvious alternative for a Python developer is the conventional split: a FastAPI backend exposing a chat endpoint, with a JavaScript frontend consuming it. FastAPI appears frequently in searches around this project, which suggests people arrive expecting that shape. The difference in approach is real and worth stating plainly.

In the FastAPI model you write two codebases and one interface contract. The backend owns sessions, authentication and streaming; the frontend owns rendering and optimistic updates. You get a mature ecosystem on both sides, and you can hire for either half independently. You also get to maintain a build pipeline, a type boundary and two sets of dependencies.

Reflex Chat collapses that into one language and one process. State changes flow through Reflex rather than through endpoints you design. The cost is that you inherit Reflex's model for everything, including the parts where you would rather drop down to raw HTTP. If your team already writes React, the single-language benefit shrinks and the framework dependency grows. If your team is Python-only and the chat UI is a side feature of a larger tool, the calculus flips. Neither choice is universally right, but the deciding factor is who maintains the frontend, not which framework is faster.

Maintenance, upgrades and what the MIT licence means here

The repository is not archived, and the last push was on 2026-06-02. That is recent enough that the project has not been abandoned, but the README gives no release notes, no changelog and no versioning policy, so there is no documented upgrade path to follow. Your upgrade signal is requirements.txt, which uses lower bounds rather than pins: reflex>=0.7.11 and openai>=1.78.1. A fresh install today can pull a Reflex release considerably newer than the one the code was written against, and Reflex has been moving quickly. If reflex run fails after a fresh install, the version floor is the first thing to inspect, and pinning an exact Reflex version in your own fork is the cheapest way to make builds reproducible.

The MIT licence is permissive: it allows commercial use, modification and redistribution, and it requires that the copyright notice and licence text travel with copies. That is the whole of it. Nothing in the repository imposes a separate terms-of-service layer, which means the compliance burden you actually carry comes from the OpenAI API terms governing the key you supply, not from this project's licence. If you fork and ship it, keep the LICENSE file. Beyond that, this is not a place for legal advice, and the licence text in the repository is the authority, not this paragraph.

Editorial conclusion

Adopt Reflex Chat if you want a readable Python reference for wiring an LLM chat UI and you are comfortable with Reflex as the framework. Do not adopt it as a production chat backend: it ships no authentication, no database and no persistence layer, and the README documents none of those. Before you build on it, check the Reflex version pinned in requirements.txt against the Reflex release you intend to run, and confirm the OPENAI_API_KEY path is replaced by a server-side secret store rather than an exported shell variable.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. reflex-dev/reflex-chat on GitHub