[🤖] Vi o contexto encher no início da conversa e refiz as regras compartilhadas

✨ Resumo do GPT-5.6 Sol

Um registro de como encontrei nas regras compartilhadas e nas Skills a causa de o contexto de 258k encher logo no começo, rejeitei uma redução de poucas linhas e reorganizei tudo em inglês comprimido sem distorcer o significado.

O contexto já estava cheio antes de eu começar a trabalhar

Abri uma conversa nova com o Codex e percebi que uma parte considerável do contexto já estava ocupada. O limite era 258k, mas as regras compartilhadas e a lista de Skills já consumiam espaço antes mesmo de o trabalho real começar.

Primeiro, perguntei quanto conteúdo entrava no início de uma conversa. O Codex respondeu com um número absurdamente maior, e eu o corrigi na hora.

“Não, 258k é o máximo. Acho que as regras globais estão grandes demais…”

Pensando bem, não havia nada de estranho nisso. Sempre que a IA errava, eu acrescentava outra regra compartilhada para que ela nunca repetisse o mesmo erro. Autoridade, Git, credenciais, deploy, navegador, UI/UX, documentação, Goals, trabalho paralelo e a fronteira entre projetos da empresa e pessoais: tudo foi se acumulando. Eu transformava tarefas repetidas em Skills e, quando uma Skill falhava, adicionava mais uma exceção ou procedimento de verificação.

Eu queria evitar que a IA perdesse o contexto a cada tarefa. Até tinha ficado satisfeito por ter conectado o fluxo e o senso do meu trabalho com Codex Skills. Mas, quando os mecanismos criados para preservar o contexto ficam longos demais, começam a consumir o espaço destinado ao trabalho novo. As pistas que antes mantinham o fluxo passaram a virar bagagem.

Recusei terminar depois de apagar apenas algumas linhas

No começo, pedi uma auditoria que removesse somente o que certamente não causaria perda de desempenho. O Codex foi cauteloso e limpou apenas algumas repetições e trechos obviamente longos.

O resultado me frustrou de imediato.

“Só isso…? E comprimir descrições desnecessariamente longas e coisas assim? Você realmente aplicou todos os métodos que considera melhores?”

Eu não queria apenas apagar algumas frases. Queria corrigir a própria estrutura: a mesma condição de segurança repetida em vários parágrafos, uma decisão dando voltas em descrições longas e detalhes que já estavam em uma reference ou em um script copiados novamente para o corpo da Skill.

Mas buscar somente a brevidade seria ainda mais perigoso. Se aprovação explícita virasse apenas aprovação, ou se o alvo e o escopo exatos se tornassem verificar quando necessário, o número de tokens cairia, mas o comportamento da IA também mudaria. Em regras sobre credenciais, mudanças destrutivas, propriedade no Git, deploy e UI para clientes, uma diferença aparentemente pequena em uma frase pode deslocar a fronteira real de autoridade.

Então redefini o critério: reduzir exemplos e explicações repetidas, mas preservar as condições, proibições, exceções, verificações e critérios de parada que determinam o comportamento.

Medi se o coreano ou o inglês consumia menos tokens

Durante o processo, pensei em mudar todas as Skills para coreano. Para mim, é mais fácil ler e editar em coreano, mas o objetivo não era o conforto dos meus olhos. Era reduzir os tokens consumidos pelo Codex.

Criei amostras comprimidas em coreano e inglês com o mesmo significado e passei ambas pelo tokenizer real. Em várias descrições de Skills que eu havia escrito, o inglês comprimido ficou claramente menor. Isso não significava que o coreano sempre fosse mais caro. Mesmo assim, muitas das regras compartilhadas acumuladas mantinham o significado com menos tokens quando comprimidas em inglês.

Nesse ponto, a direção ficou clara.

“Então é melhor transformar todas as regras compartilhadas e as Skills em inglês comprimido, não é? Assim economiza tokens.”

