Introdução
Agentes de inteligência artificial voltados para programação conseguem hoje trabalhar durante horas em uma mesma tarefa. Eles exploram repositórios, leem arquivos, executam comandos, consultam documentação, modificam código e validam o resultado antes de devolver o controle ao desenvolvedor.
Essa autonomia cria um problema fácil de ignorar no início de uma sessão: toda essa atividade produz contexto. Quando um agente lê um arquivo, executa um comando ou consulta uma ferramenta, informações resultantes podem passar a disputar espaço com as instruções e decisões realmente necessárias para concluir a tarefa.
Ferramentas como Claude Code, Codex e Cursor já adotam diferentes estratégias para lidar com esse problema. Elas resumem conversas, mantêm memórias fora do histórico principal, recuperam informações sob demanda, isolam tarefas em outros agentes e tentam preservar partes do prompt em cache.
Essas técnicas fazem parte do que vem sendo chamado de context engineering, ou engenharia de contexto: decidir quais informações um modelo deve receber, quando deve recebê-las e por quanto tempo devem permanecer disponíveis.
Neste artigo, vamos entender como esse processo funciona e explorar estratégias que podemos aplicar aos nossos próprios agentes para reduzir consumo de tokens sem simplesmente remover informações importantes.
O que realmente existe dentro da janela de contexto?
Modelos de linguagem trabalham sobre uma quantidade limitada de informações representadas em tokens, pequenas unidades usadas para processar texto e outros conteúdos. A janela de contexto representa a quantidade de tokens que o modelo consegue considerar durante uma inferência.
Em um chatbot simples, podemos imaginar:
Instruções do sistema
+ mensagens anteriores
+ nova mensagem do usuário
+ resposta que será gerada
Em um agente que executa tarefas mais longas, a situação é mais complexa:
Instruções do sistema
+ regras do projeto
+ memória carregada
+ histórico da conversa
+ documentos consultados
+ resultados de buscas
+ respostas de sistemas externos
+ chamadas de ferramentas
+ nova solicitação
+ resposta que será gerada
A documentação do Claude Code, por exemplo, descreve sua janela como
contendo histórico, arquivos, saídas de comandos, CLAUDE.md, memória
automática, skills carregadas e instruções do sistema.
Isso significa que uma operação aparentemente simples pode ter custo indireto. Se pedirmos ao agente para procurar uma implementação e ele executar uma busca que devolve centenas de linhas, abrir cinco arquivos e rodar testes com uma saída extensa, boa parte desse material pode passar a disputar espaço com as informações realmente necessárias.
Quando a janela se aproxima do limite, alguma estratégia precisa ser adotada: remover informações antigas, resumi-las, iniciar uma nova sessão ou recuperar novamente informações quando forem necessárias.
Contexto, memória e cache não são a mesma coisa
Contexto é a informação disponível para o modelo naquela inferência.
Memória é uma forma de persistir informação fora do histórico imediato para que ela possa ser recuperada posteriormente.
Cache, por outro lado, não é memória semântica. Prompt caching permite reaproveitar computação associada a partes idênticas ou estáveis de um prompt. Os tokens continuam fazendo parte do contexto lógico, mas seu processamento pode ser mais barato e rápido.
Uma forma simples de visualizar essa diferença é:
Contexto = o que o modelo sabe agora
Memória = o que pode ser recuperado depois
Cache = o que já foi processado e pode ser reutilizado
Existe ainda um quarto conceito importante: retrieval, ou recuperação. Em vez de carregar todo o conhecimento disponível, o agente pesquisa uma fonte externa e insere somente os trechos relevantes.
A pergunta deixa então de ser "como colocar tudo na janela?" e passa a ser: como fazer o agente encontrar a informação certa no momento em que precisar dela?
Observational Memory (memória observacional): resumindo enquanto o agente trabalha
Uma abordagem recente que merece atenção é a Observational Memory (memória observacional), implementada pelo Mastra para agentes de longa duração.
A ideia se aproxima da maneira como registramos acontecimentos em um ambiente de trabalho. Ao final de uma reunião, normalmente não precisamos guardar cada frase pronunciada para continuar um projeto. Um registro contendo decisões, mudanças de estado e pendências costuma ser mais útil para a próxima etapa.
Na arquitetura do Mastra, dois agentes auxiliares trabalham em segundo plano. O Observer (Observador) acompanha a conversa e, quando o histórico recente atinge determinado limite de tokens, transforma mensagens antigas em observações densas e datadas. Essas observações substituem parte do histórico bruto.
Quando o conjunto de observações também cresce, entra o Reflector (Refletor). Ele reorganiza e condensa essas anotações, combina informações relacionadas e remove elementos que perderam relevância.
O contexto passa a ter aproximadamente três níveis:
Reflexões
↓
Observações condensadas
↓
Mensagens recentes em formato original
Isso cria uma diferença interessante em relação a uma compactação feita apenas quando a janela está quase cheia. A memória vai sendo construída continuamente durante o trabalho, preservando decisões e mudanças importantes antes que o histórico precise ser descartado de uma só vez.
Há também uma consequência para o prompt caching (cache de prompt). Como as observações são acrescentadas progressivamente e as mensagens recentes permanecem no final, boa parte do prefixo pode continuar estável entre chamadas. Segundo os testes publicados pelo Mastra, a implementação alcançou 94,87% de acurácia no LongMemEval com GPT-5 mini, mantendo uma janela de contexto estável. Esse número vem do benchmark divulgado pelos próprios autores e deve ser interpretado dentro dessa metodologia.
Para agentes que trabalham durante horas, essa abordagem é particularmente interessante porque combina duas preocupações que normalmente aparecem separadas: preservar memória de longo prazo e manter o contexto previsível para aproveitar cache.
Como Claude Code, Codex e Cursor lidam com o problema
Claude Code
Cada sessão do Claude Code começa com uma nova janela de contexto. Para
carregar conhecimento persistente entre sessões, a ferramenta possui
mecanismos como CLAUDE.md e Auto Memory (memória automática).
CLAUDE.md contém instruções escritas pelo desenvolvedor: convenções,
comandos importantes, regras arquiteturais e informações que o agente
deveria conhecer. A documentação recomenda mantê-lo conciso; arquivos
com mais de aproximadamente 200 linhas consomem mais contexto e podem
diminuir a aderência. Regras específicas de determinados caminhos e
skills permitem carregar parte das instruções somente quando necessário.
A memória automática segue uma estratégia interessante. O Claude Code
mantém um MEMORY.md conciso e carrega no início da sessão apenas as
primeiras 200 linhas ou 25 KB, o que ocorrer primeiro. Informações
detalhadas podem ficar em arquivos temáticos e ser lidas sob demanda.
Quando a sessão cresce, Claude Code pode limpar resultados antigos de
ferramentas e depois compactar a conversa. /compact substitui o
histórico por um resumo estruturado; instruções persistentes da raiz e a
memória automática são reinjetadas.
Subagentes também ajudam. Eles recebem janelas de contexto separadas, podendo pesquisar muitos arquivos e devolver apenas um resumo. Delegar trabalho, portanto, também funciona como isolamento de contexto.
Codex
A OpenAI descreveu em janeiro de 2026 como o agent loop do Codex acumula mensagens e resultados de ferramentas. O histórico anterior é preservado como prefixo do próximo prompt sempre que possível, favorecendo prompt caching.
Quando o contexto cresce além de determinado limite, Codex utiliza compactação. A Responses API possui um mecanismo específico que permite substituir o histórico por uma representação menor e continuar o trabalho.
A OpenAI chegou a outra conclusão útil ao projetar grandes repositórios
para Codex: é melhor fornecer ao agente um mapa do que um manual de
mil páginas. Em vez de transformar AGENTS.md em uma enciclopédia, um
arquivo pequeno pode apontar para documentação estruturada que o agente
consulta conforme a tarefa exige.
Cursor
Cursor chama abordagem semelhante de dynamic context discovery, ou descoberta dinâmica de contexto: fornecer menos informação antecipadamente e permitir que o agente encontre o restante conforme trabalha.
Resultados muito grandes de ferramentas podem ser armazenados em arquivos. Em vez de colocar milhares de linhas na conversa, o agente recebe uma referência e consulta somente as partes necessárias.
O mesmo princípio pode ser aplicado às ferramentas MCP. Em um teste A/B divulgado pelo Cursor, carregar ferramentas dinamicamente reduziu em 46,9% o total de tokens do agente nas execuções que utilizaram MCP, com variação de acordo com a quantidade de servidores instalados.
Cursor também resume conversas longas e utiliza smart condensation (condensação inteligente) em arquivos grandes, apresentando inicialmente elementos estruturais como classes, métodos e assinaturas.
Apesar das diferenças, o padrão é parecido:
manter pouco contexto permanente
↓
descobrir informações sob demanda
↓
compactar o histórico quando necessário
↓
preservar conhecimento importante fora da conversa
O melhor contexto pode ser aquele que nunca entrou na conversa
Considere um agente responsável por analisar contratos e responder a uma dúvida sobre uma cláusula específica.
Uma estratégia pouco eficiente seria abrir documentos completos, consultar anexos sucessivamente e manter todos esses conteúdos na conversa até encontrar a resposta.
Pergunta
↓
vários documentos completos
↓
anexos e resultados intermediários
↓
informação relevante
Uma alternativa é pesquisar primeiro quais partes da base têm maior probabilidade de responder à pergunta:
Pergunta
↓
Busca
↓
Índice de conhecimento
↓
Trechos mais relevantes
↓
Agente
O mesmo princípio pode ser aplicado a políticas internas, bases de atendimento ou documentação operacional. A informação permanece disponível, mas entra na janela de contexto somente quando existe uma razão para utilizá-la.
Esse é um dos usos mais naturais de RAG (Retrieval-Augmented Generation, ou geração aumentada por recuperação) em agentes.
Busca semântica, RAG e recuperação híbrida
Busca tradicional funciona muito bem quando existe um termo conhecido. Uma consulta por número de contrato, nome de produto ou identificador de cliente pode encontrar rapidamente um registro.
Em outros casos, a pergunta descreve uma intenção. Um usuário pode querer saber quais condições permitem cancelar um serviço antecipadamente sem conhecer a expressão usada nos documentos.
É aí que entram embeddings (representações vetoriais), representações numéricas que permitem comparar similaridade semântica. Documentos podem ser divididos em chunks (blocos) menores e armazenados em um índice.
Quando o agente faz uma pergunta, o sistema procura os blocos semanticamente mais próximos e entrega somente alguns resultados.
Soluções mais robustas podem combinar busca lexical e semântica. Algoritmos como BM25 ajudam a ranquear documentos por relevância textual, enquanto embeddings ajudam quando as palavras da pergunta são diferentes das usadas na fonte.
Para agentes empresariais, essa arquitetura permite consultar grandes bases de conhecimento sem carregar todo o material a cada solicitação.
Um exemplo técnico: codesearch
O mesmo princípio aparece de maneira clara no desenvolvimento de software. Um exemplo interessante é o codesearch, uma ferramenta de busca semântica criada especificamente para agentes. Ela funciona localmente como servidor MCP e combina busca vetorial com BM25, navegação por símbolos e divisão estrutural do código.
Um detalhe relevante para gestão de contexto é o comportamento das
buscas: o codesearch pode retornar primeiro metadados sobre os
resultados e deixar o conteúdo completo para uma chamada posterior. O
agente descobre onde provavelmente está a informação antes de trazer o
código para sua janela.
A ferramenta representa bem um princípio que pode ser transportado para outros domínios: primeiro localizar, depois carregar. Um agente financeiro pode localizar os registros relevantes antes de consultar detalhes; um agente de atendimento pode identificar o procedimento adequado antes de carregar o documento completo.
Outro exemplo: Graphify e busca em grafos
Uma abordagem complementar aparece no Graphify, ferramenta voltada à criação de grafos de conhecimento consultáveis. Ela pode processar código, documentos, PDFs e outros conteúdos, transformando conceitos e relações em uma estrutura persistente que pode ser consultada posteriormente.
Em vez de reler a fonte completa a cada pergunta, o agente pode consultar o grafo para descobrir quais entidades estão relacionadas, encontrar caminhos entre conceitos ou recuperar apenas um subgrafo associado à pergunta atual. A ferramenta oferece operações como query, path e explain, além de poder expor o grafo por MCP para acesso estruturado por agentes.
Documentos e outras fontes
↓
Graphify
↓
Grafo de conhecimento persistente
↓
consulta específica
↓
subgrafo relevante para o agente
Um aspecto útil para gestão de contexto é a persistência do graph.json. Depois que a estrutura foi construída, consultas posteriores podem utilizar o grafo sem exigir que todos os arquivos originais sejam lidos novamente.
O Graphify também registra a origem das relações. Conexões podem ser marcadas como EXTRACTED (extraídas), quando aparecem explicitamente nas fontes, ou INFERRED (inferidas), quando foram derivadas durante o processamento. Essa distinção ajuda o agente a tratar relações inferidas com mais cautela.
Para graph search (busca em grafos), essa abordagem é interessante porque permite responder perguntas relacionadas à estrutura do conhecimento. Em uma base empresarial, por exemplo, pode ser mais útil descobrir como uma política se conecta a um processo do que localizar apenas documentos semanticamente parecidos.
O codesearch e o Graphify representam duas formas complementares de reduzir contexto. O primeiro ajuda a localizar trechos relevantes antes de carregá-los. O segundo permite explorar conexões já estruturadas e recuperar somente a parte do grafo necessária para a pergunta atual.
Quando similaridade não é suficiente: relações e grafos
Busca semântica é eficiente para encontrar informações relacionadas a uma pergunta. Algumas tarefas, porém, dependem das relações entre entidades.
Considere um agente analisando fornecedores. Encontrar documentos que mencionam uma empresa é diferente de descobrir quais contratos estão associados a ela, quais unidades dependem desses contratos e quais processos seriam afetados por uma mudança.
Essas relações podem ser representadas como um grafo:
Fornecedor
↓ possui
Contrato
↓ atende
Unidade
↓ executa
Processo
Os nós representam entidades e as conexões registram seus relacionamentos.
Essa abordagem permite combinar recuperação semântica com conhecimento estrutural. O GraphRAG, por exemplo, explora grafos para organizar entidades e relações antes da recuperação.
No desenvolvimento de software, trabalhos como o GraphCoder aplicam ideia semelhante às relações existentes dentro de um repositório.
O uso de grafos faz mais sentido quando as relações estruturais justificam o custo adicional de criar e manter esse índice. Para muitas bases empresariais, busca textual e semântica já resolve grande parte das consultas.
Ferramentas também podem produzir contexto desnecessário
Agentes modernos utilizam ferramentas para consultar sistemas externos, pesquisar bases de dados ou executar operações. Cada resposta dessas ferramentas pode entrar no contexto.
Imagine um agente de operações que consulta um sistema para verificar pedidos atrasados. Se a ferramenta devolver centenas de campos por pedido quando apenas status, data e responsável são necessários, o modelo recebe uma quantidade de informação que pouco contribui para a decisão.
Uma boa interface para agentes deve considerar também quanto contexto cada ferramenta produz.
Agente
↓
Ferramenta
↓
Resposta completa do sistema
↓
Filtragem
↓
Informação relevante
↓
Contexto
No desenvolvimento de software, o RTK (Rust Token Killer) é um exemplo específico desse princípio. A ferramenta reformata saídas de comandos para produzir versões mais compactas antes que elas cheguem ao agente.
A mesma lógica pode ser aplicada em integrações empresariais. APIs e ferramentas destinadas a agentes podem oferecer respostas resumidas, paginação e filtros adequados à tarefa.
Existe, porém, um equilíbrio. Uma resposta excessivamente reduzida pode obrigar o agente a realizar uma segunda consulta para recuperar detalhes que foram removidos.
Por isso, a avaliação deve considerar tokens, custo e qualidade por tarefa concluída, e não apenas o tamanho de uma resposta isolada.
O que acontece quando o contexto inevitavelmente fica grande?
Mesmo com retrieval e ferramentas eficientes, tarefas longas acumulam histórico. O agente tomou decisões, modificou arquivos, recebeu correções, executou testes e descobriu informações importantes.
Em algum momento, manter tudo deixa de ser viável.
Uma solução é a compactação:
100.000 tokens de trajetória
↓
compactação
↓
Objetivo atual
Decisões importantes
Arquivos relevantes
Alterações realizadas
Testes executados
Problemas conhecidos
Próximos passos
↓
contexto muito menor
Claude Code, Codex e Cursor implementam alguma forma desse processo.
No Claude Code, /compact substitui o histórico por um resumo, enquanto
mecanismos persistentes como CLAUDE.md da raiz e Auto Memory são
reinjetados.
Cursor também resume conversas longas. Em sua estratégia de descoberta dinâmica, o histórico pode continuar acessível para recuperação: se uma informação importante tiver desaparecido do resumo, o agente pode pesquisar o material anterior.
Codex utiliza a funcionalidade de compactação da Responses API e pode fazê-lo automaticamente quando o histórico ultrapassa determinado limite.
Toda sumarização envolve escolher quais informações serão preservadas, o que cria a possibilidade de perda de contexto. Se uma conversa contém vinte decisões e o resumo preserva dezenove, a informação descartada pode ser justamente a necessária horas depois.
Handoff: começar uma sessão nova sem começar do zero
Uma técnica simples que tenho utilizado é pedir ao agente para criar um documento de handoff (passagem de contexto), antes de encerrar uma sessão longa.
# Objetivo
# Estado atual
# Arquivos importantes
# Decisões tomadas
# Alterações realizadas
# O que já foi tentado
# Problemas conhecidos
# Próximos passos
Depois podemos iniciar uma sessão limpa e pedir ao novo agente para ler esse documento.
Em vez de carregar 120 mil tokens de trajetória, a nova sessão pode receber:
instruções do projeto
+ HANDOFF.md
+ arquivos necessários para o próximo passo
Isso funciona como uma compactação explícita e revisável. Podemos garantir que decisões críticas foram registradas e separar informações temporárias daquelas que precisam sobreviver.
A abordagem também serve para transferir trabalho entre agentes diferentes. Um agente pode investigar o problema, produzir o handoff e permitir que outro continue a implementação sem receber toda a trajetória anterior.
Menos tokens nem sempre significa pagar menos
Até aqui falamos principalmente sobre reduzir o tamanho do contexto. Existe, porém, outra otimização importante: prompt caching (cache de prompt).
Considere várias inferências consecutivas:
Chamada 1
[20k tokens estáveis][2k novos]
Chamada 2
[20k tokens estáveis][2k][1k novos]
Chamada 3
[20k tokens estáveis][2k][1k][800 novos]
Grande parte do começo continua igual. Com prompt caching, o provedor pode reaproveitar o processamento de um prefixo que já apareceu:
[ prefixo em cache ][conteúdo novo]
É por isso que a organização do prompt importa.
A OpenAI explica que cache hits dependem de correspondências de prefixo. Conteúdo estático, como instruções, deve permanecer no começo; informações variáveis devem ser acrescentadas depois sempre que possível.
No Codex, preservar esse prefixo é preocupação explícita do harness. Alterar o modelo, a lista de ferramentas ou determinadas configurações pode provocar um cache miss (falha de cache). A OpenAI relata inclusive um problema em que ferramentas MCP eram enumeradas em ordem não determinística, reduzindo o reaproveitamento do cache.
Os provedores podem cobrar valores diferentes por input, cache write e cache read (leitura de cache). Portanto, dois agentes que processam aproximadamente a mesma quantidade lógica de contexto podem ter custos diferentes dependendo da capacidade de reutilizar prefixos.
Mas há uma distinção fundamental:
Prompt caching pode reduzir custo e processamento, mas não faz os tokens desaparecerem da janela de contexto.
Isso significa que cache e compactação resolvem problemas diferentes.
Compactar ou preservar o cache?
Essa diferença cria um trade-off interessante.
Imagine que um agente possui um histórico grande cujo prefixo está sendo reutilizado eficientemente. Se removermos ou alterarmos conteúdo no meio desse histórico, podemos liberar espaço na janela, mas também alterar o prefixo utilizado pelo cache.
Em outras palavras, uma otimização pode prejudicar outra.
Por isso, engenharia de contexto não deve ser reduzida a "usar menos tokens". Precisamos equilibrar pelo menos quatro fatores:
qualidade da resposta
↕
contexto relevante
↕
espaço disponível
↕
cache hit
↕
custo e latência
Às vezes vale manter um contexto maior porque grande parte dele está sendo recuperada do cache. Em outros casos, o contexto acumulou tanto ruído que uma compactação ou nova sessão produz resultados melhores mesmo que seja necessário reconstruir parte do cache.
Uma estratégia prática para agentes que trabalham por muito tempo
Todas essas técnicas podem parecer independentes, mas funcionam melhor como camadas.
Uma estratégia prática seria:
- Manter instruções permanentes pequenas.
CLAUDE.md,AGENTS.md, Rules e equivalentes deveriam funcionar principalmente como mapas e regras realmente universais. - Manter documentação detalhada fora do contexto inicial. O agente deve saber onde encontrá-la.
- Pesquisar código antes de ler grandes quantidades de arquivos. Busca textual, semântica ou híbrida pode reduzir exploração desnecessária.
- Carregar ferramentas sob demanda quando possível. Schemas extensos de ferramentas também consomem contexto.
- Controlar saídas ruidosas. Logs e comandos devem retornar a quantidade necessária de informação, sem esconder dados críticos.
- Usar subagentes para investigações isoladas. A pesquisa pode acontecer em outra janela e retornar apenas sua conclusão.
- Persistir aprendizados importantes em memória externa. Não dependa de uma conversa antiga para guardar regras que serão necessárias amanhã.
- Compactar em pontos naturais da tarefa. Uma mudança de etapa é um momento melhor para resumir do que esperar a janela ficar completamente cheia.
- Criar handoffs para tarefas longas. Uma nova sessão com estado bem documentado pode ser mais eficiente que uma conversa indefinidamente crescente.
- Preservar prefixos estáveis quando isso não conflitar com qualidade. Um bom cache hit pode reduzir significativamente o custo de chamadas repetidas.
A estratégia pode ser resumida em uma pirâmide:
Compactação
quando necessário
▲
Handoff / memória
▲
Retrieval sob demanda
▲
Saídas de ferramentas enxutas
▲
Instruções permanentes pequenas e estáveis
O ponto principal é evitar tratar a janela de contexto como um depósito onde toda informação possivelmente útil deve ser colocada.
Ela se parece mais com a memória de trabalho de um sistema.
Conclusão
Janelas de contexto continuam crescendo, mas isso não elimina a necessidade de gerenciá-las.
Um agente eficiente não precisa manter tudo o que já viu disponível o tempo todo. Ele precisa saber o que manter, o que esquecer, onde procurar e o que recuperar quando necessário.
Claude Code, Codex e Cursor vêm convergindo para esse princípio por caminhos diferentes. Memórias persistentes guardam conhecimento entre sessões. Code search e RAG recuperam informações específicas. Grafos ajudam quando relações estruturais importam. Compactação reduz trajetórias longas. Handoffs permitem reiniciar sessões preservando estado. Prompt caching reduz o custo de informações que precisam continuar presentes.
Por isso, talvez a estratégia mais importante para economizar tokens não seja encontrar a melhor maneira de comprimir tudo depois.
É evitar que informação desnecessária entre no contexto desde o início.
Conforme agentes de inteligência artificial passam de conversas curtas para tarefas que duram horas ou dias, gerenciamento de contexto deixa de ser apenas uma limitação técnica dos modelos e passa a fazer parte da arquitetura do próprio sistema.
Fontes
GRAPHIFY LABS. Graphify - queryable knowledge graphs for AI assistants. GitHub. Acesso em: 29 ago. 2026.
FLUPKEDE. codesearch --- Multi-repo semantic code search for AI agents. GitHub. Acesso em: 26 ago. 2026.
MASTRA. Observational Memory: 95% on LongMemEval. 9 fev. 2026. Acesso em: 26 ago. 2026.
MASTRA. Anatomy of a harness: building a coding agent that can run for hours. 2026. Acesso em: 26 ago. 2026.
ANTHROPIC. How Claude remembers your project. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/memory. Acesso em: 26 ago. 2026.
ANTHROPIC. Explore the context window. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/context-window. Acesso em: 26 ago. 2026.
ANTHROPIC. Manage sessions. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/sessions. Acesso em: 26 ago. 2026.
OPENAI. Unrolling the Codex agent loop. 23 jan. 2026. Disponível em: https://openai.com/index/unrolling-the-codex-agent-loop/. Acesso em: 26 ago. 2026.
OPENAI. Harness engineering: leveraging Codex in an agent-first world. 2026. Disponível em: https://openai.com/index/harness-engineering/. Acesso em: 26 ago. 2026.
CURSOR. Dynamic context discovery. 6 jan. 2026. Disponível em: https://cursor.com/blog/dynamic-context-discovery. Acesso em: 26 ago. 2026.
CURSOR. Summarization. Cursor Docs. Disponível em: https://docs.cursor.com/en/agent/chat/summarization. Acesso em: 26 ago. 2026.
CURSOR. Memories. Cursor Docs. Disponível em: https://docs.cursor.com/en/context/memories. Acesso em: 26 ago. 2026.
RTK. RTK --- Rust Token Killer. GitHub. Disponível em: https://github.com/rtk-ai/rtk. Acesso em: 26 ago. 2026.
MINISHLAB. Semble --- Semantic Code Search. GitHub. Disponível em: https://github.com/MinishLab/semble. Acesso em: 26 ago. 2026.
LIU, et al. GraphCoder: Enhancing Repository-Level Code Completion via Code Context Graph-based Retrieval and Language Model. arXiv, 2024. Disponível em: https://arxiv.org/abs/2406.07003. Acesso em: 26 ago. 2026.
MICROSOFT. GraphRAG. GitHub. Disponível em: https://github.com/microsoft/graphrag. Acesso em: 26 ago. 2026.
