Provider API: /v1/responses rejects reasoning.summary with 400 "json: unknown field \"summary\"" (deepseek/* models)

[HuHong-Tao]

Summary

POST /provider/v1/responses returns 400 json: unknown field "summary" for the deepseek/* models whenever the request body carries the standard OpenAI Responses reasoning object with a summary field:

"reasoning": { "effort": "high", "summary": "auto" }

Any OpenAI-Responses client that sets a thinking level therefore fails every turn. Both models list /responses in supported_endpoints, and the Provider API docs say Responses request bodies "follow the OpenAI Responses schema", so this looks like the route is advertised but the field is not accepted.

Same client and same payload worked until 2026-09-27 19:38 (UTC+8) and started failing on 2026-09-28, so this looks like a recent change on the gateway/upstream side.

Expected Behavior

A body containing reasoning.summary should be accepted, or the field ignored if it cannot be honored — the route returns summary arrays in its own reasoning output items. If this route genuinely cannot support the field, dropping /responses from supported_endpoints for the affected models would let clients route to /chat/completions instead.

Actual Behavior

400 {"message":"{\"type\":\"BadRequest\",\"code\":\"InvalidParameter\",\"message\":\"json: unknown field \\\"summary\\\" Request id: 0217905825038199ef299c750278aff859a2ad68462f46ac88ece trace_id: 8ee9b95c1451059671d52c2c5d897a82\"}\n","type":"invalid_request_error"}

Measured today with an API key, alternating payloads:

Body	Result
reasoning: {effort: "high", summary: "auto"}	400, 6/6 runs
reasoning: {effort: "high"} (no summary)	200, 6/6 runs

• Affected: deepseek/deepseek-v4.1-flash, deepseek/deepseek-v4-flash.
• Not affected: xiaomi/mimo-v2.6-flash accepts the same body, so this looks upstream-specific rather than route-wide.
• /chat/completions is unaffected for the same models.

Steps to reproduce

# 400 json: unknown field "summary"
curl https://api.commandcode.ai/provider/v1/responses \
  -H "Authorization: Bearer $CMD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek/deepseek-v4.1-flash","input":"hi","reasoning":{"effort":"high","summary":"auto"}}'

# 200 with summary removed
curl https://api.commandcode.ai/provider/v1/responses \
  -H "Authorization: Bearer $CMD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek/deepseek-v4.1-flash","input":"hi","reasoning":{"effort":"high"}}'

Reproduced in a real client with pi 0.87.1 (custom provider, "api": "openai-responses", same key) — every turn fails and the agent ends with an error and no output. The official @commandcode/pi-commandcode-provider avoids this by preferring /chat/completions for non-gpt-* models, so the failure surfaces for other Responses clients pointed at the documented endpoint.

Command Code Version

1.62.1 (cmd --version). The reproduction above used the Provider API directly with an API key, not the CLI.

Operating System

macOS

[ZhangEnlin]

I encountered the same error today when using the deepseek-v4.1-flash model in the dsh + GOAT plan:

OpenAI API error (400): {"message":"{\"type\":\"BadRequest\",\"code\":\"InvalidParameter\",\"message\":\"json: unknown field \\\"summary\\\" Request id: xxx trace_id: xxx\"}\n","type":"invalid_request_error"}

I hope the Command Code provider can ignore fields that are currently unsupported. The JSON validation is currently too strict.