Calling tool stuck/frozen a lot while using gptel in agentic manner

[lucaspeixotot]

Please update gptel first -- errors are often fixed by the time they're reported.

• I have updated gptel to the latest commit and tested that the issue still exists

Bug Description

Gptel works perfectly if I try to use for simple things, using it like a google or something like that. However, if I try to use it in a more agentic way, to investigate code bases, to plan features, to work with MCP servers and so, it is currently impossible.

I use github copilot in te work but the same experience happen by using deepseek in my personal computer. More agentic you use it more buggy it becomes.

My main issue is "Calling tools" stuck, and the experience is like this:

Usually I need to run gptel-abort many times, and ask new prompts until I get it unblocked. But either way in subsequent prompts the same error happens.

I'm not sure how to debug this. toggle-on-debug-error doesn't show anything. I have notice that some models are worse than others. GPT 5.5 is the one that works better, Opus is a disaster, and this gpt 5.6 looks bad as well.

I really love gptel and I would like to use it more and more in agentic manners. Even after the last meeting that Karthink participated where a new feature of invoking gptel outside an gptel buffer with floating windows is suppose to be release. But for me this kind of error is a blocker to use gptel for more things than googling it.

Backend

Other (please specify in Additional Context)

Steps to Reproduce

Just try to use gptel with gptel-agent, MCPs, and ask to do complex things like checking code on different repos, planning a change, doing a change, and so. This is what I want to do and I always get calling tools stuck.

Additional Context

I'm using emacs at "GNU Emacs 30.2.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0)
of 2026-07-03"

My emacs runs in a WSL2 Ubuntu. But in my personal computer with Arch Linux the same problem happens.

My emacs config is simple:

