[Bug] @ai-sdk/azure Responses API: encrypted content verification fails after 3-4 tool-calling turns (store: false)

[samuel-pullely]

Description

Using @ai-sdk/azure with the Responses API in stateless mode (store: false enforced server-side), multi-turn sessions consistently fail after 3-4 tool-calling turns with:

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

This happens on a fresh session with GPT-5.5 (gpt-5.5-2026-04-24) after just a few tool calls. It's 100% reproducible.

Environment

• OpenCode v1.15.12
• Provider: @ai-sdk/azure with custom baseURL pointing to an Azure OpenAI-compatible gateway
• Model: gpt-5.5-2026-04-24
• store: false enforced by the backend (stateless mode, no data retention)
• Responses API endpoint: /responses?api-version=2025-04-01-preview

Config (relevant section)

{
  "npm": "@ai-sdk/azure",
  "options": {
    "baseURL": "http://localhost:9000/openai",
    "apiKey": "key",
    "apiVersion": "2025-04-01-preview"
  },
  "models": {
    "gpt-5.5-2026-04-24": {
      "name": "GPT-5.5",
      "modalities": {
        "input": ["text", "image"],
        "output": ["text"]
      }
    }
  }
}

Steps to Reproduce

1. Configure a custom provider using @ai-sdk/azure with a backend that enforces store: false
2. Start a new session with GPT-5.5
3. Send a prompt that triggers multiple tool calls (e.g., any multi-step task requiring 3+ tool invocations)
4. After 3-4 successful Responses API round-trips, the next request fails with invalid_encrypted_content

Analysis

PRs #28678 and #29000 fixed similar issues for the @ai-sdk/openai path (preserving native continuation metadata, splitting reasoning summary blocks). However, these fixes may not cover the @ai-sdk/azure code path.

The @ai-sdk/azure SDK's createResponsesModel is used (default provider.languageModel), and include: ["reasoning.encrypted_content"] is set by OpenCode's transform layer. The encrypted blob returned in one response is passed back in subsequent requests but becomes unverifiable after a few turns.

Possibly related closed issues:

• [Bug] OpenAI Responses store:false can replay stale reasoning from older turns #21020 (store:false replays stale reasoning)
• Cannot fix "the encrypted content <b64 content> could not be verified" for old session #10585 (encrypted content verification failure)

Expected Behavior

Multi-turn sessions with tool calling should work beyond 3-4 turns without encrypted content verification failures when using @ai-sdk/azure with store: false.

[samuel-pullely]

Root Cause Analysis

The native LLM runtime (packages/llm) which properly handles encrypted content continuations via openai-responses.ts (PRs #28678, #29000) does not activate for @ai-sdk/azure.

In packages/opencode/src/session/llm/native-runtime.ts, lines 46-51:

const providerID = input.model.providerID
if (providerID !== "openai" && providerID !== "anthropic" && !providerID.startsWith("opencode"))
  return { type: "unsupported", reason: "provider is not openai, opencode, or anthropic" }
const npm = input.model.api.npm
if (npm !== "@ai-sdk/openai" && npm !== "@ai-sdk/openai-compatible" && npm !== "@ai-sdk/anthropic")
  return { type: "unsupported", reason: "provider package is not OpenAI, OpenAI-compatible, or Anthropic" }

Both guards reject @ai-sdk/azure. This causes the session to fall back to the AI SDK's streamText() path (via ai-sdk.ts), which doesn't properly manage encrypted content round-tripping in store: false mode.

Fix Requirements

1. Add @ai-sdk/azure to the npm allowlist in the native runtime status check
2. Relax the providerID guard to allow custom provider IDs when using a supported npm package
3. Support api-version query param — the native openai-responses protocol sends to {baseURL}/responses without query params, but Azure requires ?api-version=2025-04-01-preview. The Endpoint layer supports query fields but there's currently no path for model/provider options to inject them.

Points 1-2 are trivial. Point 3 requires changes in the route/endpoint layer to allow provider options (like apiVersion) to flow through as query parameters on the endpoint.

[rekram1-node]

@samuel-pullely the native llm runtime is opt in and experimental

[samuel-pullely]

@rekram1-node Thanks for the response. Just to clarify — are you saying that @ai-sdk/azure with the Responses API isn't a fully supported configuration yet, and the encrypted content issue is a known limitation? Or is there something else I should look at on my side?

For context: the non-native AI SDK fallback path is what's being used here (since the native runtime rejects @ai-sdk/azure), and it breaks consistently after 3-4 tool-calling turns with store: false.

Is there a recommended workaround or configuration to make this work reliably? We're using this in an enterprise context where @ai-sdk/azure is the only option (all traffic routes through an Azure OpenAI-compatible gateway that enforces store: false). Without a fix, GPT-5.x models are effectively unusable from within OpenCode for anything beyond trivial single-turn requests.

[samuel-pullely]

@rekram1-node ping — any guidance on this? Specifically:

1. Is there a workaround to make @ai-sdk/azure + store: false work reliably with GPT-5.x today?
2. Are there plans to add @ai-sdk/azure to the native runtime allowlist?

As it stands, we can't use GPT-5.5 within our enterprise setup with OpenCode until this is resolved.

[quantumnic]

Yes that would be amazing :)

[rekram1-node]

1. The @ai-sdk/azure has nothing to do w/ the native llm runtime, the @ai-sdk/azure is used for the ai sdk which is the default code path and like i said just basically ignore the fact that native llm exists rn.
2. We set store: false by default I thought...

Can u send me a session where u encounter this? Because i am unable to replicate at all. Try: opencode export > session.json and send me the file

Oh i think it's cause u arent using the azure provider, why arent u using the azure provider btw?

[rekram1-node]

What version are u using? On any of the newer releases this should never happen

[samuel-pullely]

@rekram1-node Thanks for looking into this and for the pointer — you were right, this isn't an opencode issue.

The root cause turned out to be our upstream LLM gateway's load balancer routing follow-up requests to a different Azure region. Since encrypted reasoning tokens are region/account-specific, cross-region routing breaks the chain with the "encrypted content could not be decrypted" error.

Our gateway team has since shipped a session-pinning mechanism (X-Target-Id header) that we'll integrate in our proxy layer to ensure related requests hit the same deployment.

Apologies for the noise — closing this out.

[rekram1-node]

sweet!