---
title: "Como revisar prompts e harness antes de migrar para Claude Opus 5"
locale: pt
category: how_to
category_name: "Como Fazer"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/claude-opus-5-verification-and-migration-guide
published_at: 2026-07-28T11:42:11+09:00
---

# Como revisar prompts e harness antes de migrar para Claude Opus 5

> Distingue as características do Claude Opus 5 alegadas no material fornecido das informações verificáveis e explica como reformular prompts, harnesses e sistemas de avaliação ao adotar uma nova geração de modelos. A disponibilidade, os preços e os nomes dos modelos devem ser confirmados na lista oficial de modelos e na tabela de preços da Anthropic.

## Key Points

- As datas de lançamento, os preços e o desempenho de Claude Opus 5, Fable 5 e Sonnet 5 apresentados no material fornecido devem ser confirmados de forma independente em fontes oficiais antes do uso.
- Em vez de simplesmente copiar os prompts existentes para um novo modelo, é preciso medir novamente a qualidade, o custo e a latência com dados de trabalho reais.
- Instruções redundantes de verificação e chamadas ilimitadas de subagentes podem aumentar o custo e o tempo de execução sem melhorar os resultados.
- Separar instruções do sistema, regras do projeto, Skills carregadas quando necessário e referências técnicas facilita o gerenciamento do contexto.
- Mais do que a posição em benchmarks, avaliações próprias que reflitam as tarefas reais e o custo das falhas da organização oferecem uma base mais direta para escolher o modelo.

O material fornecido apresenta Claude Opus 5 como um modelo voltado para tarefas cotidianas de agentes e ambientes empresariais e afirma que, na nova geração de Claude, é necessário reformular os prompts e harnesses existentes. No entanto, **as datas de lançamento, os preços e o desempenho de Claude Opus 5, Fable 5 e Sonnet 5, bem como as declarações de parceiros mencionadas no material, não puderam ser verificados de forma independente apenas com as informações fornecidas neste texto.** Em particular, é necessário primeiro confirmar na lista oficial de modelos se `Fable` é um nome oficial de modelo da Anthropic.

Portanto, em vez de repetir essas informações de lançamento como fatos confirmados, este documento distingue e organiza os itens que precisam ser verificados na documentação oficial e os procedimentos de validação que podem ser aplicados a uma migração real de modelo.

## Informações de lançamento que devem ser verificadas primeiro

Antes de aplicar um novo modelo à API, ao aplicativo Claude ou ao Claude Code, é necessário comparar os itens a seguir com a documentação oficial da Anthropic e com a tela de seleção de modelos do serviço utilizado.

| Item a verificar | Alegação do material fornecido | Verificação necessária |
|---|---|---|
| Nome dos modelos | Claude Opus 5, Fable 5, Sonnet 5 | Nomes exatos dos produtos e IDs dos modelos na lista oficial |
| Datas de lançamento | 9 de junho, 30 de junho e 24 de julho, respectivamente | Ano e datas no anúncio oficial e no histórico de alterações |
| Preço do Opus 5 | 5 dólares para entrada, 25 dólares para saída/1 milhão de tokens | Tabela oficial de preços da API e cobranças separadas por lote, cache e contexto longo |
| Modelo padrão no produto | Novo modelo padrão do Claude Max | Aplicabilidade por região, plano e cliente |
| Função de cada modelo | Divisão entre tarefas autônomas de longa duração, tarefas cotidianas e tarefas leves | Descrições oficiais dos modelos e resultados de avaliações em trabalhos reais |
| Melhoria de desempenho | Melhoria em uma proporção específica em relação ao modelo anterior | Tarefas de avaliação, tamanho da amostra, critérios de medição e texto original do parceiro |

Se o nome ou o preço de um modelo não constar na documentação oficial, ele não deve ser usado nas configurações da API nem nos cálculos de orçamento. Caso sejam utilizados provedores de nuvem ou serviços de revenda, o ID do modelo, o preço e a data de disponibilização também podem ser diferentes dos oferecidos diretamente pela API da Anthropic.

## Critérios de decisão que devem mudar na migração de modelo

### 1. Medir a eficiência por tarefa, não apenas o desempenho máximo

Processar todas as solicitações com o modelo mais caro pode aumentar rapidamente os custos quando um agente chama repetidamente diversas ferramentas e subagentes. O modelo deve ser escolhido não pelo nome ou pela categoria, mas pela análise conjunta dos seguintes indicadores.

- **Taxa de sucesso:** proporção de resultados que atendem aos requisitos sem correções humanas
- **Custo total:** custo que inclui não apenas a solicitação inicial, mas também novas tentativas, chamadas de ferramentas e chamadas de subagentes
- **Tempo de conclusão:** tempo que inclui a espera e o período de revisão e correção humana
- **Custo da falha:** impacto causado pela falha, como vulnerabilidades de segurança, implantações incorretas ou análises incompletas
- **Consistência:** grau de variação dos resultados ao repetir o mesmo tipo de tarefa

