Version 8.4.4 fronts hosted providers and local models
GPT4Free v8.4.4 is an adapter collection with several ways in. Python callers get synchronous and asynchronous clients, browser users get a local GUI, and existing OpenAI-style applications can point at its Interference API. Provider modules cover text and media services, authenticated accounts, browser-driven sessions, and local runtimes such as Ollama.
commit 0701d8e spans 386 files, roughly 76,608 source lines, and 19.3 MB before installation. That is a large surface for a project whose value depends on many outside services. Each adapter can inherit a provider's authentication, rate limits, page changes, model list, and terms. The README acknowledges that model availability and behavior depend on provider capabilities.
A 44-second install occupies 507 MB before model assets
Our Python 3.12 sandbox installed 137 packages in 44 seconds and consumed 507 MB on disk. The build then completed successfully in 4 seconds. Those figures came from the full measured source setup, not the smaller optional groups in setup.py. The project offers api, gui, search, image, files, local, tray, webview, and slim extras for buyers who want to reduce or specialize the environment. A careful deployment should install only the paths it uses.
Pip-audit found 0 known vulnerabilities in the installed environment at commit 0701d8e. That is a useful snapshot, though it says nothing about unreported flaws, provider-side code, Chrome extensions, downloaded local models, or a future dependency resolution. Browser automation and document conversion widen the trust boundary beyond Python packages. Pin the release and lock the environment if repeatability matters, especially because the README says the slim container can update g4f and add dependencies when it starts.
What happened when we ran it
Our run used 3 CPUs, 8 GB of RAM, no secrets, and an unprivileged Debian container. Installation succeeded in 44 seconds with 137 packages, the build passed in 4 seconds, and pip-audit reported 0 known vulnerabilities. The repository had 5 CI workflow files, a compose file, no top-level Dockerfile, and no conventional tests directory. The checkout itself held 386 files and about 76,608 lines of source.
Tests were skipped because the project exposed no tests script or target in the measured setup. That is different from a passing suite. The tree contains material under etc/testing and etc/unittest, but our harness found no command it could treat as the repository test entry point. We did not call a provider, open the GUI, start the API, exercise MCP, or generate media. No response-quality, uptime, latency, or model-availability claim comes from this sandbox run.
Three credential paths require different threat models
The README describes at least 3 access patterns: provider API keys or tokens, browser cookies or HAR files, and local model runtimes. Browser-driven providers may also need Chrome or Chromium and an interactive desktop exposed on port 7900. The full Docker example persists har_and_cookies and generated_media, while the example environment lists keys for several services. Those files and variables can carry account access, so mounting them into a convenience container is a security decision.
A hosted g4f server needs controls the package does not supply by magic. The README tells production operators to add HTTPS, authentication, and firewall rules, and to restrict access to cookie and HAR storage. Its compose example maps ports 8080, 1337, and 7900; the browser desktop should not be exposed casually. An application-level G4F_API_KEY can protect the API path, but network policy, secret storage, rotation, logs, and generated-media retention still need an owner.
Provider compatibility does not guarantee provider reliability
Issue 3519, opened September 5, 2026, asks the maintainers to publish reliability ratings after its author found that some listed models did not consistently work. One report is not a benchmark, yet its request matches the README's own caveat that availability and behavior depend on provider capabilities. Provider selection and fallback can reduce individual failures, but they can also hide changes until output quality, cost, or authentication breaks in production. Test the exact route instead of trusting a broad model name.
The legal notice adds another adoption boundary. It says the repository is unaffiliated with the API providers, intended for educational use, and places compliance responsibility on the user. That language does not decide what every use is allowed to do. It tells an organization to check provider terms, account authorization, data handling, and local law before routing real prompts through scraped or session-based adapters. Official API credentials through a conventional gateway are easier to approve and support.
MCP exposes 3 tools to assistants over stdio or HTTP
The bundled MCP server gives assistants 3 documented tools: web search through DuckDuckGo, page scraping, and image generation. It runs over stdio for a local client or HTTP with a JSON-RPC endpoint and health route. The README includes a Claude Desktop configuration, so this is a real MCP integration rather than a tag attached to the project. Every tool can reach outside the assistant process, which makes host allowlists, output handling, provider credentials, and HTTP binding part of the MCP deployment.
Documentation is uneven here. The main README links readers to g4f/mcp/README.md, but that file is absent at commit 0701d8e even though the server package and example configuration exist. The main page supplies enough commands to start it, while detailed tool behavior requires reading source. This is manageable for an experiment and weak for a service granting web and media actions to an agent. Start on loopback, use the 3-tool set deliberately, and inspect each tool before wider access.
Same-day release activity accompanies fast provider churn
GitHub recorded 66,662 stars, 2 open issues and pull requests combined, and a last push on September 8, 2026. Release v8.4.4 was published earlier that day. Nearby commits removed one provider, changed browser management, adjusted page selectors, and fixed headless handling. That pace shows active maintenance and the reason maintenance is necessary: browser-backed adapters can stop working when an outside site changes. A release tag does not freeze the services behind it.