Como usar o Claude Sonnet 5.5 em tarefas longas sem perder o contexto

Fala aí, beleza? Tarefa grande não cabe em um pedido só, e quem já tentou sabe disso 😛

O que some entre uma sessão e outra não é a inteligência do modelo, é o estado do trabalho: o que já foi feito, o que falta e o que foi decidido no caminho

A Anthropic lançou o Claude Sonnet 5.5 em 28/09/2026, e a página oficial cita trabalho de longo horizonte como uma das forças dele

Porém modelo bom sozinho não resolve continuidade…

Então neste post eu te mostro um método pra quebrar um objetivo grande em etapas verificáveis, guardar o progresso por escrito e retomar sem perder contexto

Bora ver na prática?

Por que o Sonnet 5.5 serve para tarefas de longo horizonte?

A página oficial do Sonnet 5.5 diz que ele é forte em trabalho de longo horizonte

O exemplo que ela dá é curioso: é o primeiro Sonnet a zerar Pokémon Red usando apenas capturas de tela, haha

Tem também o AA-Briefcase, um benchmark de trabalho de conhecimento de longo horizonte

Nele, o Sonnet 5.5 no esforço Medium supera a melhor nota do Sonnet 5 com cerca de um nono do custo por tarefa

Tome cuidado com a leitura desse dado: é um número informado no anúncio oficial, não é posição em ranking

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

Os números de base do modelo ficam assim:

Junto com o lançamento, a Anthropic ampliou os limites de uso no Chat, no Cowork, no Claude Code e na Claude Platform, pra comportar o consumo maior de tokens nos níveis de esforço mais altos

Aí vem a tentação: "1 milhão de tokens, cabe tudo, beleza"

Se liga nisso: janela grande não substitui estado externo

Que estado externo? São arquivos no disco que registram o andamento do trabalho, fora da conversa

Sem eles, o agente perde a memória entre sessões, e isso vira funcionalidade incompleta, trabalho duplicado ou tarefa declarada pronta antes da hora

O que você precisa antes de começar?

A lista é curta:

• Claude Code instalado e com acesso ao Sonnet 5.5
• Um repositório git no projeto: cada etapa concluída vira um commit, e o histórico vira parte da memória do trabalho
• Um objetivo descrito em termos de resultado verificável: "melhorar o sistema" não serve, "usuário consegue exportar relatório em CSV" serve

Esse último ponto é o mais importante de todos

Se você não consegue dizer como vai conferir que ficou pronto, o modelo também não consegue 🙂

Passo a passo: como organizar uma tarefa longa no Claude Sonnet 5.5

O método segue o padrão que a Anthropic descreve no artigo sobre harnesses para agentes de longa duração

A ideia central: um agente inicializador roda uma vez e prepara o ambiente, e depois sessões de agente de código avançam de forma incremental

É como montar o canteiro de obra antes de levantar parede: primeiro organiza tudo, depois cada dia de trabalho sabe exatamente onde parou

1. Rode uma sessão inicializadora (só uma vez)

Nessa primeira sessão, o objetivo não é programar funcionalidade nenhuma

É preparar o terreno: a lista de funcionalidades em feature_list.json, o repositório git, o arquivo de progresso claude-progress.txt e um init.sh pra partida rápida de cada sessão

Um pedido nessa linha funciona bem (exemplo de prompt, adapte ao seu projeto):

Esta é uma sessão de preparação, não implemente nenhuma funcionalidade
Crie feature_list.json com todas as funcionalidades do objetivo abaixo
Crie claude-progress.txt para registrar o andamento de cada sessão
Crie init.sh para a partida rápida das próximas sessões
Faça o commit inicial

Objetivo: sistema de relatórios em que o usuário faz login com e-mail e senha e exporta relatório em CSV

O erro comum deste passo: fazer a lista em Markdown

No artigo, a lista fica em JSON justamente porque o modelo corrompe esse formato com menos facilidade que Markdown

2. Escreva cada item da lista como algo testável

Cada funcionalidade precisa de um critério claro de pronto

