I am trying to call the above model to generate premium image thorugh https://huggingface.co/proxy/router.huggingface.co/hf-inference/models/black-forest-labs/FLUX.1-dev
but i am getting 410 gone as error saying The requested model is deprecated and no longer supported by provider hf-inference.
I am using this in angular project
can anyone help me here to solve this
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://huggingface.co/proxy/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 shows fal as a Text-to-Image Inference Provider. Hugging Face’s current Fal provider documentation 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:
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 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:
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 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 and Angular’s environment documentation 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
hf-inference still exists; this is not simply “HF Inference was deleted”.
However, Hugging Face now describes it as the service that used to be called “Inference API (serverless)”, and says that as of July 2025 it focuses mostly on CPU inference, such as embeddings, ranking, classification, and smaller historically important models.
That is a substantially different model from the older expectation that an arbitrary model on the Hub could necessarily be sent to the Serverless Inference API and cold-started.
The current architecture is closer to:
HF model
+
task
+
provider currently serving that model/task
|
v
Inference Providers
rather than:
any HF model
|
v
one universal Serverless Inference API
This is why the distinction in your error message matters: it says that this model/provider combination is deprecated, not that the model repository has disappeared.
I would avoid inferring the exact internal reason or date on which FLUX.1-dev was removed from the hf-inference catalog; I have not found a public source establishing that specific internal decision.
Provider availability can change, so for future troubleshooting it is useful to query the current mapping rather than assuming a provider name from an old example.
Hugging Face exposes this through the Hub API / inferenceProviderMapping.
For example:
from huggingface_hub import model_info
info = model_info(
"black-forest-labs/FLUX.1-dev",
expand="inferenceProviderMapping",
)
print(info.inference_provider_mapping)
That mapping reports the providers serving the model, their status (live / staging), the task, and the provider-side model ID.
The same Hub API documentation currently gives this example for listing Fal text-to-image models, and FLUX.1-dev is among the returned models.
This distinction is useful in general:
"The provider supports text-to-image"
does not necessarily imply:
"This exact model is currently mapped to text-to-image on that provider"
The exact model × task × provider mapping is what matters.
Provider mappings are also dynamic. Hugging Face’s provider registration documentation says mapped models are automatically tested periodically; mappings that fail validation can be temporarily removed from the active-provider list and retested later.
So I would phrase Fal as a provider that is currently available for FLUX.1-dev, rather than assuming it will permanently be the one provider for this model.
Once you stop forcing hf-inference, the next error—if there is one—may reveal a different layer:
New request
|
+-- works
| -> done
|
+-- 401 / 403
| -> check the token and its Inference Providers permission
| -> also check access to the gated FLUX.1-dev model if relevant
|
+-- model/provider/task availability error
| -> check the current inferenceProviderMapping
|
+-- credit / billing error
| -> check Inference Providers credits / PAYG settings
|
+-- token is inside the Angular bundle
-> move the actual HF request behind your own backend/proxy
FLUX.1-dev is also a gated model whose files require accepting its access conditions, so that is worth checking if the provider issue is fixed and the error changes to an authorization/access error. I would not treat that as the explanation for the current 410, because the current response is specifically about hf-inference no longer supporting the model.
If this is eventually for commercial/production use, I would also check the terms for the particular hosted provider/API route you choose. The FLUX.1-dev model repository itself is published under the FLUX.1-dev non-commercial license, while hosted-provider terms can be a separate layer.
So, for this particular error, my default path would be:
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.