1. wget "https://civitai.com/api/download/models/2299145?token=YOUR_API_KEY" -O "pixva_1.zip"

2. apt update && apt install -y zip

3. unzip pixva_1.zip

4. profit?

@Rickets - wow do you get paid to make people laugh? You must be poor. Automation is what it's about. I don't need any help unzipping a file, but thanks for being an obnoxious POS.

I have a ton of scripts that use the civitai API to get metadata about models... and so does everyone else with a brain. It's been that way for YEARS. The software relies on the safetensors file to be the endpoint of the URL so the hashes will match. Then LoRA managers can see the file and get samples and triggers and such.

It seems as if you are just daft and don't know how to use the available software.

Frankly, the blame lies with civ. Off the top of my head, I have yet to see any zips which did not contain: (a) a bunch of images masquerading as a model, (b) high / low as in here, (c) adetailer single file zips to either vex the user or evade the pickle scanner, (d) multi gb model packs made by batch trainers who cba to gen individual samples or descriptions (nor deal with civ's subpar uploader), (e) whole training or gen environments.

Had civ implemented a proper batch uploader and disabled zips in the first place, we might have seen a few less low effort uploads.

@firemanbrakeneck - of course there are innumerable legitimate criticisms of civitai... anyone who uses the site daily or has used it for years knows it can always use improvement in a multitude of ways.

What I know is true, however, is that if the creator uploads the safetensors file directly to civit, then SwarmUI and CivitAI Helper and LoRA Manager for ComfyUI can all just query the API and get me some thumbs and triggers/desc/URL/hash etc...

In cases like this the solution is for the user/creator to use the current tools effectively while hoping for better tools in the future, and that would involve simply uploading two files instead of one. I have a large collection AND terrible bandwidth, so I can't effectively micromanage every file downloaded without great efforts, and automation has made AI possible in the first place and has always been a part of inference software and metadata from civit. I expect my tools/scripts to be able to identify most of my LoRAs, and when zips are uploaded none of my tools can cope.

@Gongoloid "the solution is for the user/creator to use the current tools effectively while hoping for better tools in the future" - Not really. This is for a small scale, temporary problem. Better tools don't fall from the sky. Someone has to build them. If you don't make the relevant devs aware there is a problem, they definitely won't fix it. You have little to no control over what creators do. With tools, if the problem is solved once it can be solved for good: for example, manually setting the model+version id, auto unzipping and logging the zip's hash, using a secondary source which makes the connection between content file hashes and zip's by user or community input. I imagine the existing tools don't fetch civ's api every time (unless it's a really crappy one written by a chatterbot), they fetch once and create some file for future reference - so that mechanism should be hackable.

Nobody's stopping you from pestering creators till the end of time, but it is most definitely an ineffective approach.

@firemanbrakeneck - hmmm, perhaps you aren't really grasping the situation, I'm not sure. Do you understand that "currently" has a distinct meaning? In the future, civitAI may change something. It's doubtful. It is a huge machine and is understaffed and poorly funded. This is not a "site design" problem. Uploading zips is perfectly fine for various reasons.

Until Wan 2.2, we had no need of this two-for-one logic, so nobody is equipped for it. Uploading a zip is convenient and saves the creator a few minutes of time. But it creates work for everyone else. There is no solution here at all. There is no magic single dev out there who can fix this problem. It's about the API and all the innumerable already existing scripts that can't do anything with these LoRAs because when they look for the hash of the LoRA file on civit it isn't there. My LoRA managing scripts are not looking for zip endpoints and the hash of the zip is useless when dealing with the safetensors.

I've uploaded hundreds of LoRAs to this site. I also have used nearly all of the available software to generate media and train models. I have an extensive collection of models, of which are included some 20k LoRA models. If I thought something about my behavior would impede others from using my LoRAs, I would at least consider changing that behavior.

Civit serves thousands of people terabytes of data all day every day. 99.9% of that data moves smoothly and everything functions. Civit isn't doing anything wrong and their code doesn't need to be fixed or patched. What would you say to them? How do you appeal to civit about this? Serious question, since you seem to think there are alternatives.

Swarm and CivitAI Helper and LoRA manager and all the scripts out there are not going to magically change to accommodate a dozen lazy users on civit. This creator is one of a very small number of uploaders who do this, and the majority of them will upload the files if you ask. So I ask. You telling me not to ask is ... asinine.

The only current useful solution to this problem (which is not a small problem no matter what your personal experience might indicate) is for the uploader to upload each file separately directly to civit.

@Gongoloid Condescending first paragraph. Skimmed the rest. If that is all you see, this discussion is futile. Good luck.

@firemanbrakeneck - "I have no real argument so I'm going to claim to not have read your comment."

Cool story bro.

There are exactly two things that can happen:

creators can upload safetensors files directly, or

civit can change their entire website to accommodate a handful of lazy uploaders...

I wonder which position is more reasonable?

@Gongoloid More like, this fellow brings nothing to the table that I need because:

- He is adamant on performing manual labour and parochial thinking, dismissing out of hand any ideas that might rock the boat.

- He is a civ apologist and believes civ's api suffices as the sole source of metadata.

- He speaks of data without checking (of the ~711.5k model files we know, just short of 2000 are model zip uploads; that's ~0.28%, and far more than I'd like to go over manually, personally).

- He is a lowkey braggart.

But it is also true that I find arguments tedious, so if you believe this is what's at play here, that's fine by me.

@firemanbrakeneck - more like - you are an agitator and your initial foray into this thread was obnoxious and irrelevant. You are an arrogant and myopic person and your contributions to this conversation are asinine and worthless.

Asking creators to upload the files works. You are correct in that it is a tiny number of files that are zipped, and that bolsters my argument that developers across the globe don't need to scramble to rewrite scripts just to accommodate a few edge cases. The outliers of the edge cases - those few who balk or refuse - make up a very tiny percentage of all models anywhere.

I have personally written scripts to handle databases full of metadata... trying to consolidate sources. Because civit should not be the final arbiter.

But I actually, in real life, on a daily basis... use SwarmUI and ComfyUi and LoRA Manager. They all rely on civitAI for metadata.


You are pompous and frankly sort of ridiculous. Your implication that everyone should coddle these few lazy users instead of encouraging them to use the site the way literally everyone else does is just outright stupid. You think faaaarrr too highly of yourself.

Top kek.

download the zip file

The zip has the low and high lora.

@CharlieBrown0115 thank u

@Kierkegaard420 thank u