[GH-ISSUE #208] cache.json error due to high amount of Loras #149

New issue

Closed

opened 2026-10-30 21:20:05 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-30 21:20:05 +00:00

Owner

Originally created by @freecoderwaifu on GitHub (Jul 26, 2023).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/208

Unsure if this solely an issue with the extension, the cache system in A1111 or a combination of both, but I recently encountered it on a fresh reinstall, and only after installing the Tag Autocomplete extension, with it being the only extension installed.

When having a ridiculous amount of Loras (about 14k, send help), currently I'm getting a cache.json error "moving cache.json to /tmp and creating a new one". This seems to happen on every relaunch of the UI. There's also a high level of HDD activity since it re-reads the Lora folder and re-caches all of them, which also severely slows down the UI launch. I'm not entirely sure if it's a specific Lora causing this, it might be, but would also be hard to pin it down since the console doesn't specify one.

However, this only seems to happen with the default extension's settings. Disabling all "Search for" options except "Search for embeddings" and "Search for Loras", setting "How many results to load at once" to 10 and also disabling "Active in third party textboxes (though I think this last one isn't the issue) seems to resolve it.

Though I did have to temporarily rename the Lora folder to load the UI faster and then change those settings. I still got an error on relaunch, but only once since it only recached checkpoints and embeddings, and after that no more cache.json errors appeared on the console after changing the settings mentioned. Everything else seems to work as normal after that.

I do have Loras mixed with Lycoris, Lohas and other variations in the main Lora folder, so possibly disabling Lycoris autocomplete might be what's resolving it in my case. With A1111 native Lycoris support built in now, I haven't had other issues related to mixing all Lora types in one folder, and they all load fine with just <lora:name:weight>. Lowering the limit to load at once from the default 100 to only 10 is also possibly what's helping.

Originally created by @freecoderwaifu on GitHub (Jul 26, 2023). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/208 Unsure if this solely an issue with the extension, the cache system in A1111 or a combination of both, but I recently encountered it on a fresh reinstall, and only after installing the Tag Autocomplete extension, with it being the only extension installed. When having a ridiculous amount of Loras (about 14k, send help), currently I'm getting a cache.json error "moving cache.json to /tmp and creating a new one". This seems to happen on every relaunch of the UI. There's also a high level of HDD activity since it re-reads the Lora folder and re-caches all of them, which also severely slows down the UI launch. I'm not entirely sure if it's a specific Lora causing this, it might be, but would also be hard to pin it down since the console doesn't specify one. However, this only seems to happen with the default extension's settings. Disabling all "Search for" options except "Search for embeddings" and "Search for Loras", setting "How many results to load at once" to 10 and also disabling "Active in third party textboxes (though I think this last one isn't the issue) seems to resolve it. Though I did have to temporarily rename the Lora folder to load the UI faster and then change those settings. I still got an error on relaunch, but only once since it only recached checkpoints and embeddings, and after that no more cache.json errors appeared on the console after changing the settings mentioned. Everything else seems to work as normal after that. I do have Loras mixed with Lycoris, Lohas and other variations in the main Lora folder, so possibly disabling Lycoris autocomplete might be what's resolving it in my case. With A1111 native Lycoris support built in now, I haven't had other issues related to mixing all Lora types in one folder, and they all load fine with just `<lora:name:weight>`. Lowering the limit to load at once from the default 100 to only 10 is also possibly what's helping.

bsakaguchi closed this issue

2026-10-30 21:20:05 +00:00

bsakaguchi commented

2026-10-30 21:20:06 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jul 27, 2023):

A few words about the assumptions:

Tag autocomplete does not use the cache.json file from the webui, so this is likely only a symptom
Almost all the extension settings affect the client side (the website in the browser), so changing anything there would only change the load times of the page or potential lag when the completion window itself shows up. The terminal should be unaffected.
- In fact, the lora list etc. is even loaded if the setting to complete it is off, it will just skip it when searching for matches (to enable quickly toggling the settings without needing to reload).
Lycoris and Lora autocomplete use exactly the same methods, only that they search in different folders.

