4

Pitch: Como o Burnless transforma a gestão de Contexto LLM em uma arquitetura de protocolos e ainda economiza tokens. (e muito)

Criei o Burnless (opensource, MIT) porque percebi que estávamos utilizando a janela de contexto (context window) para coisas que não precisavam mais estar ali.

Eu queria parar de "queimar" tokens com o que já tinha acontecido e que não era mais necessário para o próximo passo.

Não foi uma descoberta tardia. O Burnless nasceu para separar as coisas. O que eu ainda não sabia era a dimensão do problema, a magnitude do ganho e quão diferente isso era da trajetória que todos os outros estavam seguindo.

O que vejo hoje é que todo mundo quer que a janela de contexto seja maior.

Isso ajuda, claro. Mas, na minha opinião, o conceito está errado. Uma janela maior apenas permite que você coloque mais coisas dentro dela; mas isso não resolve o fato de estarmos usando o mesmo lugar para conversação, memória, decisões, execução, perguntas abertas, histórico de trabalho e todos os antigos registros do que já foi feito.

O Burnless separa tudo isso em camadas.

As conversas, pensamentos, debates, perguntas e o histórico do trabalho são indexados e armazenados no seu disco (disk).

O contexto principal contém apenas as decisões e informações que ainda são necessárias para continuar o trabalho. Mas as palavras reais permanecem no disco se precisarem ser verificadas (não é mesmo necessário, honestamente). Além disso, quando dizemos algo e alguém nos pede para repetir, nós nunca usamos as mesmas palavras. Por que a IA precisa fazer isso? (Lembre-se: o original continua no disco, não se preocupe...)

As tarefas são delegadas a workers independentes e leves. Eles recebem uma tarefa limpa, escrevem o código, manipulam arquivos, executam comandos e registram em disco tudo o que fizeram. E sim, os workers usam o mesmo cabeçalho de cache (byte cache header) (não se preocupe com isso também...).

O Burnless então audita o resultado. Se um worker alega ter criado ou alterado um arquivo, o Burnless verifica se ele realmente existe antes de marcar a tarefa como concluída.

Assim, o contexto deixa de ser o lugar onde tudo precisa morar.

Ele se torna o local onde apenas o que requer atenção no momento é mantido.

É por isso que compare o Burnless a um protocolo e, inicialmente, até ao TCP/IP. Não porque ele tem a mesma dimensão histórica, mas porque o movimento é similar: separar responsabilidades em camadas, em capacidades de workers, criando uma forma útil e limpa de definir a comunicação entre este sistema vivo.

A memória não é mais carregada durante toda a conversa.

A execução deixa de ser um papel do modelo principal (main model).

O histórico do projeto não ocupa mais permanentemente a memória do trabalho.

O projeto pode continuar mesmo após um comando /clear ou ao alternar entre modelos.

A economia de tokens foi a motivação inicial, mas acabou se tornando uma consequência da arquitetura.

Em uma tarefa real, os workers processaram aproximadamente 1,4 milhão de tokens. Mas o contexto ativo do "Cérebro" (Brain) tinha apenas 1.590 tokens após concluir a tarefa completa.

Eu não estou alegando que o Burnless pegou exatamente os mesmos 1,4M de tokens de texto e os comprimiu em 1.590 tokens.

O que realmente aconteceu foi que todo aquele trabalho foi feito, registrado, verificado e continuado sem que o histórico acumulado permanecesse dentro do contexto ativo.

A proporção operacional final foi de aproximadamente 908 para 1. (Sim, 908x).

Quando eu mostro esse número para você, parece inacreditável. Foi aí que percebi que o problema era muito maior do que eu imaginava inicialmente.

Enquanto a direção geral é construir janelas de contexto cada vez maiores, eu fui na direção oposta: removi do contexto tudo o que não precisa ser considerado no momento.

O repositório também inclui um arquivo llms.txt contendo toda a arquitetura, benchmarks, cálculos, limitações e comandos necessários para reproduzir os números.

Como não consigo explicar tudo adequadamente em um comentário curto, o arquivo llms.txt está lá para quem quiser entender o que está acontecendo em um nível mais profundo e verificar as afirmações. Use-o para ajudar sua IA a entender essas coisas facilmente e responder às suas perguntas.

https://github.com/rudekwydra/burnless

Carregando publicação patrocinada...
1
1

Obrigado demais! Star e fork nesse começo contam muito.

E quando testar, me faz um favor: me conta exatamente onde e se você travou nos primeiros 5 minutos. Travar é o resultado mais útil que você pode me dar, é assim que o Burnless está evoluindo.

Caminho rápido: pip install burnless, depois burnless init --claude-code dentro do projeto, usa numa sessão real e dá um /clear pra ver o contexto sobreviver.

Vou dar uma olhada no seu livro. Saúde e sucesso pra você também!

1

Autor aqui.

Eu uso o Burnless todos os dias, e acho que ele é realmente útil. E o mais impressionante é que o LLM aprende a usá-lo instantaneamente. É muito interessante ver como a IA pensa quando está delegando ou decidindo sobre o /clear para nos ajudar.

Ontem, em um dia de trabalho real completo, eu usei 1,44M de tokens. Mas no contexto, apenas 1.590 tokens. Isso é 908x menos de contexto. E o contexto pode sobreviver a qualquer /clear.

Não estou alegando que o Burnless pegou exatamente os mesmos 1,4M de tokens de texto e comprimiu em 1.590 tokens. O que realmente aconteceu foi que todo aquele trabalho foi feito, registrado, verificado e continuado sem que o histórico acumulado permanecesse dentro do contexto ativo.

Para reproduzir com sua própria chave: python bench/run.py --turns 10

Postei aqui para receber críticas técnicas de pessoas que usam sessões longas de LLMs ou agentes.