Executando verificação de segurança...
2

A ilusão do contexto infinito: por que seu LLM esquece seu código (e como parei de jogar dinheiro fora com token inútil)

Sobre mim e este projeto

Meu nome é Cláudio Silva, mas pode me chamar de Dinho. Sou desenvolvedor fullstack de Fortaleza-CE e fundador da Comunidade Frontend Fusion.

Este artigo não é sobre uma API que eu construí. É sobre uma ferramenta que eu criei pra resolver um problema real: como fazer uma IA entender um código base sem jogar fora dinheiro com token inútil e sem perder informação importante no meio do contexto.

O nome da ferramenta é Nexor. Ela pega qualquer repositório, analisa a estrutura, remove o que não presta, organiza o que presta, e gera um JSON pronto pra ser jogado no ChatGPT, no Claude Code ou em qualquer LLM.

Pra testar o Nexor, usei um projeto real da Comunidade Frontend Fusion: a Plataforma Certify.

O repositório que foi analisado: a Plataforma Certify
https://github.com/Projeto-FrontEnd-Fusion/certify_platform

A Certify é uma plataforma digital para emissão, gestão e validação de certificados acadêmicos e institucionais. O problema que ela resolve é simples: hoje, muitas instituições ainda emitem certificados de forma manual, com processos descentralizados, dificuldade na validação de autenticidade e risco de falsificação.

A Certify organiza tudo isso em três pilares. Emissão, onde a instituição cria o certificado e associa a um usuário, evento e carga horária. Gestão, onde o usuário autenticado pode visualizar, acompanhar status, baixar e consultar histórico dos seus certificados. Validação, onde cada certificado tem um identificador único que permite consulta pública e verificação de autenticidade.

A plataforma atende desde comunidades técnicas e organizadores de eventos até instituições educacionais e projetos open source. Atualmente, a Certify está em estágio de MVP funcional, com autenticação estruturada, criação e listagem de certificados, e uma arquitetura consistente preparada pra expansão.

O código tem 22 arquivos, com 6 classes, 8 funções e 135 imports no total.

O resultado do Nexor rodando na Certify tá aqui: https://gist.githubusercontent.com/dinhoSilwa/3638d9d107c4a935f786f6ebb42fa481/raw/3d3edbf582e153f7aee13e0fa589c059da07fd51/.json

Agora vou te mostrar o problema que motivou tudo isso.

O problema que ninguém tá resolvendo direito

A evolução das janelas de contexto virou uma das corridas mais importantes da IA até 2026. Mas o número bruto sozinho engana bastante.

Hoje, os principais modelos estão mais ou menos assim. Os modelos frontier como GPT-4.1 e GPT-5.x vão de 400 mil até 1 milhão de tokens dependendo da versão. O Claude 4.5 e 4.6 tem 200 mil tokens padrão, com beta de 1 milhão. O Gemini 2.5 e 3 Pro já tão na casa do 1 milhão, com roadmap pra 2 milhões.

Nos modelos intermediários, os GPT mini e nano também chegam a 1 milhão de tokens, mas com limitações de capacidade. O Claude Haiku fica nos 200 mil. Modelos de reasoning menores também tão nessa faixa.

E nos experimentais open source, o Llama 4 Scout já chega a 10 milhões de tokens. Modelos de pesquisa já tão atingindo 100 milhões, mas não é prático ainda.

Parece muito, né? Dá pra jogar um código inteiro aí dentro.

Aqui vem o ponto crítico que muita gente ignora: capacidade teórica não é igual a capacidade real utilizável.

A performance cai conforme o contexto aumenta. Tarefas longas perdem precisão drasticamente. Tem estudo mostrando isso.

Tem também o fenômeno "lost in the middle". O modelo esquece ou ignora partes do meio do contexto. Melhorou entre 2025 e 2026, mas ainda existe.

Tem o tal do "context rot". Quanto maior o contexto, mais ruído você enfia junto e mais inconsistência aparece na resposta. Estudos mostram que o uso efetivo mal chega a 50 ou 65 por cento do total.

E por fim, custo. Tokens grandes custam caro. Muitos modelos cobram extra acima de 200 mil tokens.

Traduzindo: você pode ter 1 milhão de tokens de janela, mas se você jogar um código de 500 mil tokens lá dentro sem preparação, a IA vai ignorar metade, errar outra parte, e você ainda vai pagar caro por isso.

A mentalidade antiga e errada é pensar "vou jogar tudo no prompt porque tenho 1 milhão de tokens".

A mentalidade moderna em 2026 é: vou estruturar contexto e recuperar só o necessário.

Isso significa usar RAG, que não manda tudo, só o relevante. Usar chunking inteligente pra dividir código e documentos. Fazer context engineering, organizando JSON e AST. E usar sliding window, com contexto dinâmico ao longo da conversa.

E é exatamente isso que o Nexor faz.

O que o Nexor faz na prática

O Nexor tem três pilares.

Primeiro, minificação. Remove comentários, docstrings e espaços em branco. Tudo que é útil pra humano mas atrapalha a IA.

Segundo, clusters semânticos. Agrupa arquivos por funcionalidade real, não por pasta. Ensina o LLM sobre o domínio do sistema.

