NTK (Neural Token Killer): daemon em Rust que comprime até 90 % da saída de comandos antes de chegar no Claude Code. [PT-BR] · luizinhoh2o1

TL;DR

Criei o NTK (Neural Token Killer), um proxy local em Rust que fica entre o Claude Code (e outros editores com hook) e o LLM. Ele intercepta a saída de Bash / cargo test / docker logs / tsc e comprime antes de virar contexto. Números medidos: até 92 % em logs repetitivos do Docker, 56–83 % em stack traces de várias linguagens, < 20 ms de overhead nas camadas regex + tokenizer. Pode ser utilizado juntamente com o RTK já que e RTK é PreToolUse e NTK é PostToolUse.

O projeto é open-source (MIT) e está no começo. Preciso de gente para testar, adicionar fixtures de linguagens que ainda não cobrimos, traduzir a documentação, portar o hook para outros editores e fazer benchmarks em GPUs que eu não tenho.

Repositório: https://github.com/VALRAW-ALL/ntk

O problema

Se você usa Claude Code, Cursor, OpenCode ou qualquer outro editor com agente LLM, já percebeu: cada vez que o modelo roda um comando Bash, toda a saída é empurrada de volta para o contexto na próxima turn. Um cargo test com 200 testes passando, um docker logs de 10 mil linhas, um tsc com warnings repetidos — tudo isso consome milhares de tokens que, do ponto de vista do modelo, são ruído.

Consequências:

Cap de contexto atingido mais rápido — a janela acaba no meio de uma sessão produtiva.
Latência maior — o modelo processa mais tokens de entrada.
Custo maior — se você está na API paga.
Perda de foco do modelo — output verboso dilui a informação relevante (erros, diffs, warnings).

A alternativa que já existia (RTK, filtros por regex no shell) funciona para casos simples mas é síncrona e cega à semântica: filtra o que o autor da regra sabia que era ruído, não o que o modelo consideraria ruído.

A ideia do NTK

Pipeline em 4 camadas, assíncrona, via PostToolUse hook:

Saída do Bash
  → Hook PostToolUse
    → POST /compress no daemon local
      → L1 Fast Filter    (regex, < 1 ms) — ANSI, dedup por template, stack-trace filter
      → L2 Tokenizer       (cl100k_base, < 5 ms) — path shortening, BPE, normalização
      → L3 Local Inference (Phi-3 Mini, só quando pós-L1+L2 > 300 tokens)
      → L4 Context Injection — prefixa a intenção do usuário no prompt da L3
  → Contexto do modelo

L1 e L2 são sempre ligadas. L3 só dispara quando pós-L1+L2 ainda está acima de 300 tokens — evita overhead de 300-800 ms para outputs pequenos tipo git status. L4 lê o transcript da sessão do Claude Code para descobrir a pergunta atual do usuário e prefixa no prompt de compressão.

Números reais

Todos vindos de bench/microbench.csv rodado contra 15 fixtures determinísticos em bench/fixtures/. Nada de estimativa.

Fixture	Cenário	Economia L1+L2
`docker_logs_repetitive`	Logs com timestamps repetidos	92 %
`node_express_trace`	Stack trace Node.js com node_modules/express	83 %
`cargo_test_failures`	`cargo test` com 1 falha em 50	68 %
`python_django_trace`	Stack trace Django + gunicorn/asgiref	62 %
`stack_trace_java`	Spring/Tomcat/CGLIB	60 %
`go_panic_trace`	Go panic + goroutine dumps	56 %
`php_symfony_trace`	Symfony/HttpKernel + /vendor	33 %

L3 empurra esses números mais para cima em outputs desestruturados, mas o tempo CPU do Phi-3 Mini é longo (~60 s) sem GPU, então na prática só vale ligar com aceleração CUDA/Metal.

Por que Rust

Latência determinística — cada chamada de Bash é interceptada; overhead precisa ser previsível.
Binário único, zero runtime — se seu shell abre, NTK roda.
Multiplataforma sem #ifdef — Windows, macOS, Linux compilam a mesma base.
Enum de backend de inferência — trocar Ollama por Candle ou llama.cpp é um match.

O que precisa de ajuda (é aqui que você entra)

Comecei sozinho. A lista do que não tenho como fazer bem é maior do que a que consigo:

Fixtures de linguagens novas — pares .txt + .meta.json. Ainda abertos: Elixir/Phoenix, Scala/Akka, Swift/iOS, Flutter/Dart, Clojure, Erlang/OTP. Qualquer log real serve.
Portar o hook para outros editores — Claude Code e OpenCode já funcionam. Cursor, Aider, Zed, Continue, Windsurf têm esquemas JSON parecidos. É um script shell autocontido.
Benchmarks em hardware que não tenho — números de AMD (Vulkan), Apple Silicon (Metal) e Intel AMX no README são parcialmente estimados.
Traduções — docs/ tem pt-BR e en-US. ES/FR/DE/JA é só copiar e traduzir.
Quebrar invariantes — 8 property-based tests em cargo test --test compression_invariants. Achar uma entrada que viole qualquer um é ouro.

Trade-offs honestos

Não substitui LLM remoto. A L3 usa Phi-3 Mini (3.8B). É bom para sumarizar output estruturado, não escreve código no seu lugar.
Privacidade. Nada sai da sua máquina. Telemetria é opt-out e não envia arquivos/paths/conteúdo.
NTK+RTK combinado ainda não medido. Hoje o painel "combined" no site mostra N/A porque eu não tenho o número real.

Perguntas abertas (é aqui que eu quero opinião)

Você usa agente de LLM que roda comandos locais? Qual comando mais entope seu contexto?
Se isso existisse antes e você soubesse, teria instalado? O que faria você não instalar?
Alguma linguagem / framework que queria ver suportado primeiro?

Crítica dura (incluindo "isso é ruim porque X") vale mais do que upvote silencioso.

Obrigado pela leitura. Ponto de partida mais curto pra contribuir: https://github.com/VALRAW-ALL/ntk/blob/master/CONTRIBUTING.md