O custo por tarefa não deve ser avaliado apenas pelo preço unitário dos tokens. Conceitualmente, ele pode ser calculado da seguinte forma.

`Custo total por tarefa = custo do modelo principal + custo dos subagentes + custo das ferramentas + custo das novas tentativas + custo da revisão humana`

### 2. Separar benchmarks públicos de avaliações próprias

Benchmarks públicos são um ponto de partida para comparar as características gerais dos modelos, mas não garantem o sucesso em uma base de código, formato de documento ou regra de negócio específicos. A organização deve criar seu próprio conjunto de avaliação com tarefas reais anonimizadas.

Um bom conjunto de avaliação inclui os seguintes casos.

- Tarefas representativas que devem ser concluídas normalmente
- Casos-limite em que o modelo costuma errar
- Tarefas com requisitos ambíguos que exigem perguntas adicionais
- Tarefas que exigem chamadas de ferramentas ou verificação de materiais externos
- Tarefas de alto risco que devem ser interrompidas ou submetidas à aprovação humana
- Tarefas que exigem salvar e restaurar o estado durante execuções prolongadas

Para possibilitar a comparação, devem ser aplicados a cada modelo as mesmas entradas, ferramentas, limites de tempo e critérios de sucesso. É mais seguro registrar a taxa de sucesso e a distribuição de custos de várias execuções repetidas do que se basear em um ou dois resultados impressionantes.

### 3. Avaliar o modelo e o harness como um único sistema

**Harness** é o ambiente de execução que envolve o modelo. Ele inclui o prompt de sistema, as instruções do projeto, a busca, a memória, as ferramentas, as Skills, os subagentes, o gerenciamento de permissões e a lógica de validação e novas tentativas.

Mesmo o mesmo modelo pode gerar resultados diferentes dependendo do harness. Por exemplo, se o próprio modelo escreve e executa testes e o harness também impõe a mesma validação, o trabalho pode ser duplicado. Por outro lado, é arriscado deixar sob o julgamento autônomo do modelo até mesmo etapas que exigem controles determinísticos, como aprovação de implantação ou verificação de segurança.

O princípio central é **distinguir o raciocínio que o modelo executa bem dos controles que o sistema deve obrigatoriamente garantir**.

## 6 pontos a verificar nos prompts e no harness

### 1. Remover experimentalmente instruções duplicadas de validação e nova verificação

Excluir incondicionalmente frases como `após concluir, verifique tudo novamente` não é necessariamente a resposta correta. Primeiro, acompanhe se as validações executadas espontaneamente pelo novo modelo se sobrepõem às etapas de validação do harness.

- Se a revisão do próprio modelo apenas se repetir sem melhorar a qualidade, reduza o prompt.
- Mantenha no harness verificações que possam ser automatizadas, como testes, validação de esquema e análise estática.
- Não substitua pela autovalidação do modelo a aprovação de tarefas de alto risco, como pagamentos, implantações e exclusão de dados.

### 2. Definir condições e limites para chamadas de subagentes

Subagentes são úteis para pesquisas paralelas ou para separar áreas especializadas, mas delegar até mesmo tarefas pequenas aumenta os custos e a latência. É possível especificar políticas como estas.

- Usar subagentes apenas em tarefas que possam ser divididas de forma independente.
- Limitar a quantidade que pode ser executada simultaneamente em uma solicitação.
- Fornecer a cada subagente um resultado esperado e uma condição de encerramento claros.
- Impedir que vários agentes pesquisem o mesmo material de forma duplicada.
- Obter aprovação humana se o custo ou o tempo estimado ultrapassar o limite.

### 3. Converter regras de proibição detalhadas em critérios de decisão

Listas longas de proibições podem entrar em conflito entre si ou não contemplar situações novas. Em áreas de baixo risco, como estilo, pode-se permitir que o modelo leia o contexto ao redor e faça seu próprio julgamento.

- Prescritivo: `Nunca escreva docstrings com vários parágrafos.`
- Delegação de julgamento: `Siga a densidade de comentários, o formato das docstrings, a nomenclatura e os padrões idiomáticos do código existente.`

No entanto, regras com alto custo de violação, como as relacionadas ao tratamento de dados pessoais, à segurança e às obrigações legais, devem ser mantidas por meio de restrições explícitas e verificações programáticas.

### 4. Especificar diretamente o tamanho da resposta e o formato de saída

Os recursos usados no raciocínio e o tamanho da resposta exibida ao usuário não são o mesmo conceito. Mesmo que o cliente ofereça `effort` ou uma opção semelhante de intensidade de raciocínio, quando uma resposta curta for necessária, as condições de saída devem ser definidas separadamente.

