Free-GPT4-WEB-API: A Self-Hosted HTTP Front End for Free LLM Providers

The gap Free-GPT4-WEB-API fills

Most LLM providers require an account, an API key, and a billing relationship before you can send a prompt. Free-GPT4-WEB-API takes the opposite route: it wraps access to providers such as Gemini, DeepSeek, Claude and GPT behind a single self-hosted HTTP interface that returns plain text. The README describes it as a "Self-hosted web API that exposes free, unlimited access to modern LLM providers through a single, simple HTTP interface." The target user is someone who wants to call a model from a script, a shortcut, or a small internal tool without managing keys or quotas. The project's own example use case is Siri integration, which tells you the intended scale: personal automation, not multi-tenant serving. The repository is Python, licensed GPL-3.0, and the default branch is main. It is not archived, and the most recent release listed is 1.1.3 from May 2026.

How the request path actually works

The server listens on port 5500 by default and exposes a root endpoint that takes the prompt as a query parameter. A browser request to http://127.0.0.1:5500/?text=Hello returns the model's answer as plain text, not JSON. The parameter name is configurable through --keyword, so a deployment can rename text to something else, and the README notes that clients must then use the new keyword. Behind that endpoint, the server routes the request to a configured provider. The README lists Bing, DuckDuckGo and others, with DuckDuckGo described as the "reliable fallback" and Bing as the default provider in the CLI options section (the configuration section separately states DuckDuckGo is the default provider, which is an inconsistency worth checking against your installed version). Provider fallback switches automatically between Bing, DuckDuckGo and other providers, and the README mentions real-time provider status tracking. Requests can be spread across proxies or virtual users with --enable-proxies and --enable-virtual-users. There is no model output parsing layer described beyond removing sources with --remove-sources.

Running it with Docker or from source

The Docker path is a single command: docker run -p 5500:5500 d0ckmg/free-gpt4-web-api:latest. To supply cookies, mount the file read-only with -v /path/to/your/cookies.json:/cookies.json:ro. A docker-compose.yml is provided with the same image and a commented-out volume line for cookies.json. The README warns that if you plan to use the Web GUI inside Docker, you should set a password, and that the password is mandatory in some Docker environments. From source, the sequence is git clone, cd into the directory, pip install -r requirements.txt, then python3 src/FreeGPT4_Server.py. To enable the browser configuration interface, add --enable-gui, and to protect it, add --password your_secure_password. The GUI is reachable at /settings and /login on the same port. Other flags include --port, --model (default gpt-4), --provider (default Bing in the options list), --system-prompt, --enable-history, and --private-mode, which requires a private token for API access.

Cookies, proxies and the fragility they imply

The need for a cookies.json file is the clearest signal of how this project works. The README states that some providers require cookies to work properly and that for the Bing model only the "_U" cookie is needed. That means the server is not calling a documented public API with a key; it is presenting a browser session to a provider's web endpoint. Cookies expire, provider markup changes, and the README itself concedes that the demo server "can be overloaded and may not always respond." The proxies and virtual users flags exist to work around blocking, which is another admission that the upstream side is hostile to this traffic pattern. The README also notes that SOCKS and HTTP proxy support depends on your environment being configured for aiohttp and aiohttp_socks. None of this makes the project dishonest, but it does mean your uptime is a function of someone else's terms of service and front-end code, not of your own infrastructure.

Where it is the wrong tool

If you need a stable contract, this is not it. There is no versioned response schema, no token accounting, and no guarantee that a given --model value maps to the same underlying model next week. The plain-text response format is convenient for a shell script and awkward for anything that needs structured output, tool calls, or streaming. The GPL-3.0 licence also matters if you plan to embed the server in a product: the licence is copyleft, and the repository does not offer a separate commercial exception in the material provided. For workloads involving personal data, health information, or anything under a compliance regime, sending prompts through a scraped provider session is difficult to justify. The README's own security note about setting a GUI password suggests the authors expect the tool to sit on a trusted network rather than the open internet. Treat the demo hostname in the homepage field as a convenience, not an endpoint you can build against.

How it compares with a direct provider SDK

The obvious alternative is calling a provider's official API through its own SDK, for example the OpenAI Python client or Google's Gemini SDK. The difference is not just cost. An official SDK gives you a documented request and response schema, stable model identifiers, streaming, and a support path when something breaks. Free-GPT4-WEB-API gives you a single GET parameter and plain text, at the price of depending on undocumented provider behaviour and cookie files. A second alternative is a local runtime such as Ollama, which removes the network dependency entirely and gives you a model you control, at the cost of hardware and lower capability than the hosted frontier models. Choosing between them comes down to what you are optimising for: zero cost and minimal setup on one side, or predictable behaviour and a contract on the other. Free-GPT4-WEB-API sits firmly on the first side.

Maintenance cost and licence terms

The release history in the supplied material shows 1.1.1 in October 2025, 1.1.2 in January 2026, and 1.1.3 in May 2026, with the repository last pushed in August 2026. That cadence suggests active but not constant maintenance, and the release titles ("Providers Update", "New Stable Version") hint that provider drift is the main driver of new versions. Expect to update the image or pull from main when a provider stops responding. The project is GPL-3.0. If you modify and distribute it, or run a modified version as a network service, the copyleft obligations are likely to apply. This is a description of the licence identifier, not legal advice; check with counsel if you intend to ship it inside a commercial product. Running it privately for personal use carries far fewer questions.

Who should deploy this

Deploy it if you want a local endpoint for personal scripts, a home assistant, or a Siri shortcut, and you are comfortable re-pulling the container when a provider changes. The Docker command is short enough to try in a few minutes, and the --keyword and --system-prompt flags make it adaptable without touching code. Skip it if you need an SLA, structured output, or a clean compliance story. Before you rely on it, confirm three things in your own deployment: which providers are currently listed and which one is the actual default, whether your chosen provider needs a cookies.json mount, and whether the GUI is reachable only behind --password on a network you trust. Those three checks will tell you more about your real experience than any feature list.

Editorial conclusion

Adopt it if you want a local, GPL-3.0 HTTP endpoint for experimentation or a personal assistant, and you accept that upstream providers can break responses at any time. Do not adopt it for production traffic, regulated data, or anything requiring an SLA, because there is no API key contract with the providers it queries. Before committing, verify the current provider list and default model, confirm whether the provider you need requires a cookies.json file, and test the /settings and /login pages behind --password in your own deployment.

Official sources

1. aledipa/Free-GPT4-WEB-API on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases