Reasoning Effort no GLM 5.2: o ajuste que reduz o custo em 20x

O GLM 5.2 já está disponível na Synthorai por cerca de um sexto do preço por token dos modelos de ponta. E a promessa de um modelo open-weight com resultados comparáveis aos melhores é real. Mas o preço por token não é a métrica certa para avaliar o custo. Em uma tarefa de programação, o custo real do GLM 5.2 pode variar mais de dez vezes por causa de um único ajuste: o reasoning effort. E a configuração padrão deixa esse controle na pior posição. Com o ajuste certo, o GLM 5.2 acerta e custa menos que os modelos de ponta tanto em tarefas fáceis quanto difíceis. No padrão, a mesma resposta custa vinte vezes mais e leva vários minutos. Nós medimos.

TL;DR

• O GLM 5.2 custa $1.40/M de input e $4.40/M de output na Synthorai, cerca de um sexto da tarifa de output do claude-opus-4-8.
• Em uma tarefa simples de programação, o GLM 5.2 com o reasoning desativado custou $0.0008 e levou 5 segundos. O padrão ilimitado gerou a mesma resposta por $0.0285 em 137 segundos.
• Em uma tarefa difícil, reasoning_effort: high acertou por $0.0031 em 13 segundos, cerca de 20x mais barato e 30x mais rápido que o padrão ilimitado ($0.062, 405 segundos).
• O esforço low do GLM gerou mais tokens de reasoning que high nas duas tarefas: os nomes dos níveis não correspondem à quantidade de tokens.

O que é o GLM 5.2

O GLM 5.2 é o modelo open-weight de ponta da Zhipu, lançado em 2026-06-13. Ele usa uma arquitetura mixture-of-experts (~744B de parâmetros no total, ~40B ativos), oferece contexto utilizável de 1M tokens e tem licença MIT, permitindo self-hosting. O foco está em programação e tarefas com agentes, com bons resultados publicados em benchmarks (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). Na Synthorai, ele está disponível como glm-5.2, por $1.40 a cada milhão de tokens de input e $4.40 a cada milhão de tokens de output.

O ponto central para tudo o que vem a seguir: ele é um modelo de reasoning, e você define quanto reasoning ele deve usar.

Como ele se posiciona em preço

Pelo preço por token, o GLM 5.2 fica bem abaixo dos modelos ocidentais de ponta e na mesma faixa dos modelos chineses mais baratos. Estas são as tarifas da Synthorai para um conjunto representativo:

A tarifa de output de $4.40 é cerca de um sétimo da do gpt-5.5 e um sexto da do claude-opus-4-8, embora deepseek-v4-pro e kimi-k2.5 sejam mais baratos. O GLM 5.2 entrega capacidade de ponta por um preço próximo ao dos modelos chineses, mas não é a opção mais barata. Não há cobrança separada para gravação em cache: a gravação é faturada pela tarifa de input, e apenas a leitura recebe o desconto mostrado acima. O desconto varia por fornecedor. No GLM 5.2, a leitura de cache custa cerca de um quinto da tarifa de input. Nos modelos de ponta (gpt-5.5, claude-opus-4-8, gemini-3.1-pro), a leitura custa aproximadamente um décimo.

Também há um salto em relação aos antecessores. A geração anterior do GLM era extremamente barata. A linha GLM 5 aumentou os preços, e o GLM 5.2 chegou custando cerca de 3x mais por input que o GLM-4.6, segundo as tarifas oficiais da Zhipu:

Esse aumento traz o contexto de 1M tokens e os resultados de ponta nos benchmarks. Mas a tarifa por token é só o número de vitrine. O custo real por tarefa depende do reasoning effort.

O controle de reasoning effort

O reasoning do GLM 5.2 funciona como um controle de intensidade, não como um simples liga-desliga. Você pode desativá-lo (enable_thinking: false), definir reasoning_effort como low, medium ou high, ou manter a configuração padrão, que executa o reasoning sem limite. Esse ajuste afeta custo e latência muito mais que o preço por token. Executamos uma tarefa fácil e outra difícil de programação em todas as configurações, comparando cada resposta com uma implementação de referência em centenas de casos aleatórios.

Uma tarefa fácil: reasoning só aumenta o custo

Agendamento de intervalos ponderados, um problema de dificuldade moderada de programação dinâmica:

Dois pontos se destacam. Com o reasoning desativado, a resposta está correta e tem o menor custo da tabela, cerca de 8x abaixo dos modelos de ponta. Aumentar o nível apenas encarece a mesma resposta. Além disso, a cobrança acompanha o reasoning, não a resposta: o código retornado pelo GLM tem cerca de 150 tokens em todas as execuções, enquanto o reasoning anterior à resposta vai de zero a aproximadamente 6,300 tokens, cobrados pela mesma tarifa de output de $4.40/M. O padrão ilimitado gasta todo esse reasoning para chegar à mesma resposta que o modo sem reasoning produziu, e isso explica toda a diferença de custo. Os modelos de ponta respondem com pouco ou nenhum reasoning declarado: o gpt-5.5 usa 59 tokens de reasoning, enquanto o relatório de uso do claude-opus-4-8 não mostra nenhum.

Uma tarefa difícil: reasoning compensa, mas o padrão não

Correspondência de strings com curingas (? e *), um problema clássico no qual é fácil errar em algum detalhe. Sem reasoning, a resposta falhou. O modelo retornou uma recursão com memoização:

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

À primeira vista, parece correta, e a memoização até indica algum cuidado. Mas o ramo de * chama match(i + 1, j) sem limitar i. Quando a string termina e ainda há um * no padrão, i continua aumentando indefinidamente até ocorrer stack overflow. Rápido, barato e errado.

