gptel agents or configuration presets

[karthink]

Note

This feature has been implemented.

You can now define "presets", which are a bundle of gptel options, such as the backend, model, system message, included tools, temperature and so on. This set of options can be applied together, making it easy to switch between different tasks using gptel. From gptel's transient menu, you can save the current configuration as a preset or apply another one. Presets can be applied globally, buffer-locally or for the next request only. To persist presets across Emacs sessions, define presets in your configuration using gptel-make-preset.

Original feature request follows:

---

A suggestion when you do get to this, I find the system message one prefers often depends on the model that is selected. I find when having a dialogue, in which I switch models mid-chat, I also sometimes need to switch the system prompt to better match the new model.

This appears to be a need that many users have. There are many discussions threads where people have asked how to implement a "presets" feature. I think it might make sense to add a presets feature to the package which is a bundle of configuration you can switch to all at once.

(gptel-make-preset
 "coding-preset"
 :system "system message for coding here..."    ; can be a function, see gptel-directives
 :backend gptel--anthropic-backend              ; or name of backend, like "Claude"
 :model   'claude-3-sonnet-20240229
 :context 'gptel-context-lsp
 :tools  (list gptel-tool-1 gptel-tool-2 ...)   ; list of gptel tools to supply
 :callback nil)

You can then select a preset from the transient menu, which sets all of these options at once. Via the "scope" switch in the menu, this preset can be set globally, in one buffer or just for the next request.

Some of these options/sources (like gptel-context-lsp) don't exist yet. :callback is basically a custom action you can specify instead of inserting the response, with nil being the default callback gptel uses.

In other LLM clients this is called an "agent", but really they're just a bundle of prompts+configuration.

Originally posted by @karthink in #416 (comment)

[ovistoica]

Gptel presets would be very useful!

I created a per-project side panel chat workflow inspired by Cursor, and changing the context for each project is not ideal. I would much appreciate a list of presets I could set (maybe with .dir-locals) for each project.

References:

• ai-project-agent.el

Functionality

(use-package ai-project-agent
  :after (gptel flycheck)
  :bind (("C-c c a" . ai-project-agent-toggle-panel)
         ("C-c c d" . ai-project-agent-clear-panel)
         ("C-c c c" . gptel-add)
         ("C-c c l" . ai-project-agent-send-lint-feedback)
         ("C-c c RET" . ai-project-agent-send)))

[skissue]

I agree that this would be great to have! I envision being able to use it to easily create an agent-based workflow, so it would be nice if a preset could simply be passed to gptel-request:

(gptel-request
 "prompt"
 :preset "some-preset-name")

Since a lot of gptel settings can be set via dynamic variables, a possible stop-gap implementation right now could be to define a preset as an alist of variable bindings (e.g. gptel--system-message, gptel-backend, gptel-model, etc.) and then bind them during the call to gptel-request (e.g. with cl-progv). Not sure if it would work in practice, just an idea!

[ahmed-shariff]

This is based on our discussion: :fsm could be another parameter for an agent.

[kyrella]

Maybe a bit offtopic, but is there a way to enable tools provided by API itself? Gemini provides grounding - https://ai.google.dev/gemini-api/docs/grounding as I understand it, this doesn't require any extra support on the client side in terms of processing responses. I looked around the source code but couldn't quite figure out where to put tool configuration for Gemini.

[ahmed-shariff]

You can then select a preset from the transient menu, which sets all of these options at once. Via the "scope" switch in the menu, this preset can be set globally, in one buffer or just for the next request.

I am throwing ideas out there. Would it make more sense to do it the other way around? i.e., all variables are read from a current-preset. Changing a value in the transient menu changes the value of the given variable in the current-preset (globally or locally based on the scope). We can have additional options for the presets where the user can reset the variables to the default values of the preset, and also options to save/create new presets from the transient-menu. There can also be a with-gptel-preset wrapper for gptel-equest with options to override some of the variables.

[jwiegley]

One other thing I would suggest for this feature is to add inheritance: A :parent property that adds in all of the settings from another "agent", so that I can derive specific agents from more general ones.

[karthink]

I've added initial support for presets on the feature-presets branch. You can select a preset from the transient menu after defining it.

You can use the = Scope option to apply the preset globally, buffer-locally or for the next request only.

To define a preset, use gptel-make-preset, which see. Here are a couple of examples:

(gptel-make-preset 'gpt4coding
  :description "A preset optimized for coding tasks"
  :backend "ChatGPT"                    ;backend or backend name
  :model 'gpt-4.1
  :system "You are an expert coding assistant. Your role is to provide high-quality code solutions, refactorings, and explanations."
  :tools '("read_buffer" "modify_buffer")) ;gptel tools or tool names

(gptel-make-preset "proofreading"         ;name is a symbol or string, symbol preferred
  :description "Preset for proofreading tasks"
  :backend "Claude"
  :model 'claude-3-7-sonnet-20250219
  :tools '("read_buffer" "spell_check" "grammar_check")
  :temperature 0.7
  :use-context 'system)

All keyword arguments to gptel-make-preset are optional.

There are a couple of special keys used by this function: :description (for your reference only) and :parents (for inheriting settings from other presets). Apart from these, there is no predefined set of recognized keys. Any key of the form :foo corresponds to setting gptel-foo (preferred) or gptel--foo. So you can set any gptel option in a preset, including internal ones. Unrecognized keys are ignored with a warning.

Switching to a preset simply applies the settings specified, and does not touch or reset other settings. So if

1. applying preset1 sets gptel-foo to t
2. and preset2 doesn't include a setting for gptel-foo,
3. gptel-foo will stay as t when you switch to preset2.
   This is a consequence of the open-ended specification format.

Please let me know if you have suggestions. (feature-presets branch)