GLM 5.2: o reasoning effort é a alavanca de custo

O GLM 5.2 já está na Synthorai por cerca de um sexto do preço por token dos modelos de fronteira, e a manchete de modelo open-weight com desempenho de fronteira é real. Mas o preço por token é o número errado para se apegar. O que uma tarefa de coding realmente custa no GLM 5.2 varia por mais de uma ordem de grandeza dependendo de um único botão — o reasoning effort — e o default deixa esse botão na pior posição possível. Ajuste-o bem e o GLM 5.2 acerta e fica mais barato que os modelos de fronteira, tanto em tarefas fáceis quanto difíceis. Deixe no default e a mesma resposta custa vinte vezes mais e leva minutos. Nós medimos.

O que é o GLM 5.2

O GLM 5.2 é o modelo open-weight de fronteira da Zhipu, lançado em 2026-06-13: uma rede mixture-of-experts (~744B no total, ~40B ativos), um contexto utilizável de 1M tokens e uma licença MIT que você pode rodar por conta própria. O foco é coding e trabalho agêntico, com benchmarks publicados fortes (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). Na Synthorai ele é o glm-5.2, com preço de $1.40 por milhão de tokens de input e $4.40 por milhão de output.

O detalhe que comanda tudo daqui pra frente: é um modelo de reasoning, e o quanto ele raciocina é algo que você define.

Onde ele se encaixa em preço

No preço de tabela por token, o GLM 5.2 fica bem abaixo da fronteira ocidental e entre os modelos chineses mais baratos. 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 o deepseek-v4-pro e o kimi-k2.5 fiquem ainda mais baratos. Ou seja, o GLM 5.2 entrega capacidade de fronteira a preços de modelo chinês, mas não é o piso absoluto. Não há cobrança separada de cache write: uma escrita de cache é cobrada na tarifa de input, e só o cache read recebe o desconto da tabela acima. O desconto varia por fornecedor — o cache read do GLM 5.2 fica em cerca de um quinto da tarifa de input, enquanto os modelos de fronteira (gpt-5.5, claude-opus-4-8, gemini-3.1-pro) descontam as leituras para perto de um décimo.

Ele também é um avanço em relação aos próprios antecessores. A geração GLM anterior era extraordinariamente barata; a linha GLM 5 subiu os preços, e o GLM 5.2 chega a cerca de 3x a tarifa de input do GLM-4.6 (tarifas oficiais da Zhipu):

Isso compra o contexto de 1M e os benchmarks de fronteira. Mas a tarifa por token é só a manchete. O que você realmente paga por tarefa é definido pelo reasoning effort.

O botão do reasoning effort

O reasoning do GLM 5.2 é um botão, não uma chave liga/desliga. Você pode desligá-lo (enable_thinking: false), ajustar o reasoning_effort para low, medium ou high, ou deixar no default, que roda o reasoning sem limite. Esse ajuste muda custo e latência muito mais do que o preço muda. Rodamos uma tarefa de coding fácil e uma difícil ao longo das configurações, conferindo cada resposta contra uma referência em centenas de casos randomizados.

Uma tarefa fácil: raciocínio só adiciona custo

Weighted interval scheduling, um problema de programação dinâmica de dificuldade moderada:

Dois pontos chamam atenção. Com thinking off a resposta está correta e é a opção mais barata da tabela, cerca de 8x menos que os modelos de ponta — e cada passo que você sobe no dial só adiciona custo para chegar na mesma resposta. E a conta acompanha o raciocínio, não a resposta: o código que o GLM devolve tem sempre uns 150 tokens, enquanto o raciocínio que vem antes cresce de zero até uns 6,300, cobrado à mesma taxa de $4.40/M na saída. O default sem limite gasta esse raciocínio para chegar à mesma resposta que o thinking off produziu sem nenhum, e essa diferença é exatamente toda a diferença de custo. Os modelos de ponta respondem aqui com pouco ou nenhum raciocínio reportado: o gpt-5.5 gasta 59 tokens de raciocínio, e o uso do claude-opus-4-8 não reporta nenhum.

Uma tarefa difícil: aqui o reasoning compensa, o default não

Casamento de strings com wildcards (? e *), aquele problema clássico em que é fácil errar nos detalhes. Aqui, com o thinking desligado, deu errado. O modelo devolveu 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)

Parece certo, e a memoização até sugere algum cuidado. Mas o ramo do * chama match(i + 1, j) sem limitar i. Quando a string acaba e o padrão ainda tem um *, o i cresce indefinidamente e a stack estoura. Rápido, barato e errado.

Aumente o nível e ele devolve o algoritmo iterativo correto, com dois ponteiros, que faz backtrack até o último * em vez de recorrer à recursão:

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)

O range completo do dial nesta tarefa:

