Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openai-completions-compat.ts and openai-completions.ts disagree about which endpoints need requiresReasoningContentOnAssistantMessages. The agent-layer compat covers both DeepSeek and Xiaomi AI Studio endpoints; the provider-layer auto-detect (detectCompat) only covers DeepSeek. Xiaomi multi-turn sessions that go through the provider layer without the agent transport will not inject the required empty reasoning_content field on replayed assistant messages, causing the provider API to reject the request.

Steps to reproduce

1. Configure an OpenClaw model using api: "openai-completions" pointed at a Xiaomi AI Studio (MiModel) endpoint:

   models:
     providers:
       - type: openai-completions
         apiUrl: "https://api.ai.xiaomi.com/v1"
         models:
           - id: "MiMo-7B-RL"

2. Start a multi-turn conversation session that triggers assistant-message replay (second+ turn of a reasoning session).
3. Observe: Xiaomi API returns a validation error because replayed assistant messages lack the required reasoning_content field.

Rolling back to route the same endpoint through openai-transport-stream.ts (i.e., through an agent with useTransportStream: true) bypasses the bug because the agent layer's openai-completions-compat.ts correctly sets requiresReasoningContentOnAssistantMessages: true for endpointClass === "xiaomi-native".

Expected behavior

detectCompat in openai-completions.ts should return requiresReasoningContentOnAssistantMessages: true for Xiaomi-native endpoints, consistent with the agent-transport layer.

Actual behavior

detectCompat in openai-completions.ts only returns requiresReasoningContentOnAssistantMessages: isDeepSeek. Xiaomi endpoints are not covered.

Code pointers (analysis, not observed)

Divergence found at:

• src/agents/openai-completions-compat.ts — agent-layer compat auto-detect:

  requiresReasoningContentOnAssistantMessages: isDeepSeek || isXiaomi,

  where isXiaomi = endpointClass === "xiaomi-native" || endpointClass === "xai-native".

• src/llm/providers/openai-completions.ts — provider-layer detectCompat:

  requiresReasoningContentOnAssistantMessages: isDeepSeek,

  isXiaomi is absent.

The two files serve different call paths. openai-completions-compat.ts feeds the transport-stream layer (src/agents/openai-transport-stream.ts) which our PR #89832 now correctly wires through getCompat. openai-completions.ts's detectCompat is used when the provider is called without the higher-level transport (e.g., tool-result or completion-only code paths). For Xiaomi endpoints in that lower path, the field remains false and assistant-message replay omits reasoning_content.

The divergence was likely introduced when isXiaomi was added to openai-completions-compat.ts without a corresponding update to detectCompat in openai-completions.ts.

This pattern mirrors the original requiresReasoningContentOnAssistantMessages schema gap fixed in PR #89832 (issue #89660), but at the auto-detection layer rather than the configuration layer.

Proposed fix options

Option A (preferred): Add isXiaomi to openai-completions.ts detectCompat, matching the agent-compat logic:

// src/llm/providers/openai-completions.ts — detectCompat
requiresReasoningContentOnAssistantMessages: isDeepSeek || isXiaomi,  // add isXiaomi

Requires importing or replicating the endpointClass === "xiaomi-native" || "xai-native" check already present in openai-completions-compat.ts.

Option B: Extract a shared requiresReasoningContent(model) utility used by both files, so the set of affected endpoints stays in one place and can't diverge again.

Option C: Document that detectCompat in openai-completions.ts intentionally omits Xiaomi (if these endpoints always go through the transport-stream path). Add a test assertion confirming Xiaomi endpoints are never reached through the provider path without the transport-stream intermediary.

Analysis derived from static code search; live reproduction with a Xiaomi AI Studio API key was not performed. Root cause confidence: high (direct code comparison); user impact scope: limited to Xiaomi AI Studio endpoints using the openai-completions provider type without the agent transport layer.

This issue was investigated by an automated contributor (openclaw-cron). Analysis follows the #89832 fix; the reviewer who merged that PR may have context on the intended call-path separation between openai-completions-compat.ts and openai-completions.ts. If the gap is by design, please close with a brief note — it would clarify the architecture for future contributors.