DeepSeek stream terminated at ~4 minutes — API closes connection mid-stream (after #16201 fix)

[Learn-Implement]

What happened?

After upgrading to v0.8.8-rc4, which includes the fix from PR #16201 for the 5-minute undici timeout (issue #16195), a new and different termination occurs.

Agent and Preset runs using the custom DeepSeek endpoint now terminate after approximately 4 minutes with:

The model provider could not complete this request.
terminated

This is NOT the previous undici body/header timeout. Testing with NODE_DEBUG=undici,http,net shows the following sequence:

UNDICI: connected to api.deepseek.com using https:h1
UNDICI: sending request to POST https://api.deepseek.com/v1/chat/completions
UNDICI: received response to POST https://api.deepseek.com/v1/chat/completions - HTTP 200
...streaming for ~4 minutes...
NET: close handle
NET: emit close
UNDICI: request to POST https://api.deepseek.com/v1/chat/completions errored - other side closed

There is no bodyTimeout, no headersTimeout, and no ECONNRESET. The remote server (api.deepseek.com) closes the TCP connection after roughly 4 minutes of streaming.

HTTP 200 was received before the connection closed, so the request itself was accepted. The failure is on the response streaming.

This happens in both standard chat and Agent modes, and in Edge, Firefox, Chrome, and Opera, so it is not browser-specific.

Expected behaviour: The stream should continue until the model finishes, or LibreChat should retry when the connection is closed by the provider.

Actual behaviour: The stream terminates at ~4 minutes and the user sees a generic error.

Version Information

LibreChat v0.8.8-rc4
Deployment: Self-hosted Docker Compose (local)
Image: ghcr.io/danny-avila/librechat:v0.8.8-rc4
Digest: ghcr.io/danny-avila/librechat@sha256:929f4491cb9a87d6beb02e9e9ce9a54d4ee05bc56b65b1debe5b1f28a327a4fb
Reverse proxy: None (direct port 3080)
Custom endpoints: DeepSeek V4 Pro, DeepSeek Flash, Gemini, Qwen
Redis: redis:7-alpine (docker), USE_REDIS_STREAMS=true

Steps to Reproduce

1. Use the custom DeepSeek endpoint with deepseek-v4-pro and reasoning_effort: high.
2. Start a new conversation (standard chat or Agent).
3. Send a prompt that requires extended reasoning (more than 4 minutes of thinking).
4. Wait approximately 4 minutes.
5. Observe the termination error.

What browsers are you seeing the problem on?

Chrome, Firefox, Microsoft Edge

Relevant log output

UNDICI 26: received response to POST https://api.deepseek.com/v1/chat/completions - HTTP 200
...streaming for ~4 minutes...
NET 26: close handle
NET 26: emit close
UNDICI 26: request to POST https://api.deepseek.com/v1/chat/completions errored - other side closed

2026-09-25 14:26:46 error: [api/server/controllers/agents/client.js #sendCompletion] Upstream model error
{"userId":"[REDACTED]","requestId":"846b13d6-4991-44bb-8794-096c4eb4e743","request_method":"POST","request_path":"/api/agents"}

Screenshots

Code of Conduct

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

[danny-avila]

Investigating, was not able to reproduce right away so moved to discussions.

[Learn-Implement]

Reproducible prompt for the ~4-minute DeepSeek termination

To help reproduce the issue reported earlier in this thread, below is the prompt that reliably triggers it. My logs are unchanged from the initial report, but I am including the key excerpt below for convenience.

Setup:

Model: deepseek-v4-pro

Endpoint: custom DeepSeek endpoint (https://api.deepseek.com/v1)

reasoning_effort: high

No attachments

Reproduces in both standard chat and Agent mode

Reproduces in Edge, Firefox, and Chrome

Prompt:

text
A business sells two products, product 1 and product 2, with the following parameters:

- End-user price (VAT 20% included): 100 USD for product 1 and 200 USD for product 2. That is the minimum price. We can increase if needed.
- Cost of goods sold (COGS) / breakeven points – calculate for both products.
- Payment processing commission: 10% of the end-user price for seller 1, commission is counted from prices excluding 20% VAT (net price). 25% for seller 2, commission is calculated from prices including 20% VAT (gross price).
- VAT 20% is calculated on the net price, not the gross.

Calculate the following for the business for both products, showing every intermediate step and verifying each step before moving on:

1. The net price before VAT
2. The VAT amount
3. The commission paid for both products
4. The gross margin in USD
5. The gross margin as a percentage of the net price
6. Cost of goods sold (COGS) / breakeven points

Then repeat the calculation for end-user prices of 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, and 111 USD.
Then repeat the calculation for end-user prices starting from 200 USD through 212 USD.

How will numbers change if the same business operates in jurisdictions with 15% and 20% VAT? For the same two products?

After each price, verify the previous result before continuing.

After you have verified, proceed to the following:
What is more profitable? To sell product A at cost of 111 USD 20 units or product B at 222 USD 10 units.

Verify final results.

Expected behaviour:
The model should be allowed to reason for as long as it needs to produce a complete answer. The user expects the request to remain active until the model finishes, even if that takes 5, 10, or 15 minutes. The client should not impose an artificial cutoff below the provider's own limits, and the provider should not close the connection mid-stream while the model is still generating.

LibreChat timeout configuration in this instance:

The running image is ghcr.io/danny-avila/librechat:v0.8.8-rc4 which includes the fix from PR #16201 for the previous undici body/header timeout (issue #16195).

PR #16201 changed the defaults for Agent model calls to modelResponseBodyTimeoutMs: 900000 (15 minutes) and modelResponseHeadersTimeoutMs: 300000 (5 minutes). These are now the built-in defaults and are not overridden in .env.

There is no handle.js patch mounted. The container uses the image's version.

Redis is enabled for resumable streams (USE_REDIS=true, USE_REDIS_STREAMS=true).

Provider-side limits (for context):

Providers impose their own streaming limits. DeepSeek documentation and community reports mention various limits in the 2-minute to 10-minute range, but there is no single authoritative figure for deepseek-v4-pro with reasoning_effort=high. This variability is part of the problem.

Actual behaviour:
The client is configured for a 15-minute body-idle allowance by default. The provider closes the connection at approximately 4 minutes, but the exact timing varies between runs (3m50s to 4m20s). This variability suggests the provider is enforcing an idle timeout between tokens rather than a fixed wall-clock limit. There is no client-side timeout firing — the close is initiated by the provider and sits below the client's configured ceiling.

Client-side evidence (unchanged from initial report):

HTTP 200 received, SSE stream started.

Connection closed by the remote server at ~4 minutes.

No client-side bodyTimeout, headersTimeout, or ECONNRESET.

Relevant log excerpt from the failure is below.

Suggested action:
If the provider closes an idle connection mid-stream, LibreChat should surface a clear message about the provider's behaviour rather than a generic terminated error. If the connection is closed by the provider before the model finishes, LibreChat should attempt a retry or preserve the partial response so the user does not lose their work.

Relevant log excerpt:

UNDICI 26: received response to POST https://api.deepseek.com/v1/chat/completions - HTTP 200
...streaming for ~4 minutes...
NET 26: close handle
NET 26: emit close
UNDICI 26: request to POST https://api.deepseek.com/v1/chat/completions errored - other side closed

2026-09-25 14:26:46 error: [api/server/controllers/agents/client.js #sendCompletion] Upstream model error
{"userId":"[REDACTED]","requestId":"846b13d6-4991-44bb-8794-096c4eb4e743","request_method":"POST","request_path":"/api/agents"}