openclaw - 💡(How to fix) Fix Custom providers cannot use Responses API reasoning params (multiple hardcoded guards) [1 participants]

Summary

When using a custom provider with api: "openai-responses", reasoning parameters (params.thinking: "high") are silently ignored. The request reaches the provider but with reasoning: { effort: "none" } instead of { effort: "high" }.

This affects any custom provider (e.g. load balancers like litellm, one-api, or similar proxies) that needs Responses API + reasoning support.

Root Cause (3 layers)

1. ensureCustomApiRegistered guard blocks custom provider streamFn registration

In the bundled dist (anthropic-vertex-stream-*.js), ensureCustomApiRegistered() calls getApiProvider(api) first — if the API name (e.g. openai-responses) is a built-in, it returns false immediately without registering the custom provider's streamFn.

function ensureCustomApiRegistered(api, streamFn) {
  if (getApiProvider(api)) return false; // ← blocks custom providers for built-in APIs
  registerApiProvider({ api, stream: ..., streamSimple: ... }, ...);
  return true;
}

2. supportsOpenAIReasoningCompatPayload hardcodes provider names

In provider-attribution-*.js, reasoning payload compatibility is gated by:

provider === "openai" || provider === "openai-codex" || provider === "azure-openai" || provider === "azure-openai-responses"

Custom providers are excluded even when they proxy to OpenAI-compatible endpoints.

3. Field name mismatch: options.reasoning vs options.reasoningEffort

pi-agent-core's Agent.createLoopConfig() maps thinkingLevel to options.reasoning:

// pi-agent-core/dist/agent.js
reasoning: this._state.thinkingLevel === "off" ? undefined : this._state.thinkingLevel,

But the embedded buildOpenAIResponsesParams() only checks options.reasoningEffort:

if (options?.reasoningEffort || options?.reasoningSummary) { ... }

The native provider in pi-ai (openai-responses.js) does the mapping correctly:

const reasoningEffort = supportsXhigh(model) ? options?.reasoning : clampReasoning(options?.reasoning);

But the embedded version in the dist bundle skips this conversion, so options.reasoning: "high" is never picked up.

Additional requirement

The model definition must have reasoning: true — otherwise if (model.reasoning) skips the entire reasoning block regardless of params.

Steps to Reproduce

1. Configure a custom provider with api: "openai-responses"
2. Set agents.defaults.models["custom/model"].params.thinking: "high"
3. Set reasoning: true in the model definition
4. Send a message — observe that the proxied request has reasoning: { effort: "none" } or no reasoning field

Expected Behavior

Custom providers using openai-responses should be able to use reasoning params the same way built-in OpenAI providers do.

Workaround

Patch 3 files in the dist bundle (lost on upgrade):

1. anthropic-vertex-stream-*.js: Comment out getApiProvider(api) guard + add options.reasoning fallback
2. provider-attribution-*.js: Add custom provider name to supportsOpenAIReasoningCompatPayload
3. pi-embedded-*.js: Add streamOpts.reasoning fallback in WebSocket path

Related

• #43018 (custom providers + openai-responses transport bug — covers the WebSocket routing issue but not the reasoning params issue)

Environment

• OpenClaw version: 2026.4.5
• Provider: custom (OpenAI-compatible proxy)
• API: openai-responses