Prompt em português ou em inglês no Claude Code: faz diferença?

Fala aí, beleza? Tem uma cena que todo dev brasileiro já viveu: o repositório inteiro em inglês, variável em inglês, docs em inglês, e você ali pensando em português na hora de explicar o bug

Aí bate a dúvida: escrever o prompt em inglês deixa a resposta melhor, ou isso é crendice de internet?

A resposta curta é que a pergunta está mal colocada, e eu vou mostrar por quê

Neste post eu comparo os três caminhos (português puro, inglês puro e o híbrido), mostro o que a documentação realmente sustenta, o que NÃO tem medição pública, e fecho com veredito

Português, inglês e híbrido: o que muda em cada eixo

Antes da tabela, um aviso importante: não existe benchmark oficial da Anthropic comparando português e inglês em tarefas de código

Então qualquer tabela que te prometer "X% a mais de acerto em inglês" está chutando

O que dá pra comparar de verdade são os eixos práticos:

Formação Recomendada

Formação Claude Code

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

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Clareza da instrução: o gargalo do prompt raramente é o idioma, é a vagueza

Aderência aos nomes do repositório: aqui mora o erro caro, e eu volto nele na próxima seção

Custo em tokens: o que está documentado é outra coisa, e é bom não confundir. A partir do Claude 4.7 os modelos usam um tokenizer novo que gera cerca de 30% mais tokens para o MESMO texto em relação aos modelos anteriores (faixa aproximada de 1x a 1,35x, variando com o conteúdo)

Isso é comparação entre versões de modelo, não entre idiomas 🙂

A orientação da Anthropic é recontar seus prompts no modelo que você vai usar, em vez de reaproveitar contagem antiga. E dá pra medir: a API Messages tem o endpoint count_tokens, que mostra quantos tokens uma mensagem consome antes de você enviar, é gratuito e sujeito a limite de requisições por minuto

Consistência entre turnos: a documentação da Anthropic recomenda declarar o idioma alvo explicitamente em vez de confiar só na detecção automática, e diz que o lugar mais confiável pra essa instrução é o system prompt, porque ela se mantém estável em todos os turnos da conversa

Esforço de escrita: esse é o eixo que ninguém mede e que mais pesa no dia a dia

E o único parâmetro público que existe pra comparar idiomas no Claude é a tabela multilíngue da Anthropic, montada com o MMLU em inglês traduzido por tradutores humanos profissionais para 14 idiomas adicionais, com avaliação zero-shot chain-of-thought e resultado expresso em porcentagem relativa ao desempenho em inglês (inglês = 100%)

É conhecimento geral, não tarefa de código. Serve de referência de metodologia, não de promessa

Quando escrever em português, quando escrever em inglês

Nada de dogma aqui, se liga: a divisão que funciona é por SITUAÇÃO

Escreva em português quando:

• for raciocínio complexo, do tipo que você precisa destrinchar
• estiver explicando regra de negócio (a que só existe na cabeça de quem trabalha ali)
• estiver descrevendo bug com nuance: "acontece só quando o usuário volta pra tela anterior e o filtro ainda tá aplicado"
• estiver revisando decisão de arquitetura e quer discordar do Claude com precisão

Em todos esses casos, escrever numa língua que você não domina te faz simplificar a ideia. E ideia simplificada vira prompt vago

Escreva em inglês quando:

• a instrução for reutilizável e virar arquivo versionado, lido pelo time (é o caso de arquivos de contexto, comandos e subagentes no Claude Code, que vivem no repositório e passam pela mão de todo mundo)
• a coisa precisar casar com a interface, que é exibida só em inglês

E SEMPRE literal, em qualquer cenário: nome de função, nome de variável, rota, comando, caminho de arquivo, mensagem de erro

Copia do repositório e cola sem traduzir

Por que isso é o erro que mais custa? Porque quando você escreve "o método buscarUsuario" e no código o método é getUser, o Claude vai procurar um símbolo que não existe

Aí ele faz uma de duas coisas: ou cria o símbolo novo, ou sai vasculhando arquivo atrás de algo que não está lá

Os dois desfechos custam turno, custam token e custam sua paciência

É o mesmo princípio de quando você conversa com outro dev sobre o código: ninguém traduz o nome da função no meio da conversa, né? A instrução é em português, o símbolo é o símbolo

Como fixar o idioma e o padrão híbrido no Claude Code

Passo a passo curto, tudo verificável na documentação oficial (que, aliás, já está publicada em português em code.claude.com/docs/pt, além do inglês e de outros idiomas)

1. Defina a chave language no settings.json, com o idioma em linguagem natural

{
  "language": "portuguese"
}

Essa configuração define o idioma em que o Claude responde. Quando ela não está definida, o Claude responde no idioma em que você escreve

O erro comum deste passo: achar que isso traduz a ferramenta. Não traduz, a interface continua em inglês

2. Escolha o escopo certo do arquivo, porque são três e eles não são a mesma coisa:

• ~/.claude/settings.json: usuário, vale para todos os seus projetos
• .claude/settings.json: projeto, versionado com o time
• .claude/settings.local.json: pessoal, fora do controle de versão

O erro comum deste passo: cravar sua preferência pessoal de idioma no .claude/settings.json e commitar isso pro time inteiro. Se é gosto seu, vai no escopo de usuário ou no .local

