Major breakage on g4f.dev/chat/

[Palacee-hun]

On the evening of 17 December 2025, both g4f.dev/chat/ and g4f.dev/chat/sr.html (the screen reader friendly version) worked perfectly. However the following day (which was yesterday, 18 December 2025) major breakage symptoms occured which haven't "healed" yet.
The first noticeable thing was that the page reported its version as "undefined" - it reported 6.7.1 on 17 December 2025. The "Failed to load public key" message appeared in the log section of the page. But the most serious issue is that the provider selection is almost non-working. It began with no providers displayed at all, then slowly some providers began appearing up to the point that altogether 13 appeared (it was 72 on 17 December 2025). But this morning (19 December 2025) only 2 providers are shown again (Default and Nectar).
I almost exclusively use mlabonne/gemma-3-27b-it-abliterated model which is only available through the "HuggingFaceAPI" provider (since recently HuggingFace divided its model portfolio into various providers, and now this model is in the provider labelled "HuggingFace (text generation)" ). But this provider (as most others) simply doesn't appear in the providers list now, and thus I simply cannot select it.
I see the exact same symptoms both on my Windows laptop with Firefox and on my iPhone with Safari.
I went into the Firefox web console for some diagnostic info and I see that fetching
https://g4f.dev/backend-api/v2/version
produces "Internal server error" result, more specifically it can be seen from the returned JSON that
"shield:status:530" is returned. This points to a Cloudflare Smart Shield type of issue.
The same happens when fetching
https://g4f.dev/backend-api/v2/providers
I manually pointed my browser to
https://g4f.dev/backend-api/v2/models/HuggingFaceAPI
to check whether the provider-specific model list for the provider I am most interested in would be available at all. But, no, "shield:status:530" is returned again.
So it's no wonder that the provider list doesn't work normally. This all points to a Cloudflare-side issue or a backend breakage or both. I've seen lots of these since I use g4f.dev/chat/ (September 2025) with lots of various symptoms, but those all cleared up in few hours, but this persists for more than a day, that's why I am opening this issue. The question is whether others can experience this breakage too, or there is something specific going on for me. I access the page from Budapest, Hungary. I don't experience any problems with other webpages hosted by Cloudflare.

[Palacee-hun]

As of 24 December 2025, all described symptoms are resolved and everything works as expected again. Thanks much and merry Xmas!!!

[hlohaus]

@Palacee-hun merry xmas 👋

[Palacee-hun]

Unfortunately backend breakage occured again. On the evening of 26 December 2025, the working of the site became erratic once more. I saw in the web console of Firefox that the backend URLs mentioned in my original description returned "Error 1033". Of course that resulted in syntax errors in JSON parsing, as"Error 1033" is by no means a valid JSON. On this morning (27 December 2025) the situation is that fetching the backend URLs produces "502 Bad Gateway". These of course also result in syntax errors in JSON parsing for the same reason. So another Cloudflare-related backend breakage. Cloudflare is probably not the easiest beast to work with in a stable manner I suppose. Now the symptoms are:

• version is reported as 6.8.0 (probably okay)
• "Failed to load public key"appears in the log once more (probably important for some providers)
• provider list is messy: 15 live providers + 15 other providers with some duplications in that section. Huggingface-related providers and many others are misssing. This is much more diverse than for the original issue, but significantly more limited than it usually is.
  As an "added bonus" I note a coding error that Firefox flags for a long time and for a reason. In line 3757 of chat.v1.js "Unreachable code after return statement" is flagged. The problem is with the erroneous commenting of the if block between lines 3751 and 3755. Only the beginning and ending line of the block is commented with a single line comment (//) and not the whole block itself with a block comment (/* ... */). The result is that the code in the if block runs unconditionally and that block contains a return statement on line 3754, so everything after it up to the end of the try block the whole stuff is in is skipped. That's why Firefox flags this rightfully.
  This is absolutely not related to this issue, as that code piece deals with media recording. But I note this as sort of a post-Xmas gift :)

[hlohaus]

Thank you for utilizing gpt4free and for bringing these issues to our attention. We are committed to resolving them promptly.

Regarding your report, the /v1 endpoint was experiencing functionality issues, and the Python providers were unavailable. To clarify, the Python providers on g4f.dev previously required a local Python server, which occasionally necessitated manual restarts.

@Palacee-hun

We are pleased to inform you that the /v1 endpoint now operates on a new cloud-based backend, eliminating the dependency on Python. We trust this enhancement will significantly improve your experience with AI.

[Palacee-hun]

