Kimi K3, GLM ou DeepSeek: qual modelo barato aguenta refatorar código de verdade?

Fala aí, beleza? Modelo barato tem uma pegadinha que ninguém coloca na tabela de preços: o preço por token não é o preço da tarefa

Se o modelo erra a refatoração, você paga o retrabalho, paga o contexto de novo, paga sua própria hora revisando código quebrado

E aí o "barato" vira caro do jeito mais chato possível

Os três candidatos da vez são o Kimi K3, da Moonshot AI, o GLM-5.2, da Z.ai, e a linha V4 da DeepSeek

O recorte deste post é bem específico: usar modelo barato pra mexer em código que já existe, e não pra criar projeto do zero

Já adianto o que você vai encontrar aqui: os números oficiais lado a lado, o único teste de mão própria que eu tenho (Kimi K3 rodando no Kimi Code, o CLI da própria Moonshot, criando projeto do zero) e a configuração de cada um pra rodar no seu terminal

Nada de "qual é o melhor modelo do mundo", beleza? A pergunta é qual deles você conseguiria colocar pra mexer num repositório que já existe sem se arrepender no fim do mês

Kimi K3, GLM-5.2 e DeepSeek V4: preço, inteligência e velocidade lado a lado

Antes de qualquer opinião, o que dá pra checar em fonte oficial

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 110 aulas
• 4 projetos
• 9h 2min

Conhecer formação

Olha a linha da saída, que é onde a conta dói de verdade: o milhão de tokens custa US$ 15,00 no Kimi K3, US$ 4,40 no GLM-5.2 e US$ 1,98 no DeepSeek V4 Pro fora de pico

É quase oito vezes de diferença entre a ponta cara e a ponta barata, o que parece decisivo… e não é

Porque a tabela mede três coisas: preço de lista, inteligência agregada em benchmark e velocidade de geração

Nenhuma delas é "esse modelo consegue mudar o nome de um método em 14 arquivos sem inventar import que não existe"

Refatoração longa é outro bicho: depende de seguir instrução, de não alucinar API, de manter a mesma regra de negócio em arquivos diferentes

E isso os números públicos não medem, então trate a tabela como ponto de partida, não como veredito 🙂

Quando cada modelo barato compensa (e quando o barato sai caro)

Em vez de coroar um vencedor genérico, dá pra ligar cada modelo a um cenário concreto

Tarefa longa, com o projeto inteiro no contexto:

Aqui o Kimi K3 tem um argumento forte que não aparece no preço por token: o preço é plano em todo o contexto de 1 milhão, sem taxa extra de contexto longo

Ou seja, encher a janela não muda a tarifa

Pra refatoração isso importa muito, porque o erro clássico do modelo é escrever a regra de um jeito num arquivo e de outro jeito no arquivo vizinho, justamente por não estar vendo os dois ao mesmo tempo

Se você comparou Kimi K3 ou Claude Code, esse é o mesmo raciocínio aplicado ao bolso

Volume alto e tolerante a erro:

A DeepSeek mudou a conta em 16 de agosto de 2026, quando passou a cobrar por faixa de horário

As janelas de pico são das 01:00 às 04:00 e das 06:00 às 10:00 UTC, e todo o resto do dia é fora de pico, com tarifa 50% menor

Junte isso ao deepseek-v4-flash, que sai por US$ 0,22 de entrada e US$ 0,66 de saída fora de pico, e você tem o cenário de rodar muita coisa em lote, com revisão sua no fim

Tradução: se a tarefa aguenta uma segunda tentativa sem drama, essa é a conta mais leve da mesa

Uso diário previsível:

O GLM Coding Plan é assinatura de preço fixo pra ferramentas de código, com três níveis (Lite, Pro e Max) começando em US$ 18 por mês

Pro e Max entregam 6x e 14x a cota do Lite

O plano fala protocolo Anthropic e OpenAI, e é aplicável a ferramentas como Claude Code, Cline e OpenCode

Quem odeia abrir o painel de billing e tomar susto costuma preferir esse formato, mesmo pagando um pouco mais na média

E a lógica que amarra os três cenários é a do retrabalho

Saída cara multiplicada por poucas tentativas pode ser mais barata que saída barata multiplicada por muitas

Se o modelo mais barato precisa de três rodadas pra entregar o que o mais caro entrega numa, a diferença de tabela evapora