Alguns exemplos:

- `Apresente primeiro a conclusão e organize os fundamentos em no máximo três itens.`
- `Escreva a resposta final em no máximo 500 caracteres.`
- `Retorne apenas um objeto JSON válido, sem explicações.`
- `Informe apenas os arquivos alterados, os principais motivos e os riscos restantes.`

### 5. Recalibrar a intensidade de raciocínio com tarefas reais

Não aplique diretamente ao novo modelo a intensidade de raciocínio ou o valor padrão de effort usado no modelo anterior. Meça a curva de custos começando por uma configuração baixa e aumentando-a apenas quando a qualidade for insuficiente.

| Tipo de tarefa | Direção da configuração inicial | Condição para aumentar |
|---|---|---|
| Classificação e conversão de formato | Começar em nível baixo | Quando erros de esquema ou omissões se repetirem |
| Documentação geral e alterações de código | Comparar níveis intermediários | Quando dependências entre vários arquivos forem ignoradas |
| Depuração complexa | Testar nível intermediário ou superior | Quando a taxa de sucesso da análise de causa e da validação for insuficiente |
| Tarefas prolongadas de agentes | Medir por etapa | Em trechos de alta dificuldade que exijam replanejamento e recuperação |

Como os nomes exatos das opções e o escopo de suporte podem variar conforme a versão da API e o produto, é necessário consultar a documentação oficial.

### 6. Dividir o contexto por função e revelá-lo progressivamente

Se todas as instruções forem colocadas em um único prompt de sistema ou arquivo `CLAUDE.md`, até mesmo informações irrelevantes poderão ser incluídas em todas as solicitações. A seguinte estrutura hierárquica é prática.

1. **Instruções do sistema e do produto:** regras sempre necessárias, como função, limites de segurança e contrato de saída
2. **Instruções leves do projeto:** comandos de compilação, estrutura de diretórios e métodos de trabalho comuns
3. **Skills carregadas quando necessário:** procedimentos condicionais, como implantação, alterações no banco de dados e frameworks específicos
4. **Referências técnicas:** esquemas de API, exemplos de código, documentos de design e especificações testáveis

Isso pode ser chamado de **divulgação progressiva**. O modelo deve pesquisar ou carregar os materiais necessários para a etapa atual, mas é preciso registrar quais materiais foram utilizados para garantir a reprodutibilidade e a auditabilidade.

## Procedimento de migração recomendado

### Etapa 1: Fixar o estado atual

Salve os prompts, as versões das ferramentas, a taxa de sucesso, o uso de tokens, a latência e os casos de falha do modelo existente. Sem uma linha de base, é difícil determinar se o novo modelo realmente apresentou melhorias.

### Etapa 2: Validar as informações e permissões do modelo

Verifique o ID oficial do modelo, o preço, o limite de contexto, o suporte a ferramentas e a política de retenção de dados. No ambiente de testes, restrinja as permissões de gravação, exclusão e implantação.

### Etapa 3: Testar o harness existente sem alterações

No início, não altere tudo de uma só vez. Substituir apenas o modelo e compará-lo com a linha de base permite isolar o impacto da mudança de modelo.

### Etapa 4: Remover instruções duplicadas uma por uma

Remova um tipo de cada vez: instruções de validação, regras de estilo excessivamente detalhadas, exemplos desnecessários e referências sempre injetadas. A cada alteração, meça novamente a qualidade e o custo.

### Etapa 5: Criar uma política de roteamento

Escolha o modelo com base na dificuldade da tarefa, no risco, no contexto esperado e no limite de tempo. As funções de cada modelo sugeridas pelo material fornecido devem ser testadas como hipóteses após a confirmação dos nomes oficiais e do desempenho, e não devem ser adotadas diretamente como política operacional.

### Etapa 6: Implantar primeiro para um tráfego limitado

Aplique inicialmente a alguns usuários ou a tarefas sem risco. Amplie o escopo após observar a taxa de falhas, as novas tentativas, a quantidade de subagentes, os erros de ferramentas e o tempo gasto em correções humanas.

## Checklist operacional

- [ ] Confirmei os nomes oficiais dos modelos e seus IDs na API.
- [ ] Confirmei as tarifas realmente aplicáveis a entrada, saída, cache, lote e outros itens.
- [ ] Há um conjunto próprio de avaliação composto por tarefas reais.
- [ ] As etapas de validação do modelo e do harness não são duplicadas.
- [ ] Há critérios para chamadas de subagentes, limite de execuções simultâneas e teto de orçamento.
- [ ] O tamanho da resposta e o esquema de saída foram especificados.
- [ ] Comparei qualidade, custo e latência em cada nível de intensidade de raciocínio.
- [ ] Tarefas de alto risco ainda contam com verificações determinísticas e aprovação humana.
- [ ] O contexto está separado entre instruções permanentes, Skills e referências.
- [ ] O modelo e as configurações anteriores estão preparados para rollback.