3. Escreva a regra do híbrido no CLAUDE.md, que é o arquivo markdown que o Claude Code lê no início de toda sessão pra receber instruções persistentes

## Idioma

Responda em português do Brasil.
Não traduza identificadores: nome de função, variável, rota,
comando e mensagem de erro ficam exatamente como estão no repositório.
Código, nomes de arquivo e mensagens de commit permanecem em inglês.

Vale entender COMO esse carregamento acontece: no lançamento, o Claude Code carrega todo CLAUDE.md do diretório de trabalho e de cada diretório pai. O arquivo de um subdiretório é carregado sob demanda, quando ele lê arquivos ali

E tem escopo aqui também: ~/.claude/CLAUDE.md guarda preferências pessoais que valem em todos os projetos, e o CLAUDE.md na raiz do repositório guarda as instruções compartilhadas com o time

O erro comum deste passo: escrever a regra num subdiretório fundo e estranhar que ela não valeu pra sessão toda

4. Cuide da manutenção com os atalhos certos:

• comece a mensagem com # para adicionar uma memória: ele abre a escolha de em qual arquivo de memória salvar
• /memory abre os arquivos de memória pra edição dentro da sessão
• /init gera o CLAUDE.md e, se o repositório já tiver um AGENTS.md, lê esse arquivo e incorpora as partes relevantes. Ele também lê configs de outras ferramentas, como .cursorrules e .windsurfrules

O erro comum deste passo: rodar /init num repo que já tem contexto escrito achando que vai perder tudo. Ele aproveita o que existe

5. Se quiser mexer em tom e formato, use /config na opção Output style, e a escolha fica gravada no campo outputStyle em .claude/settings.local.json

Mas atenção: o output style muda COMO o Claude responde (papel, tom, formato), não o que ele sabe

O erro comum deste passo: confundir output style com configuração de idioma. São coisas diferentes, e uma não substitui a outra

O híbrido não é gambiarra: é o formato natural de usar a ferramenta

Repara numa coisa: o híbrido não é um truque que você inventa pra contornar limitação

Ele é o jeito que a ferramenta já funciona hoje

A interface é exibida em inglês, os comandos têm nome em inglês, e o seu raciocínio sobre o problema continua saindo em português

Essas duas coisas não brigam entre si, elas convivem na mesma sessão sem drama

O que faz diferença é ONDE cada coisa mora: a instrução vai na língua que você domina, o termo técnico vai literal como está no repositório, e a regra disso tudo fica escrita no CLAUDE.md pra você não depender da sua memória a cada sessão nova

E tem um efeito colateral bacana: o que você escreve em português (descrição do problema, objetivo, restrição) vira insumo pro contexto do projeto, não obstáculo

Se a comparação entre usar um fluxo pronto e montar seu próprio fluxo de prompts te interessa, esse recorte também aparece por lá

Veredito: faz diferença, mas não a que você imagina

Vamos ao que a evidência sustenta, e só isso

Custo em tokens muda, mas por causa do modelo: o tokenizer novo a partir do Claude 4.7 gera cerca de 30% mais tokens pro mesmo texto que os modelos anteriores. Se você tem contagem antiga anotada num canto, ela envelheceu. Reconte no modelo que você usa

A interface segue só em inglês: menus, comandos e mensagens de status são exibidos em inglês independentemente da sua preferência de idioma. A localização de UI é um pedido em aberto no repositório oficial, a issue #66637, aberta em 09/06/2026 e ainda aberta. A configuração de idioma afeta as respostas do Claude, não a interface

A documentação já está em português: então a barreira do inglês pra APRENDER a ferramenta caiu

E tem uma análise que eu achei topzera: um desenvolvedor esloveno pegou os próprios prompts de uso diário com o Claude Code pra testar justamente se prompt em inglês rende mais que prompt no idioma nativo

Foram 2.319 prompts na primeira contagem, e 1.899 depois de um filtro mais estrito, que descartou log colado, saída de ferramenta e turno gerado por máquina

A conclusão dele: escrever no idioma em que pensa mais rápido, manter os termos técnicos literais como estão no repositório, escrever as instruções reutilizáveis em inglês e investir o esforço poupado em objetivos e restrições claros

O motivo é a melhor parte: os prompts fracos eram VAGOS, não estrangeiros

Então, pra quem é cada opção?

• Português puro: pra quem pensa em português e trabalha sozinho ou num time que também fala português. Só cuide dos identificadores
• Inglês puro: pra quem tem inglês confortável e escreve instrução que vai ser versionada e lida por gente de fora
• Híbrido: pra praticamente todo mundo aqui. É o que junta clareza de raciocínio com fidelidade ao código

Conclusão

A regra do híbrido cabe numa frase: instrução no idioma que você domina, termo técnico exatamente como está no repositório

O resto é ruído de internet, e boa parte do debate sobre prompt em português ou inglês some quando você percebe que o problema real do prompt ruim é falta de objetivo e de restrição, não de sotaque 😀

Próximo passo concreto, na ordem: abre o settings.json, escolhe o escopo (usuário, projeto ou local), define a chave language, registra a regra de idioma no CLAUDE.md e mede o custo do seu prompt no modelo que você usa de verdade antes de confiar em contagem velha

É meia hora de ajuste que vale pra todas as sessões que vierem depois

até o próximo post!