Confusing UI save options. Or am I missing something?

[sidran]

I'm encountering some confusion regarding the local SaveData workflow.

In my initial setup, I select a model, configure options, and choose a local SaveData file before launching. I'm unsure if the LoadStory? functionality should already be integrated within this SaveData file.

Once in the web UI, I find the save options to be unexpectedly obfuscated, and the limited number of save slots feels restrictive, reminiscent of a Gameboy cartridge. While the download option is appreciated for backups, it's not ideal for frequent session management.

It seems logical that once a local SaveData file is specified, the UI could automatically save progress and seamlessly allow for an unlimited number of distinct sessions, similar to platforms like ChatGPT. The current slot-based system feels opaque and clunky, leading to wasted slots.

Am I misunderstanding the intended workflow or missing a key feature?

[LostRuins]

The save data is not obfuscated, rather it is compressed. Take a look at #1465

The save slots are limited because they are mapped to a single .json file which is completely overwritten every time data is saved. Uncapping the slots would quickly lead to slowdown if there are many stories being stored. If you wish to increase the slot count, you can edit koboldcpp.py and increase net_save_slots = 8 to a higher value. It is indeed a little clunky, but that's because it doesn't use a database or multiple separate files.

[sidran]

Thanks for the clarification. Now I understand the logic behind using fixed slots and a single JSON file. That approach definitely keeps things minimal and avoids some complexity under the hood.

That said, from a user’s perspective, the current save/load system adds friction where there doesn’t need to be any. The slot model feels a bit limiting, especially for anyone doing multiple threads or returning to different sessions frequently. Saving becomes something users have to manage, instead of something the system just handles naturally.

One idea that might offer a simple middle ground: instead of a single SaveData file, what if the chosen “save” path became a folder that stores each session as a separate JSON file? Sessions could be automatically timestamped or named, easily duplicated, renamed, and browsed. The interface could show all sessions on the left (like ChatGPT does), and the system could autosave periodically or on key interactions.

There’s no need for compression or a database, just plain-text files per session. Given the typical size of these saves and the limits of context windows in LLMs, performance should remain snappy even with dozens or hundreds of sessions. It also keeps the data portable, inspectable, and modifiable, which many users appreciate.

This kind of setup would allow KoboldCPP to remain lean and offline-friendly, but also more ergonomic, turning saving into a background concern rather than a user task. And it would avoid the kind of overengineered UX trap we see in tools like SillyTavern, which somehow manages to be both bloated and cryptic, despite calling itself "for power users." KoboldCPP is already much closer to what power users actually want: clean, fast, local, and under control. A smoother save system would be a huge step toward that vision.

Happy to flesh out the idea more if it’s useful.

[LostRuins]

Fair points, I guess I was just trying to find a good middleground where it remains simple and easy to use (pick a single file for you save database) while still being feature rich.

Save folders does mean that you have multiple files to juggle (and possible some may be moved/edited/renamed/deleted at runtime or anytime) - also the risk of allowing strangers to create and delete arbitrary files on disk if the server instance is shared in public (vs simply writing to a single file).

But its good to keep in mind.

[LostRuins]

If you do want to try out a more comprehensive save system, there is esobold at https://github.com/esolithe/esobold#esobold-esolithes-fork-of-koboldcpp which is an unofficial koboldcpp fork made by @esolithe , that has a more extensive sqlite based save system.

[sidran]

Thanks a lot for the thoughtful response and also for pointing me to the fork. I had a look, but honestly, what drew me to KoboldCPP in the first place was exactly the opposite of that direction. The beauty of your approach is that it’s self-contained, minimal, and doesn’t drag around layers of Linux-like config chaos. Just a single executable that works, with smart defaults, like automanaging layer offloading between VRAM and RAM. That’s powerful, ergonomic design. Not "beginner-friendly," but well-thought-out and user-respectful.

I totally get the caution about juggling multiple files or user-writable directories, especially in shared setups. But in a private/local context, that kind of risk is negligible. What matters more is flow. When a system handles what it can on its own, and only brings the user in when it truly has to, it creates a kind of effortless power. Options stay available, but they don’t obstruct. That’s the real definition of a good UI, not a flood of toggles, but something that just works, until you want to dig deeper.

What you’ve built already hits a sweet spot: lightweight but not superficial. It doesn’t try to impress with clutter or fake complexity. It actually gets out of the way and lets the model do its job. That’s why I brought this up, not to criticize, but because I think the save system is one of the few areas where that same philosophy could go even further. And if it ever evolves, I think that same design ethos: clean, intuitive and efficient, could make it something uniquely excellent in this space.

Thanks again for engaging, and for all the work you’re doing on this project.