O que é o /code-review do Claude Code? Como usar, como escolher o nível, o preço do ultra, as desvantagens e o resultado de usá-lo de verdade

O /code-review do Claude Code é um comando que lê o diff que você tem agora (as mudanças não commitadas e os commits à frente do upstream), procura bugs de correção e os relata. É uma skill embutida que já vem com o Claude Code, então dá para rodar direto do terminal, sem instalar nenhum app do GitHub. Digitar /review faz a mesma coisa.

Este artigo se baseia no texto original da documentação oficial do Claude Code (a seção "Review a diff locally" de Code Review, Find bugs with ultrareview e Commands) e no CHANGELOG para explicar o que ele faz, como escolher entre os níveis (de low a max) e o ultra, e como usar --fix e --comment. Todas as especificações descritas aqui foram conferidas no texto original em 2 de outubro de 2026. As seções 9 e 10 também mostram o que aconteceu quando rodei de fato o /code-review high no código deste site e as desvantagens que encontrei no caminho.

1. O que é o /code-review? Uma skill embutida que acha bugs no seu diff

A referência de Commands o descreve como um comando que revisa o diff atual, ou um número de PR, uma branch ou um caminho que você passar, em busca de bugs de correção. Em seguida, diz que, dependendo do modelo e do nível de effort, a revisão também cobre oportunidades de limpeza, e a página de Code Review explica que ele relata bugs de correção e também limpezas de reutilização, simplificação e eficiência. Caçar bugs é o trabalho principal; as sugestões de limpeza vêm junto conforme as condições.

