A working package leaves provider behavior unverified
GPT4Free installed in 40 seconds and built successfully in our sandbox. That is enough to distinguish it from a checkout that stops at setup. It doesn't establish whether a chosen provider will answer your next request. The README explicitly says model availability and behavior depend on provider capabilities, a boundary that should shape the adoption decision.
The appeal is practical. A Python client, async client, optional web GUI and OpenAI-compatible API give you several ways to use the adapter collection. Text and media requests can go through hosted providers or local inference backends. If you're comparing services, a shared interface saves some integration work. You still need to know which service receives a prompt and which credentials authorize it.
What happened when we ran it
Our sandbox installed commit 74661d1 on October 14, 2026 in 40 seconds, recording 127 dependencies and 495 MB on disk. The build succeeded in 2 seconds. Tests were skipped because no tests script or target was found. Calling that a passing suite would turn an evidence gap into a result we don't have.
Pip-audit reported 0 known vulnerabilities. That finding concerns known dependency advisories in the measured environment. It doesn't establish the safety of browser sessions, prompt destinations or generated files. The scan found 4 CI workflow files and a compose file, with no Dockerfile or tests directory. The current README describes Docker images, so the scan's negative Dockerfile result should not be read as a claim that containers are unsupported.
The recorded configuration had 3 CPUs, 8 GB RAM and image ghcr.io/astral-sh/uv:python3.12-bookworm. Actual runtime and OS versions require the raw toolchain logs. The run provides no provider response measurements, model-quality comparison or uptime evidence. Its successful build is a useful starting condition for a trial, with the provider evaluation still ahead.
Cookies and HAR files change what you must protect
Some adapters need API keys or tokens. Others use browser cookies or HAR files, which can contain session data. Chrome or Chromium is a documented requirement for browser-driven providers. Local inference backends require their own model runtime. Decide which access path you need before accepting the entire project's range of integrations as your deployment scope.
The Docker examples persist har_and_cookies and generated_media. One exposes a browser desktop for optional provider logins. These details matter more than whether the first chat window appears quickly: persistent account sessions need restricted access, and generated files need a retention decision. The README itself tells production operators to add HTTPS, authentication and firewall rules. Keep that responsibility attached to whoever owns the service.
An empty-reply report concerns one named adapter
Issue 3525 reports empty replies from the OpenaiChat adapter using the API or web interface. The issue remained open and had activity on October 18, 2026. It is a user report about a named route, not a failure reproduced by our sandbox and not a reliability score for the whole project.
For your own evaluation, choose the exact adapter and model rather than accepting an automatic selection as proof of compatibility. Check that a response contains useful content, that streaming finishes, and that an expired session produces an error your application can handle. Those are proposed acceptance checks. Our recorded build cannot answer them, and a model appearing in a list cannot answer them either.
The MCP server adds web and image actions
The README documents a Model Context Protocol server with web search, page scraping and image generation tools. It supports a local stdio connection and an HTTP mode, and includes a Claude Desktop configuration. That can be useful if an assistant needs those actions through the same project you're already evaluating.
Each tool also introduces a destination or action outside the chat client. Inspect which provider handles image requests and how scraped content reaches the assistant. A working MCP connection would establish transport, while permission to fetch a page or send content to a provider remains your configuration decision. Our lab record contains no MCP execution result, so these tools contribute to scope, not to a claim of tested integration quality.
LiteLLM and Ollama narrow the decision
LiteLLM offers a Python SDK and a shared gateway for model-provider calls. Compare it when your main problem is a common API for a team's configured providers. Ollama supports open models locally and in the cloud. Compare it when running a chosen model is the job and browser-backed adapters add no value. Neither alternative was measured in this batch.
GitHub recorded a last push on October 19, 2026, with recent issue activity and provider-related pull requests. That indicates current work, without resolving the empty-reply report or guaranteeing any outside service. I'd keep a GPT4Free trial tied to one named route and a small set of disposable prompts. Before putting user traffic behind it, require that route to produce useful answers and recover from lost authentication.