Open dan-homebrew opened 4 weeks ago
According to this:
There would be many conclusions that affect Jan's UX such as:
Threads are now coupled with model settings, which introduces a bad UX where users get their model restarted every time they switch to a new thread, even with the same model.
As a new user to this space, it's quite hard to get thread's parameters and settings. The Assistant Personas (instructions and parameters) and Model Capability Settings (more about hardware explanations) would help onboard users better.
As a new user to this space, it's quite hard to get thread's parameters and settings. The Writing Assistant Persona (instructions and parameters) and Model Capability Settings (more about hardware explanations) would help onboard users better.
Can you elaborate a bit more about:
ah @dan-homebrew I just mean
temperature, frequency penalty, presence penalty
are quite incomprehensible. Move those to Assistant
would make building an assistant persona easier to get.ah @dan-homebrew I just mean
- Thread's Inference Parameters such as
temperature, frequency penalty, presence penalty
are quite incomprehensible. Move those toAssistant
would make building an assistant persona easier to get.- Modifying Thread's settings parameters, such as context window and ngl, cause a bad UX. Move to per-model settings might help. From there we add more hardware detection information such as the recommended GPU layers load and context length based on their device specs -> Global effect per model, not per thread.
Got it. Can you proceed to make the recommendations for how we can break down the Assistants, Threads/Messages, and Models endpoints (and the related data structures).
model.yaml
and Models tablemodel presets
? (I don't think so?)I think it's better we bite the bullet and move to the correct data structures.
Goal
Tasklist