Provider API: HTTP 400 "a single path expansion cannot exceed 512 candidates" makes a long session unrecoverable

[Success625]

Summary

A long-running session using the Provider API (/provider/v1/chat/completions)
started receiving HTTP 400 on every request and could not be recovered. Other
sessions on the same account worked normally.

Error body:

{"message":"a single path expansion cannot exceed 512 candidates trace_id: 5a604d6ce8d75303493e0438b66a84ba","type":"invalid_request_error"}

trace_ids observed over ~10 minutes (6 consecutive failed requests):
7968d9b9b9e8349578f610eaed588d95, 9d02af819df5685f206856f2bbc3baab,
660a04061c0e7b767f85cdffc8ef45e4, eb0ef9bd3ff006d492bd9cd597951c1e,
e35f596ba07869df219ba44ea244d5e0, 5a604d6ce8d75303493e0438b66a84ba

Environment

• Client: OpenCode v2.0.18, provider configured directly with
  @ai-sdk/openai-compatible (no Command Code plugin/harness involved)
• Model: deepseek/deepseek-v4.1-flash
• Endpoint: POST https://api.commandcode.ai/provider/v1/chat/completions
• Session size at failure: ~210 messages / ~574k input tokens (normal requests
  had worked for hours in the same session)

Expected Behavior

Session should continue normally or be recoverable using the continue prompt without the same unrecoverable error showing up.

Actual Behavior

• The first 400 occurred automatically — no /compact, no user prompt, right
  after a tool/background task completed.
• Every subsequent request for that session failed with the same error.
  Reverting the conversation to earlier messages did not help.
• Requests from other sessions (same account, same provider) continued to work.

Steps to reproduce the issue

This is my first time encountering this bug and I can't really tell exactly how to reproduce the issue.

Command Code Version

N/A

Operating System

Linux

Terminal/IDE

opencode

Shell

zsh

Session file (optional)

No response

Fix prompt (optional)

No response

Additional context

No response

[Success625]

Questions

1. What does "a single path expansion" validate in the Provider API pipeline,
   and what request content can produce more than 512 candidates?
2. Is there a way to recover or reset a session once a request trips this
   validation?
3. Can the error name the offending field/message so clients can self-correct?

Related report from another OpenCode user: anomalyco/opencode#52291

[D1ff1culTT]

Same failure from a plain OpenAI-compatible client (no Command Code harness in the path)

Adding a second data point: a different client, same error shape and same wrapper format.

• Client: AstrBot v4.28.1 — generic OpenAI-compatible chat-completions provider, no CC plugin/harness involved
• Endpoint: POST https://api.commandcode.ai/provider/v1/chat/completions
• Model: deepseek/deepseek-v4-flash
• When: 2026-09-30 13:33 UTC (21:33 UTC+8)
• trace_id: 1aba926955f85fe7b8054171f50b704f

Error body, verbatim:

{"error": {"message": "{\"message\":\"a single path expansion cannot exceed 512 candidates trace_id: 1aba926955f85fe7b8054171f50b704f\",\"type\":\"invalid_request_error\"}\n", "type": "invalid_request_error"}}

Observations that may help localize it:

1. The failing call was a continuation inside a tool-calling loop — the client had just executed tools and was sending the tool results back. This matches the note above that the first 400 arrived right after a tool/background task completed.
2. The client's retry wrapper did not recover it — the error surfaced out of the provider retry loop (tenacity), and repeat attempts returned the same body with only the trace_id differing.
3. This is a third-party agent calling the Provider API directly, so the trigger is not specific to the CLI harness.

Questions from a client author's perspective:

• Which part of the request feeds the "path expansion" that is capped at 512 candidates — tool definitions, message parts, reasoning fields, or something else?
• Is there a supported way to un-poison an affected session without starting a new conversation?
• Could the error name the offending field or message, so clients can self-correct instead of losing the session?

[D1ff1culTT]

Update: the failure travels with the message history, not with the session

More data from the same client (AstrBot v4.28.1, deepseek/deepseek-v4-flash, POST /provider/v1/chat/completions):

• Starting a new conversation with the same provider/model works normally.
• Copying the failing conversation's history into that new conversation reproduces the 400 immediately — same error body, new trace_id.

So the trigger is carried by the request content, not by server-side session state. That is consistent with the report above that reverting to earlier messages did not help: whatever trips the 512-candidate cap is still present in the history that gets sent.

Two implications:

1. There is no client-side way to "un-poison" a session other than removing the offending content — a plain "continue" against that history will keep failing, and moving it to a fresh conversation does not help.
2. If the cap is counting expanded paths, then message count, per-message content shape (plain string vs. an array of content parts) and tool count all plausibly contribute to it.