Não apaguei o coreano indiscriminadamente. Mantive as frases de ativação em coreano que realmente uso, nomes de estado e exemplos de saída mostrados ao usuário e termos próprios do trabalho da empresa cuja tradução reduziria o reconhecimento. O restante das explicações e procedimentos virou frases curtas em inglês.

O Codex carrega no contexto inicial o nome, a descrição e o caminho de cada Skill, e só lê o SKILL.md completo quando aquela Skill é ativada.¹ Por isso, primeiro reduzi as regras globais e as descrições de Skill discovery que estão sempre presentes. Depois, comprimi separadamente o inventário de rede e a Skill de escrita, que entravam como blocos pesados quando acionados.

Verifiquei separadamente se as frases menores ainda produziam o mesmo comportamento

Desta vez, não usei “foi traduzido para o inglês” como critério de conclusão. Primeiro reescrevi uma amostra representativa: parte das regras de segurança compartilhadas, uma Skill de auditoria e uma Skill de registro de tempo. Um reviewer independente comparou os originais com as versões comprimidas e detectou, na primeira revisão, que uma condição da Skill de auditoria tinha enfraquecido: o comportamento não relacionado à architecture existente também precisava ser preservado.

Restaurei essa condição e pedi uma nova revisão à mesma pessoa. Depois apliquei o padrão ao restante das regras compartilhadas e às treze Skills criadas pelo usuário. Por fim, uma session diferente da primeira revisão comparou os vinte e nove arquivos completos com seus originais. Ela verificou se o texto reduzido ainda produzia as mesmas fronteiras de aprovação, condições de parada, procedimentos de verificação e contratos de saída. Nenhuma omissão importante permaneceu.

Os números também mostraram a diferença. No tokenizer o200k, as regras globais sempre lidas caíram de 14.933 tokens para 10.644, uma redução de cerca de 28,7%. As descrições de Skills expostas no início de uma conversa caíram aproximadamente 31,1%. Duas references grandes lidas na ativação caíram cerca de 50,5%. Em todo o escopo comparado, o total passou de 81.347 tokens para 62.765, uma redução aproximada de 22,8%.

Como os corpos completos de todas as Skills não são carregados no início, não posso chamar esses 22,8% diretamente de “custo inicial da conversa”. Ainda assim, a parte sempre presente ficou menor de imediato, e a carga adicional ao chamar uma Skill pesada também diminuiu.

O contexto precisava de densidade, não apenas de volume

Antes, quando a IA errava, eu só pensava em escrever mais regras. Acreditava que mais detalhes reduziriam os erros e que guardar exemplos ajudaria na próxima vez. A ideia não estava totalmente errada. De fato, essas regras evitaram muitos problemas.

O problema era que eu apenas adicionava regras e quase nunca voltava para comprimi-las. Frases que impediam a mesma falha apareciam em vários lugares, explicações de incidentes recentes permaneciam como regras definitivas, e um texto longo escrito para esclarecer um ponto uma única vez virava o custo básico de todas as tarefas.

Desta vez, não removi as salvaguardas. Removi a repetição e o excesso de texto em volta delas. Mantive o que proteger, quando parar, quem deve aprovar e como verificar, mas cortei as frases que repetiam por que aquela regra existia.

Dar mais contexto à IA e dar um contexto melhor são coisas diferentes.

Daqui em diante, a manutenção de uma regra compartilhada ou de uma Skill não vai terminar quando eu adicionar uma frase nova. Também preciso conferir se o mesmo significado já existe, se um incidente pode virar um invariant e quantas palavras não alteram o comportamento real. O contexto não é um depósito infinito.

Em vez de acumular mais memória, quero reproduzir o mesmo discernimento com menos tokens.

Desta vez, avancei mais um passo nessa direção.

Referências

1. OpenAI, Codex Skills. Explica o carregamento progressivo dos metadados de Skill discovery e das instruções completas. ↩