issue: Random response stops after tool call

[trinhkvo]

Check Existing Issues

• I have searched for any existing and/or related issues.
• I have searched for any existing and/or related discussions.
• I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
• I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

0.8.12

Ollama Version (if applicable)

N/A

Operating System

Windows 11

Browser (if applicable)

Edge

Confirmation

• I have read and followed all instructions in README.md.
• I am using the latest version of both Open WebUI and Ollama.
• I have included the browser console logs.
• I have included the Docker container logs.
• I have provided every relevant configuration, setting, and environment variable used in my setup.
• I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
• I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
• Start with the initial platform/version/OS and dependencies used,
• Specify exact install/launch/configure commands,
• List URLs visited, user input (incl. example values/emails/passwords if needed),
• Describe all options and toggles enabled or changed,
• Include any files or environmental changes,
• Identify the expected and actual result at each stage,
• Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

The model should finish running tool calls and providing responses completely.

Actual Behavior

Sometimes the response just stops after a tool call, which is pretty random. It might finish a few tool calls and keep going, then suddenly stop after a random one.

I finally found an example where it stops. For some reason, the AI model (Qwen 3.5 122B-A10B) could analyze other images, but with this one (attached), it finishes read_file and then just stops.

Steps to Reproduce

Use the attached image and ask the model to analyze the image.

My configurations:

• Open WebUI v0.8.12 (docker) + Open-Terminal v0.11.32 (docker with root user access, multi-user enabled)
• llama-swap with llama.cpp (b86xx)
• Qwen3.5-122B-A10B UD IQ4_NL - using Native tool call, context size 150,000
• No filter enabled.

Logs & Screenshots

Open WebUI docker log doesn't show anything abnormal.

Additional Information

No response

[tjbck]

Unable to reproduce.

[MRNAQA]

Like this?

[fnf]

I concur, this has been an issue for the past month or two (maybe earlier, but I've been using tools calling more often these days).
This happens most often for high-reasoning models and/or prompts that involve high numbers of tool calls. It is random:

There are no errors when this occurs, the model just stops responding after a tool call (could be any call):

2026-04-29 15:47:09.556 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "POST /api/chat/completions HTTP/1.1" 200
2026-04-29 15:47:09.556 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 -
192.168.86.1:0 - "POST /api/chat/completions HTTP/1.1" 200
2026-04-29 15:47:10.268 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:10.268 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 -
192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:10.280 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:10.280 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 -
192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:26.173 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:26.173 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 -
192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:26.184 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 -
192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:26.184 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-04-29 15:47:30.266 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304

The time gap from 15:47:10 to 15:47:26 was when I asked the model to continue. This is the same workaround I use like @MRNAQA above.

[fnf]

Another person reported a similar issue here https://www.reddit.com/r/OpenWebUI/comments/1qvsic6/llm_stops_midanswer_when_it_tries_to_trigger_a/ .

[Classic298]

Hi everyone!

We fixed this in dev now can you please test dev branch? Thanks!!

[fnf]

Yes, this issue is a little intermittent and I'd only seen it for chat sessions with a large number of tools call (20-100 calls with 2-10 million tokens accumulated), so it's a bit tricky to collect useful debug info (there are no errors in the standard log when this happens). If it's cheap to trigger then I'd be more than happy to run a few tests until we get better debug messages :) .

I'd implemented a pipe-based orchestration system that lets the LLM automatically spawns sub-agents. With this system in place, most of the time the main/sub-agents would work with perhaps up to 200k tokens at a time (but usually less than 100k), so I haven't encountered this issue very often since the past 2 month (in fact, I'd only seen it once last week).

Thanks for the information, I'll keep an eye on this issue and if I find a reliable way to trigger this then would add to this discussion.
I'll probably try switching to llama.cpp as well to see if it makes the issue goes away.

[fnf]

I ran into the Attempt to decode error today (same symptom of the response stopping, but this time there was an actual error):

2026-06-03 17:58:50.520 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-06-03 17:58:54.193 | WARNING  | open_webui.utils.tools:execute_tool_server:1528 - API Request Error: HTTP error 502:
2026-06-03 17:58:55.248 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-06-03 17:58:55.283 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-06-03 17:59:28.578 | ERROR    | open_webui.routers.openai:generate_chat_completion:1255 - 502, message='Attempt to decode JSON with unexpected mimetype: ', url='http://litellm-work.vanhtu1987.uk/chat/completions'
2026-06-03 17:59:39.022 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-06-03 17:59:39.035 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.86.1:0 - "GET /_app/version.json HTTP/1.1" 304

This occurred after a moderate session of about 50 tool calls/0.5M tokens. I suppose the tool call that resulted in this error wasn't logged in the UI.
I'll try changing the provider to llama.cpp and will report back if it occurs with this provider.

[fnf]

I got the "Attempt to decode JSON with unexpected mimetype" error again today with the same gpt-5.5 model (LiteLLM proxy) and llama.cpp provider.

@Classic298 I had a look at this filter https://github.com/Classic298/open-webui-plugins/tree/main/keep-reasoning-content but don't understand if it'll actually fix this issue. This looks like it'd help with models such as DeepSeek V4 (of which llama.cpp procider also works). Could you please elaborate?.

[Classic298]

yes it will not help with gpt models. its not meant for gpt models.

that error stems from elsewhere. Is your litellm fully updated? is the reverse proxy for your litellm and open webui properly configured too?

[fnf]

Thanks for the confirmation,

My LiteLLM proxy is up-to-date. It's hard to say if it's been properly configured, but since this issue is intermittent: I'm inclined to think that this might have been caused by specific model output.

This error had always occurred during chats with multiple tools calls (in my case it's reading/patching code, it was most often a combination of C and Python). I wonder if the output from reading certain files could have tripped it up, but I looked at the last tool call when it was interrupted and retried that tool call and it ran fine, so the tool call that led to the fault might not have been recorded.

It'll keep an eye on this to see if I could find a simple reproducible case. For now, I have a filter that filters tool call output from the last prompts automatically (to preserve context window and avoid confusing the model, particularly over multiple code patches), it also lets me continue generating without filtering: so it's a minor inconvenience than a show-stopper.