tristan/gptel
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gptel/gptel-ollama.el

183 lines
6.4 KiB
EmacsLisp
Raw Normal View History

gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;; gptel-ollama.el --- Ollama support for gptel -*- lexical-binding: t; -*-
;; Copyright (C) 2023 Karthik Chikmagalur
;; Author: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
;; Keywords: hypermedia
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;; You should have received a copy of the GNU General Public License
;; along with this program. If not, see <https://www.gnu.org/licenses/>.
;;; Commentary:
gptel: Fix prompt collection bug + linting * gptel.el: Update package description. * gptel-gemini.el(gptel--request-data, gptel--parse-buffer): Add model temperature to request correctly. * gptel-ollama.el(gptel--parse-buffer): Ensure that newlines are trimmed correctly even when `gptel-prompt-prefix-string` and `gptel-response-prefix-string` are absent. Fix formatting and linter warnings. * gptel-openai.el(gptel--parse-buffer): Ditto.
2023-12-20 14:23:45 -08:00
;; This file adds support for the Ollama LLM API to gptel
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;; Code:
(require 'gptel)
(require 'cl-generic)
gptel: Use libjansson support if available Using the libjansson JSON parser gives us a modest boost in speed. It's not as significant a speedup as it is for LSP clients since our jSON payloads are smaller and less frequent -- but we might as well use it. * gptel.el (gptel--json-read, gptel--json-encode, gptel--url-get-response, gptel--parse-response): Define macros to use the libjansson-supported `json-parse-buffer` and `json-serialize`. Replace use of `json-encode` and `json-read` appropriately. * gptel-openai.el: (gptel-curl--parse-stream) : Use `gptel--json-read` instead of `json-read`. * gptel-ollama.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-gemini.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-curl.el (gptel-curl--get-args, gptel-curl--get-response, gptel-curl--log-response, gptel-curl--stream-cleanup, gptel-curl--parse-response): Use `gptel--json-read` and `gptel--json-encode` in place of the json.el versions. * gptel-anthropic.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * test/gptel-org-test.el: Use `gptel--json-read`.
2024-03-13 01:53:06 -07:00
(declare-function json-read "json" ())
(defvar json-object-type)
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;; Ollama
(cl-defstruct (gptel-ollama (:constructor gptel--make-ollama)
(:copier nil)
(:include gptel-backend)))
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
(defvar-local gptel--ollama-token-count 0
"Token count for ollama conversations.
gptel: Appease the byte compiler.
2023-11-07 20:20:54 -08:00
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
This variable holds the total token count for conversations with
Ollama models.
Intended for internal use only.")
gptel: Appease the byte compiler.
2023-11-07 20:20:54 -08:00
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(cl-defmethod gptel-curl--parse-stream ((_backend gptel-ollama) info)
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
"Parse response stream for the Ollama API."
gptel-ollama: Fix parsing error (#179) * gptel-ollama.el (gptel-curl--parse-stream): Don't throw an error when regex-searching.
2024-04-27 20:14:17 -07:00
(when (and (bobp) (re-search-forward "^{" nil t))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(forward-line 0))
gptel-ollama: Adjust Ollama stream parser for libjansson * gptel-ollama.el (gptel-curl--parse-stream): libjansson and json.el behave differently w.r.t moving point when there is a parsing error. Fix by explicitly handling point when there is an error. (#255)
2024-03-15 22:27:10 -07:00
(let* ((content-strs) (content) (pt (point)))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(condition-case nil
gptel: Use libjansson support if available Using the libjansson JSON parser gives us a modest boost in speed. It's not as significant a speedup as it is for LSP clients since our jSON payloads are smaller and less frequent -- but we might as well use it. * gptel.el (gptel--json-read, gptel--json-encode, gptel--url-get-response, gptel--parse-response): Define macros to use the libjansson-supported `json-parse-buffer` and `json-serialize`. Replace use of `json-encode` and `json-read` appropriately. * gptel-openai.el: (gptel-curl--parse-stream) : Use `gptel--json-read` instead of `json-read`. * gptel-ollama.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-gemini.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-curl.el (gptel-curl--get-args, gptel-curl--get-response, gptel-curl--log-response, gptel-curl--stream-cleanup, gptel-curl--parse-response): Use `gptel--json-read` and `gptel--json-encode` in place of the json.el versions. * gptel-anthropic.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * test/gptel-org-test.el: Use `gptel--json-read`.
2024-03-13 01:53:06 -07:00
(while (setq content (gptel--json-read))
gptel-ollama: Adjust Ollama stream parser for libjansson * gptel-ollama.el (gptel-curl--parse-stream): libjansson and json.el behave differently w.r.t moving point when there is a parsing error. Fix by explicitly handling point when there is an error. (#255)
2024-03-15 22:27:10 -07:00
(setq pt (point))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(let ((done (map-elt content :done))
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
(response (map-nested-elt content '(:message :content))))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(push response content-strs)
gptel: Use libjansson support if available Using the libjansson JSON parser gives us a modest boost in speed. It's not as significant a speedup as it is for LSP clients since our jSON payloads are smaller and less frequent -- but we might as well use it. * gptel.el (gptel--json-read, gptel--json-encode, gptel--url-get-response, gptel--parse-response): Define macros to use the libjansson-supported `json-parse-buffer` and `json-serialize`. Replace use of `json-encode` and `json-read` appropriately. * gptel-openai.el: (gptel-curl--parse-stream) : Use `gptel--json-read` instead of `json-read`. * gptel-ollama.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-gemini.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-curl.el (gptel-curl--get-args, gptel-curl--get-response, gptel-curl--log-response, gptel-curl--stream-cleanup, gptel-curl--parse-response): Use `gptel--json-read` and `gptel--json-encode` in place of the json.el versions. * gptel-anthropic.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * test/gptel-org-test.el: Use `gptel--json-read`.
2024-03-13 01:53:06 -07:00
(unless (eq done :json-false)
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(with-current-buffer (plist-get info :buffer)
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
(cl-incf gptel--ollama-token-count
(+ (or (map-elt content :prompt_eval_count) 0)
(or (map-elt content :eval_count) 0))))
gptel: Appease the byte compiler.
2023-11-07 20:20:54 -08:00
(goto-char (point-max)))))
gptel-ollama: Adjust Ollama stream parser for libjansson * gptel-ollama.el (gptel-curl--parse-stream): libjansson and json.el behave differently w.r.t moving point when there is a parsing error. Fix by explicitly handling point when there is an error. (#255)
2024-03-15 22:27:10 -07:00
(error (goto-char pt)))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(apply #'concat (nreverse content-strs))))
(cl-defmethod gptel--parse-response ((_backend gptel-ollama) response info)
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
"Parse a one-shot RESPONSE from the Ollama API."
(when-let ((context
(+ (or (map-elt response :prompt_eval_count) 0)
(or (map-elt response :eval_count) 0))))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(with-current-buffer (plist-get info :buffer)
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
(cl-incf gptel--ollama-token-count context)))
(map-nested-elt response '(:message :content)))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(cl-defmethod gptel--request-data ((_backend gptel-ollama) prompts)
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
"JSON encode PROMPTS for sending to ChatGPT."
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(let ((prompts-plist
`(:model ,gptel-model
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
:messages [,@prompts]
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
:stream ,(or (and gptel-stream gptel-use-curl
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
(gptel-backend-stream gptel-backend))
:json-false)))
options-plist)
(when gptel-temperature
(setq options-plist
(plist-put options-plist :temperature
gptel-temperature)))
(when gptel-max-tokens
(setq options-plist
(plist-put options-plist :num_predict
gptel-max-tokens)))
(when options-plist
(plist-put prompts-plist :options options-plist))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
prompts-plist))
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
(cl-defmethod gptel--parse-buffer ((_backend gptel-ollama) &optional max-entries)
(let ((prompts) (prop))
(while (and
(or (not max-entries) (>= max-entries 0))
(setq prop (text-property-search-backward
'gptel 'response
(when (get-char-property (max (point-min) (1- (point)))
'gptel)
t))))
(push (list :role (if (prop-match-value prop) "assistant" "user")
:content
(string-trim
(buffer-substring-no-properties (prop-match-beginning prop)
(prop-match-end prop))
(format "[\t\r\n ]*\\(?:%s\\)?[\t\r\n ]*"
(regexp-quote (gptel-prompt-prefix-string)))
(format "[\t\r\n ]*\\(?:%s\\)?[\t\r\n ]*"
(regexp-quote (gptel-response-prefix-string)))))
prompts)
(and max-entries (cl-decf max-entries)))
(cons (list :role "system"
:content gptel--system-message)
prompts)))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;;###autoload
(cl-defun gptel-make-ollama
gptel-openai: curl-args slot in gptel-backend (#221) gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure): Add a curl-args slot to the backend struct for additional Curl arguments. Usage example: This can be used to set the `--cert` and `--key` options in a custom backend that uses mutal TLS to communicate with an OpenAI proxy/gateway. gptel-curl.el (gptel-curl--get-args): Add backend-specific curl-args when creating HTTP requests. gptel-gemini.el (gptel-make-gemini): Add a curl-args slot to the constructor. gptel-kagi.el (gptel-make-kagi): Ditto. gptel-ollama.el (gptel-make-ollama): Ditto.
2024-02-21 00:21:46 +01:00
(name &key curl-args header key models stream
gptel-ollama: Use default host in gptel-make-ollama
2024-01-10 09:22:34 -08:00
(host "localhost:11434")
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(protocol "http")
gptel-ollama: switch to chat API * gptel-ollama.el (gptel-curl--parse-stream, gptel--parse-response, gptel--request-data, gptel--parse-buffer, gptel--ollama-context, gptel--ollama-token-count, gptel-make-ollama): Switch to Ollama's chat API from the completions API. This makes interacting with Ollama fully stateless, like all the other APIs, and should help significantly with issues like #249 and #279. Support non-streaming responses from Ollama in the process. Remove `gptel--ollama-context` as it is no longer needed. Add a `gptel--ollama-token-count` for tracking token costs. A UI affordance for this is not implemented yet, but is planned.
2024-04-22 12:21:49 -07:00
(endpoint "/api/chat"))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
"Register an Ollama backend for gptel with NAME.
Keyword arguments:
gptel-openai: curl-args slot in gptel-backend (#221) gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure): Add a curl-args slot to the backend struct for additional Curl arguments. Usage example: This can be used to set the `--cert` and `--key` options in a custom backend that uses mutal TLS to communicate with an OpenAI proxy/gateway. gptel-curl.el (gptel-curl--get-args): Add backend-specific curl-args when creating HTTP requests. gptel-gemini.el (gptel-make-gemini): Add a curl-args slot to the constructor. gptel-kagi.el (gptel-make-kagi): Ditto. gptel-ollama.el (gptel-make-ollama): Ditto.
2024-02-21 00:21:46 +01:00
CURL-ARGS (optional) is a list of additional Curl arguments.
gptel-ollama: Use default host in gptel-make-ollama
2024-01-10 09:22:34 -08:00
HOST is where Ollama runs (with port), defaults to localhost:11434
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
MODELS is a list of available model names.
STREAM is a boolean to toggle streaming responses, defaults to
false.
PROTOCOL (optional) specifies the protocol, http by default.
ENDPOINT (optional) is the API endpoint for completions, defaults to
\"/api/generate\".
HEADER (optional) is for additional headers to send with each
gptel: Fix prompt collection bug + linting * gptel.el: Update package description. * gptel-gemini.el(gptel--request-data, gptel--parse-buffer): Add model temperature to request correctly. * gptel-ollama.el(gptel--parse-buffer): Ensure that newlines are trimmed correctly even when `gptel-prompt-prefix-string` and `gptel-response-prefix-string` are absent. Fix formatting and linter warnings. * gptel-openai.el(gptel--parse-buffer): Ditto.
2023-12-20 14:23:45 -08:00
request. It should be an alist or a function that retuns an
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
alist, like:
((\"Content-Type\" . \"application/json\"))
KEY (optional) is a variable whose value is the API key, or
gptel: Fix prompt collection bug + linting * gptel.el: Update package description. * gptel-gemini.el(gptel--request-data, gptel--parse-buffer): Add model temperature to request correctly. * gptel-ollama.el(gptel--parse-buffer): Ensure that newlines are trimmed correctly even when `gptel-prompt-prefix-string` and `gptel-response-prefix-string` are absent. Fix formatting and linter warnings. * gptel-openai.el(gptel--parse-buffer): Ditto.
2023-12-20 14:23:45 -08:00
function that returns the key. This is typically not required
for local models like Ollama.
gptel-ollama, gptel-openai: Add example of backend creation README: Fix error with Ollama backend instructions
2023-10-29 00:31:56 -07:00
Example:
-------
(gptel-make-ollama
\"Ollama\"
:host \"localhost:11434\"
gptel: address byte-compile and checkdoc warnings * gptel.el, gptel-transient.el, gptel-openai.el, gptel-ollama.el
2023-10-31 20:18:00 -07:00
:models \\='(\"mistral:latest\")
gptel-ollama, gptel-openai: Add example of backend creation README: Fix error with Ollama backend instructions
2023-10-29 00:31:56 -07:00
:stream t)"
gptel: checkdoc linting and indentation rules * gptel.el (gptel-use-header-line, gptel--parse-buffer): Docstrings. * gptel-transient.el (gptel--transient-read-variable): Docstring. * gptel-openai.el (gptel-make-openai, gptel-make-azure): Add indent declaration. * gptel-ollama.el (gptel-make-ollama): Add indent declaration. * gptel-kagi.el (gptel-make-kagi): Add indent declaration. * gptel-gemini.el (gptel-make-gemini): Add indent declaration.
2024-01-19 14:19:22 -08:00
(declare (indent 1))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(let ((backend (gptel--make-ollama
gptel-openai: curl-args slot in gptel-backend (#221) gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure): Add a curl-args slot to the backend struct for additional Curl arguments. Usage example: This can be used to set the `--cert` and `--key` options in a custom backend that uses mutal TLS to communicate with an OpenAI proxy/gateway. gptel-curl.el (gptel-curl--get-args): Add backend-specific curl-args when creating HTTP requests. gptel-gemini.el (gptel-make-gemini): Add a curl-args slot to the constructor. gptel-kagi.el (gptel-make-kagi): Ditto. gptel-ollama.el (gptel-make-ollama): Ditto.
2024-02-21 00:21:46 +01:00
:curl-args curl-args
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
:name name
:host host
:header header
:key key
:models models
:protocol protocol
:endpoint endpoint
:stream stream
:url (if protocol
(concat protocol "://" host endpoint)
(concat host endpoint)))))
(prog1 backend
(setf (alist-get name gptel--known-backends
nil nil #'equal)
backend))))
(provide 'gptel-ollama)
;;; gptel-ollama.el ends here
Reference in a new issue Copy permalink