# Como evitar que sessões longas de programação percam o contexto? > Evite perda de contexto movendo fatos duráveis do chat para um registro compacto de tarefas, decisões, testes e checkpoints do repositório. Antes de comprimir ou trocar de modelo, restaure o estado desses artefatos em vez de reproduzir uma conversa ilimitada. Sessões longas costumam falhar por desvio, não por amnésia súbita. O agente lembra o objetivo geral, mas perde uma pequena restrição, confia em teste antigo, repete uma investigação ou edita segundo um plano que já não corresponde ao repositório. A solução é um estado externo durável, menor e mais confiável que a conversa. Trate a conversa como memória de trabalho e o repositório como fonte de verdade. Em cada checkpoint relevante, registre o que mudou, o que foi verificado, o que segue incerto e o que fazer depois. ## Acompanhe quatro tipos de contexto Separe os fatos por função para que o resumo não vire uma história indiferenciada. | Tipo | Exemplos | Local durável | |---|---|---| | Objetivo | Resultado e critérios de aceitação | Registro de tarefas | | Restrições | Compatibilidade, segurança, estilo e escopo | Registro de tarefas | | Estado do repositório | Arquivos alterados e branch atual | Controle de versão | | Evidência | Testes, logs, capturas e benchmarks | Registro de verificação | Adicione hipóteses como quinta categoria somente quando claramente marcadas. Cada hipótese deve indicar a ação mais barata para confirmá-la ou rejeitá-la. ## Mantenha um registro compacto Um bom registro cabe em uma tela. Atualize-o após marcos, não após cada mensagem. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Guarde caminhos, comandos e nomes de falha exatos. Evite um diário da conversa. ## Faça checkpoints de estados verificados Um checkpoint deve seguir um resultado reproduzível: grupo de testes aprovado, pequena alteração confirmada, resposta API verificada ou decisão sustentada por um caso. Registre arquivos não confirmados antes de trocar de modelo ou comprimir. Não diga que algo funciona porque o código foi escrito; ligue a afirmação a teste, build ou artefato observável. | Afirmação | Evidência necessária | |---|---| | Parser aceita duas chamadas | Caso com dois IDs correlacionados | | Nova tentativa é segura | Teste de idempotência com desconexão | | Refatoração preserva o comportamento | Suítes antiga e nova passam | | UI está correta | Inspeção renderizada nos tamanhos alvo | ## Recupere a fonte em vez de repetir o chat Quando um detalhe importar, reabra o arquivo, schema ou documento oficial atual. Um trecho antigo pode descrever código que já mudou. Forneça caminhos e termos de busca para inspecionar o estado vigente. Mantenha a recuperação estreita: carregue interface, implementação, teste com falha e log relevante antes do repositório inteiro. Isso preserva espaço para raciocínio. ## Comprima preservando decisões e evidências Boa compressão remove repetição, mas mantém restrições, decisões difíceis de reverter, alternativas rejeitadas e verificações. Diferencie `verified`, `observed`, `assumed` e `pending`. Não resuma um experimento fracassado como projeto final. Guarde o motivo de rejeição se a mesma abordagem puder reaparecer. ## Limite a saída das ferramentas Logs longos e arquivos gerados consomem atenção. Peça intervalos, contagens ou linhas correspondentes; guarde a saída completa como artefato e devolva um resumo com caminho. Nos testes, conserve o primeiro stack útil, a asserção e os dados do ambiente, não centenas de frames repetidos. ## Retome com um ritual determinístico Após pausa, compressão ou troca de modelo: * Leia objetivo e restrições. * Inspecione o controle de versão e mudanças recentes. * Abra os arquivos citados no estado atual. * Repita a última verificação relevante. * Confirme que a próxima ação ainda é válida. Essa rotina detecta resumos antigos antes de novas edições. ## Escolha modelos sem depender da memória Um gateway facilita a troca, mas o estado continua sob sua responsabilidade. A Atlas Cloud oferece vários protocolos em uma URL base; confira a [matriz de protocolos](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) e o [catálogo de modelos](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) antes de mover um agente ativo. Entregue ao substituto o registro, os arquivos relevantes e uma verificação recente. Não dependa de identificadores específicos do provedor sem confirmar protocolo e comportamento. ## Conclusão Sessões longas mantêm contexto quando o estado durável é compacto, baseado em evidência e fácil de recarregar. Use um registro de uma tela, checkpoints após mudanças verificadas, fonte atual em vez de chat repetido, saída limitada e retomada determinística. Uma janela maior ajuda, mas o estado externo disciplinado torna o trabalho recuperável. ## FAQ ### Uma janela de contexto maior basta para uma sessão longa? Não. Mais espaço adia a pressão, mas não garante que restrições antigas continuem visíveis nem que observações obsoletas sejam corrigidas. ### O que deve constar no registro da sessão? Objetivo, restrições, plano atual, arquivos alterados, decisões principais, verificações, riscos em aberto e a próxima ação exata. ### Quando criar um checkpoint? Após uma mudança significativa, como teste aprovado, etapa concluída, decisão de design ou descoberta que altere o plano. ### Devo colar toda a conversa em um modelo novo? Normalmente não. Forneça um checkpoint selecionado, arquivos e logs relevantes e deixe o novo modelo inspecionar o estado atual. ### Como impedir que um resumo preserve um erro antigo? Separe fatos verificados de hipóteses, anexe comandos ou caminhos como evidência e retire afirmações contrariadas por novos testes. ### Qual é a forma mais segura de retomar? Recarregue o registro, confira o controle de versão, repita a última verificação relevante e comece pela próxima ação registrada.