Testei com stream false e true. O Erro é recebido nas duas configurações no opencode.json

Pedi o deepseek para analisar o erro. De repente, te ajuda a encontrar onde o problema. Primeiro, vou colar o erro que recebo ao conversar com o Giga-token. E depois o que o deepseek falou (troquei de modelo).

Pergunta ao giga-token: você está online?

Resposta do giga-token:Sim, estou online e pronto para ajudar.

Abaixo da resposta do giga-token vem o erro:

Type validation failed: Value: {"id":"chat*cmpl-bea967ac305add26006cd6ee","object":"chat.completion.chunk","created":1782214846,"model":"glm-4.7","choices":[{"index":0,"delta":[],"finish_reason":"stop"}]}. Error message: [ { "code": "invalid_union", "errors": [ [ { "expected": "object", "code": "invalid_type", "path": [ "choices", 0, "delta" ], "message": "Invalid input: expected object, received array" } ], [ { "expected": "object", "code": "invalid_type", "path": [ "error" ], "message": "Invalid input: expected object, received undefined" } ] ], "path": [], "message": "Invalid input" } ]

Resposta do deepseek:

O problema está claro: a Giga Token está retornando a resposta streaming final com "delta": [] (array vazio) em vez de "delta": {} (objeto vazio), que é o formato OpenAI esperado.
Causa raiz:
No último chunk do streaming (finish_reason: "stop"), a API da Giga Token envia:
"delta": []
Mas o formato OpenAI-compatible espera:
"delta": {}
O validador do opencode rejeita o array e espera um objeto, daí o erro "Invalid input: expected object, received array".
Soluções possíveis:

1. Reportar pra Giga Token — o bug está no lado deles, o delta final deveria ser {} e não [].
2. Desabilitar streaming — se você não precisa de streaming, mude "stream": false (ou remova a linha) no opencode.json. (Edit meu: Testei e nao resolveu o problema)
3. Aguardar fix do opencode — se o opencode tratar esse caso como tolerância a erro do provider."

Fiz mais algumas analises aqui e consegui contornar o erro usando um script. Mas no final, não deu pra usar com opencode pq o modelo não chama ferramentas. Mandei o deepseek fazer um resumo para tentar ajudar:

Contexto: Usando Open WebUI com provedor GigaToken (API: https://api.giga-token.com/rest/V1) modelo GLM-4.7. Criamos um proxy local para corrigir o formato do "delta":[] que a API retorna no lugar de "delta":{} nos chunks finais do streaming.
Regressão identificada: O function calling não funciona. O Open WebUI envia corretamente "tools" no body da requisição, mas o modelo/API ignora e responde apenas com texto simples (finish_reason:"stop"), sem nunca chamar as ferramentas disponíveis.
Exemplo concreto:

• Prompt: leia o arquivo README.MD e ajude a planejar um ERP
• Request 1 (sem tools, primeira chamada): resposta "Plano de implementação ERP" — sem tool call
• Request 2 (com tools, retorno do resultado do ReadFile executado localmente): resposta "Lendo o arquivo README.MD..." — sem tool call também
  Evidência:
  [1] body received (2530 bytes, tools:undefined, tool_choice:auto, last_msg:user)
  [2] body received (33552 bytes, tools:true, tool_choice:true, last_msg:user)
  Ambas as respostas retornam apenas delta.content com texto, finish_reason:"stop". O modelo nunca retorna tool_calls no delta.
  Problemas adicionais:
• Streaming retorna "delta":[] (array vazio) no último chunk — formato inválido, deveria ser "delta":{} (objeto vazio). Isso quebra validadores de schema no cliente.
• Streaming demora ~20-25s para iniciar a resposta (TTFT alto).