Guia prático do GLM-5.3: pensamento sempre ativo, três níveis de esforço e matriz de suporte das APIs

Título: Guia Prático do GLM-5.3: Pensamento Sempre Ativo, Três Níveis de Esforço & Matriz de Suporte de API

Descrição: Guia do GLM-5.3 de agosto de 2026: pensamento sempre ativo com três níveis de reasoning_effort, resumos de raciocínio, chamadas de ferramentas paralelas, saída estruturada e cache automático, com exemplos verificados para as APIs Chat / Responses / Messages da AIHubMix.

Este artigo aborda as principais mudanças de API e observações de uso do GLM-5.3. O GLM-5.3 é o modelo principal da Z.ai lançado em 2026-08-14. Ele usa exatamente o mesmo modelo base do GLM-5.2, com todos os ganhos vindo do pós-treinamento. Na AIHubMix, o ID do modelo é coding-glm-5.3 (atualmente uma rota de prévia por tempo limitado), disponível pelas APIs Chat Completions, Responses e Messages compatível com Claude. Veja também: o blog oficial de lançamento da Z.ai.

As conclusões "Verificado" e as respostas de exemplo em cada seção vêm de chamadas reais feitas em 2026-08-14 pelas APIs da AIHubMix (Chat Completions / Responses / Messages).

1. Especificações do Modelo em Resumo

Verificado: max_tokens: 999999 retorna 400 com o intervalo válido descrito no corpo do erro. O teto é realmente validado, não truncado silenciosamente.

# max_tokens=999999 -> HTTP 400
"max_tokens parameter invalid: value must be within [1,131072]"

2. GLM-5.3 vs GLM-5.2: Pensamento Sempre Ativo, Intensidade via reasoning_effort

Estas são as duas mudanças de API mais importantes do GLM-5.3 em relação ao GLM-5.2:

1. thinking.type não aceita mais disabled: o pensamento não pode ser desligado. A orientação oficial de migração é que aplicações que enviavam {"type": "disabled"} passem a enviar {"type": "enabled"} e definam reasoning_effort como "low".
2. reasoning_effort passa a ter três níveis: low (leve) / high (reforçado) / max (profundo, o padrão). O mapeamento de compatibilidade de 7 valores da era GLM-5.2 não se aplica mais; a Z.ai recomenda max para tarefas de programação.

Verificado: enviar thinking: {"type": "disabled"} pela AIHubMix retorna 200 e o pensamento continua acontecendo (reasoning_content é retornado normalmente). O valor é convertido automaticamente conforme a semântica do canal oficial, em vez de ser rejeitado. Se seu cliente dependia de "desligar o pensamento para economizar tokens", mude para reasoning_effort: "low".

Verificado: valores fora do enum para reasoning_effort também retornam 200 sem erro (recorrendo ao padrão max conforme a documentação oficial). low vs max mostra a tendência esperada de pensamento mais leve (27 vs 39 tokens de raciocínio na mesma pergunta aritmética).

Chat Completions

O conteúdo do pensamento é retornado no campo reasoning_content; em streaming, chega como delta.reasoning_content.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    reasoning_effort="max",          # low / high / max, default max
    extra_body={"thinking": {"type": "enabled"}},
    messages=[
        {"role": "user", "content": "Compute the square root of (17*23-19*11), rounded down. Digits only."}
    ],
)

print(completion.choices[0].message.reasoning_content)
print(completion.choices[0].message.content)   # Observed: "13"

Verificado: usage.completion_tokens_details.reasoning_tokens informa o uso de pensamento: 27 com reasoning_effort="low", 39 com "max" na mesma pergunta.

Responses

O conteúdo do pensamento volta como um item de saída reasoning, com o texto dentro do array summary como summary_text.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

response = client.responses.create(
    model="coding-glm-5.3",
    input="What is the capital of France? City name only.",
)

# Observed response.output item types: ["reasoning", "message"]
# reasoning item: {"type": "reasoning", "summary": [{"type": "summary_text", "text": "The user is asking..."}]}
# usage.output_tokens_details.reasoning_tokens: 80

Verificado: a requisição padrão (sem nenhum parâmetro reasoning) já inclui o item reasoning com summary_text. Não é necessário optar explicitamente.

Messages

O conteúdo do pensamento é retornado como blocos de conteúdo thinking nativos.

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com"
)

response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "What is the capital of France? City name only."}
    ],
)

# Observed response.content block types: ["thinking", "text"]

Verificado: blocos de thinking são retornados por padrão; thinking: {"type": "disabled"} nesta API também retorna 200 com o pensamento continuando (consistente com a semântica oficial de "disabled converte para low, a requisição continua").

3. Chamada de Ferramentas e Ferramentas Paralelas

Chamada de função verificada e funcionando nas três APIs. Na API Responses, também observamos chamadas de ferramentas paralelas em um único turno (a Z.ai declara explicitamente supports_parallel_tool_calls: true para o GLM-5.3). Limites upstream: até 128 funções em tools; tool_choice suporta nativamente apenas auto.

