GLM 5.3 vs. DeepSeek V4 Pro: resultados, tempo e custo

Comece testando o GLM 5.3 quando um resultado aceito a mais em uma tarefa difícil puder justificar um gasto maior. Vale comparar o DeepSeek V4 Pro-0813 quando o custo de várias tentativas for decisivo. Em uma avaliação publicada, o GLM concluiu mais tarefas e apresentou uma mediana de tempo menor entre as tarefas concluídas; o Pro custou menos. Isso não define um vencedor universal.

Há uma limitação de disponibilidade próxima: a DeepSeek planeja desligar o V4 Pro em 14 de setembro de 2026, às 12h de Pequim: 04h UTC ou 07h de Moscou. Um aviso na plataforma oficial, visível após o login, informa que as requisições Pro serão direcionadas ao V4.1 Flash e cobradas pelas tarifas dele. Não construa uma nova integração de longo prazo com a API oficial supondo que o nome antigo continuará entregando o Pro-0813.

A comparação trata de GLM 5.3 e Pro-0813, não de GLM 5.3 Flash nem de V4.1 Flash. Os resultados históricos do Pro podem servir de referência para avaliar um substituto; não descrevem o modelo que responderá por esse nome após o desligamento.

O que a avaliação de 30 tarefas mostra

Em 27 de agosto, a Composio publicou uma comparação de cinco modelos em 30 tarefas de agente com várias etapas:

Métrica da Composio	GLM 5.3	DeepSeek V4 Pro-0813
Tarefas concluídas	22 de 30	19 de 30
Custo total das 30 tarefas	$5.31	$1.23
Custo divulgado por tarefa bem-sucedida	$0.24	$0.065
Mediana de tempo entre tarefas concluídas	2 min 54 s	4 min 41 s
Tempos limite excedidos	1	3

Resultados originais: conclusão, custo total, custo por sucesso, tempo e limites de tempo.

O GLM concluiu três tarefas a mais nessa amostra. O custo por sucesso do Pro foi cerca de 3,7 vezes menor: $0.24 / $0.065. São gastos históricos daquela avaliação, sem retrabalho humano, e não preços atuais da API.

As medianas incluem somente sucessos, e os conjuntos de tarefas concluídas pelos modelos são diferentes. Elas não demonstram que o GLM é mais rápido em cada tarefa idêntica nem que uma sessão inteira terminará proporcionalmente antes. Falhas e tempos limite também consomem tempo.

A avaliação é da Composio, não um teste nosso. Sem configurações completas, ambiente de execução e repetições, 22 contra 19 não prevê com segurança o sucesso no seu projeto. Um fluxo de várias etapas com ferramentas externas também é diferente de corrigir um bug em um repositório.

Os benchmarks de programação são mais variados

A ficha oficial do GLM 5.3 inclui resultados do Pro-0813:

Teste na tabela da Z.ai	GLM 5.3	Pro-0813
Terminal Bench 2.1	88.2	87.9
DeepSWE v1.1	66.9	62.7
NL2Repo	58.0	61.1
Toolathlon Verified	73.0	74.1

O GLM lidera as duas primeiras linhas; o Pro, as duas seguintes. São resultados publicados pela Z.ai nas condições descritas na ficha, não um substituto para testar os dois modelos de forma independente no seu cliente. Tarefas e métodos de pontuação diferentes não podem ser somados em uma única porcentagem de qualidade.

Os padrões também diferem. O GLM 5.3 usa reasoning_effort = max. O guia atual do DeepSeek V4 ativa o raciocínio com esforço high. Duas execuções sem configuração usam modos distintos; igualar nomes de esforço tampouco provaria orçamentos computacionais iguais.

Para reproduzir um benchmark, siga as condições publicadas. Para escolher um modelo de trabalho, defina custo e tempo aceitáveis e teste configurações adequadas a cada modelo dentro desses limites.

Conte todas as tentativas até a aceitação

Defina primeiro o sucesso. Uma correção pode exigir que o teste antes falho passe sem regressões. Um agente que modifica vários sistemas pode precisar deixar todos no estado correto, sem registros extras nem ações duplicadas.

cost_per_accepted_task = total_api_cost_of_all_attempts / accepted_tasks

Inclua no numerador falhas, novas tentativas e chamadas a modelos de reserva. Sem tarefas aceitas, a métrica é indefinida: registre zero sucessos e o gasto total, não custo por sucesso igual a zero.

Registre separadamente o tempo humano de revisão e correção. Ao convertê-lo em dinheiro, use seu próprio custo por hora e mantenha-o separado do gasto com API. Um retrabalho demorado pode superar a economia na conta do modelo; meça isso nas suas tarefas.

No Dashboard do BetterToken, você pode consultar modelo, horário da requisição, tokens de entrada, saída e cache, e gasto correspondente. Aceitação da tarefa e esforço humano exigem registros próprios. Um nome de modelo no log não comprova de forma independente quais pesos um provedor externo utilizou.

Decida com sua própria carga de trabalho

Selecione um pequeno conjunto de tarefas recorrentes. Dê aos modelos o mesmo estado inicial do projeto, instruções, permissões de ferramentas e critérios de aceitação. Use dados de teste para que ações externas repetidas não criem duplicatas reais.

Registre versões do modelo e cliente, provedor, modo de raciocínio, tempo limite e limite de tentativas. Guarde gasto e resultado de cada execução, inclusive falhas. Compare quais tarefas específicas cada modelo resolveu, não apenas a conta total.

• Mudanças complexas com correção humana cara: teste primeiro o GLM 5.3 e veja se suas vantagens em algumas avaliações geram mais mudanças aceitas no seu caso.
• Tarefas bem definidas com orçamento restrito: os resultados históricos do Pro-0813 mostram a utilidade do custo por sucesso. É possível compará-lo ao seu modelo atual antes do desligamento; a continuidade exige uma opção com disponibilidade confirmada.
• Processos longos com várias ferramentas: limite o tempo da tarefa inteira, incluindo repetições. Medianas de sucessos omitem o tempo perdido em trabalhos inacabados.

Depois de 14 de setembro, uma nova requisição oficial a deepseek-v4-pro não pode ser tratada automaticamente como teste de Pro-0813. Confira primeiro o roteamento. Se V4.1 Flash responder, será uma nova comparação com GLM 5.3 e exigirá novos resultados. Confira separadamente a disponibilidade e os prazos de terceiros.