Por isso a métrica que interessa é custo por tarefa concluída, não preço por milhão de tokens

O que aconteceu quando coloquei o Kimi K3 pra trabalhar num projeto

Seja honesto comigo que eu sou honesto com você: eu não rodei o mesmo teste de refatoração nos três modelos

O que eu tenho de primeira mão é com o Kimi K3, e foi no Kimi Code, o CLI próprio da Kimi rodado pelo terminal

Escolhi o CLI dele justamente porque, em testes anteriores, colocar modelo Kimi dentro do Claude Code não tinha me dado uma boa experiência

O teste foi montado como projeto real, não como pergunta solta: um analisador de contratos em Next com TypeScript, avaliado por etapas (scaffold, design, autenticação, integração com IA)

No primeiro prompt pedi a estrutura inicial mais uma landing page completa, com direção de design detalhada (tema escuro, tipografia forte, cor de acento, microinterações) e a lista de seções que eu esperava

O agente gerou os arquivos, rodou instalação de dependências e build por conta própria

A etapa toda levou cerca de 10 minutos na minha máquina, e o CLI mostrou quase 1% da assinatura consumido logo depois

Aí veio a primeira coisa que ele NÃO fez sozinho: subir o servidor

Precisei de um segundo prompt pedindo pra rodar o projeto e me devolver o endereço de teste, e foi quando ele apontou as 3 páginas entregues (landing, login e registro)

Abri no navegador e gostei do design: bonito, com microinterações, sem cair naquela fonte padrão de sempre

Porém faltaram seções que estavam no meu prompt, entre elas preços e perguntas frequentes

E as rotas de login e registro saíram como placeholder, com a autenticação só inicializada, não implementada de fato

O visual ainda tem cara de projeto feito por IA, algo que dá pra contornar com skills e prompts melhores

Outra ressalva: o CLI da Kimi não mostra contador de tempo de sessão, o que atrapalhou bastante a medição durante a gravação (fica a sugestão de melhoria aí, Moonshot 😀)

No vídeo acima você vê o modelo trabalhando do zero, com o agente gerando arquivo por arquivo e a landing abrindo no navegador no fim

E agora a parte importante: o que esse teste prova e o que ele não prova

Ele prova que o modelo segue direção de design longa, cria estrutura de projeto coerente e roda ferramenta sozinho

Ele NÃO prova nada sobre refatorar código que já existe

Criar arquivo em branco é fácil, o difícil é entrar num repositório com histórico, entender por que aquela função está daquele jeito e mudar sem quebrar o resto

Benchmark de lançamento costuma ser auto reportado, então só o teste na sua máquina, no seu código, dá segurança de verdade

Veredito: o modelo que eu escolheria pra refatorar código de verdade

Sem fingir que comparei os três no mesmo repositório, dá pra dar um veredito por perfil

Quem prioriza acertar na primeira tentativa olha pro Kimi K3

É o de maior pontuação de inteligência entre os três (60 contra 53 do DeepSeek V4 Pro e 53 do GLM-5.2), com o custo médio por token mais alto (US$ 2,31 contra US$ 0,69 e US$ 0,88) e a menor velocidade no par medido: 38,6 tokens por segundo contra 80,2 do V4 Pro

Ele é o mais lento e o mais caro da lista, e ainda assim pode sair mais barato se cortar rodadas de retrabalho

Quem prioriza conta baixa vai de DeepSeek, escolhendo entre o v4-pro e o v4-flash conforme o tamanho da encrenca, e rodando fora das janelas de pico sempre que der

Quem prioriza previsibilidade e velocidade olha pro GLM, que tem a geração mais rápida no par medido (135,3 contra 88,7 tokens por segundo do V4 Pro) e o formato de assinatura fixa

Agora a limitação, que é grande e você precisa saber antes de escolher

Todos esses números medem inteligência agregada e velocidade, não refatoração num repositório real com histórico

E tem o detalhe do GLM-5.3, lançado em 14 de agosto de 2026: até hoje ele só pode ser acessado pelo GLM Coding Plan e pelo ambiente ZCode

A API geral não abriu, a página do modelo exibe um aviso de "GLM-5.3 API is coming soon" e não tem data

Então, se o seu plano era pegar a chave avulsa e apontar pro 5.3, esse caminho ainda não existe