Ao aumentar o nível, o modelo retorna o algoritmo iterativo correto com dois ponteiros. Em vez de usar recursão, ele volta ao último *:

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

Estes foram os resultados de todas as configurações nessa tarefa:

Todos os níveis explícitos resolveram o problema. Com reasoning_effort: high, a resposta correta custou $0.0031 e levou 13 segundos. Isso foi cerca de vinte vezes mais barato e trinta vezes mais rápido que o padrão ilimitado para a mesma resposta. Também custou menos que os modelos de ponta, com apenas alguns segundos a mais de latência. Há uma peculiaridade: o nível low do GLM gerou mais reasoning que high nas duas tarefas. Portanto, os nomes não refletem a quantidade de tokens. Medium e high foram as opções mais rápidas e baratas.

O padrão ilimitado é a única configuração que deve ser evitada. Ele reúne o pior dos dois lados: compra reasoning que talvez nem seja necessário e leva minutos para concluir, chegando à mesma resposta de reasoning_effort: high por vinte vezes o custo.

A regra de decisão

O principal controle é o reasoning effort, e a configuração correta depende da tarefa, não do modelo:

• Tarefas simples ou de alto volume, nas quais é fácil validar a correção: desative o reasoning (enable_thinking: false). A resposta fica correta e custa cerca de 8x menos que nos modelos de ponta.
• Problemas mais difíceis, nos quais o modo sem reasoning falha: use reasoning_effort: medium ou high. A resposta fica correta, custa cerca de $0.003 por tarefa e continua abaixo dos modelos de ponta em preço, com apenas alguns segundos a mais.
• Nunca use o padrão ilimitado. Manter o reasoning ativo sem limitar o esforço transforma uma resposta de $0.003 em uma chamada de $0.06 que leva sete minutos.

Se não for possível saber antecipadamente se a tarefa exige reasoning, reasoning_effort: high é um padrão seguro: teve baixo custo, resolveu as duas tarefas e nunca saiu de controle.

O cache reduz o custo do input, não do reasoning

O GLM 5.2 oferece suporte a cache no gateway e funciona como esperado. Enviamos um prefixo compartilhado de 1,494 tokens, um módulo de código para revisão, com várias perguntas diferentes:

Depois que um prefixo grande aparece pela primeira vez, ele entra no cache. Os tokens de input em cache custam aproximadamente um quinto da tarifa normal de input. Com isso, uma requisição idêntica caiu de $0.0026 para $0.0009, uma redução de cerca de 64%. Uma repetição exata é atendida diretamente pelo cache semântico: mesma resposta e mesmo custo da chamada com cache, mas em cerca de um segundo, em vez de cinco.

A limitação é a mesma mostrada pelo controle de esforço: o cache reduz o custo do input. Quando o reasoning está ativo, custo e latência passam a se concentrar no output de reasoning, que não é armazenado em cache. O cache traz uma economia real em tarefas com muito contexto e reasoning desativado, como quando o mesmo system prompt ou codebase é enviado em todas as chamadas. Com reasoning ativo, a economia é pequena.

Como usar na Synthorai

O glm-5.2 já está disponível no gateway. Nossos testes apontaram três recomendações práticas:

• Defina explicitamente o reasoning effort. Use enable_thinking: false para tarefas simples e reasoning_effort: medium ou high para problemas mais difíceis. Evite deixar o reasoning ativo sem limite de esforço, que é o padrão ilimitado e pode levar a uma chamada de $0.06 com sete minutos de duração.
• Use streaming quando o reasoning estiver ativo. Respostas com reasoning podem levar minutos. Em uma requisição sem streaming, a conexão fica sem atividade por tempo suficiente para o cliente provavelmente atingir o timeout antes de receber a resposta. Com stream: true, o output chega aos poucos e o resultado completo é preservado.
• Reutilize o contexto. Se o mesmo system prompt grande ou codebase for enviado em todas as chamadas, o cache de prefixo reduz o custo do input. Com reasoning desativado, toda a requisição fica barata.

O preço é $1.40 / $4.40 por milhão de tokens, e o gateway retorna um campo cost em cada chamada para mostrar exatamente quanto custou cada requisição.

Conclusão

O GLM 5.2 é um modelo de programação realmente barato e capaz. Com a configuração correta, custa menos que os modelos de ponta tanto em tarefas fáceis quanto difíceis. O ponto crítico é a configuração. O reasoning tem níveis de intensidade, e o padrão não impõe limite. É assim que uma tarefa que deveria custar $0.003 vira uma chamada de $0.06 com sete minutos de duração. Use enable_thinking: false em tarefas simples e reasoning_effort: medium ou high nas demais. Dessa forma, o GLM 5.2 mantém baixo custo e boa precisão em todos os cenários. Com o reasoning no padrão, ele se torna a opção mais lenta e cara disponível.

Fontes

• VentureBeat: o GLM-5.2 open-weight da Z.ai supera o GPT-5.5 em programação de longo prazo por 1/6 do custo
• eigent.ai: especificações e visão geral do GLM-5.2
• CloudPrice: preços e especificações do GLM-5.2
• Z.ai: preços oficiais da API do GLM (gerações GLM-4.5 / 4.6 / 5)

Outros guias desta série com custos medidos: custo de transcrição de áudio em sete modelos ASR e custo de geração de imagens.

(Os preços da Synthorai acima correspondem às tarifas da plataforma em 2026-06-24; as tarifas das gerações do GLM são os preços oficiais da Zhipu.)

Custos medidos na Synthorai em 2026-06-24 (glm-5.2 a $1.40 / $4.40 por M tokens); confira os preços atuais antes de usá-los como referência.

← Voltar ao blog