openclaw - 💡(How to fix) Fix Cross-provider reasoning_content → thought_signature serialization error when switching from DeepSeek to Google Gemini

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When DeepSeek v4 Flash responds in a session, its reasoning_content thinking data is stored in the session history. If the next message in the same session is routed to Google Gemini (via fallback or primary model switch), the serialized session history passes the DeepSeek reasoning_content field to Gemini as a thought_signature field. Gemini's API expects thought_signature to be Base64-encoded bytes and fails with a 400 error: "Invalid value at 'contents[N].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for 'reasoning_content'". This blocks the request and triggers fallback retries that can also hit rate limits.

Steps to reproduce

1. Configure OpenClaw 2026.5.20 with primary model as deepseek/deepseek-v4-flash (contextCaching not required but used).
2. Send a message that gets answered by DeepSeek (any message triggering a thinking/reasoning response).
3. Configure fallback chain or manually switch to google/gemini-3.1-pro-preview.
4. Send another message in the same session.
5. Observe: Gemini API returns 400 error. Log shows: "Invalid value at 'contents[N].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for 'reasoning_content'".

Expected behavior

Session history should sanitize or strip provider-specific thinking/reasoning fields (e.g., reasoning_content from DeepSeek, thought_signature from Gemini) when serializing for a different provider. The Google Gemini provider should receive clean contents arrays without cross-contaminated thinking metadata. If cross-provider thinking handoff is not feasible, the session serializer should at minimum omit or convert the reasoning_content field so it does not appear as an invalid thought_signature in the Gemini request.

Actual behavior

Google Generative AI API returns 400 error: "Invalid value at 'contents[N].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for 'reasoning_content'". This causes the request to fail, triggering OpenClaw's fallback chain. In our case, 25 occurrences of this 400 error were observed on a single day across WhatsApp and cron job sessions. Additionally, the retry loop from repeated 400 errors can consume API quota, resulting in secondary 429 rate-limit errors (also 25 occurrences in the same period).

OpenClaw version

2026.5.20 (e510042)

Operating system

macOS (Darwin 25.5.0 arm64)

Install method

npm global (via Homebrew node@24)

Model

deepseek/deepseek-v4-flash (primary, with contextCaching) → google/gemini-3.1-pro-preview (via fallback or manual model switch)

Provider / routing chain

openclaw → deepseek (openai-completions) → fallback to google (google-gemini-cli provider, gemini-3.1-pro-preview)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Error log (redacted):

Google Generative AI API error (400): Invalid value at 'contents[10].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for "reasoning_content" [code=INVALID_ARGUMENT]

Google Generative AI API error (400): Invalid value at 'contents[1].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for "reasoning_content" [code=INVALID_ARGUMENT]

Google Generative AI API error (429): Resource has been exhausted (e.g. check quota). [code=RESOURCE_EXHAUSTED]

Observed 25 occurrences of the 400 error and 25 occurrences of the 429 error across WhatsApp and cron sessions on 2026-05-24.

Impact and severity

Affected: Any user with both DeepSeek (or other reasoning models returning reasoning_content) and Google Gemini in their model fallback chain or session. Blocks all Gemini responses in sessions that previously received DeepSeek answers. Severity: High — blocks Gemini provider from functioning after deepseek reasoning responses in the same session. Frequency: Always reproducible (every time a session has DeepSeek's reasoning in history and Gemini is invoked next). Consequence: Google Gemini becomes unusable in mixed-provider sessions. Repeated fallback retries consume API quota, leading to secondary rate-limit errors. Users must manually clear session history or avoid using multiple providers in the same session.

Additional information

Related issues:

• #75105 — Per-model reasoning_content setting (cross-provider model routing enhancement, closely related)
• #85192 — DeepSeek V4 unsigned thinking blocks (same code path, isSignedThinkingBlock / assessLastAssistantMessage)

Current workaround (effective): Restrict models to a single provider per session. We moved to deepseek/deepseek-v4-flash as primary for all channels and cron jobs.

The bug is likely in the session history serialization layer — when serializing a DeepSeek assistant response that contains reasoning_content into the next request's contents array for a different provider, the field should be either omitted or transformed into the target provider's expected format.