GLM 5.2 dispara 116,9% e devolve parte da alta no mesmo dia

Se você usa GLM 5.2 em produção, o custo de uma chamada chegou a mais que dobrar no mesmo dia. O preço passou de US$ 1,452 para US$ 3,15 por milhão de tokens, uma alta de 116,9%, segundo os preços listados no OpenRouter. Depois, recuou para US$ 1,54 — ainda acima do valor inicial, mas muito perto dele.

A oscilação não ficou restrita ao modelo da Z.ai. Kimi K2.6 e Qwen 3.6 27B também subiram e voltaram ao preço anterior no recorte de um dia. Para quem calcula margem por chamada, o problema não é apenas o preço médio: é descobrir qual valor será cobrado quando o tráfego estiver ativo.

A alta do GLM 5.2 foi a mais agressiva

O GLM 5.2 teve o movimento mais extremo entre os modelos destacados. A primeira alteração registrada levou o preço de US$ 1,452 para US$ 3,15 por milhão de tokens. Em seguida, o valor caiu para US$ 1,54, uma redução de 51,1% em relação ao pico.

A reversão, porém, não apagou completamente a alta. O preço final do recorte ficou acima do ponto de partida. Na prática, uma aplicação que tenha roteado chamadas durante o pico poderia ter enfrentado um custo muito diferente do previsto pelo orçamento baseado no preço anterior.

Esse comportamento exige cuidado com estimativas estáticas. Uma planilha que use apenas o valor de US$ 1,452 pode subestimar a fatura. Uma simulação baseada em US$ 3,15, por outro lado, pode superestimar o custo depois do recuo. O valor observado no momento da chamada passa a ser parte importante da conta.

Kimi e Qwen voltaram ao preço inicial

O Kimi K2.6 saiu de US$ 2,36 para US$ 4 por milhão de tokens, alta de 69,5%. Depois, caiu 41% e retornou a US$ 2,36. O Qwen 3.6 27B fez movimento semelhante: subiu de US$ 2,40 para US$ 3,60, avanço de 50%, e recuou 33,3% até voltar a US$ 2,40.

A diferença está no tamanho da reversão. No Kimi e no Qwen, o preço final registrado coincide com o valor inicial. No GLM 5.2, a queda parou em US$ 1,54, ligeiramente acima dos US$ 1,452 anteriores.

Para o usuário de teste, a reversão pode fazer a alteração parecer passageira. Para uma operação com volume, ela ainda importa: chamadas feitas no intervalo mais caro não são automaticamente recalculadas quando o preço baixa. O impacto depende do momento em que a aplicação consumiu os tokens.

O lançamento do GLM 5.3 não estabiliza o GLM 5.2

O mesmo dia também registrou o lançamento do Z.ai: GLM 5.3. No OpenRouter, o modelo aparece com preço de US$ 1,40 por milhão de tokens de entrada e US$ 4,40 por milhão de tokens de saída, além de uma janela de contexto de 1.310.720 tokens.

Isso não significa que o GLM 5.2 tenha sido substituído nem que seu preço esteja vinculado ao novo modelo. São registros diferentes. O lançamento pode chamar atenção para a família GLM, mas não oferece, por si só, uma explicação operacional para as mudanças observadas no GLM 5.2, Kimi K2.6 ou Qwen 3.6 27B.

Também não há estreia de benchmark registrada para o dia. As notas de inteligência, código e desempenho agêntico do Artificial Analysis ajudam a comparar modelos, mas não eliminam a necessidade de acompanhar preços quando a decisão envolve chamadas em produção.

Quem precisa agir agora

A volatilidade pesa mais para quem usa roteamento automático, mantém orçamento fechado ou opera fluxos agênticos com muitas chamadas. Nesses casos, uma mudança temporária por milhão de tokens pode se propagar por milhares de requisições antes que alguém perceba a alteração.

Se você usa um desses modelos, registre o preço efetivamente selecionado no momento da chamada, acompanhe a fatura por modelo e configure limites de gasto. Também vale manter uma rota alternativa para tarefas que não dependem especificamente do GLM 5.2, Kimi K2.6 ou Qwen 3.6 27B.

Para quem apenas experimenta os modelos ocasionalmente, a reversão do Kimi e do Qwen reduz o efeito duradouro da alta. Para quem tem contrato interno de custo por tarefa, a mensagem é diferente: o preço publicado não deve ser tratado como constante ao longo do dia.

A decisão prática é separar qualidade de modelo de estabilidade de preço: antes de fixar qualquer um dos três em produção, monitore o valor por token durante a operação e imponha um teto que impeça uma oscilação relâmpago de virar surpresa na fatura.