## Conclusão

O ponto central da migração para um novo modelo não é tornar os prompts incondicionalmente mais curtos nem ampliar incondicionalmente a autonomia. O essencial é **primeiro confirmar as informações oficiais do produto e, por meio de avaliações com tarefas reais, redefinir as funções do modelo e do harness**.

Os números e nomes relacionados ao Claude Opus 5 no material fornecido devem ser tratados como informações provisórias até que suas fontes oficiais sejam confirmadas. Ainda assim, a remoção de validações duplicadas, a limitação de subagentes, contratos de saída claros, a divulgação progressiva do contexto e o roteamento baseado em avaliações próprias são princípios de migração aplicáveis independentemente da geração do modelo.

## FAQ

### O Claude Opus 5 é um modelo lançado oficialmente?
Os materiais fornecidos apresentam a data de lançamento e o preço, mas essas informações não foram verificadas de forma independente apenas com base no conteúdo deste texto. Até que o nome exato do modelo e o ID do modelo sejam confirmados na lista oficial de modelos da Anthropic, no anúncio e no console da API, é mais seguro não tratá-las como informações definitivas sobre o produto.

### Fable 5 é um nome de modelo oficial da Anthropic?
Não é possível confirmar apenas com os materiais fornecidos. Como a Anthropic pode usar IDs de modelo da API ou nomenclaturas diferentes conforme o serviço, mesmo quando os nomes dos produtos são semelhantes, é necessário verificar na lista oficial de modelos se a denominação `Fable 5` realmente existe.

### Ao mudar para um novo modelo Claude, é preciso excluir todos os prompts existentes?
Não. Primeiro, deve-se realizar uma avaliação de referência com as configurações existentes e, depois, remover uma a uma as instruções de verificação duplicadas ou as regras de estilo desnecessárias, comparando a qualidade e o custo. Os controles que o sistema deve garantir, como verificações de segurança, validação do esquema de saída e aprovação da implantação, devem ser mantidos.

### O que é um harness?
Um harness é o sistema que envolve o modelo de AI para executá-lo no trabalho real. Ele inclui prompt de sistema, instruções do projeto, ferramentas, busca, memória, Skill, subagent, novas tentativas, gerenciamento de permissões e procedimentos de validação automática.

### Como o uso de subagent deve ser limitado?
Deve ser usado apenas em tarefas que possam ser divididas de forma independente, estabelecendo-se limites máximos para o número de execuções simultâneas e o total de chamadas. É possível especificar os resultados e as condições de encerramento de cada subagent e projetar o sistema para exigir aprovação humana caso o custo ou o tempo estimado ultrapasse um valor-limite.

### Por que a avaliação própria é mais importante do que benchmarks públicos?
Benchmarks públicos não refletem exatamente a base de código, o formato dos documentos, o ambiente de ferramentas nem o custo das falhas de uma organização. É preciso medir a taxa de sucesso, o custo total, o tempo de conclusão e a consistência dos resultados em casos reais de trabalho para determinar qual modelo é adequado ao ambiente operacional.

### Se o modelo tiver verificação própria, os testes podem ser eliminados?
Não. A revisão feita pelo próprio modelo é um recurso auxiliar e não substitui testes, verificações de esquema, análise estática nem políticas de segurança. Especialmente em tarefas de alto risco, como implantação, pagamentos e exclusão de dados, são necessárias verificações determinísticas e aprovação humana.

### Reduzir o effort também torna a resposta automaticamente mais curta?
Não necessariamente. A intensidade do raciocínio e o tamanho da saída final podem ser objetos de controle distintos. Se for necessária uma resposta concisa, deve-se especificar diretamente no prompt o formato da resposta, como o número de caracteres, a quantidade de itens e o esquema de saída.

## Sources

- [Documentação da Anthropic: visão geral dos modelos](https://docs.anthropic.com/en/docs/about-claude/models/overview)
- [Preços da Anthropic](https://www.anthropic.com/pricing)
- [Documentação da Anthropic: visão geral da engenharia de prompts](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)
- [Documentação da Anthropic: memória do Claude Code](https://docs.anthropic.com/en/docs/claude-code/memory)

## Images

![Ilustração de cubos de IA inspecionados junto a uma barreira de alerta e ícones de verificação](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--f44d725b558668593419631e29f28834deb66ecc/ai-95ae89bc.webp)
![Modelo de IA ligado a segurança, documentos, usuários, ferramentas, controles de agentes e indicadores](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5NiwicHVyIjoiYmxvYl9pZCJ9fQ==--5ddddd2dfbbbcedb1849fbdfe606aca94f9a98af/ai-b298a672.webp)