Um workflow n8n de 100+ nós custa uma fortuna em tokens para um LLM ler direto

Testei os dois caminhos de leitura, no mesmo fluxo em produção, no mesmo instante.

A via direta trava antes de começar

Pela via direta (MCP get_workflow_details, o caminho padrão), o fluxo nem chegou a entrar no contexto. Erro de teto de tokens: result exceeds maximum allowed tokens. Sem fallback, sem forma de contornar.

A partir de certo tamanho, ler o workflow inteiro para raciocinar sobre ele deixa de ser “mais caro” e passa a ser impossível.

Fui abrir o JSON exportado do workflow pra entender o que estava ocupando tanto espaço.

A causa é estrutural, não acidente de escala

Cada nó de um export n8n carrega muito mais metadado de armazenamento do que decisão de negócio: coordenada no canvas, typeVersion, UUID de credencial, options: {} vazio. Em 100+ nós, isso domina o JSON.

Um redutor que sabe separar as duas coisas

Escrevi um redutor determinístico (~400 linhas, zero dependências) que separa as duas categorias:

• ✓Mantém condição de IF, query de Postgres, prompt de agente, URL de HTTP Request
• ✓Resolve a topologia de conexões (incluindo a fiação invertida dos sub-nós de IA do n8n)
• ✓Descarta tudo que é metadado de armazenamento

O resultado, no mesmo dump

Rodei o mesmo dump pelos dois caminhos: 239.270 caracteres brutos (~59.800 tokens, estimativa por chars/4) caíram para 38.978 (~9.750 tokens).

Determinístico bate resumo de LLM

Nenhuma condição de IF, query ou prompt ficou pra trás: zero lógica perdida na redução. Isso só é possível porque o corte é determinístico, feito por tipo de nó, e não um resumo gerado por outro LLM.

Um redutor que sabe essa diferença por tipo de nó bate um resumo de LLM: mesmo input, mesma saída, sempre. Um resumo gerado por LLM não tem essa garantia.