# About the modelFLUX.1-dev

> Source: <https://discuss.huggingface.co/t/about-the-modelflux-1-dev/179954#post_2>
> Published: 2026-09-06 23:35:24+00:00

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.