[Resolved / transient] DSH rc.2 openai-codex / gpt-5.6-sol returned overloaded; same session now succeeds

[BoWuGit]

Note

Resolution update (2026-09-03): this no longer reproduces and is being closed as a transient incident. The same DSH session was continued without any User-Agent or request-body shim and completed further gpt-5.6-sol tool steps successfully. DSH is still 0.1.1-rc.2, dsh-llm-pi-ai is still 0.1.1-rc.2, and pi-ai is still 0.82.1; the installed LLM package files match their npm tarballs byte-for-byte, and the OAuth grant did not rotate between failure and success. The failed turn had already completed two tool steps (create_goal, then todo_write) before a later model step returned overloaded; the resumed turn completed get_goal and update_goal. This falsifies the deterministic “legacy tools are rejected” interpretation. The Responses Lite wire difference below is real but was not the established cause. Most likely this was transient provider capacity/routing behavior. The original hypothesis is retained below only as investigation history.

Important

Correction after follow-up: Pi Coding Agent 0.84.4, with its embedded @earendil-works/pi-ai@0.84.4, is currently working normally with openai-codex / gpt-5.6-sol, including multi-step tool calls. Therefore this is not evidence that Pi or pi-ai 0.84.4 is generally broken for Sol. This report is now scoped to the DSH 0.1.1-rc.2 integration path. The Responses Lite source difference is real, but its causal connection to the DSH failure is unproven; a capability gate would be premature without reproducing on stock DSH alpha.4 / pi-ai 0.84.4.

Summary

openai-codex / gpt-5.6-sol agent turns on DSH 0.1.1-rc.2 can terminate with:

Codex error: Our servers are currently overloaded. Please try again later.
failure.code = PI_AI_ERROR

In the observed DSH session, the model first produced a normal response and a create_goal tool call. After the tool result was recorded, the next model request failed before generation with input/output usage both zero. The same account and model complete tool calls in the official Codex CLI 0.146.1.

This has the same visible symptom as #3306 and #3407, but those discussions focus on error classification and retries. There is also a separate request-dialect mismatch: official Codex marks gpt-5.6-sol as a Responses Lite model, while the pi-ai version resolved by this DSH release still emits the legacy top-level instructions and tools request shape.

I am not proposing a User-Agent/header workaround. Local compatibility experiments were removed. After verifying current Pi Coding Agent behavior, Responses Lite should be treated as a diagnostic difference to investigate—not as an established fix or a reason by itself to withhold Sol.

Versions

• DSH: 0.1.1-rc.2
• @deepseek-ai/dsh-llm-pi-ai: 0.1.1-rc.2
• resolved @earendil-works/pi-ai: 0.82.1
• provider/model: openai-codex / gpt-5.6-sol
• reasoning effort: high
• transport: SSE
• comparison client: official Codex CLI 0.146.1

Request-format difference

DSH maps assembled tools to pi-ai Context.tools. pi-ai 0.82.1 then sends top-level instructions and top-level tools, with parallel_tool_calls: true.

Official Codex CLI 0.146.1 marks gpt-5.6-sol with use_responses_lite: true. Its Responses Lite branch instead:

• moves tools to an input item with type: "additional_tools" and role: "developer";
• moves base instructions to a developer message in input;
• omits top-level instructions and tools;
• disables parallel tool calls;
• uses reasoning.context: "all_turns".

A loopback capture of the official CLI request, sent only to a local HTTP server, confirmed this structure without recording credentials, prompt content, tool descriptions, schemas, IDs, or full payloads.

Source references