Did you experience any kind of slow startup before updating the webui to 1.5.0 with recent tag autocomplete versions?
The extension will run a recursive path search in the Lora folder at startup to obtain a list of all your loras, but that should not be that slow since it only lists the file names.
With the recent addition for model-keyword support, it will also write a cache file (that only updates when needed) to cache calculated simple hashes. These are compared with the model keyword lists. But if you don't have it installed, it shouldn't run, and the short hash only looks at the first few bytes so should be reasonably fast too.
14k files could very well be a problem for either approach, though.
As to why this results in the cache.json error you mentioned, no idea. Could maybe be file access related, as in that the webui tries to read files that are still being processed by tag autocomplete and locked by the file system.

Since you said it stopped after changing the extension settings, I'd like you to test a few things in order:

Does the issue come back if you re-enable those settings?
In the autocomplete install folder, go to tags/temp/. There should be three relevant files here, lora.txt, lyco.txt and known_lora_hashes.txt.
- How many rows do these files have? Do they contain the expected 14k lora names?
- Try deleting these one at a time, restart the webui completely between each one, see if the issue comes back.
- These files are the only read/write operation the extension does related to loras, so it's likely to be related.

@DominikDoom commented on GitHub (Jul 27, 2023): A few words about the assumptions: - Tag autocomplete does not use the cache.json file from the webui, so this is likely only a symptom - Almost all the extension settings affect the client side (the website in the browser), so changing anything there would only change the load times of the page or potential lag when the completion window itself shows up. The terminal should be unaffected. - In fact, the lora list etc. is even loaded if the setting to complete it is off, it will just skip it when searching for matches (to enable quickly toggling the settings without needing to reload). - Lycoris and Lora autocomplete use exactly the same methods, only that they search in different folders. Did you experience any kind of slow startup before updating the webui to 1.5.0 with recent tag autocomplete versions? The extension *will* run a recursive path search in the Lora folder at startup to obtain a list of all your loras, but that should not be that slow since it only lists the file names. With the recent addition for model-keyword support, it will also write a cache file (that only updates when needed) to cache calculated simple hashes. These are compared with the model keyword lists. But if you don't have it installed, it shouldn't run, and the short hash only looks at the first few bytes so should be reasonably fast too. 14k files could very well be a problem for either approach, though. As to why this results in the cache.json error you mentioned, no idea. Could maybe be file access related, as in that the webui tries to read files that are still being processed by tag autocomplete and locked by the file system. Since you said it stopped after changing the extension settings, I'd like you to test a few things in order: 1. Does the issue come back if you re-enable those settings? 2. In the autocomplete install folder, go to `tags/temp/`. There should be three relevant files here, lora.txt, lyco.txt and known_lora_hashes.txt. - How many rows do these files have? Do they contain the expected 14k lora names? - Try deleting these one at a time, restart the webui completely between each one, see if the issue comes back. - These files are the only read/write operation the extension does related to loras, so it's likely to be related.

bsakaguchi commented

2026-10-30 21:20:07 +00:00

Author

Owner

@freecoderwaifu commented on GitHub (Jul 27, 2023):

Thank you. Yeah honestly it might have been some rogue Lora and not the extension, it might even have been something specific to my system. I was able to reproduce it consistently on the fresh install, and the fresh reinstall was due to having sudden cache issues in the first place in the latest dev commits, but once the cache got properly recreated I haven't had that issue since.

Re-enabling those options doesn't bring the issue back either, the tags/temp folder does contain those files properly and deleting them and letting the extension recreate them also doesn't bring the issue back.

I'll close this since it's fixed, will update if it presents itself again in the future.

@freecoderwaifu commented on GitHub (Jul 27, 2023): Thank you. Yeah honestly it might have been some rogue Lora and not the extension, it might even have been something specific to my system. I was able to reproduce it consistently on the fresh install, and the fresh reinstall was due to having sudden cache issues in the first place in the latest dev commits, but once the cache got properly recreated I haven't had that issue since. Re-enabling those options doesn't bring the issue back either, the tags/temp folder does contain those files properly and deleting them and letting the extension recreate them also doesn't bring the issue back. I'll close this since it's fixed, will update if it presents itself again in the future.