O JSON abaixo é só um exemplo ilustrativo de estrutura, não é o formato oficial do artigo:

{
  "funcionalidades": [
    {
      "id": 1,
      "descricao": "Usuário faz login com e-mail e senha",
      "criterio_de_pronto": "Teste de login passa com credenciais válidas e falha com senha errada",
      "concluida": false
    },
    {
      "id": 2,
      "descricao": "Usuário exporta relatório em CSV",
      "criterio_de_pronto": "Arquivo CSV gerado com as colunas definidas e teste de exportação passando",
      "concluida": false
    }
  ]
}

O erro comum deste passo: item vago tipo "melhorar a autenticação"

Item vago deixa espaço pro modelo declarar pronto antes da hora, porque não tem como conferir

3. Coloque as regras permanentes no CLAUDE.md da raiz

Padrão de código, comando de teste, o que nunca pode ser feito (os rm -rf da vida)… tudo isso vai no CLAUDE.md da raiz do projeto

E por que na raiz?

Porque depois do /compact o Claude Code relê esse arquivo do disco, enquanto o que entrou só pela conversa acaba resumido

O erro comum deste passo: deixar regra importante num CLAUDE.md de subpasta

Esse só recarrega quando o Claude lê arquivos daquela pasta, então a regra pode simplesmente não estar lá quando você precisa

4. Faça uma funcionalidade por sessão, com teste, nota e commit

Cada sessão de código pega uma funcionalidade da lista, implementa, roda os testes, registra uma nota em claude-progress.txt e faz commit com mensagem descritiva

Exemplo de pedido pra fechar a sessão:

Rode os testes da funcionalidade 2
Se passarem, marque como concluída no feature_list.json
Registre no claude-progress.txt o que foi feito, o que ficou pendente e as decisões tomadas
Faça commit com uma mensagem que descreva a funcionalidade

O erro comum deste passo: pedir três ou quatro funcionalidades de uma vez

Aí a sessão mistura tudo, o commit fica genérico e você perde o rastro do que realmente funciona

5. Use /compact quando o histórico pesar

Conversa longa acumula muita coisa

O /compact resume o histórico da conversa e abre uma janela de contexto nova com esse resumo já carregado

O erro comum deste passo: confiar que uma decisão dita só no chat vai sobreviver ao resumo

Já vi muita decisão boa virar uma linha genérica depois de compactar, então se é importante, vai pro CLAUDE.md da raiz ou pro claude-progress.txt ANTES

6. Retome a sessão mandando ler o estado

Pra voltar ao trabalho no Claude Code tem dois caminhos:

• claude --continue (ou claude -c): retoma a última sessão
• claude --resume (ou claude -r): abre um seletor com as sessões recentes

Tem mais detalhes sobre isso no post de como retomar a sessão do Claude Code

E logo na abertura, mande ler o estado:

Leia claude-progress.txt, feature_list.json e o log do git
Me diga qual é a próxima funcionalidade pendente antes de começar

O erro comum deste passo: abrir sessão nova e sair pedindo código sem mandar ler nada

O modelo começa no escuro e a chance de refazer algo que já estava pronto é enorme

Problemas comuns em tarefas longas e como corrigir

O artigo da Anthropic aponta três sintomas clássicos, e todos têm a mesma causa: falta de estado externo

Funcionalidade incompleta: por que acontece?

A sessão acaba no meio e a próxima não sabe o que faltava

Solução: a nota em claude-progress.txt registra o que ficou pendente, e a lista em JSON mostra que o item ainda não foi marcado como concluído

Trabalho duplicado: como evitar?

Sem registro, o modelo reimplementa algo que já existia

Solução: commit por etapa e leitura do log do git na abertura de cada sessão, assim o histórico mostra o que já foi feito

Tarefa declarada pronta antes da hora: o que fazer?

É o clássico "pronto!" que não passa no primeiro teste 😀

Solução: item da lista com critério verificável e teste rodando antes de marcar como concluído

Como prevenir os três de uma vez?

Regra simples: toda sessão fecha atualizando o progresso e fazendo commit

Sem exceção, mesmo quando a sessão foi curta

