AI_InvalidResponseDataError: Expected 'id' to be a string — models returning integer tool_call IDs cause crash

[vfamim]

Bug

When using models that return tool_call.id as an integer (e.g., NVIDIA's z-ai/glm-5.1), the Vercel AI SDK raises:

AI_InvalidResponseDataError: Expected 'id' to be a string.

This makes all MCP tool calls fail with this model (and potentially others that return numeric IDs).

Root Cause

The @ai-sdk/openai-compatible provider validates that tool_call.id is a string (per the OpenAI API spec), but some models — notably nvidia/z-ai/glm-5.1 — return integer IDs in their chat completion responses. The AI SDK's transform function in the OpenAI-compatible provider throws AI_InvalidResponseDataError before any coercion happens.

Steps to Reproduce

1. Configure opencode with the NVIDIA provider and model nvidia/z-ai/glm-5.1
2. Trigger any MCP tool call (e.g., NotebookLM, Context7, etc.)
3. The model returns a tool_call with id as a number
4. AI SDK rejects it: Expected 'id' to be a string

Expected Behavior

The AI SDK should coerce numeric tool_call.id values to strings (String(id)) before validation, since the semantic meaning is identical and this is a common divergence from the OpenAI spec among third-party models.

Workaround

Switch to a model that returns proper string IDs, e.g.:

"model": "nvidia/qwen/qwen3-coder-480b-a35b-instruct"

Environment

• opencode: 1.14.34
• Provider: NVIDIA (via @ai-sdk/openai-compatible)
• Model: nvidia/z-ai/glm-5.1
• Stack trace location: chunk-t9xac7k9.js (bundled AI SDK runtime)

Suggested Fix

In the @ai-sdk/openai-compatible provider's response transform, add a coercion step:

// Before validation
if (typeof toolCall.id === 'number') {
  toolCall.id = String(toolCall.id);
}

This would handle the divergence without breaking spec-compliant models.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• NVIDIA NIM kimik2.5 returns numeric tool call IDs causing 'expected id to be a string' error #19947: Same bug — NVIDIA NIM model returning numeric tool call IDs causes the same expected id to be a string error

If this is indeed a duplicate, please close this issue and continue discussion in the linked one.