Is it a request payload issue?
[x] Yes, this is a request payload issue. I am using a client/cURL to send a request payload, but I received an unexpected error.
[ ] No, it's another issue.

If it's a request payload issue, you MUST know
Our team doesn't have any GODs or ORACLEs or MIND READERs. Please make sure to attach the request log or curl payload.

Describe the bug
When using /v1/responses with multi-provider fallback/switching, the request fails with HTTP 400 invalid_encrypted_content after switching upstream from OpenAI to Azure OpenAI.
It appears that reasoning.encrypted_content generated under one provider is forwarded to another provider, where it cannot be verified/decrypted.

CLI Type
opencode/codex same issue.

Model Name
gpt-5.3-codex

LLM Client
codex

Request Information
Reproducible request shape (simplified):

{
  "method": "POST",
  "url": "/v1/responses",
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "model": "gpt-5.3-codex",
    "input": [
      {
        "role": "developer",
        "content": "..."
      },
      {
        "role": "user",
        "content": [
          {
            "type": "input_text",
            "text": "Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed."
          }
        ]
      },
      {
        "type": "reasoning",
        "encrypted_content": "gAAA...6W4="
      }
    ]
  }
}

Observed error:

{
  "error": {
    "message": "The encrypted content gAAA...6W4= could not be verified. Reason: Encrypted content could not be decrypted or parsed.",
    "type": "invalid_request_error",
    "param": null,
    "code": "invalid_encrypted_content"
  }
}

Typical response headers:

• Status: 400
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
• Access-Control-Allow-Headers: *
• Content-Type: application/json
• Access-Control-Allow-Origin: *

Expected behavior
When provider switching occurs (e.g., OpenAI -> Azure OpenAI), the gateway should not forward incompatible reasoning.encrypted_content across providers.
Expected outcomes:

• either automatically strip reasoning.encrypted_content on provider switch,
• or return a clear recoverable message instructing client to reset continuation context.

Screenshots
N/A

OS Type

• OS: Docker
• Version: v6.8.38

Additional context
This happens during provider failover/rotation scenarios (e.g., OpenAI exhausted -> switch to Azure OpenAI).
The same conversation continuation may succeed before switching, then fail immediately after switching with invalid_encrypted_content.