Will I be able to put an @ cookie at the beginning of a system prompt in gptel-directives, and use that to set the model for when that directive is used? Like if I need to use a specific local LLM for tool-related prompts…
Karthik: Since you have access to gptel-prompt-transform-functions, you can do it
John: I’m just checking because I don’t mean the per rewrite directive that you can select in that pop-up menu, but the system prompt that you select from the rewrite menu.
Does that mean I would need to write code to make it happen, or that this is certainly a built-in feature of this approach?
I guess I can always just try it and see what happens too. :-)
Karthik: You don’t need to put the @ in front of a system prompt in the directives.
Basically you want to treat the system prompts as presets?
John: Pool thoughts, coming to you live
Karthik: I’m in the gym myself
John: No, I want to define a system prompt in my GPTel directives that will make use of a preset to set up some parameters for any request that makes use of that directive
I know I can do it the other way around, where the preset can set the system message. But can the system message engage a particular preset?
Like my current shortening system message. What if I always want that to be processed using Claude, in the case were no other explicit choice has been made.
(setq gptel-directives '((shorten . "@claude Do the thing")))In this sense, presets are just “collections of buffer-local globals” as you’ve implemented them, and there are plenty of places I would want to use that mechanism outside of user prompts/directives.
Oh, and another reason why you may want to support @@ to reset the state of the buffer local globals back to before the last preset was chosen: there will be times when a person doesn’t remember everything that a preset does, so they’re going to select a preset, but not realize how many different settings it’s going to change. They may then realize that’s a mistake, and they want to undo it and go back to where they were a moment before. I imagine it will probably only be used for that sort of immediate undo, but that’s just my thinking right now. I know I wanted to do exactly that today.
Something else I realized: I don’t think I want to use GPTel chat buffers ephemerally anymore. Every buffer should be a file within my org-roam thinkbase. This way it becomes part of the general collection of my thoughts on various topics. I only want to create an ephemeral buffer explicitly. I’ll try implementing that tonight.
Karthik: Okay, that’s a lot of pool thinking!
Something else I realized: I don’t think I want to use GPTel chat buffers ephemerally anymore. Every buffer should be a file within my org-roam thinkbase. This way it becomes part of the general collection of my thoughts on various topics. I only want to create an ephemeral buffer explicitly. I’ll try implementing that tonight.
You should probably check them into git then
In this sense, presets are just “collections of buffer-local globals” as you’ve implemented them, and there are plenty of places I would want to use that mechanism outside of user prompts/directives.
They’re not buffer-local
The scope with which a preset is applied can be changed on the fly
In this sense, presets are just “collections of buffer-local globals” as you’ve implemented them, and there are plenty of places I would want to use that mechanism outside of user prompts/directives.
“plenty of places to use it outside of prompts/directives”: But presets are not tied to prompts/directives
I know I can do it the other way around, where the preset can set the system message. But can the system message engage a particular preset?
Not unless you write a custom augmentor
John: More thoughts: I wonder if there’s a way to export the current chat conversation into the Perplexity web interface, because I often find myself wanting to start a dialog with a local model, but then “upgrade” it to the full power of their deep research model, but via the Web so it’s included in my monthly fee rather than charged at API rates. Same would go for the other prescription services.
I’m not clear on what you’re saying above. Can I use the preset in my system directive and have it changed the parameters of the query?
Karthik:
I’m not clear on what you’re saying above. Can I use the preset in my system directive and have it changed the parameters of the query?
No. You’d have to write a new augmentor
But it’s simple enough, simpler than the current implementation
What I’m trying to understand is why
When presets exist
John: I see, maybe that’s a good candidate for a built-in augmentor that the user could choose
But I want to pre-code the use of the preset
I want to use the preset as the way of defining the collection of parameters. And then I want to reference the preset in the system directive as one of the ways I might switch to that set of parameters
Karthik: Why not set the system message in the preset?
John: Because certain directives will only make the most sense in the context of certain presets
But then I have to choose the preset using the syntax, when I might wanna just choose the system directive and use it over the course of several queries
Oh I see
You would want me to first set the system directive, and then set the preset in the transient menu
I guess what I’m reacting to is that sometimes the system directive implies the preset, as well as the reverse
Karthik:
But then I have to choose the preset using the syntax, when I might wanna just choose the system directive and use it over the course of several queries
If you have to choose the system message you can just apply the corresponding preset? It’s fewer keys than activating a system message
John: Hmmm
I see now
You would want me to use the preset instead of the system directive. That only works if there’s a one-to-one or one too many correlation from preset to system directive. Sometimes there’s a one-to-one relationship from system directive to preset.
Karthik: Presets are designed to be an umbrella covering as little or as much as you want
John: Meaning, I might have a preset that sets the system directive. But I might have a system directive that wants to engage the settings of multiple presets.
I suppose I’m blurring the line now between system messages and presets. Maybe there’s not even a reason to have the distinction anymore.
If a preset can inherit from multiple parents, then I think presets alone can do everything I’m wanting to do
Got just two laps before I’m done :-)
Karthik:
I suppose I’m blurring the line now between system messages and presets. Maybe there’s not even a reason to have the distinction anymore.
There isn’t a distinction because presets can act as system message
By setting only the system message
You don’t need gptel-directives at all
John: Right!
That’s what I just realized as well. We could drop directives from the transient menu entirely, because a preset that only defines a system. Message is a directive.
Karthik: You don’t need any individual settings
John: i’m going to change my GP tell prompts package with respect to this now. Exciting!
Karthik: Haha
Sure. I’m going to retain gptel-directives
Users already find gptel highly confusing
It’s best to describe presets as an optional feature for a bundle of settings, I think
John: That’s fine, they are now just specialized presets with their own separate engagement interface
But implementation wise, there could be a benefit to unifying them
I think for my Org-roam idea, I’m going to make it so that control X control W rights to a file, but control X control S automatically creates an Org-roam entry with the current timestamp