Maybe because of this infrastructural change, maybe not, but LMArena provider throws the following error in the chat section:
LMArena with grok-4-fast-chat
An error occured: MissingRequirementsError: Install "nodriver" and "platformdirs" package | pip install -U nodriver platformdirs
I got this when trying to regenerate the last response in a conversation.
In the log section I furthermore found the following relevant message:
MissingAuthError: Response 401: User not found
LMArena: Cloudflare error
MissingRequirementsError: Install "nodriver" and "platformdirs" package | pip install -U nodriver platformdirs User: admin
This is the first time I tried using LMArena provider so I don't know whether this is something brand new or not.
I also don't know whether LMArena would require some form of auth on my side. It doesn't have the "key" symbol besides its name in the provider list, so in theory no.
By the way there is something interesting also in the log section:
OpenaiChat: New conversation:
What's particular about this message is that I have never ever chatted with any OpenAI-related provider or model through g4f.dev/chat, so I haven't got the faintest idea where this comes from.

[hlohaus]

@Palacee-hun, we are currently utilizing browser automation for authentication purposes, specifically employing a tool named Nodriver. This process necessitates the use of Google Chrome and the Nodriver Python package. It is worth noting that OpenAI Chat is designated as one of our default providers when the default model is in use.

[Palacee-hun]

Unfortunately g4f.dev "celebrates" New Year's Eve with yet another backend breakage. The whole thing started in the afternoon of 30 December 2025. The first thing that happened was that the "Failed to load public key" error message appeared in the log again. Because of this, generation stopped working, as encription errors appeared in the web console when g4f.dev tried to send my request to HuggingFaceAPI provider (model mlabonne/gemma-3-27b-it-abliterated). The Firefox web console showed that interacting with
https://g4f.dev/backend-api/v2/public-key
produced "502 Bad Gateway" error.
After some time this "502 Bad Gateway" behaviour started propagating to other g4f.dev/backend-api/v2/... URLs. First the model lists went down, then after around half an hour everything else also broke down: /v2/version, /v2/providers. etc. "502 Bad Gateway" everywhere, and this still persists now, in the morning of 31 December 2025. This indicates a backend stoppage, and probably neccessitates manual intervention.
g4f.dev reports itself as version 6.8.2 (probably correct)
I note here that when sending requests breaks because of the failure to load the public key, the chat interface stucks in such a way that I have to press "Stop generating response" to "wake it up". The chat interface should handle such situations gracefully, and should display a suitable error message in the chat window instead of waiting infinitely. I experience this behaviour with the screen reader friendly version, but I presume it is the same for the "normal" one as well. I use them both alternately, but I just haven't tried this scenario with the "normal" one yet.
I will leave this issue open indeterminately as a placeholder where I can report backend breakages of this nature, i.e. when g4f.dev accessing backend URLs produces serious errors when such a behaviour persists for more than half a day.
I wish everyone who reads this a happy, productive and satisfying 2026 with much less bugs and erratic behaviours!

[hlohaus]

@Palacee-hun Greetings. To utilize the HuggingFaceAPI on g4f.dev, kindly integrate HuggingFace as a custom server within the members' area, accessible via https://g4f.dev/members. Subsequently, you will be able to leverage it as a provider within the Chat interface. This functionality operates entirely within a cloud-based environment, ensuring robust and continuous service. Enjoy your experience.

[Palacee-hun]

I reopen this issue, as on 29 January 2026 another serious breakage occured regarding g4f.dev/backend-api/v2/... type URLs. As I state in my comment above, I use this issue as a placeholder for such problems,because I don't feel it appropriate to clutter the issue space with new issues every time something along this line happens.
Now g4f.dev/backend-api/v2/... URLs (like version, providers, model lists, speech synthesizer etc.) all simply return Error 404, i.e. page not found. This still persists on 3 February 2026. g4f.dev/chat/reports version 7.0.0, so apparently a new major version. Perhaps somethinghas been restructured, and somehow hasn't been followed up in the code of the website yet. Consequences are "Failed to load public key" error in the log, and e.g. "Play audio" feature not working as accessing that URL (also in backend-api/v2) also returns error 404. Chat functionality seems unaffected this time. Furthermore on 30 January 2026, CORS error for https://mcp.g4f.dev/mcp also began to appear in theweb console of Firefox when the code tried fetching tools.
Note to @hlohaus: I have found out that in fact I can't reopen this issue myself, as I am not a contributor for this repo, and though I am the author of this issue, but it was not me who closed it. Nevertheless I hope this report reaches the g4f.dev developers this way too, as just a simple comment.

[Palacee-hun]

@hlohaus, I suspect that you just accidentally closed this issue again with a wrong click few seconds after you had reopened it. I see no other reason for this so hasty closing again, as no fix seems to be made: the issues I mention in my comment of 29 January 2026 still persist in the exact same way.