NTK (Neural Token Killer): daemon em Rust que comprime até 90 % da saída de comandos antes de chegar no Claude Code. [PT-BR]
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/Aporque 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
Fonte: https://ntk.valraw.com/