Chat Completions

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    messages=[{"role": "user", "content": "What's the weather in Beijing today?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
)

# Observed: finish_reason "tool_calls", with a get_weather call in tool_calls

Verificado: tool_choice: "none" funciona. A mesma pergunta sobre o clima retorna texto simples, sem chamada de ferramenta.

Responses

response = client.responses.create(
    model="coding-glm-5.3",
    input="Check today's weather in Shanghai and Beijing",
    parallel_tool_calls=True,
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed: a single turn returns 2 parallel function_call output items (one for each city)

Verificado: 2 chamadas de ferramentas paralelas em um único turno, em conformidade com a declaração oficial supports_parallel_tool_calls: true.

Messages

response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    messages=[{"role": "user", "content": "What's the weather in Beijing today?"}],
)

# Observed: stop_reason "tool_use"; content contains a tool_use block

❗ Verificado: nesta API, o modelo ainda produz chamadas de ferramentas após tool_choice: {"type": "none"}. Para desativar ferramentas, remova totalmente o parâmetro tools, ou use tool_choice: "none" na API Chat Completions.

4. Saída Estruturada

response_format suporta text e json_object; o upstream não lista um modo json_schema. Quando você precisar de conformidade estrita com um schema, incorpore o JSON Schema no prompt e valide no cliente.

Chat Completions

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    messages=[
        {"role": "user", "content": "What is the capital of France? Answer in JSON with the key \"answer\"."}
    ],
    response_format={"type": "json_object"},
)

# Observed response content: {"answer": "Paris"}

Verificado: a saída é JSON válido contendo a chave solicitada.

Responses

response = client.responses.create(
    model="coding-glm-5.3",
    input="What is the capital of France? Answer in JSON with the key \"answer\".",
    text={"format": {"type": "json_object"}},
)

# Observed output text: {"answer": "Paris"}

Messages

# Specify the JSON structure in the prompt; observed output is valid JSON
response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "What is the capital of France? Answer in JSON with the key \"answer\"."}
    ],
)

# Observed response text: {"answer": "Paris"}

5. Cache de Contexto é Automático

O cache implícito fica ativado por padrão, sem parâmetros a passar. Prefixos longos repetidos reportam acertos de cache no usage (o nome do campo varia por API).

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 960}

Verificado: a segunda de duas chamadas consecutivas atingiu 960 tokens em cache.

Responses

# usage of the second call with an identical long prefix
"input_tokens_details": {"cached_tokens": 960}

Messages

# hits are reported via usage.cache_read_input_tokens
"cache_read_input_tokens": 0

Verificado: não reproduzimos um acerto de cache nesta API nesta rodada (os caches são aquecidos por canal; uma troca no balanceador de carga pode causar um miss). O campo de contabilização de acertos segue a semântica da Anthropic.

6. Amostragem e Validação de Parâmetros

A amostragem segue as convenções de endpoint da família GLM: temperature no intervalo [0, 1] com padrão 1.0 (atenção: mais restrito que o [0, 2] do protocolo OpenAI); top_p no intervalo [0.01, 1] com padrão 0.95. A Z.ai recomenda ajustar apenas um dos dois.

Verificado: a validação de parâmetros difere entre as APIs. A API Messages rejeita um temperature: 3 fora do intervalo com um 400 que descreve o intervalo válido [0,1], enquanto Chat Completions / Responses aceitam silenciosamente o mesmo valor fora do intervalo com 200. Ao migrar entre APIs, não conte com o gateway para barrar valores de amostragem fora do intervalo.

# Messages API with temperature=3 -> HTTP 400
"temperature parameter invalid: value must be within [0,1]"

7. Matriz de Suporte Capacidade × API

Cada célula abaixo foi verificada com chamadas reais pelas APIs ativas da AIHubMix em 2026-08-14; as células mostram a grafia do parâmetro/campo para cada API.

FAQ

Qual é o ID do modelo GLM-5.3 na AIHubMix? Preciso do sufixo [1m]?
O ID do modelo é coding-glm-5.3, use exatamente assim. glm-5.3[1m] é a sintaxe de nome de modelo da Z.ai para o cliente Claude Code e não tem nada a ver com chamadas na AIHubMix; nenhuma das três APIs precisa de qualquer sufixo.

Posso desligar o pensamento?
Não. O pensamento do GLM-5.3 é sempre ativo e thinking.type aceita apenas enabled. Em nossos testes, enviar disabled retorna 200 com o pensamento continuando (convertido para o nível low conforme a semântica oficial). Para economizar tokens de pensamento, envie reasoning_effort: "low".

Como o GLM-5.3 se relaciona com o GLM-5.2?
Mesmo modelo base: todos os ganhos vêm do pós-treinamento (texto oficial: "Usa o mesmo modelo base do GLM-5.2; todos os ganhos vêm do pós-treinamento"). Há duas mudanças rígidas de API: o pensamento não pode mais ser desativado, e reasoning_effort passa a ter três níveis low/high/max (padrão max).

E se eu precisar de saída estruturada json_schema estrita?
O upstream não lista um modo response_format: json_schema. Em nossos testes, o modo JSON json_object produziu JSON válido nas três APIs; para schemas estritos, incorpore o JSON Schema no prompt e valide no cliente.

O coding-glm-5.3 é a versão de produção?
Atualmente, trata-se de uma rota de prévia por tempo limitado (a documentação da API de modelos da Z.ai marca a API oficial como "em breve"); a AIHubMix fará uma atualização assim que a API comercial for lançada. Consulte a página do modelo para ver os preços e o status atuais.

Para preços e status em tempo real, consulte a página do modelo GLM-5.3; para mais modelos, visite a galeria de modelos.