I can't figure out how to get CivitAI Flux Models to work

[BrickRockwell]

I've installed a Huggingface token, and I'm signed-in, not that I think it should matter. When I try to load Flux_dev, or a different Flux model, both downloaded from CivitAI, the system errors out. I check the command prompt, and it says That there's a 404 error, because "Repository Not Found for url: https://huggingface.co/api/models/[Model File Name]/auth-check." It's trying to authenticate with a page which doesn't exist, even when the URL is https://huggingface.co/api/models/flux_dev/auth-check.

I can not, for the life of me, find any way to tell the system that these models were downloaded from CivitAI. Even when I try to update model info under the model tab. And I don't see anything in the System tab which would allow me to bypass this unnecessary check for gated models.

[vladmandic]

when you say you downloaded a model, what exactly did you download, where did you place it and how are you trying to load it.

Also pls upload actual log.

[BrickRockwell]

I'll try to replicate it later today to get a log. I didn't realize I need a VAE for the smaller model. But the larger model is the 15GB option from the CivitAI Flux page at: https://civitai.com/models/618692/flux. It's pruned, but it's supposed to have everything necessary to run it (no need for a VAE or CLIP, etc.).

I'm placing it in the \models\Stable-diffusion folder. I've tried the steps in the wiki for the UNET Transformer, but I don't see any place in settings called "Executions & Models," and the 15GB model doesn't seem to be a UNET model. I've included a snippet of the command prompt where it says there was a 404 error when authenticating.

If you want me to try changing settings, no problem. If you want me to edit some files, I'm not a coder, but I can do a bit of editing.

Thanks for the help.

[BrickRockwell]

I thought that I might have done something wrong with my installation, so I downloaded Stability Matrix and tried running things through that. I still have the same problem. I've enclosed a log showing the 404 error happening at startup, when the model is being loaded for the first time. If you want me to try loading a Pony or Illustrious model, then switch -- or if you want me to try anything else -- just let me know. I'm having illness flareups, but I'll try very hard to work with you on this.

sdnext.log

Thanks again for having a look.

[BrickRockwell]

I've since switched machines, and am now using an Evo-X2 in order to run bigger models. I've been using Stability Matrix to manage installations, which is starting to feel like a mistake. However, even outside of Stability Matrix, SD Next still has issues with authentication and matching the model with the repository. I've had to spin up the venv in Command Prompt, then run huggingface-cli to get my token to be read properly by HF. And then I still get a 404 error, with SD Next now trying to tell HF that the repository is at huggingface.co/api/models/{local save location for the Flux dev model}. Yes, the part in brackets is exactly what I wrote -- SD Next is trying to use the local directory in which Flux dev has been saved, merging it into the repository URL in order to authenticate the model with HF.

I know it seems like I'm blaming SD Next, but I'm not. I think this is connected to an issue with HF. I've read that HF has had numerous issues in the past with their website, as well as their APIs. All I know is, I'm getting tired of trying to hack frontends, just to get them to run image gen models and chat LLMs. I know that AMD needs to do a lot of work, too, but some of these issues seem ridiculous.

[Disty0]

https://github.com/vladmandic/sdnext/wiki/FLUX#unettransformer

[vladmandic]

disty provided the link to wiki page - and it does state to start with reference model first and then replace components with finetunes as desired. i don't know which model you tried and you did not provide logs for the issue with incorrect hf api endpoint.
i'd suggest to stop and reset what we're doing: lets start with flux reference and then use finetunes on top of it.

[BrickRockwell]

And I looked at the page. And I've downloaded different versions of Flux, including using SD Next to download it directly from HF, all total being over 120GB of downloads, getting the same results of either a 401, even though the token is added to SD Next, or a 404, where SD Next tries to use the save directory as the last half of the repository URL. The type of model doesn't matter, as it can be reference, dev from HF, CivitAI, dev from HF through SD Next direct download, etc.

Also, I'll be happy to show new logs, though I DID add one back in June, in reply to your request for a log. That log came from the PC with the 7900XT, and it has the incorrect HF endpoint of "flux_dev/auth-check." It's supposed to point to the Black Forest Labs Flux 1 repository instead. When I log into my Evo-X2, I'll get it to recreate the save directory bug, since I've pretty well figured out how to use hf.exe or huggingface-cli.exe to work around the 401 error.

I've "reset" what I'm doing multiple times: on a whole new machine, or reinstalling SD Next a few times (including a couple of times where I used Windows restore points), or reinstalling on the new machine. After making my last post, I tried switching my Evo to use its unified RAM dynamically, then load Flux in SD Next. After getting the 404, it still tried to load Flux, but now it loads it into system memory, then stops & says the model failed to load because it doesn't have a text encoder (and specified it needed the TXXX5 or whatever it's called) -- this is for the dev model, which already is an all-in-one. After failing to load, SD Next leaves the model in the system memory, and I have to exit and reload SD Next to get it to dump the memory.

After that happened, I installed Amuse. It directly downloaded Flux, then had no problem making a test image. I don't like Amuse. It isn't SD Next. Even though it uses similar concepts to other frontends, it still doesn't feel right. That's why I keep trying with SD Next. I have an extremely busy day, but I'll try to get the Evo logs in a few moments.