Terceiro, compressão condicional. Arquivos grandes são comprimidos com gzip e viram base64. Reduz o tamanho sem perder informação.

E tem também a hierarquia de prioridade, que organiza os arquivos do mais importante pro menos importante. Se o contexto estourar, os testes e scripts vão pro final. O core e a infraestrutura ficam no início.

Passo a Passo Técnico

1. Minificação: tirando fora o que a IA não precisa ler

O primeiro passo é o mais óbvio. Comentários e docstrings são úteis pra humanos, mas pra IA eles são só ruído.

Um exemplo real da Certify. Um campo de email tinha uma docstring enorme explicando o que é email. A IA não precisa saber que "email é um endereço eletrônico válido". Ela só precisa saber que o campo se chama email, é do tipo EmailStr e é obrigatório.

O código de minificação é simples na superfície, mas complicado nos detalhes.

def minify_code(content: str, keep_docstrings: bool = False, keep_comments: bool = False) -> str:
    if not keep_docstrings:
        result = re.sub(r'""".*?"""', '', result, flags=re.DOTALL)
    
    if not keep_comments:
        for line in result.split('\n'):
            if '#' in line and not dentro_de_string(line):
                line = line[:line.index('#')].rstrip()

O detalhe chato é remover comentário sem quebrar string, principalmente quando a string tem URL com "https://". Já quebrei isso no começo. Demorei horas pra descobrir que o problema era uma URL sendo cortada no meio.

2. Clusters semânticos: ensinando o domínio

O segundo passo é mais sofisticado. Não adianta jogar os arquivos em ordem alfabética. A IA precisa saber quais arquivos trabalham juntos.

Por isso eu criei os clusters semânticos. São padrões de regex que identificam arquivos relacionados por funcionalidade.

SEMANTIC_CLUSTER_PATTERNS = {
    "autenticacao": {
        "patterns": [r"jwt_manager", r"auth_service", r"auth_repository", r"auth_routes"],
        "description": "Fluxo completo de autenticação: criação, login e geração de JWT",
    },
    "certificados": {
        "patterns": [r"certificate_service", r"certificate_repository", r"certificate_routes", r"certificate_model"],
        "description": "Gestão de certificados: emissão, consulta e validação",
    }
}

No JSON de saída, a IA recebe um campo "semantic_clusters" que lista exatamente quais arquivos pertencem a cada domínio.

Quando testei com o Claude Code pedindo uma nova funcionalidade na Certify, o modelo entendeu de cara que precisava mexer no fluxo de certificados. Ele não ficou perdido tentando adivinhar a arquitetura.

3. Compressão condicional: só quando vale a pena

Terceiro passo. Arquivos pequenos, quando comprimidos com gzip e convertidos pra base64, ficam maiores que o original. O overhead da base64 é real.

Por isso implementei compressão condicional. Só comprime arquivos acima de 10 kilobytes.

COMPRESSION_THRESHOLD_BYTES = 10 * 1024

def compress_content(content: str) -> Tuple[str, bool]:
    content_bytes = content.encode('utf-8')
    
    if len(content_bytes) > COMPRESSION_THRESHOLD_BYTES:
        compressed = gzip.compress(content_bytes, compresslevel=6)
        compressed_b64 = base64.b64encode(compressed).decode('ascii')
        return compressed_b64, True
    
    return content, False

Na Certify, todos os arquivos ficaram abaixo do limite, então nada foi comprimido. Em repositórios maiores que testei, a compressão reduziu arquivos enormes pra poucos kilobytes em base64.

4. Prioridade: o que vem primeiro?

O último passo é sobre ordenação. Se o contexto estourar, o LLM corta o final do prompt. Você quer que os arquivos cortados sejam os menos importantes.

Por isso criei uma hierarquia de prioridade baseada em padrões de pasta.

PRIORITY_PATTERNS = {
    "core": [r"core/", r"models\\.py", r"security/"],
    "supporting": [r"main\\.py", r"dependencies\\.py"],
    "infrastructure": [r"repositories/", r"database/"],
    "testing": [r"tests/", r"test_"],
}

No JSON da Certify, os arquivos aparecem organizados assim. O main.py como "supporting". Os repositórios como "infrastructure". Os testes como "testing". Os modelos como "default".

Problemas que Enfrentei e Como Resolvi

1. Token counting impreciso

Causa: Eu usava len(texto) dividido por 4 pra estimar tokens. Uma aproximação horrível. Código cheio de chaves, colchetes e parênteses quebrava a conta toda.

Resolução: Migrei pro tiktoken, mesma biblioteca que a OpenAI usa. O encoding cl100k_base é o mesmo do GPT-4.

def count_tokens(text: str) -> int:
    encoding = tiktoken.get_encoding("cl100k_base")
    return len(encoding.encode(text))

A diferença foi brutal. Minha estimativa inicial de tokens caiu pra um número muito menor na contagem real. Eu tava superestimando e pagando a mais sem saber.

2. Remoção de comentários quebrava strings

Causa: Um simples re.sub pra tudo que começava com jogo da velha. Até que uma string com URL "https://" perdeu o "https" porque o código achou que era comentário.