Por esse mesmo motivo o quadro geral também vale pra quem já leu sobre Kimi K3 contra Claude e ChatGPT: a diferença aqui não está só no modelo, está no que cada provedor te deixa acessar

Como plugar cada um dos três no Claude Code

Kimi e DeepSeek expõem endpoint compatível com a API da Anthropic e documentam a integração com o Claude Code

A Z.ai também tem o endpoint dela, mas com uma pegadinha grande: por ali só rolam GLM-5.3, GLM-5-Turbo e GLM-4.7, ou seja, o GLM-5.2 que aparece na tabela lá em cima fica de fora dessa porta

O que muda em cada caso é o nome da variável, o nome do modelo e a armadilha de cada um

Kimi K3, pela Moonshot:

1. Aponte a base URL e o token pro endpoint Anthropic da Moonshot, e declare o modelo kimi-k3

export ANTHROPIC_BASE_URL=https://api.moonshot.ai/anthropic
export ANTHROPIC_AUTH_TOKEN=sua-chave-da-kimi

2. Confira a configuração dentro do Claude Code com o comando /status, que é o caminho indicado na documentação oficial da Kimi

Ele deve mostrar a Base URL https://api.moonshot.ai/anthropic e o modelo kimi-k3

O erro comum deste passo: achar que configurou e estar falando com o modelo errado, porque a variável ficou setada só naquela sessão do terminal

3. Se você trocar pro kimi-k2.7-code, ligue o Thinking antes (tecla Tab no Claude Code)

O erro comum deste passo: o kimi-k3 já pensa por padrão e funciona direto, mas o kimi-k2.7-code exige o Thinking ligado ou a requisição volta com erro 400 invalid thinking

Tome cuidado, porque a mensagem não é nada óbvia pra quem só trocou o nome do modelo

GLM, pela Z.ai:

4. Edite o arquivo ~/.claude/settings.json com a base URL e a chave da Z.AI

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "sua-chave-da-zai"
  }
}

5. Escolha um modelo que esse endpoint realmente atende

O erro comum deste passo: pelo endpoint Anthropic da Z.ai só três modelos podem ser chamados, GLM-5.3, GLM-5-Turbo e GLM-4.7

A variável ANTHROPIC_DEFAULT_HAIKU_MODEL aponta pro GLM-4.7

6. Se a sua ferramenta não for o Claude Code, troque o endereço

O erro comum deste passo: o /api/anthropic é específico pra Claude Code e Goose

Pras demais ferramentas a Z.ai usa https://api.z.ai/api/coding/paas/v4, e apontar pro endereço errado te dá aquele erro genérico que consome meia hora do seu dia

DeepSeek V4:

7. Aponte a base URL e a chave pro endpoint Anthropic da DeepSeek, que documenta oficialmente a integração com o Claude Code

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_API_KEY=sua-chave-da-deepseek

Repare que aqui a variável é ANTHROPIC_API_KEY, e não ANTHROPIC_AUTH_TOKEN como nos outros dois

8. Preste atenção no nome do modelo que você digita, porque existe mapeamento automático

O erro comum deste passo: nomes começando com claude-opus caem no deepseek-v4-pro, e claude-sonnet e claude-haiku caem no deepseek-v4-flash

Ou seja, o nome que você digita decide o preço que você paga, e a diferença entre pro e flash é de três vezes na saída

Já vi gente jurando que estava economizando enquanto rodava tudo no modelo mais caro 😛

Conclusão

O critério prático não é preço por token, é custo por tarefa concluída

Um modelo que cobra oito vezes menos e precisa de quatro tentativas não é oito vezes mais barato, é uma dor de cabeça com desconto

E nenhum benchmark público responde isso pra você, porque a variável que decide é o SEU código, com as suas convenções e a sua bagunça acumulada

Então o próximo passo é bem concreto: escolhe uma refatoração pequena e real do teu projeto, algo que você já sabe como deveria ficar

Roda ela no modelo escolhido, com a configuração da seção anterior, e conta quantas tentativas foram necessárias até o código passar

Faz isso com dois modelos diferentes e você vai ter, em uma tarde, uma resposta mais útil que qualquer tabela da internet (inclusive a minha aí em cima, haha)

Se curtiu esse tipo de teste, fica de olho no blog e no canal que eu vou continuar colocando esses modelos pra trabalhar em projeto de verdade…

até o próximo post! =)