Getting an issue integrating a custom provider: AI_TypeValidationError, failed type validation
AI_TypeValidationError: Type validation failed: Value: {"id":"usage-1753417795","provider_id":"or","model":"qwen3-
coder","usage":{"prompt_tokens":5186,"completion_tokens":35,"total_tokens":5221,"multiplier_applied":2,"prompt_tokens_details":
{"cached_tokens":0,"audio_tokens":0},"completion_tokens_details":{"reasoning_tokens":0,"audio_tokens":0,"accepted_prediction_to
kens":0,"rejected_prediction_tokens":0},"zj_usage":{"multiplier":2,"prompt_cost":10372,"completion_cost":70,"total_cost":10442,
"credits_remaining":282833.449999981}},"request_id":"zj-v1cc-fbf09f7e-8f1d-4d50-b7ae-a1f268cb2d48"}.
Error message:
[{"code":"invalid_union","errors":[[{"expected":"array","code":"invalid_type","path":["choices"],"message":"Invalid input:
expected array, received undefined"}],[{"expected":"object","code":"invalid_type","path":["error"],"message":"Invalid input:
expected object, received undefined"}]],"path":[],"message":"Invalid input"}]
opencode.json
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"zukijourney": {
"npm": "@ai-sdk/openai-compatible",
"options": {
"baseURL": "https://api.zukijourney.com/v1"
},
"models": {
"qwen3-coder": {
"limit": {
"context": 262000,
"output": 2048
}
}
}
}
}
}
Any updates on this? @thdxr or please refer me to the file which causes this, i will fix it
Any updates on this? @thdxr or please refer me to the file which causes this, i will fix it
For what it's worth, the AI_TypeValidationError appears to ultimately come from the vercel/ai dependency.
The issue here seems to be the api not returning things in the correct format, so you need to either change the provider package or maybe use a different endpoint.
@bhaswata08 is this still an issue for u?
Sorry for the extremely late reply @rekram1-node, but yes, this is still an issue for me. This is primarily a provider issue since the provider uses non standard api reply, I would like to be pointed to the right resources to change this if possible.
Thank you
Running into this as well
AI_TypeValidationError: Type validation failed: Value: {"code":"Some resource has been exhausted","error":"Channel xcode-0828-joint-klfix-lap4-unified-qt85b-0 is overloaded: load=581520, num_requests=11"}.
Error message: [{"code":"invalid_union","errors":[[{"expected":"array","code":"invalid_type","path":["choices"],"message":"Invalid input: expected array, received undefined"}],[{"expected":"object","code":"invalid_type","path":["error"],"message":"Invalid input: expected object, received string"}]],"path":[],"message":"Invalid input"}]
Using grok
@kaanyalti looks like that is a 529 from xai but sent as a stream messsage under a 200 status code, we have some logic to handle this can add grok case in too
We have some special parsing for it: https://github.com/sst/opencode/blob/0eb97086fce1283047fd2296fcdbc37b09b4763f/packages/opencode/src/session/retry.ts#L56-L69
Added case for it: https://github.com/sst/opencode/commit/91db82c138cc7ab1e046d078e44e6336669da3a6
@rekram1-node I'm also getting this issue. Did some analysis and i think i know what is going on.
Resource exhaustion errors return error objects instead of the expected OpenAI response structure with choices arrays, causing Zod validation to fail.
The AI_TypeValidationError is coming from the AI SDK's validation layer and the OpenAI response schema expects a choices array, but error responses don't contain this field and in my case the root cause seems to be that when APIs are rate-limited or exhausted, they return error objects instead of the expected success response format.
Note: i get this with the Grok model which is free. I switched to Big Pickle and the problem is gone
@rekram1-node I'm also getting this issue. Did some analysis and i think i know what is going on.
Resource exhaustion errors return error objects instead of the expected OpenAI response structure with choices arrays, causing Zod validation to fail. The
AI_TypeValidationErroris coming from the AI SDK's validation layer and the OpenAI response schema expects a choices array, but error responses don't contain this field and in my case the root cause seems to be that when APIs are rate-limited or exhausted, they return error objects instead of the expected success response format.Note: i get this with the Grok model which is free. I switched to Big Pickle and the problem is gone
can confirm the exact same issue with Opencode Zen Grok Code Fast 1
I'm getting the same error trying to use Cortecs provider and model Devstral 2 2512.
AI_TypeValidationError: Type validation failed: Value: {"status":500,"message":"Internal server error."}.
Error message: [{"code":"invalid_union","errors":[[{"expected":"array","code":"invalid_type","path":["choices"],"message":"Invalid input: expected array, received undefined"}],[{"expected":"object","code":"invalid_type","path":["error"],"message":"Invalid input: expected object, received undefined"}]],"path":[],"message":"Invalid input"}]
That's your provider sending a 500 response as a streamed message that isn't compliant with whatever format ur request goes through, most likely openai compat
@rekram1-node I looked into commit 91db82c and I think I understand why we're still seeing this error.
The problem is with the order of operations. Here's what's happening:
When Grok's API is overloaded, it returns an error response like {"code": "Some resource has been exhausted"}. The Vercel AI SDK tries to validate this response and expects a choices array to be present. Since there's no choices array in the error response, Zod validation fails immediately and throws AI_TypeValidationError. The retry logic in retry.ts never gets a chance to run because the validation error is thrown before we get there.
The commit added handling for the "Some resource has been exhausted" case in the retryable() function, which is great. But that function only gets called if we make it past the validation layer. Since the validation happens first and fails hard on malformed responses, the retry logic is never reached.
I think the issue is that we need to either catch these responses before they hit the Zod validation, or make the validation schema flexible enough to accept both success and error response formats. Right now the validation is too strict and doesn't give the retry logic a chance to do its job. The error gets thrown at the validation layer and never makes it down to where the retry handling actually lives.
A few ways this could be fixed: add a pre-validation step that checks if the response is an error object and handles it accordingly before schema validation runs, or update the Zod schema to accept both success responses with choices an error responses with error codes and route based on which one we got, or wrap the validation in a try-catch that specifically looks for validation errors caused by missing choices arrays and then checks if it's actually a retryable error response.