• DSH pi-ai dependency:

  deepseek-harness/packages/llm/llm-pi-ai/package.json

  Lines 45 to 47 in b150a55

  	"dependencies": {
  	"@earendil-works/pi-ai": "^0.82.1",
  	"@deepseek-ai/schemastery": "workspace:^"

• DSH lock resolving pi-ai 0.82.1:

  deepseek-harness/pnpm-lock.yaml

  Lines 5540 to 5542 in b150a55

  	'@earendil-works/pi-ai':
  	specifier: ^0.82.1
  	version: 0.82.1(@modelcontextprotocol/sdk@1.29.0(zod@4.4.3))(ws@8.21.0)(zod@4.4.3)

• DSH tool-to-context mapping:

  deepseek-harness/packages/llm/llm-pi-ai/src/context.ts

  Lines 116 to 133 in b150a55

  	function toolsOf(options: GenerateOptions): PiTool[] | undefined {
  	return options.tools?.map(tool => ({
  	name: tool.name,
  	description: tool.description,
  	// ToolSchema.parameters is a JSON Schema object; pi-ai's TSchema
  	// (TypeBox) is structurally JSON Schema, so it assigns directly.
  	parameters: tool.parameters,
  	}))
  	}
  	/** Assemble the request-level pi-ai context envelope shared by both conversion paths. */
  	function piContext(options: GenerateOptions, messages: PiMessage[]): PiContext {
  	const tools = toolsOf(options)
  	return {
  	...options.system !== undefined ? { systemPrompt: options.system } : {},
  	messages,
  	...tools !== undefined && tools.length > 0 ? { tools } : {},
  	}

• pi-ai 0.82.1 request builder: https://github.com/earendil-works/pi/blob/v0.82.1/packages/ai/src/api/openai-codex-responses.ts#L516-L567
• official model metadata: https://github.com/openai/codex/blob/rust-v0.146.1/codex-rs/models-manager/models.json#L4-L23
• official Responses Lite builder: https://github.com/openai/codex/blob/rust-v0.146.1/codex-rs/core/src/client.rs#L848-L880
• official Responses Lite test: https://github.com/openai/codex/blob/rust-v0.146.1/codex-rs/core/tests/suite/responses_lite.rs#L84-L133
• related upstream request: Support Responses Lite for GPT-5.6 Codex models earendil-works/pi#6516

Reproduction

1. Start DSH 0.1.1-rc.2 with an existing valid openai-codex OAuth grant.
2. Select openai-codex / gpt-5.6-sol, reasoning effort high.
3. In a fresh session, send a task that causes a normal DSH tool to be called.
4. Observe the request after its tool result, or use a harmless no-op function in an isolated adapter probe.
5. The request can terminate before generation with the overload sentence, PI_AI_ERROR, and zero token usage.
6. Run an equivalent tool task with official Codex CLI on the same account/model; it completes.

Please do not include authorization headers, OAuth grants, request IDs, full system prompts, message content, or complete payloads when reproducing.

Expected behavior

DSH 0.1.1-rc.2 should complete the same Sol tool loop that current Pi Coding Agent 0.84.4 completes. Before proposing a wire change or model gate, the request and behavior should be re-captured on stock DSH alpha.4, which resolves pi-ai 0.84.4.

Questions / suggested direction

• What differs between current working Pi Coding Agent 0.84.4 and the failing DSH 0.1.1-rc.2 integration path (adapter headers, transport options, context/replay conversion, or resolved pi-ai behavior)?
• Can the issue be reproduced on stock DSH alpha.4 / pi-ai 0.84.4 before changing the wire format or adding a capability gate?
• Could the original structured provider error be retained? Classifying the sentence as retryable SERVER (pi-ai adapter: third-party "server_error"/overload responses are not classified as SERVER and never retried #3407) helps real transient overloads, but retries alone cannot correct an incompatible request shape.

The source comparison proves the dialect difference. It strongly matches the tool-dependent failure, but I cannot claim knowledge of the provider's internal routing; a maintainer-owned wire fixture or integration test would make the causal link conclusive.

[argszero]

Good write-up — I traced this against current master (4e84901e64 = dsh 0.1.2-alpha.4) and the upstream pi-ai state, and the answer to your central question is now data-driven: pi-ai has not landed Responses Lite as of 0.84.4, and the upstream issue you linked was auto-closed, not resolved.

Version drift first. Your citations are all from 0.1.1-rc.2 (pi-ai 0.82.1, lock ref b150a551). Alpha.4 declares @earendil-works/pi-ai: ^0.84.2, which resolves to 0.84.4 (2026-08-28). So the dialect you captured with 0.82.1 is not exactly what alpha.4 sends — worth a re-capture against 0.84.4 before drawing the causal line.

Does 0.84.4 support Responses Lite? No. I grepped the pi-ai tree at tag v0.84.4:

• packages/ai/src/api/openai-codex-responses.ts — zero use_responses_lite / responsesLite markers;
• openai-codex.models.ts — no per-model lite flags (no gpt-5.6-sol special-casing);
• the additional_tools item in openai-responses-shared.ts (:323) is the deferred-tools mechanism (on-demand tool loading), not the Responses Lite dialect — different feature, easy to confuse.

Upstream status of your related request (#6516). Auto-closed by github-actions[bot] on 2026-07-11 (new-contributor auto-close). Maintainer @badlogic replied "all those models work fine in pi-ai and the coding agent"; @nhlmg93 pushed back the next day with a compaction error on gpt-5.6-luna. So it is not resolved upstream — at best a disputed "works fine".

What this means for your two options:

1. Wait for pi-ai — no committed timeline; the issue is closed and the maintainer's position is "works fine". Waiting alone will not fix this soon.
2. Capability gate in DSH — this is the actionable path, and the machinery already exists. llm-pi-ai/src/catalog.ts gates each resolved wire protocol through a compat profile (COMPLETIONS_COMPAT_GATE / RESPONSES_COMPAT_GATE :289-296) and already "fails resolution" when a model-level switch its protocol does not take is requested (:334). A codex-models withhold for dialects pi-ai does not yet emit is the same seam as the openRouterRouting withhold (建议在 dsh-llm-pi-ai 开放 OpenRouter 路由锚定（compat.openRouterRouting） #5349) — a small, contained catalog gate rather than a wire-level patch.

On error classification: I agree with your framing — classifying "overloaded" as retryable SERVER (#3407) is correct for genuine transient load, but retries cannot repair an incompatible request shape, and a misleading overload sentence is exactly the kind of error that hides a dialect rejection. The two fixes are complementary: keep the retry classification, add the gate, and treat the causal link as unproven until a maintainer-owned wire fixture or a 0.84.4 re-capture confirms the provider rejects the legacy shape (your loopback method is the right tool for that).

Net recommendation: a catalog capability gate (option 2) is the DSH-side-safe move today, with the gate's failure message naming the unsupported dialect explicitly — so users see a compatibility error instead of an apparent capacity failure. I can sketch that diff if it helps.

[BoWuGit]

Thanks — agreed, and this is an important correction to my original framing.

I verified the actual Pi environment I am using now:

Pi Coding Agent: 0.84.4
embedded @earendil-works/pi-ai: 0.84.4
provider/model: openai-codex / gpt-5.6-sol

Sol works normally there, including multi-step tool calls; this investigation itself is running through that Pi/Sol path. So Pi is not generally broken for Sol, and the absence of explicit Responses Lite markers in pi-ai 0.84.4 does not establish that Responses Lite is required for the model to work.

The official Codex request-shape difference remains a useful diagnostic fact, but I over-weighted it as a causal explanation. The evidence currently supports only the narrower statement: DSH 0.1.1-rc.2 with its resolved pi-ai 0.82.1 integration fails on this machine, while current Pi Coding Agent 0.84.4 succeeds. The remaining cause could be version drift or a DSH-specific adapter/header/transport/context-replay difference.

I have updated the title and added a correction at the top of the report. I also withdraw the capability-gate recommendation for now: the next useful step is exactly your suggestion—reproduce and re-capture on stock DSH alpha.4 / pi-ai 0.84.4 before proposing either a gate or a wire-format change.

[BoWuGit]

Resolution update: the failure no longer reproduces, and the new evidence changes the diagnosis.

The durable session log shows that the failed turn was not rejected merely because tools were present:

turn 12 / step 1: create_goal succeeded
turn 12 / step 2: todo_write succeeded
turn 12 / next model step: overloaded / PI_AI_ERROR

After continuing the exact same session later:

turn 13 / step 1: get_goal succeeded
turn 13 / step 2: update_goal succeeded
turn 13 / step 3: user-aborted (not a provider failure)

Controls checked after success:

• no User-Agent or request-body shim is loaded;
• DSH remains 0.1.1-rc.2;
• dsh-llm-pi-ai remains 0.1.1-rc.2;
• pi-ai remains 0.82.1;
• the installed pi-ai dist and dsh-llm-pi-ai lib trees match their npm tarballs byte-for-byte;
• provider/model remains openai-codex / gpt-5.6-sol, effort high, transport SSE;
• the OAuth access grant did not rotate between the failure and the successful continuation.

npm install -g @deepseek-ai/dsh@latest reinstalled the same rc.2 version, so its timing is correlation rather than evidence of a protocol fix. A fresh process and other transitive/runtime changes are confounders, but the strongest current explanation is transient provider capacity/routing behavior.

I am withdrawing the deterministic Responses Lite/tool-rejection hypothesis and the capability-gate suggestion. The official Responses Lite source difference remains true, but this incident does not establish it as causal. Closing as no longer reproducible; it can be reopened if a controlled stock reproduction returns.