[Compatibility] OpenDesign DeepSeek v4.1 streaming tool arguments fail with 502 via combo; opencode-go route works #7920

Summary

OpenTodo's in-app assistant can read/analyze tasks through OpenCodex, but preparing a multi-tool change proposal fails with HTTP 502 when combo/ds41-flash selects OpenDesign/deepseek-v4.1-flash. The recorded upstream error is upstream stream produced malformed tool call arguments.

Changing only the application's configured model to opencode-go/deepseek-v4.1-flash restored the workflow: subsequent real in-app turns completed with proposals containing 15 and 39 changes. The user confirmed a substantial improvement. This isolates a provider/route compatibility problem, not a proven bug in combo selection or OpenTodo.

Client or integration

OpenTodo v0.16.0 in-app assistant, self-hosted Docker on Linux, using an OpenAI-compatible Chat Completions client through a local HTTP reverse proxy to OpenCodex. OpenCodex npm package metadata reports version 2.93.0 (also the latest release checked when reporting).

Provider or upstream service

Failing route: OpenDesign/deepseek-v4.1-flash, adapter openai-chat, reached through a failover combo.
Working alternative: opencode-go/deepseek-v4.1-flash directly.

Redacted combo definition (no credentials):

{
  "ds41-flash": {
    "strategy": "failover",
    "stickyLimit": 1,
    "defaultEffort": "high",
    "reasoningEffortMode": "adaptive",
    "targets": [
      { "provider": "OpenDesign", "model": "deepseek-v4.1-flash", "weight": 1 },
      { "provider": "opencode-go", "model": "deepseek-v4.1-flash", "weight": 1 }
    ]
  }
}

The combo and direct route may resolve different reasoning defaults; this was not controlled, so this is not an identical-upstream/model-parameters A/B test.

Endpoint or capability

POST /v1/chat/completions, streamed tool calls. OpenTodo sends stream: true, stream_options: {"include_usage": true}, tools, tool_choice: "auto", and max_tokens: 8192. It sends tool results back for subsequent rounds.

Current behaviour

Two real proposal turns failed on 2026-10-28. OpenTodo displayed The provider reported an error while answering. No completed proposal was returned for either failed turn.

OpenCodex usage records (selected fields only; no prompts, task data, tokens, account identifiers, or credentials):

[
  {
    "timestamp": 1793212887267,
    "requestedModel": "combo/ds41-flash",
    "status": 502,
    "durationMs": 38308,
    "upstreamError": "upstream stream produced malformed tool call arguments",
    "failureStage": "side-effect",
    "failureCause": "upstream-fault",
    "attempts": [
      {"provider": "OpenDesign", "model": "deepseek-v4.1-flash", "adapter": "openai-chat", "status": 502}
    ]
  },
  {
    "timestamp": 1793213129330,
    "requestedModel": "combo/ds41-flash",
    "status": 502,
    "durationMs": 38594,
    "upstreamError": "upstream stream produced malformed tool call arguments",
    "failureStage": "side-effect",
    "failureCause": "upstream-fault",
    "attempts": [
      {"provider": "OpenDesign", "model": "deepseek-v4.1-flash", "adapter": "openai-chat", "status": 502}
    ]
  }
]

The associated OpenCodex log errors occurred at 2026-10-28T18:42:05.574Z and 2026-10-28T18:46:07.923Z.

Associated OpenTodo telemetry:

18:42:05Z failed=true  proposed=0 input_tokens=34700 output_tokens=887
18:46:07Z failed=true  proposed=0 input_tokens=7965  output_tokens=195

Expected behaviour

For valid upstream tool-call streams, relay complete tool names and valid JSON arguments so OpenTodo can construct a reviewable proposal. If the upstream really generates invalid arguments, fail explicitly rather than inventing arguments or silently dropping requested changes.

Please help determine whether this failure is caused by invalid upstream output, streamed delta assembly/normalization, truncation, or another provider-specific incompatibility. A sanitized indication of the invalid argument shape/parse failure would make diagnosis easier.

Only one attempt was recorded for each failed combo request. This is an observation, not a request for unconditional failover: failureStage=side-effect may correctly prevent replay after tool-call events were already delivered. Please preserve that safety boundary.

Minimal redacted request or reproduction

Observed workflow, not yet a deterministic standalone reproduction:

1. Configure the failover combo above on OpenCodex 2.93.0.
2. Point OpenTodo v0.16.0's compatible assistant at OpenCodex and set its model to combo/ds41-flash.
3. With multiple projects and open tasks, ask the assistant to analyze the projects. Read-only analysis succeeded.
4. Ask it to prepare the proposed organizational changes (move a task to its project, add dependencies, schedule tasks). Two attempts failed as recorded above.
5. Keep the application, endpoint and data unchanged; change its model to opencode-go/deepseek-v4.1-flash. Subsequent turns successfully returned proposals.

The original task contents and browser conversation are personal and are deliberately not attached. No raw upstream SSE capture was retained. The exact malformed JSON payload is therefore unavailable, and the failure has not been reproduced with synthetic data.

Tests and workaround

• OpenTodo's saved-settings connection/tool-definition test passed for the direct opencode-go model.
• A separate synthetic streaming test with tool_choice: "auto" returned the requested tool with valid JSON arguments through the direct model; no real task tools were executed by that test.
• Actual OpenTodo turns after the change completed with proposed=15, failed=false at 18:54:40Z and proposed=39, failed=false at 18:56:44Z.
• Direct-route requests in OpenCodex usage records returned HTTP 200 around those turns.
• An earlier direct-route turn did hit OpenTodo's output-token limit. The workaround fixes the observed tool-stream failure, but does not remove output-budget limits or guarantee all future tool calls succeed.
• NOT RUN: deterministic synthetic reproduction of the OpenDesign failure; raw SSE comparison; adapter regression suite. No OpenCodex code was changed.

Upstream documentation

• OpenTodo Chat Completions client in the deployed version: https://github.com/OpenTodoApp/OpenTodo/blob/v0.16.0/internal/assistant/chat.go
• OpenTodo assistant loop and output-token limit: https://github.com/OpenTodoApp/OpenTodo/blob/v0.16.0/internal/assistant/loop.go

Related issues

#1472 and #1473 describe older malformed DeepSeek tool-call failures, but concern deepseek-v4-flash-free on OpenCodex 2.12.0 rather than the OpenDesign v4.1 route here. #1473 was automatically closed for insufficient detail, not a confirmed resolution. No matching open OpenDesign/DeepSeek issue was found in the search performed for this report.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• Expected behaviour is based on the concrete client's streaming tool-call requirements.