[vladmandic]

i understand the frustration, but cant do anything with statements above - even if there is a problem.
i need exact descriptions of steps done combined with logs to show what actually happen.
then we can see "ah, you did X but log shows Y and thats a bug". otherwise, its just statements that are not actionable.

[BrickRockwell]

What I don't understand is, I have shown you an example of what happened to me. I've offered to recreated the error, so you can see other logs. But it all boils down to me telling you exactly what has happened to me — first it was a 401 error, even though I had a good key. I can't remember what I did exactly, but I got a CLI command to open some file, and that file was able to force my HF Key onto a bunch of other files in SD Next. Now, you probably think that you need to look at all of the things I've done from install to latest image gen, but that's bunk. I installed SD Next correctly. Hell, I was able to alter the right .py files in order to force it to (try) using Vulkan, thanks to ANOTHER bug. I'm not an idiot.

When I say that I installed the program, and had ZERO issues... UNTIL I tried to use Flux, and then I point to the fact that I had to teach myself which files I needed to be run, just to force SD Next to properly give HF my key, and then I still get an error, this time saying 404... What is it you think I'm doing? Breaking into other files, telling them to point at the wrong URL (actually, I'd have to tell the file to take the directory of a model & graft it to the end of an already-incorrect HF authentication page)? I guess I'm nutty enough to seek attention that way.

If you took the time, and just thought a little bit about my problem, you'd realize that, aside from altering your .py files, there is NO WAY I could install the package, and somehow do something just differently enough to convince a file, which already has the wrong authentication URL for HF, to screw up even more & add code that says "add the file path to the end of the huggingface.co/api/models/flux_dev/auth-check URL (which is already incorrect). I sure as heck wouldn't have ANY POSSIBLE WAY of telling SD Next .py files to look at a CivitAI, non-Black-Forest Flux, and demand a key and auth for HF. It'd take being a nutter, or just a moron who is somehow smart enough to alter your code. I couldn't even begin to tell you how I got past the web errors and got the model to load anyway, but when it turns into SD Next then saying that the FULL Flux needed the pieces of the piecemeal Flux, that tells me there's yet another code problem.

But, speaking of your code, I have ANOTHER problem. When I try to load Wan models, which I have confirmed are supported by SD Next (2.1 & 2.2), I get "XYZNUDIEWAN3000.safetensors is not a JSON file," and then SD Next tries to load an FP8 as a BF16. Using some bad tips from "people who know how to use SD Next," I set things up to force FP32, which is SUPPOSEDLY a way to load FP8 models. Didn't work. I tried other stuff, found here and on other sites, and it didn't work. Just because I wanted to see what would happen, as a learning experience, I chopped into SD Next & got it to run Vulkan. Obviously, that just doesn't work for other reasons, but it didn't fix the BF16 problem. Then it dawned on me: SD Next is convinced, at no fault of my own, that it needs to both look at PIPPIESMAGICALBABES.safetensors to find the config, but also the model to BE the JSON.

Now, I do still prefer the way SD Next does so much. But I'm no longer asking for some help here. I'm just telling you: your code has some issues. I'm about to shred .py files until I hack the HF authentication to work correctly, AND ONLY FOR Black Forest Labs models. And then I'm going to bludgeon the "Diffusers allow loading from safetensors files," or whatever the Wan equivalent is, into the files which need it. I won't bother you for help anymore, so don't worry about that. I don't need to be treated like a basic user, when I offered a log, the log was ignored, I was pushed towards a wiki page that didn't have anything for my problem, and I was asked to "just go ahead and burn precious time," rather than being given the benefit of the doubt. I may not be some great coder, but I know I gave you enough info to either say "That's caused by needing to select "X" tick box," or "That's caused when the install has a corrupted Y file," or to... I don't know, READ the log I gave you, so you could see for yourself that my error couldn't possibly be caused by anything other than SD Next mistakenly merging a save path with the WRONG authentication URL. And, by the way, maybe figure out why your .py file, with the "normal" HF auth URL, is pointing to the old URL, and not the HF, Black Forest Labs auth URL. Then I'll top it off by seeing if SD Next is treating Flux models like how it's treating Wan models, and hammer some code into it to make it finally accept Flux Dev as the full model it is.

Good luck!
PS: I'd be fine trying to gather up lots of regular data for you, like hardware & software/packages, and even try to recreate every error. But you've got to be willing to accept that there are software issues, especially when my problems point to bugs, not my being too dumb to read your install steps and CLI commands.

[vladmandic]

the only log file you've posted is using sdnext 2025-06-19 which is 4.5months old and most of the issues have already been fixed, so there is no point of analyzing what happened with error code 404.
so i'll say once again - if you make a claim that something bad happen, i need to log - not just to verify what you're saying, but to identify where its happening in the code, without that we're just running in circles.

regarding loading fp8 models - that's a bad idea always as sdnext prefers full model and then use quantization on the fly. its just a different phyilosopy - comfy may prefer fp8 models, sdnext does not.
and yes, for nearly all models from civitai sdnext will require hf access - because those models are NOT COMPLETE, so sdnext needs to get model config and pick up missing pieces.