An error occurred while processing the request: terminated (When LLM response takes >5 min)

[Svagtlys]

What happened?

When my LLM backend spends a long time (seems to be over 5 minutes) processing a prompt without returning tokens, I get the following error in LibreChat:

Something went wrong. Here's the specific error message we encountered: An error occurred while processing the request: terminated

When the backend subsequently tries to reach out to LibreChat, this error appears in the backend's logs:

[Error] (HttpClient) CURL error: Failed writing received data to disk/application
[Error] (WrappedServer) Streaming request failed: CURL error: Failed writing received data to disk/application
[Info] (Process) srv stop: cancel task, id_task = 1830

These errors seem to be specific to LibreChat, as other frontends (OpenCode) do not have anything similar even with similarly long (or longer) processing times. I assume that LibreChat closes the connection if it doesn't receive a response from the LLM backend in a certain amount of time. I haven't found any information in the LibreChat docs on increasing the timeout via config.

Version Information

registry.librechat.ai/danny-avila/librechat-api:latest 73c23d345657

No special build args

Steps to Reproduce

1. Prompt in LibreChat something that will take a model a long time to process (generally happens after a lot of web searches, for me)
2. Wait 5+ minutes
3. Error appears in LibreChat UI, then when model responds the CURL error appears in the backend logs

What browsers are you seeing the problem on?

Firefox

Relevant log output

Browser logs:

19:16:48.626 [ResumableSSE] Stream aborted (intentional close) - no reconnect index.C1VeOx9R.js:2:1094680
19:16:48.875 Uncaught TypeError: can't access property "status", this.xhr is null
    _onStreamFailure https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    stream https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    SSE https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    V https://chat.domain.tld/assets/index.C1VeOx9R.js:2
    <anonymous> https://chat.domain.tld/assets/index.C1VeOx9R.js:2
    async* https://chat.domain.tld/assets/index.C1VeOx9R.js:2
    el https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    bc https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    yc https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    yc https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    oc https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Bi https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    ec https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    ec https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Jl https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Qa https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Batcher https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    l https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    applyActionsToStore https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    queueOrPerformStateUpdate https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    setRecoilValue https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    useSetRecoilState https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    _ https://chat.domain.tld/assets/index.C1VeOx9R.js:2
    R https://chat.domain.tld/assets/index.C1VeOx9R.js:2
    u https://chat.domain.tld/assets/index.C1VeOx9R.js:2
    de https://chat.domain.tld/assets/forms.BwoCjvk7.js:1
    Pe https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    qe https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Ir https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Ir https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Lr https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    zr https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Re https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    zr https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Vt https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Ft https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    S https://chat.domain.tld/assets/index.C1VeOx9R.js:2
    Pe https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    qe https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Ir https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Ir https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Lr https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    zr https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    ac https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Re https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    zr https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Vt https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
    Ft https://chat.domain.tld/assets/vendor.CFTORYSF.js:1
vendor.CFTORYSF.js:1:1860282
19:16:48.931 XHR
GET
https://chat.domain.tld/api/mcp/servers
[HTTP/2 401  6ms]

19:16:48.945 401 error, refreshing token index.C1VeOx9R.js:2:206270
19:16:48.983 tokenUpdated event received event index.C1VeOx9R.js:2:599248

Screenshots

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Thanks for the detailed logs, they might point to the cause.

terminated comes from Node's HTTP client (undici), which LibreChat uses to call your model. undici aborts any in-flight request that goes 5 minutes without receiving data (its default bodyTimeout/headersTimeout of 300,000 ms). Your backend's long processing exceeds that, so LibreChat drops the socket, and your server then logs CURL error: Failed writing received data (libcurl "client disconnected") and srv stop: cancel task. Those are the effect of the abort, not the cause. It's also why OpenCode differs, it's not a Node/undici client.

This isn't a recursion/step limit either (12 tool calls is far below any, and that fails differently).

To narrow the fix:

• Are these tool calls going through MCP servers? If so, can you share your mcpServers config? The relevant knobs are timeout (per tool call, default 60000 = 1 min) and sseReadTimeout (SSE stream idle limit, default 300000 = 5 min), raising them often resolves exactly this. Example:

  mcpServers:
    my-server:
      url: http://localhost:8000/mcp
      timeout: 600000         # 10 min per tool call (default 1 min)
      sseReadTimeout: 600000  # 10 min idle stream limit (default 5 min)
      initTimeout: 30000      # optional handshake timeout

The most likely stall is a long-running tool call, not the model itself (token emission is typically fast). If a single MCP tool takes >5 min to return, that's the connection that gets dropped, which is why the MCP timeout/sseReadTimeout knobs above are the first thing to try. (For completeness: the LLM chat-stream has the same 5-min undici limit, but it's an unlikely culprit here since the model would normally emit tokens well within that window.)

[Svagtlys]

I think it is the model backend not the mcp, as this issue comes up even when not calling a tool as long as the context is long enough.
Here is the latest one that failed, it took over 15 minutes with 95k context size.

lemonade-server | 2026-06-07 18:11:48.182 [Info] (Process) 77.22.050.362 I slot launch_slot_: id 3 | task 4753 | processing task, is_child = 0
lemonade-server | 2026-06-07 18:11:48.182 [Info] (Process) 77.22.050.432 W slot update_slots: id 3 | task 4753 | n_past = 94585, slot.prompt.tokens.size() = 95880, seq_id = 3, pos_min = 95879, n_swa = 0
lemonade-server | 2026-06-07 18:29:12.706 [Error] (HttpClient) CURL error: Failed writing received data to disk/application
lemonade-server | 2026-06-07 18:29:12.706 [Error] (WrappedServer) Streaming request failed: CURL error: Failed writing received data to disk/application
lemonade-server | 2026-06-07 18:29:12.754 [Info] (Process) 94.46.622.537 W srv stop: cancel task, id_task = 4753
lemonade-server | 2026-06-07 18:29:12.823 [Info] (Process) 94.46.691.573 I slot release: id 3 | task 4753 | stop processing: n_tokens = 141178, truncated = 0

But here is the mcp config as I've been known to be wrong :) It seems that the timeout values are not set, so I will try that and report back

mcpServers:
mcpjungle:
title: "Gateway to MCPs"
description: "A gateway to multiple diverse MCPs"
command: npx
args:
- "mcp-remote"
- "http://mcpjungle:8080/mcp"
- "--allow-http"

[danny-avila]

The reason MCP is suspect is because it looks like your failure is happening in the middle of tool calls, not while the LLM is responding

LLM backend spends a long time (seems to be over 5 minutes) processing a prompt without returning tokens

this could also cause the issue but this is not expected behavior of LLM providers. Something should be emitted in the interim and it would help to understand your LLM provider side more. We can probably add the same kind of extended time out but this is an edge case as LLMs usually do not keep responses quiet for more than 5 minutes

[sicusa]

I have the same problem. I'm using LM Studio as LLM provider.

[sicusa]

I'm using qwen3.6 27b on my laptop with 10~20 tokens/second, and this bug makes LibreChat unusable when writing large files like code. Hope it to be fixed soon.

[cepreu2github]

So... Any settings to tweak and increase timeout? Or maybe other workaround?