Resolução: Implementei um parser que percorre cada caractere e só considera o jogo da velha quando ele está fora de strings.

for i, char in enumerate(line):
    if not escape and char in ('"', "'"):
        if not in_string:
            in_string = True
            string_char = char
        elif char == string_char:
            in_string = False
    elif not in_string and char == '#':
        comment_pos = i
        break

Parece besta, mas na época levei horas até descobrir que a maldita URL era o problema.

3. Performance lenta em repositórios grandes

Causa: Processar arquivo por arquivo, na sequência, lendo, minificando, contando tokens. Pra muitos arquivos, levava minutos.

Resolução: Implementei processamento paralelo com ThreadPoolExecutor.

with ThreadPoolExecutor(max_workers=self.workers) as executor:
    futures = [executor.submit(process_file, f) for f in files]
    for future in as_completed(futures):
        results.append(future.result())

Na Certify, com 22 arquivos, o ganho foi pequeno. Num repositório maior que testei, o tempo caiu de minutos pra segundos.

Resultados Alcançados

O resultado do Nexor rodando na Plataforma Certify tá nesse JSON aqui: https://gist.githubusercontent.com/dinhoSilwa/3638d9d107c4a935f786f6ebb42fa481/raw/3d3edbf582e153f7aee13e0fa589c059da07fd51/.json

Lá você consegue ver cada arquivo do repositório, quantos tokens cada um tem, qual sua prioridade, quantas classes e funções foram identificadas, e como os clusters semânticos organizaram o código por domínio.

O arquivo de modelos de certificado, que é o maior do projeto, tinha muita docstring e descrição de campo. A IA não precisa ler o exemplo "João Silva Santos" toda vez. Isso é ruído.

Os arquivos de infraestrutura, como os repositórios de autenticação e certificado, tinham muitos imports do sistema operacional e variáveis de ambiente. Também foram tratados.

O que sobrou foi a estrutura pura. Classes, métodos, relações entre arquivos. Exatamente o que o LLM precisa pra entender a arquitetura da Certify.

Fontes e Referências

Pesquisa sobre degradação de performance em contexto longo: https://arxiv.org/abs/2602.14188

Comparativo de janelas de contexto entre modelos: https://hivebook.wiki/wiki/llm-context-windows-comparison

Estudo sobre "lost in the middle" e context rot: https://www.morphllm.com/claude-context-window

Documentação do tiktoken: https://github.com/openai/tiktoken

Módulo AST do Python: https://docs.python.org/3/library/ast.html

Conclusão

A indústria de IA já sacou uma coisa em 2026: contexto grande não resolve problema. Organização de contexto resolve.

O Nexor é minha tentativa de aplicar isso na prática. Minificar ruído. Agrupar por domínio. Comprimir só quando vale a pena. Priorizar o que é importante.

O resultado na Plataforma Certify tá no link que eu passei. Abre lá, olha o JSON, vê como a IA vai enxergar seu código. É outro nível.

Se você usa ChatGPT, Claude Code ou qualquer outro LLM pra revisar, documentar ou gerar código no seu projeto, pare de jogar o repositório cru. Prepare antes. O retorno vem em dinheiro economizado e qualidade de resposta.

O Nexor é open source e tá no GitHub da Comunidade Frontend Fusion.
P.S. Nexor não é open source. A Certify, o repositório analisado, sim. perdão pela confusão

E no fim, ser dev é isso. Resolver problema real. Mesmo que o problema seja ensinar uma máquina a entender seu código.

Quer falar comigo?

Email: claudiosilva.one@gmail.com
LinkedIn: https://www.linkedin.com/in/claudiosilva-dev
GitHub: dinhoSilwa

Carregando publicação patrocinada...
1

Meus 2 cents,

Parabens pela iniciativa !

Eh sempre interessante acompanhar projetos reais usando tecnologia para automatizar as tarefas.

So um detalhe:

O Nexor é open source e tá no GitHub da Comunidade Frontend Fusion.

Mas nao colocou o endereco do repositorio.

Obrigado por compartilhar !

Post devidamente favoritado via extensão TABNEWS FAVORITOS

Saude e Sucesso !

1

Valeu pelo feedback e pelo favorito, Oletros!

Só uma correção importante: o Nexor não é open source. Eu que não me expressei bem no artigo

O que tá no GitHub da Comunidade Frontend Fusion é a Plataforma Certify (o repositório que foi analisado). Ela sim é aberta.

O Nexor é uma ferramenta que desenvolvi pra uso nos meus projetos pessoais. Mostrei ela no artigo pra compartilhar a abordagem e as técnicas, não o código em si. Por isso não coloquei o endereço do repositório - ele simplesmente não existe como projeto público.

Peço desculpa pela confusão. Vou até editar o artigo pra deixar isso mais claro.

E no mais, é isso. A ideia era mostrar que preparar o código antes de jogar no LLM faz diferença demais. Se tu levar os conceitos (minificação, clusters, prioridade) pro teu contexto, já vale.

Valeu demais pelo apoio, irmão. Saúde e sucesso pra ti também!