Tool calls throw errors for Mistral's GLM-5.2

[KPhi]

Description

Recently, Mistral has started hosting third-party open models from other providers, starting with GLM-5.2. When manually adding this model to the mistral provider, text responses work fine, but as soon as tools are called, the response validation throws an error:

AI_TypeValidationError: Type validation failed: Value: {"id":"0d56b68eea734ccd983ea66a85ad7781","object":"chat.completion.chunk","created":1787036970,"model":"zai-glm-5-2","choices":[{"index":0,"delta":{"tool_calls":[{"type":"function","function":{"name":"","arguments":"C:\\workspace"},"index":0}],"index":0,"content":""},"finish_reason":null,"logprobs":null}]}.
Error message: [
  {
    "expected": "string",
    "code": "invalid_type",
    "path": [
      "choices",
      0,
      "delta",
      "tool_calls",
      0,
      "id"
    ],
    "message": "Invalid input: expected string, received undefined"
  }
] (cause: [
  {
    "expected": "string",
    "code": "invalid_type",
    "path": [
      "choices",
      0,
      "delta",
      "tool_calls",
      0,
      "id"
    ],
    "message": "Invalid input: expected string, received undefined"
  }
])

Plugins

No response

OpenCode version

1.18.18

Steps to reproduce

1. Add Mistral manually to the plugins section in the configuration and define the zai-glm-5-2 model there (see below for example).
2. Start a session and select the new model
3. See an error as soon as a tool is called

opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "mistral": {
      "name": "Mistral (custom)",
      "npm": "@ai-sdk/mistral",
      "models": {
        "zai-glm-5-2": {
          "name": "GLM-5.2",
          "attachment": true,
          "reasoning": true,
          "temperature": true,
          "tool_call": true,
          "limit": {
            "context": 1000000,
            "output": 131072
          },
          "modalities": {
            "input": [
              "text"
            ],
            "output": [
              "text"
            ]
          },
          "variants": {
            "high": {
              "reasoningEffort": "high"
            }
          }
        },
      }
    }
  }
}

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

Windows Terminal

[github-actions]

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

• Custom OpenAI-compatible provider: "Expected 'function.name' to be a string" on streaming tool call chunks #26412: Same root cause — AI SDK streaming validator rejects non-standard tool call chunk fields from custom/compatible providers (function.name: null there vs tool_calls[N].id: undefined here). Both are caused by the strict per-chunk schema validation in the AI SDK rejecting provider responses that deviate from the OpenAI spec.

If your issue is distinct, feel free to keep it open — but reviewing #26412 may help clarify whether these share a fix path.

[opencode-agent]

For this model, use the OpenAI-compatible Chat Completions SDK at the model level:

"zai-glm-5-2": {
  "provider": {
    "npm": "@ai-sdk/openai-compatible"
  },
  // ...the rest of the model definition
}

This keeps the Mistral provider's API URL and credentials, still sends model: "zai-glm-5-2", and uses the Chat Completions stream parser that supports incremental tool-call deltas. Keep this override inside the model definition; setting npm on the top-level Mistral provider would change the SDK for every Mistral model.

[Crazyphil]

This alone didn't work, because I get a different ValidationError with the @ai-sdk/openai-compatible provider. I had to create a custom plugin that modifies the messages to get it to work:

Here's how to use GLM-5.2 on Mistral:

1. Define an OpenAI provider in opencode.jsonc (or define the provider only for the individual model as the agent above has suggested):

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "mistral-openai": {
      "name": "Mistral (OpenAI)",
      "npm": "@ai-sdk/openai-compatible",
      "models": {
        "zai-glm-5-2": {
          "name": "GLM-5.2",
          "attachment": true,
          "reasoning": true,
          "temperature": true,
          "tool_call": true,
          "limit": {
            "context": 1000000,
            "output": 131072
          },
          "modalities": {
            "input": [
              "text"
            ],
            "output": [
              "text"
            ]
          }
        }
      },
      "options": {
        "baseURL": "https://api.mistral.ai/v1"
      }
    }
  }
}

2. Connect the new provider using /connect and enter the Mistral API key
3. Copy the plugin file mistral-glm-model.ts into directory ~/.config/opencode/plugins/ (note the file extension .ts), where it will be picked up automatically on the next restart of OpenCode without additional configuration

---

Anyone wanting to fix the bug in the OpenCode source can use the plugin's source to figure out what has to be filtered in the responses to get the model to work.

1. delta.content may arrive as an array of structured parts
   (e.g. [{type:"thinking", thinking:[{type:"text", text:"..."}], closed:true}]).
   The SDK schema requires content: z.string().nullish(), so we flatten
   it: text parts → concatenated string for content, thinking parts →
   concatenated string for reasoning_content.
2. Tool-call chunks may arrive without an id field on continuation
   fragments. The SDK schema marks id as nullish so missing ids pass
   validation, but the streaming tool-call tracker throws if the first
   delta carrying function.name has no id. We ensure every tool-call
   delta with a name carries a stable, unique id.

Additionally, the outgoing request body is rewritten so assistant reasoning
is sent back in Mistral's ThinkChunk content-array format (Mistral rejects
reasoning_content on incoming requests with HTTP 422).

The plugin injects a custom fetch only into providers that (a) have
@ai-sdk/openai-compatible as their npm package, (b) have a provider id
containing "mistral", and (c) define the zai-glm-5-2 model.

[rekram1-node]

Lol so mistral is sending completely custom stuff that isnt compliant with the protocols at all? oof

[JulienCorb]

@rekram1-node I think this is a Z ai issue in the first place (see #32172 "what needs to happen .5"), but mistral says the model is served by them without modifications : https://docs.mistral.ai/models/zai-glm-5-2

[RayBB]

If anyone is willing/able to fix this (get a PR merged in) I can hook you up with a code so you can have $50 in credits on Mistral.

[Hieraaetus-moorei]

@Crazyphil
Thank you so much, but there are a tad bugs in the instruction you provided:

1. opencode.jsonc missed one } at the end (probably copy-paste issue). Correct version:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "mistral-openai": {
      "name": "Mistral (OpenAI)",
      "npm": "@ai-sdk/openai-compatible",
      "models": {
        "zai-glm-5-2": {
          "name": "GLM-5.2",
          "attachment": true,
          "reasoning": true,
          "temperature": true,
          "tool_call": true,
          "limit": {
            "context": 1000000,
            "output": 131072
          },
          "modalities": {
            "input": [
              "text"
            ],
            "output": [
              "text"
            ]
          }
        }
      },
      "options": {
        "baseURL": "https://api.mistral.ai/v1"
      }
    }
  }
}

2. I don't know if it's just me, but mistral-glm-model.js will cause build error.
   I changed its extension to .ts then it works.
   I.e. grab mistral-glm-model.js and rename it as mistral-glm-model.ts

Anyway, thank you for the workaround since opencode feels much better than Mistral's official cli tool.

[Crazyphil]

I've extracted the content from my (much longer) config file, and I had to rename the file to upload it to GitHub (it allows JS files but not TS 🤷). However, I've edited and corrected my comment - thanks for pointing them out!

[pedrxd]

Opencode2 is working properly https://opencode.ai/v2/docs

[lloeki]

I've tightened the workaround a bit (using GLM 5.2 on OpenCode v1), here's a gist: https://gist.github.com/lloeki/e3c0d15ad1d0964e42efde1f7cf44e07

Also opened #47954 to fix v1.