Removing <think>....</think> blocks from Deepseek responses

[EnigmaCurry]

I am running a Deepseek R1 model via LM Studio and it always returns responses that look like this:

In one word, what is truth?

<think>
Okay, so I need to figure out what the user means by "truth" in this context. blah blah blah .....
</think>

Truth.

My objective is to remove the entire <think>...</think> block and the extra newline it brings, because I only care about capturing the actual response. Heres my code that does this based on another answer I found here in the discussion area about trimming responses.

(defun my-gptel-deepseek-remove-think-block (beg end)
  "Delete an HTML block tag named 'think' and its content."
  (unless gptel-mode
    (save-excursion
      (goto-char beg)
      ;; Find the opening <think> tag
      (when (re-search-forward "^<think>" end t)
        (let* ((start (line-beginning-position))
               (end-pos (progn (forward-line 1) (search-forward "</think>") (point))))
          ;; Delete from start of opening tag to end of closing tag
          (delete-region start end-pos))))
    (save-excursion
      (goto-char beg)
      (delete-region
       (point) (progn (skip-syntax-backward " ")
                      (point))))))
(add-hook 'gptel-post-response-functions #'my-gptel-deepseek-remove-think-block)

With this hook enabled, now the response would be truncated to Truth.

[EnigmaCurry]

Here's an improved version for org-mode only. Instead of removing the block, it wraps it in an org-mode drawer named :THINKING: and collapses it.

 (defun my-gptel-deepseek-wrap-think-block (beg end)
   "Wrap '<think>' blocks in an Org-mode drawer if not already wrapped."
   (when (derived-mode-p 'org-mode)
     (save-excursion
       (goto-char beg)
       ;; Find all occurrences of <think> blocks
       (while (re-search-forward "^<think>" end t)
         (let ((start (line-beginning-position)))
           ;; Check if the block is already wrapped
           (unless (save-excursion
                     (forward-line -1)
                     (looking-at "^:THINKING:$"))
             ;; Insert Org-mode drawer start
             (goto-char start)
             (insert-and-inherit ":THINKING:\n")
             (forward-line 1)
             ;; Find the closing tag again after insertion
             (when (re-search-forward "</think>" end t)
               (end-of-line)
               ;; Ensure we don't add duplicate :END:
               (unless (looking-at "\n:END:")
                 (insert-and-inherit "\n:END:\n"))
               ;; Move back to the start of the drawer for org-cycle
               (goto-char start)
               (org-cycle)))))))
   (message "Think blocks wrapped and folded."))
(add-hook
  'gptel-post-response-functions
  #'my-gptel-deepseek-wrap-think-block)

[karthink]

I would replace the inserts everywhere with insert-and-inherit. This is required to mark what you insert (like "\n:END:\n") as part of the response instead of the user prompt.

[arichiardi]

In my case I had to match spaces right before <think> cause the response looked like:

@assistant
  <think>
Understood! ...

So I used this regex (rx (and line-start (* space) "<think>"))

Sometimes I get error in process sentinel: run-hook-with-args: Wrong number of arguments: (0 . 1), 2` and still debugging where that comes from.

[erwald]

When converting responses to org-mode formatting, it would perhaps be convenient to get the chain of thought in a collapsible drawer, i.e.:

:THINK:
...
:END:

Truth

[ceblan]

@erwald and @karthink , just one question about this:

would the hook prevent the concatenation of the successive CoT's to the context?

[karthink]

@erwald and @karthink , just one question about this: would the hook prevent the concatenation of the successive CoT's to the context?

If the CoT text is in the buffer, it's in the conversation context. So if you want it to be, you shouldn't delete it from the buffer.

[ceblan]

Nop, I don't want it to be in the context. Actually I am asking because of what is said in the deepseek api. In particular because of this:

"Please note that if the reasoning_content field is included in the sequence of input messages, the API will return a 400 error. Therefore, you should remove the reasoning_content field from the API response before making the API request"

[karthink]

Nop, I don't want it to be in the context. Actually I am asking because of what is said in the [deepseek api](https://api-docs.deepseek.com/guides/reasoning_model). In particular because of this: "_Please note that if the reasoning_content field is included in the sequence of input messages, the API will return a 400 error. Therefore, you should remove the reasoning_content field from the API response before making the API request_"

It looks like deepseek's API is different from OpenAI's, or that the OpenAI API has new features that gptel doesn't support. Either way, the "reasoning_content" field is not added to the chat buffer so it should work as expected.

[karthink]

@EnigmaCurry Thank you. It looks like the deepseek.com API behaves differently from the LM studio API, despite both being ostensibly OpenAI-compatible.

[infrecursion]

@infrecursion Can you confirm that the reasoning text is currently not added to the buffer? I have not used these "thinking" models. The opening post by @EnigmaCurry suggests that the reasoning block is included in the buffer, and @ceblan's messages suggest that it is not included. I don't know which is true.

@karthink yes it seems like an issue with deepseek.com API. When I invoke the model from together.ai the reasoning text do show up within tags.

[karthink]

@infrecursion Then displaying the thinking blocks in the buffer with the deepseek API will require defining a new dedicated gptel backend type.

[weavermarquez]

@karthink Seconding that using api.deepseek.com does not show any of the reasoning_content material nor any tags, but that it does show the tags when using api.together.xyz

[ceblan]

To clarify, I'm currently using deepseek-r1 within Ollama via the Open-WebUI API. This setup is quite complex, so for simplicity, let's disregard the specifics. I'll investigate the differences between this approach and using the OpenAI or DeepSeek APIs directly, and will update with a clearer explanation later if anyone is interested.

[tusharhero]

(setq-local outline-regexp "<.*"  outline-heading-end-regexp "\n")

This works to collapse the think block with outline-minor-mode. I would appreciate some help with doing this while preserving the default markdown mode outline regexps.

[karthink]

(defun gptel-markdown-wrap-think-block (beg end)
  (save-excursion
    (goto-char beg)
    (when (re-search-forward "^<think>$" end t)
      (forward-line 0)
      (let ((level))
        (save-excursion
          (when (or (thing-at-point-looking-at markdown-regex-header)
                    (re-search-backward markdown-regex-header nil t))
            (setq level (1+ (markdown-outline-level)))))
        (markdown-insert-header level "THINKING")
        (when (re-search-forward "^</think>$" end t)
          (skip-chars-forward " \t\r\n")
          (markdown-insert-header level "ANSWER")
          (forward-line -1)
          (outline-hide-subtree)))
      (add-text-properties
       beg end '(gptel response front-sticky (gptel))))))

Modify as needed.

[matchcase]

Is there any simple way to have the text appear in a separate buffer?

[karthink]

Yes, modify one of the gptel-post-response-functions hook functions from a previous message in this thread to remove the <think>...</think> block from the response and show it in another buffer.

I'll add a more formal way to handle it to gptel after #592 is merged.

[karthink]

This is done, see gptel-include-reasoning.

[karthink]

You can now show the reasoning block along the response, or in another buffer, or ignore it, or more. Including it along with the response will cause it to be enclosed in an Org block or markdown backticks. See the user option gptel-include-reasoning for details.

This should work for all backends that use reasoning blocks, including Claude (3-7-sonnet), Deepseek, Openrouter, Grok, Github Models and more.