O Claude Code tem outros mecanismos de memória que ajudam: a leitura de AGENTS.md do repositório e a auto memory, que são notas que o próprio Claude grava a partir das suas correções e preferências

São um apoio massa, mas não substituem o arquivo de progresso: eles guardam preferências e contexto, enquanto o claude-progress.txt guarda onde o trabalho parou

Quando usar o Sonnet 5.5 e quando subir para o Opus 5.5?

O posicionamento oficial é bem claro:

E aqui o método se conecta direto com a escolha do modelo

Quando você quebra um objetivo grande em etapas bem delimitadas, com critério de pronto, está colocando a tarefa longa justamente no terreno onde o Sonnet rende

E pela metade do preço do Opus 5.5 na API

Agora, se a tarefa é aberta de verdade, sem como definir etapas antes de começar, e depende de julgamento o tempo todo, o próprio posicionamento da Anthropic aponta o Opus 5.5 como claramente mais forte

Na prática: tarefas de várias etapas no Claude Cowork

Antes de tudo, deixando claro: o que eu mostro aqui é experiência com o Claude Cowork, não é teste do Sonnet 5.5 e não é instrução de Claude Code

Mas a lógica de trabalho em várias etapas com resultado verificável no fim é a mesma, por isso vale trazer

No vídeo abaixo eu mostro o Cowork organizando 250 thumbnails da minha pasta de Downloads (que estava uma bagunça, haha)

Pedi pra ele agrupar por vídeo/tema, criar subpastas, renomear de forma descritiva, identificar a versão mais elaborada de cada thumbnail e gerar um arquivo MD com a lista de vídeos e quantas versões cada um tinha

E um detalhe que tem TUDO a ver com este post: pedi explicitamente pra ele mostrar o plano antes de mover qualquer arquivo

O Cowork montou o plano de tarefas primeiro e só executou depois que eu confirmei

Ao final, ele entregou um relatório em Markdown resumindo tudo que foi feito, parecido com os artefatos da versão web do Claude

Ou seja: plano antes, execução em etapas, registro escrito no fim

No outro caso, criei uma skill própria de auditoria de SEO descrevendo o passo a passo: abrir o site, checar title tags e meta description, checar sitemap.xml e robots, rodar no PageSpeed, buscar as três keywords principais e gerar relatório

Quando testei num site, o relatório apontou 16 problemas, incluindo um crítico: idioma declarado como inglês em vez de português e ausência de URL canônica

De novo o mesmo princípio: cada etapa é conferível, e o resultado final dá pra checar item por item

Algumas coisas que percebi usando:

• Enquanto ele organizava as thumbnails eu fui fazendo outras coisas em paralelo, já que o processo roda em segundo plano
• Dá pra pausar, enfileirar prompts novos e adicionar informação no meio da execução, bem parecido com qualquer chat de IA (se quiser ir mais fundo, tem um post sobre organizar a fila de tarefas)
• No começo ele pede permissão pra quase toda ação, e depois de usar bastante passa a interromper menos
• A conversa mostra o progresso da execução, mas nem sempre deixa claro quando está montando contexto pra tarefa

E um ponto que eu reforço no vídeo: cada tarefa é única

A estrutura de pastas que funcionou num caso não necessariamente se repete no outro, então tem que avaliar cada situação

Próximo passo: comece pela lista de funcionalidades

Recapitulando: o que mantém o contexto numa tarefa longa é o estado escrito em arquivo, não a memória da conversa

O Claude Sonnet 5.5 tem força em longo horizonte e janela de 1.000.000 de tokens, mas quem garante a continuidade é o feature_list.json, o claude-progress.txt, o CLAUDE.md da raiz e o histórico do git

Então o próximo passo é concreto:

1. Abra o projeto
2. Rode a sessão inicializadora criando feature_list.json e claude-progress.txt
3. Faça só a primeira funcionalidade hoje, com teste e commit

Só uma, beleza? O resto fica pra próxima sessão, e ela vai saber exatamente de onde continuar =)

Se testar o método, me conta como foi que eu quero saber!

Até o próximo post!