(use-package gptel
  :straight (gptel :host github :repo "karthink/gptel" :branch "master")
  :bind (
         ("C-c a n" . gptel)
         ("C-c a s" . gptel-send)
         ("C-c a r" . gptel-rewrite)
         ("C-c a m" . gptel-menu)
         ("C-c a a" . gptel-add)
         ("C-c a c a" . gptel-context-add)
         ("C-c a c f" . gptel-context-add-file)
         ("C-c a c R" . gptel-context-remove-all)
         )

  :custom
  (gptel-expert-commands t)
  (gptel-default-mode 'org-mode)
  :config
  (setf (alist-get 'org-mode gptel-prompt-prefix-alist) "@user\n")
  (setf (alist-get 'org-mode gptel-response-prefix-alist) "@assistant\n")
  (gptel-make-deepseek "PersonalDeepseek" ;Any name you want
    :stream t                             ;for streaming responses
    :key (getenv "DEEPSEEK_API_KEY_EMACS")) ;can be a function that returns the key
  (gptel-make-gh-copilot "copilot")

  ;; 1) The directive: the actual prompt instructions
  (setf (alist-get 'english-refine gptel-directives)

        "...")

  ;; 2) The preset: bundles the directive with useful defaults
  (gptel-make-preset 'english-refine
    :description "Rewrite English text with 4 variants and feedback"
    :system 'english-refine
    :include-reasoning nil)
  )

(use-package gptel-agent
  :straight (gptel-agent :host github :repo "karthink/gptel-agent" :branch "master")
  :config
  (advice-add 'gptel-agent--fontify-block :override 'ignore)
  ;;  SDLC marketplace: design-workflow agents and skills.
  ;; Agents dir: files are read directly (non-recursive) as agent definitions.
  (let ((my-workflow "~/.../"))
    (when (file-directory-p my-workflow)
      (add-to-list 'gptel-agent-dirs (expand-file-name "agents/" my-workflow))
      ;; Skills dir: scanned recursively for */SKILL.md.
      (add-to-list 'gptel-agent-skill-dirs (expand-file-name "skills/" my-workflow))))
  ;; Personal skills directory. Each skill is a sub-folder containing a
  ;; SKILL.md file (see https://agentskills.io).
  (add-to-list 'gptel-agent-skill-dirs "~/custom_skills/")
  (gptel-agent-update)
  )

Backtrace

I don't see any backtrace being raised.

Log Information

I enabled the log level to debug, but where is the log buffer? I couldn't know how to open it.

[karthink]

Thanks for the issue. To be able to address the problem, I need to narrow the scope of the question a fair bit.

Just try to use gptel with gptel-agent, MCPs, and ask to do complex things like
checking code on different repos, planning a change, doing a change, and
so. This is what I want to do and I always get calling tools stuck.

1. It looks like you're using gptel-agent, which adds a bunch of things on top of gptel. I suggest reproducing the problem with just gptel first.
2. Can you give me one backend, model, MCP (or elisp tool definition) and prompt I can use to try to reproduce the problem with (just) gptel?
3. Can you also provide the log for an interaction that produces this problem? To get the log, run (setq gptel-log-level 'info), interact with the LLM, and look at the contents of the *gptel-log* buffer.

[lucaspeixotot]

My use-case for gptel is always with gptel-agent, so I don't know how could I reproduce my use case only with gptel once my use case is triggering subagents, tools, and eventually mcps.

Today I had some time to do some personal things and I got the following log. I asked gptel to investigate why clojure code is not highlighted in begin/end src code blocks on org mode. I got stuck as always, this time calling agent. The introspector task never returned.

I'm using deepseek-v4-pro, the prompt was:

I need your help to another stuff. In my org files whenever I use begin/end src and specify the clojure type, I'm not getting the code highlighted by the clojure-ts-mode. Can you investigate what could be missing? @gptel-plan 

Btw, I feel it is worse than ever when using deepseek. Almost impossible don't getting stuck in anything that triggers agents and multiple tools.

gptel-stuck-issue-log.txt

[sergiu128]

Having the same issue. I'm using llm-tool-collection.el along with 2 MCP clients (jira, atlassian and datadog). I'm noticing that tool usage just gets stuck, especially when invoking the buffer tools from llm-tool-collection (open buffer, edit buffer etc). Also noticed it when using Github's MCP tools though.

EDIT: after (setq gptel-log-level 'info) on claude-sonnet-5 (with plenty of usage left), i caught the "freeze": the last few messages logged in *gptel-log*were:

event: content_block_stop
data: {"type":"content_block_stop","index":0   }

event: message_delta
data: {"type":"message_delta","delta":{"stop_reason":"max_tokens","stop_sequence":null,"stop_details":null},"usage":{"input_tokens":103323,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"output_tokens":4096,"output_tokens_details":{"thinking_tokens":4096}}}

event: message_stop
data: {"type":"message_stop"  }

Am I hitting the max token limit on an anthropic reply? gptel-max-tokens evaluates to nil, so I have no limit configured through gptel.

EDIT2: I think the max-tokens is set to 4096 somehow?

This is my last request which got cut off

I should reduce the number of tools...

In general, I guess the recommendation for gptel is to limit the tool usage as there's no tool search+compaction involved anywhere, the api request carries the whole buffer + tool definitions? Thus for any broad tool usage, I could drop to agent-shell + MCPs. Anything else that must touch emacs can go through gptel since tools can call elisp directly.

[karthink]

Having the same issue. I'm using llm-tool-collection.el along with 2 MCP clients (jira, atlassian and datadog). I'm noticing that tool usage just gets stuck, especially when invoking the buffer tools from llm-tool-collection (open buffer, edit buffer etc). Also noticed it when using Github's MCP tools though.

Are you using gptel-agent or is this with just gptel?

[sergiu128]

Having the same issue. I'm using llm-tool-collection.el along with 2 MCP clients (jira, atlassian and datadog). I'm noticing that tool usage just gets stuck, especially when invoking the buffer tools from llm-tool-collection (open buffer, edit buffer etc). Also noticed it when using Github's MCP tools though.
Are you using gptel-agent or is this with just gptel?

this is just with gptel, no gptel-agent. The screenshot above runs normal gptel with claude-sonnet-5 (with plenty of usage left) and 105 enabled tools.

[karthink]

EDIT2: I think the max-tokens is set to 4096 somehow?

Wow, thanks for checking. Turns out it was, set in 6a000d6 a long time ago. Unlike other APIs, the Anthropic API requires that a max-tokens number be specified, otherwise the request fails. I've increased it to 64000, which all the models in the Claude 4+ series support.

That should help. Please let me know if tool calls are still causing issues. MCP tools are more complicated, reproducing issues with the synchronous elisp-only tools (like the llm-tool-collection tools) will help. If they are, I will create a gptel branch with more instrumentation around tool calls and we can dig into what is actually happening.

Occasionally I experience the situation where an async MCP tool never returns, which is outside of gptel's control. But otherwise I have never experienced tool calls getting stuck. (Another measure would be to provide a tool call timeout in gptel, but first I'd like to understand what is happening.)

In general, I guess the recommendation for gptel is to limit the tool usage as there's no tool search+compaction involved anywhere, the api request carries the whole buffer + tool definitions? Thus for any broad tool usage, I could drop to agent-shell + MCPs. Anything else that must touch emacs can go through gptel since tools can call elisp directly.

Yes, gptel does not auto-compact messages because that will mean changing the buffer text from under you. I'm not sure what tool-search is. Is this something provided only by the Anthropic API?

[sergiu128]

EDIT2: I think the max-tokens is set to 4096 somehow?

Wow, thanks for checking. Turns out it was, set in 6a000d6 a long time ago. Unlike other APIs, the Anthropic API requires that a max-tokens number be specified, otherwise the request fails. I've increased it to 64000, which all the models in the Claude 4+ series support.

That should help. Please let me know if tool calls are still causing issues. MCP tools are more complicated, reproducing issues with the synchronous elisp-only tools (like the llm-tool-collection tools) will help. If they are, I will create a gptel branch with more instrumentation around tool calls and we can dig into what is actually happening.

Occasionally I experience the situation where an async MCP tool never returns, which is outside of gptel's control. But otherwise I have never experienced tool calls getting stuck. (Another measure would be to provide a tool call timeout in gptel, but first I'd like to understand what is happening.)

In general, I guess the recommendation for gptel is to limit the tool usage as there's no tool search+compaction involved anywhere, the api request carries the whole buffer + tool definitions? Thus for any broad tool usage, I could drop to agent-shell + MCPs. Anything else that must touch emacs can go through gptel since tools can call elisp directly.

Yes, gptel does not auto-compact messages because that will mean changing the buffer text from under you. I'm not sure what tool-search is. Is this something provided only by the Anthropic API?

Thanks for the fix, I'll give it a try! no auto-compacting makes sense, that's the whole point of gptel, fully restorable converstations. About tool-search: afaik some harnesses have compacted tool descriptions so they don't need to parse many tokens before deciding what tool to pick.