DeepSeek Harness PI_AI_ERROR: no retry, misfires, 400 lock

If you use a pi-ai-kind route in DeepSeek Harness (DSH) (Codex, OpenRouter, opencode-go, a self-hosted gateway, etc.), you will likely meet a failure where "nothing is broken but it just does not retry": a turn suddenly ends with a generic PI_AI_ERROR, and there is not even one llm/retry line in the log. The cause is not the network but the error classifier: classifyPiAiError is a chain of ordered, unanchored text regexes where the first match wins, and anything unrecognized falls through to the catch-all PI_AI_ERROR; the retry round only handles the five classes EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT. So the four kinds of upstream transient failures that recur in this batch of discussions all fall into the fallback: HTTP/2 stream interruption (upstream_http2_stream_error), Codex server overload and buffer limits (server_error / exceeded request buffer limit), rate limiting stolen by an auth regex (judged AUTH when 401 and 429 appear in the same sentence), and a no-body 400 being judged INVALID_REQUEST after which a long session enters a self-heal-less absorbing state (#9589, #9397, #9502, #9564, #9636, #9352).

DeepSeek Harness mechanism: a plain-text regex classifier + a five-class allowlist

In one sentence: classification depends on "what the text looks like", not "what code the upstream gave", so any upstream wording not in the regex table is classified as the fallback code PI_AI_ERROR, and the fallback code has no retry eligibility — that is the entire reason "transient failures are not retried". Two implementation details determine all the symptoms (#9589):

1. The classifier: classifyPiAiError() is a chain of unanchored (no ^/$) text regexes, matched in order, returning on the first hit; at the end is the catch-all fallback PI_AI_ERROR;
2. The retry round: it retries only the five classes EMPTY_RESPONSE / RATE_LIMIT / SERVER / TIMEOUT / TRANSPORT, and PI_AI_ERROR is not among them.

DeepSeek Harness specific gaps reported in this batch

The thread gives a telling quantification: about half of the pi-ai retryable wordings are invisible to the harness — that is, the "upstream thinks it is retryable" and "DSH thinks it is retryable" tables are drifting apart (#9397).

DeepSeek Harness criteria: how to confirm you hit this family

Two things are enough: whether turn/end carries an assistant/message, and whether there is an llm/retry event.

1. A turn is interrupted by PI_AI_ERROR, and in the log turn/end shows an error end without an assistant output;
2. There is no llm/retry event at all (meaning it never entered the retry round this time);
3. When you switch to a TRANSPORT-class fault you can see records such as retry 5/5 — this comparison best shows the problem is in the classification, not the network (#9564).

DeepSeek Harness fix 1: add the missing codes to the retry allowlist (config layer)

In one sentence: retryableCodes has wholesale replace semantics, so when adding you must write the default five classes together. Write the config in the profile patch file matching the current session mode (cordis.patch.yml), not the outdated settings.yaml (#9694).

1. First confirm which code to add. Look at turn/end's reason.error.code in the log and confirm whether it is PI_AI_ERROR or INVALID_REQUEST (#9694).
2. Write the full list in the profile patch (list the default five together to avoid wholesale replacement squeezing them out):

# ~/.dsh/profiles/<profile>/cordis.patch.yml
- patch:
    id: llm-pi-ai
    config:
      retryPolicy:
        retryableCodes:
          - EMPTY_RESPONSE
          - RATE_LIMIT
          - SERVER
          - TIMEOUT
          - TRANSPORT
          - PI_AI_ERROR        # the fallback code to add this time

3. Restart DSH for the config to take effect, then re-run the request that failed before.
4. Verify: an llm/retry event should appear in the log this time; if it still does not, the code is being intercepted earlier (see the 400 case in the next section) (#9694).
5. Know the cost: PI_AI_ERROR is a fallback code, so adding it to the allowlist means "retry all unrecognized errors", including those that should not be retried. So this is a temporary mitigation, not a long-term answer (#9694).

A confusing point: why can you not find this option in the settings UI? Because the pi-ai adapter's retryPolicy is not marked as editable in the settings UI (only the deepseek adapter shows it), so you can only write the patch by hand (#9694).

DeepSeek Harness fix 2: why a no-body 400 is an "absorbing state"

In one sentence: INVALID_REQUEST is not in the default retryable set, while the automatic recovery from compaction overflow only recognizes CONTEXT_WINDOW_EXCEEDED, and the two do not match — so this state is neither retried nor automatically recovered, and the long session is locked from then on. The symptom is "suddenly every request returns 400 status code (no body)", after which even /compact cannot save it (#9352).

There is a related magnitude problem worth looking at together: some gateways' error bodies are only 31 bytes long, i.e. "a status code with no valid message", so DSH can only treat it as a "bare status code"; the real trigger on opencode-go is prompt_tokens + max_tokens > 2^20 — the request's max_tokens comes from the catalog-declared output cap (for example 384000), while the declared 1M window is larger than the upstream's actual 2^20 limit (#9434).

DeepSeek Harness three-step handling

1. First bring the request volume down: explicitly squeeze maxTokens for that provider/model (one workable value given in the thread is 65536), or compact the history manually with /compact (#9434):

providers:
  <provider>:
    modelOverrides:
      <model>:
        maxTokens: 65536

2. Add INVALID_REQUEST to retryableCodes (the same way as the previous section, noting the wholesale replace semantics), giving this kind of 400 a chance to retry successfully (#9352).
3. Or use a community plugin that reclassifies a no-body 4xx as a retryable error (the thread mentions a similar plugin that reclassifies "no-body 4xx" as EMPTY_RESPONSE, letting the default policy take over) (#9352).
4. Verify: replay the same request and expect this time either success or at least one retry record; if it still fails immediately, there is some other cause (for example a window declaration not matching reality), so go back to step 1 and keep squeezing the volume.

DeepSeek Harness fix 3: don't expect "opening up PI_AI_ERROR wholesale" to be a one-time cure

In one sentence: loosening the whole PI_AI_ERROR to retryable pulls in "errors that should not be retried" and retries them endlessly. The thread stresses this boundary repeatedly (#9397, #9502):

1. The errors it drags along: some state-class errors (for example running, pending) should not be retried in the first place, and retrying only amplifies cost;
2. A neighboring branch with the opposite meaning: the branch near 413 has the opposite meaning to "buffer over limit", and generalizing the match to buffer / too-large conflates the two (#9397);
3. The more stable direction: narrow fixes — map a whole family of upstream code prefixes to TRANSPORT or SERVER (for example the whole upstream_http2_* family, and server_error as its own entry), and keep the branch order, moving the rate-limit branch before the auth branch (#9502, #9636);
4. The upstream already has the capability: the thread mentions that pi-ai itself exports a retryable judgment (isRetryableAssistantError), and switching the DSH side to call it avoids maintaining a second wording table that drifts (#9589).

DSH plugin troubleshooting notes

The mnemonic for this family is: first "is there an llm/retry", then "what is the turn/end code", and only last look at the upstream text. Nine points:

1. No llm/retry means it never entered the retry round, so do not spend effort on "not enough retries" (#9564).
2. The literal meaning of PI_AI_ERROR is "classification failed", not a specific fault (#9589).
3. The two retry tables are drifting: what upstream considers retryable is not equal to what DSH considers retryable, and the magnitude of difference can reach half (#9397).
4. Rate limiting being misjudged as auth is very common; the criterion is "a clearly valid key reported as AUTH" (#9636).
5. INVALID_REQUEST is an absorbing state: no retry + no automatic recovery, so manual intervention is required (#9352).
6. When the error body is truncated (for example only 31 bytes remain), DSH can only treat it as a bare status code, making troubleshooting hard; first solve "why the error body was lost" (#9434).
7. retryableCodes is a wholesale replacement: writing it requires writing the default five classes together (#9694).
8. Not finding this option in the settings UI is normal: the pi-ai adapter's retryPolicy is not exposed to the UI (#9694).
9. State the fix status honestly: the narrow fix of the classifier gaps, the retryability of INVALID_REQUEST, and the mapping of the summary to the upstream code are all unfixed in the versions the discussions refer to; everything given here is user-side config and plugin mitigation, not an official fix.

When troubleshooting this kind of error, ruling out the "plugin layer" variable first often saves half the time — after all, the retry policy, vision attachments, and pricing guard are all plugin-shaped. If you want to see the current environment's plugins and logs at a glance in a UI, rather than typing commands in various places, use a visual plugin marketplace such as DSH Plugin Hub: the installed list, install/uninstall history, and system logs are all in one panel.

Source: Discussion #9589, Discussion #9397, Discussion #9502, Discussion #9564, Discussion #9508, Discussion #9636, Discussion #9434, Discussion #9352, Discussion #9694.