Todos os níveis explícitos de esforço resolveram o problema. O reasoning_effort: high resolveu por $0.0031 em 13 segundos, cerca de vinte vezes mais barato e trinta vezes mais rápido que o default sem limite para a mesma resposta — e ainda fica abaixo dos modelos de fronteira no custo, com poucos segundos a mais. Uma peculiaridade que vale conhecer: o low do GLM gerou mais reasoning que o high, de forma consistente nas duas tarefas, então os nomes não acompanham a contagem de tokens. Medium e high foram as configurações baratas e rápidas.

O default sem limite é a única configuração a evitar. É o pior dos dois mundos: paga por um reasoning que a tarefa talvez nem precise e leva minutos para fazê-lo, chegando à mesma resposta que o reasoning_effort: high deu por vinte vezes o custo.

A regra de decisão

A alavanca é o esforço de reasoning, e a configuração certa pertence à tarefa, não ao modelo:

• Trabalho simples ou de alto volume em que a corretude é fácil: thinking off (enable_thinking: false). Correto e cerca de 8x abaixo da fronteira.
• Problemas mais difíceis em que o thinking off falha: reasoning_effort: medium ou high. Correto, em torno de $0.003 por tarefa, abaixo da fronteira no custo e apenas alguns segundos mais lento.
• Nunca o default sem limite. Deixar o reasoning ligado sem teto de esforço é como uma resposta de $0.003 vira uma de $0.06 e sete minutos.

Se você não consegue saber de antemão se uma tarefa precisa de reasoning, o reasoning_effort: high é um default seguro: foi barato, resolveu as duas tarefas e nunca saiu do controle.

Cache ajuda no input, não no raciocínio

O GLM 5.2 suporta cache no gateway, e ele ajuda exatamente onde você esperaria. Enviamos um prefixo compartilhado de 1.494 tokens (um módulo de código para revisar) com várias perguntas diferentes:

Depois que um prefixo grande aparece uma vez, ele vai para o cache. Os tokens de input em cache são cobrados a cerca de um quinto da tarifa normal de input, o que reduziu uma requisição idêntica de $0.0026 para $0.0009, uma queda de uns 64%. Uma repetição exata é servida direto do cache semântico: a mesma resposta com o mesmo custo da chamada em cache, mas de volta em cerca de um segundo em vez de cinco.

O detalhe é o mesmo que o dial já tinha ensinado: o cache dá desconto no input, e no momento em que o raciocínio está ligado, o custo e a latência ficam no output do raciocínio, que não é cacheado. Então o cache é um ganho de verdade para trabalho com muito contexto e thinking desligado (o mesmo system prompt ou a mesma base de código em toda chamada), e um ganho pequeno quando o raciocínio está ligado.

Usando no Synthorai

O glm-5.2 já está disponível no gateway. Três observações práticas dos nossos testes:

• Defina o reasoning effort explicitamente. Use enable_thinking: false para trabalho simples e reasoning_effort: medium ou high para problemas mais difíceis. O que você quer evitar é deixar o raciocínio ligado sem limite de effort (o default sem teto), que é a armadilha dos $0.06 e sete minutos.
• Use streaming quando o raciocínio estiver ligado. Respostas com raciocínio podem rodar por minutos, e uma requisição sem streaming fica numa conexão silenciosa tempo suficiente para o seu cliente provavelmente dar timeout antes da resposta chegar. Use stream: true e você recebe o output incremental e o resultado completo.
• Reaproveite seu contexto. Se você manda o mesmo system prompt grande ou a mesma base de código em toda chamada, o prefix caching corta o custo de input, e combinar isso com thinking desligado deixa a requisição inteira barata.

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

Conclusão

O GLM 5.2 é um modelo de coding genuinamente barato e capaz, e bem configurado bate os preços de modelos de fronteira tanto em trabalho fácil quanto difícil. O problema é a configuração. O raciocínio dele é um dial, e o default o deixa sem limite, e é assim que uma tarefa que deveria custar $0.003 vira uma chamada de $0.06 e sete minutos. Defina enable_thinking: false para trabalho simples e reasoning_effort: medium ou high para o resto, e o GLM 5.2 fica barato e correto em todos os cenários. Deixe o raciocínio no default, e ele vira a opção mais lenta e mais cara que você poderia ter escolhido.

Fontes

• VentureBeat: Z.ai’s open-weight GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6 the cost
• eigent.ai: GLM-5.2 specs and overview
• CloudPrice: GLM-5.2 pricing and specs
• Z.ai: official GLM API pricing (GLM-4.5 / 4.6 / 5 generations)

(Os preços listados do Synthorai acima são as tarifas desta plataforma em 2026-06-24; as tarifas das gerações do GLM são a lista oficial da Zhipu.)

Custos medidos no Synthorai em 2026-06-24 (glm-5.2 a $1.40 / $4.40 por M tokens); verifique o preço atual antes de confiar nele.

← Voltar ao blog