Intermittent HTTP 400 "invalid request error" on /responses - retries do not always recover (deepseek/deepseek-v4.1-flash) #970

Summary

I'm on DSH 0.1.7-rc.2.

My plan is: GOAT. Username: zjwzeroba12.

As your email asked, I'm filing an issue here.

On chat/completions I hit this error with a high probability, and the larger
the context the more likely it is — past 200~300K it is extremely likely.

On responses I did run into the 400 error mentioned in your email, but at a much lower rate.

https://api.commandcode.ai/provider/v1/chat/completions - 422
本轮运行失败422: {"message":"{"message":"invalid request error trace_id: 770320a58f4fd2740bae681624caf930","type":"invalid_request_error"}\n","type":"server_error"}
INVALID_REQUEST

https://api.commandcode.ai/provider/v1/responses - 400
OpenAI API error (400): {"message":"{"type":"invalid_request_error","code":"","message":"invalid request error trace_id: 0997df0fa639b63fe2c53a0334339324"}\n","type":"invalid_request_error"}

Expected Behavior

1. A valid streaming /responses payload should return 200 and stream, at any
   context size the model can serve.

2. If a rejection is safe to retry, please do not wrap it as HTTP 400 with
   type "invalid_request_error". That combination tells clients "your request
   is wrong, retrying will not help". A 429 or 503 (with Retry-After) would
   let clients back off and retry correctly.

3. Retrying should eventually succeed. Right now it can fail 21 times in a
   row over 5.5 minutes, so a client cannot rely on backoff alone.

4. If a limit is being enforced here, please name it in the error instead of
   a bare "invalid request error".

Actual Behavior

Streaming /responses requests intermittently come back HTTP 400 with an
"invalid request error". The identical payload usually succeeds if sent
again, and the trace_id is different on every attempt.

The response body is always this shape (only the trace_id changes):

{"message":"{"type":"invalid_request_error","code":"","message":"invalid request error trace_id: "}\n","type":"invalid_request_error"}

(My client prefixes it with "OpenAI API error (400): " - that part is added
by my client, not by you.)

Rate: about 3% of my requests, which matches what support measured on their
side. From Oct 1 11:39 to Oct 2 09:35 (UTC+8): 25 affected requests out of
828, and 56 failed attempts in total. In practice that is roughly one hiccup
every 30 requests - 24 separate occurrences on Oct 1 alone, and one of them
(Oct 2) cost me a whole turn.

Worst case I have: on Oct 2, 09:29:17-09:34:43 (UTC+8), ONE payload returned
this 400 on 21 consecutive attempts over 5.5 minutes, each with a different
trace_id:

09:29:17 07483e97b82967e06a87a402cb8a7042
09:29:23 9cee0e16d5609815a60f6c640de0d0c0
09:29:29 afab8a0ad397823c6990847cbf60a22a
09:29:37 28d508144606d55bfa149da145f5daa3
09:29:46 a3688af62e5e1c83ec18d380e3c40962
09:29:58 9cdedab1bbac940f6c8ccb0e2f8bef3e
09:30:17 3504c61a62a50f43a12373acd35865d1
09:30:37 7a9dcb26f83c998219d1818e812f1631
09:30:56 fa42cf2b226276ce8430e73469fa2681
09:31:16 74ed9267f494ce3a887728e97f4d0411
09:31:37 0997df0fa639b63fe2c53a0334339324
09:31:56 76341640d4b02f5ef29c5f8c358d2802
09:32:15 fab39ca73281d03a966daa16b9d22a0c
09:32:35 4ee5078303d8bf1a4d08a71a9f2c03b4
09:32:52 c9fe2ed3962d2290565615365724e571
09:33:11 027d68b2e8a6cd590ff043f875f46b74
09:33:31 67090a98e40b57308e736b3a7b2b2c43
09:33:50 4aa28fda2f27d84260f85bbc25208bd3
09:34:08 492b056aa5500eaf62f2e5684e254621
09:34:27 74913a32619877cec4153aab5ff20e0b
09:34:43 eecb8af8177222aec4bc90d1c196df3f

That exhausted my client's 20-retry budget and killed the entire turn.

Steps to reproduce the issue

Client: DSH 0.1.7-rc.2, my own headless agent client (no UI). Streaming
requests with a tools array, in long coding sessions.

Endpoint: POST https://api.commandcode.ai/provider/v1/responses
Model: deepseek/deepseek-v4.1-flash

1. Run a streaming agent loop against /responses with a tools array.
2. Keep the session going at roughly 200k+ prompt tokens, issuing requests
   back to back.
3. Within a few hundred requests one comes back with the 400 described above.
   Sending the identical payload again usually succeeds.

It is not deterministic, so I cannot give one request that always fails.
Prompt size does not look like the trigger on this endpoint: in my logs a 74k
request was hit, while the 300k-350k bucket had zero.

Command Code Version

N/A - this is not reproduced through the Command Code CLI. I call the Provider API directly from my own client (DSH 0.1.7-rc.2).

Operating System

Windows

Terminal/IDE

No response

Shell

dsh

Session file (optional)

No response

Fix prompt (optional)

No response

Additional context

No response