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

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

Configure a custom provider using @ai-sdk/azure with a backend that enforces store: false
Start a new session with GPT-5.5
Send a prompt that triggers multiple tool calls (e.g., any multi-step task requiring 3+ tool invocations)
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.

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

Add @ai-sdk/azure to the npm allowlist in the native runtime status check
Relax the providerID guard to allow custom provider IDs when using a supported npm package
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.

@samuel-pullely

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

@rekram1-node

@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.

@rekram1-node

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

Is there a workaround to make @ai-sdk/azure + store: false work reliably with GPT-5.x today?
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.

Yes that would be amazing :)

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.
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?

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

@rekram1-node

@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.

sweet!

Navigation Menu

Repository navigation

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

Description

Environment

Config (relevant section)

Steps to Reproduce

Analysis

Expected Behavior

Root Cause Analysis

Fix Requirements

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Description

Environment

Config (relevant section)

Steps to Reproduce

Analysis

Expected Behavior

Activity

samuel-pullely commented on May 29, 2026

Root Cause Analysis

Fix Requirements

rekram1-node commented on May 29, 2026

samuel-pullely commented on Jun 2, 2026

samuel-pullely commented on Jun 10, 2026

quantumnic commented on Jun 15, 2026

rekram1-node commented on Jun 16, 2026

rekram1-node commented on Jun 16, 2026

samuel-pullely commented on Jun 17, 2026

rekram1-node commented on Jun 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions