About the modelFLUX.1-dev Hugging Face's FLUX.1-dev model is no longer served via the hf-inference provider, returning a 410 Gone error for requests pinned to that route, but the model remains available through other providers such as fal-ai. Developers are advised to use the @huggingface/inference client with automatic provider selection or explicitly specify fal-ai, and to note that Inference Providers are pay-as-you-go beyond included monthly credits, with Free accounts receiving $0.10/month and PRO $2/month at the time of writing. Hmm… I think this is because the way the service works has changed quite a bit : The 410 Gone here does not appear to mean that black-forest-labs/FLUX.1-dev itself has been removed. The important part of the error is: no longer supported by provider hf-inference Your URL is explicitly pinning the request to the hf-inference provider : https://router.huggingface.co/hf-inference/models/black-forest-labs/FLUX.1-dev ^^^^^^^^^^^^ FLUX.1-dev still exists on the Hub, and at the moment its model page https://huggingface.co/black-forest-labs/FLUX.1-dev shows fal as a Text-to-Image Inference Provider. Hugging Face’s current Fal provider documentation https://huggingface.co/docs/inference-providers/providers/fal-ai also uses black-forest-labs/FLUX.1-dev directly in its text-to-image example. So I would not try to repair this by changing Angular-specific code around the old /hf-inference/ request. I would move to the current Inference Providers client and stop hard-coding hf-inference . For example, on a server/backend : js import { InferenceClient } from "@huggingface/inference"; const client = new InferenceClient process.env.HF TOKEN ; const imageBlob = await client.textToImage { model: "black-forest-labs/FLUX.1-dev", inputs: "A cinematic photograph of a mountain lake at sunrise", } ; The current JavaScript client uses automatic provider selection by default, so this lets Hugging Face choose an available provider instead of forcing the request through hf-inference . The official Inference Providers documentation https://huggingface.co/docs/inference-providers/ currently shows essentially this same FLUX.1-dev JavaScript example. If you specifically want to pin the currently listed Fal route, you can also make that explicit: js const imageBlob = await client.textToImage { provider: "fal-ai", model: "black-forest-labs/FLUX.1-dev", inputs: "A cinematic photograph of a mountain lake at sunrise", } ; I would prefer the first form unless you have a reason to require a particular provider. One important difference from the old Serverless Inference API model: Inference Providers are pay-as-you-go beyond the included monthly credits. At the time of writing, the pricing documentation https://huggingface.co/docs/inference-providers/pricing lists $0.10/month of Inference Providers credits for Free accounts explicitly marked as subject to change , $2/month for PRO, and PAYG after the included credits are exhausted. So changing providers restores a serving route, but it should not be understood as a drop-in replacement for unlimited/free old-style serverless inference. Also, because you mentioned Angular: if your Hugging Face token is currently stored in the Angular application itself, I would change that separately. This is not the cause of the 410 , but tokens embedded in an Angular frontend are visible to the browser user. Both the Hugging Face JavaScript documentation https://huggingface.co/docs/huggingface.js/inference/README and Angular’s environment documentation https://angular.dev/tools/cli/environments recommend keeping secrets server-side and using a proxy/backend. A safer layout is therefore roughly: Angular application | | POST { prompt: ... } v your backend / serverless function | | HF TOKEN stays here v @huggingface/inference | v Hugging Face Inference Providers | v currently available provider Why this changed / why hf-inference is different now So, for this particular error, my default path would be: php stop pinning /hf-inference/ - use @huggingface/inference - let provider selection be automatic - or explicitly use a currently supported provider such as fal-ai - check the PAYG implications before relying on it in the application That should separate the actual serving change from the Angular integration, rather than treating the 410 as a problem with FLUX.1-dev itself.