A sintaxe é esta:

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [pr#|branch|path]

Vale conhecer quatro características logo de cara:

• Roda em segundo plano. A revisão roda como um subagente com a própria janela de contexto, então não enche a sua conversa. Os achados chegam à conversa quando ela termina.
• Lê o CLAUDE.md, mas não o REVIEW.md. O REVIEW.md é o arquivo de instruções da versão do Code Review como app do GitHub, explicada mais abaixo.
• /review é um alias. Segundo a documentação, antes da v2.1.223 o /review era um comando separado que lia um PR do GitHub numa única passada. Hoje é o mesmo que o /code-review.
• O nome antigo era /simplify. Segundo o CHANGELOG, o /simplify foi renomeado para /code-review na v2.1.147, e depois o /simplify voltou como um comando separado que só faz limpezas e não procura bugs.

No terminal e nas execuções com -p, os achados voltam como texto na resposta. Em apps que pedem uma lista de achados, como o app para desktop, eles aparecem numa lista em que cada item traz o local no arquivo, um resumo de uma frase e uma tag de categoria, como correctness. Quando o Claude depois os corrige, cada item é marcado como corrigido, pulado ou sem necessidade de mudança.

2. Uso básico: escolhendo o que revisar

A forma mais simples é digitar o comando sem argumentos na sessão em que você está trabalhando.

# Revisa os commits à frente do upstream + as mudanças não commitadas
/code-review

# Revisa num nível específico
/code-review high

# Passe um número de PR para revisar o pull request de um colega
/code-review high 1234

# Passe um intervalo de branches
/code-review main...my-feature

Sem argumentos, o alvo são, segundo a documentação, os commits da sua branch à frente do upstream, mais as mudanças não commitadas. Se não houver nada novo na branch nem na árvore de trabalho, não há o que relatar. Para revisar outra coisa, passe um alvo:

A não ser que você inclua ultra, tudo o que sobra depois do nível e das flags é tratado como alvo da revisão. Por exemplo, /code-review /fix-issue 123 não carrega o /fix-issue como uma segunda skill; ele lê o texto /fix-issue 123 como alvo.

Nestes casos ele roda em primeiro plano, dentro da sua conversa, e não em segundo plano: quando você o roda de novo enquanto uma revisão anterior ainda está em andamento, no modo não interativo com -p ou pelo Agent SDK, e quando você define a variável de ambiente CLAUDE_CODE_DISABLE_BACKGROUND_TASKS como 1 (o que também desliga todos os outros recursos em segundo plano).

3. Como escolher o nível: de low a max

O nível é um equilíbrio entre o quanto a revisão olha e o quanto ela precisa ter certeza dos achados. A documentação explica que, em low e medium, a revisão relata só os achados em que tem mais confiança, então aparecem menos falsos positivos, enquanto de high a max a cobertura aumenta e podem entrar achados de que a revisão tem menos certeza.

O critério prático é quanto esforço você pode gastar lendo os achados. Se quer uma checagem rápida entre uma tarefa e outra, use low ou medium; se quer pegar mais coisas antes do merge e pode descartar falsos positivos por conta própria, use high ou acima. Essa divisão segue a descrição da documentação. Que níveis mais altos gastam mais tokens é a mesma ideia do effort em geral, mas a documentação oficial não dá números de tempo nem de uso por nível. O que é o effort em si está explicado no nosso artigo sobre a configuração de effort do Claude Code.

Se você omitir o nível, ele reutiliza "o último que você digitou"

Se você não digitar um nível, a revisão usa o último nível de low a max que você mesmo digitou. Isso inclui um nível digitado numa sessão anterior; nesse caso aparece um aviso como Reusing high effort, the level you typed last time. Os detalhes:

• O nível guardado é atualizado quando você digita algo como /code-review high numa sessão interativa.
• Um nível passado numa execução não interativa com -p não é guardado.
• O ultra não usa nem atualiza o nível guardado.
• Se você nunca digitou um nível, é usado o effort atual da sessão.

A documentação também observa que, antes da v2.1.223, um /code-review sem nível sempre usava o effort atual da sessão. Se você omitir o nível esperando o comportamento antigo, ele pode rodar num nível mais alto (ou mais baixo) do que o esperado, então se isso importa, digite o nível toda vez.

4. Como usar --fix e --comment

O /rewind pode não desfazer o --fix

Esta é a parte que exige mais atenção. Segundo a documentação, as edições feitas pelo --fix numa revisão em segundo plano acontecem fora dos checkpoints da sua sessão, então o /rewind não as desfaz. Use o git para revertê-las. Quando a revisão roda em primeiro plano (uma revisão anterior ainda em andamento, -p etc.), ela edita durante o seu próprio turno, então o /rewind as restaura normalmente.

# Faça commit do estado atual antes do --fix para poder voltar fácil
git add -A && git commit -m "wip: before code-review --fix"
/code-review medium --fix

# Se não gostar do resultado, desfaça com o git
git diff
git restore .

Você também pode rodar a revisão sem --fix, ler os resultados e depois pedir "corrija só o 1 e o 3". Se não tem certeza de que todos os achados devem ser aplicados, esse é o caminho mais seguro. Os checkpoints estão explicados em detalhe no nosso artigo sobre checkpoints e /rewind.

Onde o --comment publica

• Pull requests do GitHub: publica os achados como comentários nas linhas correspondentes.
• Merge requests do GitLab: publica tudo numa única nota pelo glab, a CLI do GitLab (v2.1.257 ou posterior). Se o glab não estiver instalado, os achados só aparecem no terminal.

No GitLab, passe o MR como URL ou no formato !123. Um número solto ou um nome de branch só é tratado como MR quando o origin está no gitlab.com; numa instância do GitLab autogerenciada, a documentação manda usar a URL ou !123. Se publicar no GitHub exige autenticação como a do gh, a documentação oficial não diz, em 2 de outubro de 2026.

5. ultra: revisão na nuvem com vários agentes e preço

O /code-review ultra é uma revisão profunda que roda vários agentes revisores em paralelo numa sandbox na nuvem da Anthropic, e não na sua máquina. É um research preview chamado ultrareview e, nas contas em que está disponível, /ultrareview é um alias. A documentação oficial lista três vantagens em relação ao /code-review local:

• Mais sinal: cada achado relatado é reproduzido e verificado de forma independente, então o resultado se concentra em bugs reais, e não em sugestões de estilo.
• Cobertura maior: mais agentes exploram a mudança em paralelo, o que revela problemas que uma revisão local pode deixar passar.
• Sem usar recursos locais: roda na nuvem, então você pode seguir trabalhando no terminal enquanto isso.

Preço e execuções grátis

O ultra é cobrado dos créditos de uso (uso extra), e não do uso incluído no seu plano.

• Execuções grátis: as três do Pro e do Max são uma cota única por conta e não se renovam.
• Custo por execução: depois de usar as grátis, costuma ficar entre US$ 5 e US$ 25 em créditos de uso, conforme o tamanho da mudança. A caixa de diálogo de início mostra uma estimativa antes de cada execução.
• Como as execuções são contadas: uma execução conta assim que a sessão na nuvem começa. Interromper no meio ou uma falha também gasta uma execução grátis. As revisões pagas são cobradas pelo que de fato rodou.
• Pré-requisito: as revisões pagas não começam se os créditos de uso não estiverem ativados. Dá para conferir com /usage-credits. A confirmação para cobrar dos créditos de uso aparece uma vez por conversa.

Se "US$ 5–25" é caro ou barato depende do que você compara. Comparado com o /code-review de low a max, que fica dentro dos limites do plano sem cobrança à parte, o ultra é um gasto extra. Comparado com a versão do Code Review como app do GitHub, descrita abaixo (média de US$ 15–25 por revisão), por outro lado, as faixas de preço se sobrepõem. Mas o Code Review é outro sistema, que roda automaticamente em cada PR, e os números são expressos de formas diferentes ("média" contra "faixa típica"), então não dá para comparar diretamente.

Tempo, alcance e onde não está disponível

• Duração: normalmente de 5 a 10 minutos. Roda em segundo plano, e você pode acompanhar ou interromper com /tasks. Interromper não devolve resultados parciais.
• Alcance: sem argumentos, revisa a sua branch atual em relação à branch padrão do repositório, mais as mudanças não commitadas e em stage. É uma base diferente do "à frente do upstream" do /code-review local. Passe um nome de branch, como em /code-review ultra develop, para mudar a base.
• Revisar um PR: passe um número, como em /code-review ultra 1234, e nada é enviado da sua máquina; a nuvem clona o PR diretamente. Funciona com github.com e com o GitHub Enterprise Server conectado.
• Limites: a revisão de uma branch cobre por padrão até 500 arquivos alterados e 8.000 linhas alteradas (a documentação avisa que esses valores podem mudar).
• Onde não está disponível: exige login com uma conta do claude.ai e não está disponível pelo Amazon Bedrock, pelo Agent Platform do Google Cloud nem pelo Microsoft Foundry, nem para organizações com Zero Data Retention. Quando não está disponível, o /code-review ultra roda como revisão local.

A revisão de uma branch empacota o estado do seu repositório local e o envia para a nuvem. Mudanças não commitadas em arquivos com nomes de credenciais, como .env e *.tfvars, seguem as mesmas regras do envio para uma sessão na nuvem. Como as sessões na nuvem funcionam em geral está no nosso artigo sobre sessões na nuvem.

Publicar o resultado no PR (--post) e rodar por scripts

Ao revisar um PR do github.com com o ultra, você pode publicar o resultado no PR como um único comentário feito pela sua própria conta do GitHub (v2.1.227 ou posterior). É um comentário comum, não uma review nem uma aprovação, e o padrão é não publicar (--no-post). /code-review ultra 1234 --post deixa a publicação pré-selecionada na caixa de diálogo de início, mas a confirmação continua aparecendo antes de começar. A publicação começa quando a revisão termina, então é preciso manter a sessão aberta até o fim.

Para CI ou scripts, use o subcomando claude ultrareview. Ele espera os resultados e os escreve na saída padrão (com --json, --timeout (padrão de 45 minutos) e --post disponíveis). Já claude -p '/code-review ultra' só inicia a revisão e sai sem esperar, então você não recebe os resultados, e quando é preciso cobrar dos créditos de uso ele nem chega a começar.

# Revisa o PR 1234 com o ultra a partir de um script e recebe o resultado
claude ultrareview 1234

# Usa uma base diferente da branch padrão
claude ultrareview origin/main

6. Em que difere de recursos parecidos

O Claude Code tem vários recursos de revisão com nomes parecidos. O recurso do app do GitHub chamado "Code Review" é especialmente fácil de confundir, porque está documentado na mesma página que o comando /code-review.

• /simplify: quatro agentes verificam em paralelo a reutilização de helpers existentes, a simplificação, a eficiência e se a mudança está no nível de abstração certo, e depois aplicam as correções. Não procura bugs de correção. A página de Code Review também recomenda que, se você usava o /simplify em scripts para achar bugs, troque para /code-review --fix.
• /security-review: verifica o diff entre a sua branch atual e a branch padrão do origin em busca de vulnerabilidades como injeção, problemas de autenticação e exposição de dados. Exige um remote origin.
• Code Review (app do GitHub): depois que um Owner da organização o ativa, vários agentes na infraestrutura da Anthropic examinam um PR quando ele é aberto, a cada push ou quando alguém escreve @claude review, e deixam comentários nas linhas. É um research preview só para Team e Enterprise (indisponível para organizações com Zero Data Retention). O preço acompanha os tokens, com média de US$ 15–25 por revisão, leva 20 minutos em média e é cobrado dos créditos de uso, à parte dos limites do plano. Dá para ajustar o que ele aponta com o REVIEW.md.
• claude-code-action: roda o Claude Code em workflows do GitHub Actions no seu próprio repositório. O exemplo de revisão da documentação oficial chama a versão em plugin da skill code-review (/code-review:code-review --comment) para comentar no PR. O custo é o preço da API do Claude (ou os tokens da assinatura) mais o tempo de execução do GitHub Actions.

Separar por "onde roda, quem paga e o que olha" deixa tudo mais claro. Para checar o seu próprio diff localmente, use o /code-review; para olhar a fundo antes do merge, o ultra; para rodar automaticamente em todo PR do time, o Code Review do app do GitHub ou o claude-code-action.

7. Quando o Claude o inicia sozinho, e como impedir

O Claude pode iniciar o /code-review por conta própria. Se você pedir em linguagem comum que ele revise as suas mudanças, ele pode rodar a skill sem você digitar o comando, e uma tarefa agendada que tenha /code-review como prompt também roda uma revisão. Mas uma tarefa agendada nunca inicia o ultra (a revisão na nuvem). O ultra só roda quando você mesmo digita /code-review ultra.

Para impedir que o Claude e as tarefas agendadas o iniciem, mantendo-o disponível quando você mesmo digita, adicione o seguinte a um arquivo de configuração como ~/.claude/settings.json:

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

As revisões em segundo plano rodam como subagentes. Como os subagentes lidam com contexto e modelos está explicado no nosso artigo sobre subagentes e equipes de agentes.

8. O que usar em cada momento

A tabela comparativa da documentação oficial diz que o /code-review local serve melhor para feedback rápido enquanto você itera, e o ultra para ter confiança antes do merge de mudanças grandes. Levado para o dia a dia, fica assim:

Como as 3 execuções grátis do ultra não se renovam, compensa guardá-las para mudanças de grande impacto, ou mudanças em que a revisão local não resolveu a dúvida, e não para correções pequenas. Da mesma forma, use o /security-review quando quiser focar em vulnerabilidades e o /simplify quando quiser melhorar a legibilidade em vez de achar bugs; separar por objetivo é como a documentação os descreve.

9. Testei no código deste site

Em 2 de outubro de 2026, rodei o /code-review high no código da ferramenta de verificação de imagens de IA publicada neste site. A ferramenta lê os metadados e a procedência (C2PA) de uma imagem inteiramente no navegador, e o alvo foram quatro arquivos: a lógica da interface, a lógica de análise (um Web Worker), o controller e o template da página. Rodei no app do Claude Code para desktop (Claude Code 2.1.284 embutido, modelo Opus 5.5), logo depois de eu mesmo ter caçado bugs e corrigido cinco.

Todos os achados vieram no formato "qual arquivo, qual linha" e "qual entrada faz acontecer o quê". Conferi cada um no código-fonte da biblioteca que a ferramenta usa para ler os metadados das imagens (exifr) e em imagens de teste que eu mesmo montei, e corrigi os 9 que se mostraram reais. Os principais:

Ou seja, mesmo logo depois de eu ter procurado e corrigido coisas por conta própria, ainda havia 9 bugs de outro tipo. Os achados sobre premissas ("a biblioteca deve se comportar assim"), em especial, eram difíceis de ver sem ler o código-fonte da biblioteca. Dito isso, este é o resultado de uma única execução num único código. Ele não vai necessariamente achar bugs reais na mesma proporção toda vez, e eu não comparei com low, medium ou max, nem testei o ultra pago.

10. Desvantagens e cuidados

Pelo uso e pela leitura da documentação oficial, estes são cinco pontos de atenção:

• Gasta os seus limites. As revisões locais também saem do seu uso normal do Claude, e os níveis mais altos gastam mais. Com o ultra, depois que quem está no Pro ou no Max usa as 3 execuções grátis (no Team e no Enterprise, desde o início), você paga cerca de US$ 5–25 por execução em créditos de uso.
• Não aceite os achados sem conferir. A própria documentação diz que de high para cima podem entrar achados de menor confiança. Desta vez, 9 de 10 eram reais, mas conferir cada um ainda dá trabalho.
• O --fix não pode ser desfeito com o /rewind. As mudanças feitas em segundo plano precisam ser revertidas com o git, então faça commit antes de usar.
• Só verifica a correção do código. Não verifica se o conteúdo de textos ou configurações bate com os fatos. Por exemplo, um problema comum neste site, "o artigo diz algo diferente da especificação oficial", fica fora do alcance.
• O Claude pode iniciá-lo sozinho. Se você não quer isso, a configuração da seção 7 o limita a execuções manuais.

Minha conclusão: rodar uma vez em high depois de escrever código novo ou fazer uma mudança grande foi o uso que compensou o esforço e o consumo. Por outro lado, não serve para edições de texto nem para pequenas mudanças de configuração.

Resumo

O /code-review é uma skill embutida que revisa o seu diff local ou um PR com foco em bugs de correção. Roda em segundo plano para não interromper o seu trabalho, e o custo fica dentro do seu uso normal. Em low ou medium você recebe só achados de alta confiança; de high a max ele olha mais longe, mas é preciso separar os resultados; e, se você omitir o nível, ele reutiliza o último que você digitou.

O --fix, que vai até a correção, é prático, mas as edições em segundo plano não podem ser desfeitas com o /rewind, então fazer commit antes é o mais seguro. Quando quiser olhar mais a fundo, o ultra passa cerca de 5 a 10 minutos na nuvem e devolve só achados verificados; o Pro e o Max têm 3 execuções grátis únicas e, depois delas, cada execução custa cerca de US$ 5–25 em créditos de uso. O Code Review do app do GitHub e o claude-code-action, de nomes parecidos, são outra coisa, tanto em onde rodam quanto em quanto custam.

Quando o rodei uma vez no código deste site, 9 dos 10 achados eram bugs reais, mesmo logo depois de eu ter corrigido coisas por conta própria. É preciso conferir cada achado, mas vale muito a pena rodá-lo uma vez depois de código novo ou de uma mudança grande.

FAQ

P. Qual é a diferença entre /review e /code-review?

R. Hoje são a mesma coisa. O /review é um alias do /code-review e aceita os mesmos níveis e flags. Segundo a documentação oficial, antes da v2.1.223 o /review era um comando separado, só de leitura, que revisava um PR do GitHub numa única passada.

P. Usar o /code-review custa algo a mais?

R. De low a max, não. Na tabela comparativa da documentação oficial, o custo dele conta como uso normal. O que custa à parte é o ultra: depois das 3 execuções grátis no Pro e no Max, sai por cerca de US$ 5–25 por execução em créditos de uso.

P. As 3 execuções grátis do ultra se renovam todo mês?

R. Não. A documentação oficial descreve as três execuções do Pro e do Max como uma cota única por conta, que não se renova. Revisões interrompidas no meio ou que falham também contam como uma execução. O Team e o Enterprise não têm execuções grátis.

P. Dá para desfazer as mudanças feitas pelo --fix?

R. Use o git. As edições de uma revisão que rodou em segundo plano acontecem fora dos seus checkpoints, então o /rewind não as desfaz. Se a revisão rodou em primeiro plano (uma revisão anterior ainda em andamento, -p etc.), o /rewind consegue restaurá-las. Na dúvida, faça commit antes de usar o --fix.

P. As regras do REVIEW.md valem para o /code-review?

R. Não. O /code-review local segue o CLAUDE.md, mas não lê o REVIEW.md. O REVIEW.md é o arquivo de instruções da versão do Code Review como app do GitHub. Coloque no CLAUDE.md as regras que você quer que a revisão local siga.

Fontes

• Documentação oficial do Claude Code: Code Review (incluindo a seção "Review a diff locally")
• Documentação oficial do Claude Code: Find bugs with ultrareview
• Documentação oficial do Claude Code: Commands
• Documentação oficial do Claude Code: Claude Code GitHub Actions
• Claude Code: CHANGELOG

Todas as fontes foram conferidas no texto original em 2 de outubro de 2026. A documentação oficial avisa que o ultrareview é um research preview, e seus recursos, preços e disponibilidade podem mudar.