Quando a fronteira invisível vira o problema dos agentes

Hoje teve uma coleção de histórias que parecem separadas — um agente que manda dados para fora, um cache que muda a vida de um modelo local, um pooler de banco espremido por uma CPU — mas todas têm a mesma graça: o gargalo real costuma morar na fronteira que a gente não estava olhando.

É o tipo de dia que vale menos pela promessa de “IA mágica” e mais pela engenharia que faz a coisa ser verificável: tráfego, estado, permissões, filas, limites de conexão. Vamos ao que chamou atenção.

Um relatório sobre o Grok Build CLI acende o alerta para o que sai do workspace

Um pesquisador publicou uma análise de rede do Grok Build CLI 0.2.93 feita com proxy, repositório descartável e segredos-canário falsos. É uma investigação independente, não uma declaração da xAI nem uma auditoria de terceiros — essa distinção importa bastante aqui.

Segundo o relatório, quando o CLI leu um .env, os canários apareceram tanto numa requisição de turno do modelo quanto num upload de estado de sessão. Num experimento em que o agente recebeu a instrução de não ler arquivos, o autor diz ter recuperado um canário deliberadamente não lido dentro de um bundle Git capturado, junto com o histórico Git. O relatório identifica /v1/responses e /v1/storage como os endpoints relevantes e nomeia grok-code-session-traces como o bucket GCS observado.

O número que dá escala ao caso vem do teste com um repositório grande: 5,10 GiB de tráfego de armazenamento, contra 192 KB de tráfego de turnos do modelo. O autor também relata que, no binário testado, a opção “Improve the model” não desligou o upload de trace.

Nada disso prova que repositórios estejam sendo usados para treinar modelo, nem estabelece uma política de retenção. O que o material demonstra, na leitura do próprio pesquisador, é transmissão, aceitação de upload e armazenamento observados naquele cenário. Já é suficiente para a lição útil: trate o diretório de trabalho de um agente como uma fronteira de exposição de dados, não como uma extensão inocente do seu terminal.

Na prática, credenciais fora do repositório, fixtures descartáveis para experiências, documentação de privacidade lida de verdade e observação do tráfego de saída antes de entregar código sensível a um agente são hábitos bem mais concretos do que entrar em pânico com qualquer ferramenta. O ponto não é demonizar agentes; é pedir evidência sobre o que eles carregam consigo.

Fonte: análise de rede do pesquisador.

Quando o PgBouncer vira o gargalo antes do PostgreSQL

PgBouncer é pequeno, conhecido e, por processo, single-threaded. Em pouca concorrência isso não é drama algum. Mas a equipe do ClickHouse encontrou o momento em que um único processo passa a deixar uma máquina multi-core praticamente parada enquanto ele próprio bate no teto.

A solução descrita para o ClickHouse Managed Postgres é direta e elegante: um processo PgBouncer por core disponível, todos ouvindo a mesma porta com SO_REUSEPORT, para que o kernel distribua novas conexões. Como uma requisição de cancelamento pode cair no processo errado, eles usam o mecanismo de peering do PgBouncer para chegar ao processo que de fato possui a sessão. E os limites de conexão são divididos pela frota, para que multiplicar processos não acabe multiplicando conexões até derrubar o PostgreSQL.

Os resultados são do próprio ClickHouse, num ambiente específico: c7i.4xlarge de 16 vCPUs, PostgreSQL separado e um terceiro host rodando pgbench, com workload select-only e transaction pooling. Nesse teste, o processo único chegou perto de 87 mil transações por segundo; 16 processos chegaram a aproximadamente 336 mil com 256 clientes. O processo sozinho ficou por volta de 97% de CPU, enquanto a frota ocupou cerca de oito cores.

Não leia isso como “ganhe 4x em todo banco”. É uma medição de fornecedor, em configuração e carga bem definidas. Aliás, o texto observa que, sem carga suficiente para paralelizar, uma instância só pode ser levemente mais rápida. A parte boa da história é outra: um componente de infraestrutura aparentemente trivial pode ser o pedaço serial que impede o resto da máquina de trabalhar.

Também é uma explicação muito prática de três coisas que às vezes aparecem como siglas soltas: SO_REUSEPORT distribui aceitação de conexão; peering preserva cancelamento correto numa frota; orçamento de conexões impede que a escala do pooler vire sobrecarga no banco.

Fonte: arquitetura e benchmark do ClickHouse.

Em inferência local, o cache pode importar mais que o modelo

O autor do qMLX conta como foi rodar Qwen 3.5 122B para coding agent local num M3 Ultra de 96 GB. A parte interessante não é uma disputa de benchmarks: é a autópsia de três problemas de cache que faz qualquer pessoa que trabalha com prompts longos balançar a cabeça.

Primeiro, um ID que mudava cedo no prompt de sistema impedia reutilização byte a byte. Depois, uma geração interrompida não persistia os tokens do assistente que já tinham sido transmitidos, então o próximo turno não conseguia reaproveitar aquele prefixo. Por fim, checkpoints de background sem chave enchiam o armazenamento e expulsavam checkpoints bons. O diretório problemático tinha 27 GB de dados que não voltariam a casar com nada.

No modelo de atenção híbrida usado ali, há uma limitação adicional: estado recorrente de SSM não pode ser rebobinado. Por isso, na janela normal relatada pelo autor, foram zero acertos em cache de memória e 109 no cache de disco. É uma boa lembrança de que “tem cache” não responde à pergunta importante: qual estado pode ser retomado, em que nível, e sob qual chave?

As medições são de uma máquina e de um fork pessoal, então merecem o rótulo certo. Nesse M3 Ultra, o prefill de um prompt repetido de 32k caiu de 88 segundos sem cache para 0,64 segundo com cache — 137x, segundo o autor. Ele também relata cerca de 55 tokens/s em contexto curto e 28 tokens/s em 64k. Prefill e decode não são a mesma coisa: throughput agregado bonito pode coexistir com uma resposta em streaming que ainda parece lenta.

Para quem quer uma regra operacional simples, eu ficaria com esta: estabilize o prefixo do prompt, persista o histórico completo e trate a política de eviction como parte do produto. Antes de trocar de modelo ou comprar hardware, talvez seja aí que esteja a latência que o usuário realmente sente.

Fonte: postmortem de cache do qMLX.

Um agente em Lisp de cem linhas mostra o loop — e a faca sem cabo

Há algo refrescante em tirar a fantasia da palavra “agente”. Neste experimento em Common Lisp, a estrutura é quase constrangedoramente simples: chama o modelo, se ele pedir uma ferramenta acrescenta o resultado à conversa, e repete até vir uma resposta final. O loop mostrado tem oito linhas; o exemplo completo fica em torno de cem.

Ele usa SBCL, dexador, shasht e um modelo via OpenRouter. A ferramenta única recebe uma forma Lisp e a avalia. O autor mostra o modelo criando uma função de Fibonacci e, depois de ganhar uma chave temporária, construindo uma função para usar Brave Search. O histórico da conversa é serializado e recarregado como memória.

Como demonstração didática, é excelente porque expõe a mecânica e também a parte perigosa sem maquiagem: a ferramenta é eval arbitrário. A possibilidade de o modelo criar capacidade nova em tempo de execução parece poderosa; em produção, é justamente a razão para preferir contratos de ferramenta explícitos, permissões, isolamento e trilha de auditoria.

O próprio autor diz que rodou tudo apenas num container Docker local. Mantenha essa caveat no centro, não no rodapé. Um ambiente descartável é o mínimo quando uma saída probabilística pode virar código executável. A pequena experiência não é uma arquitetura segura para copiar; é uma maneira ótima de enxergar por que uma arquitetura segura precisa de bordas bem definidas.

Fonte: o experimento “Agent in 100 Lines of Lisp”.

Mesh LLM quer fazer várias máquinas parecerem um endpoint local

O Mesh LLM vem com uma proposta que é fácil de gostar e difícil de operar bem: expor uma API compatível com OpenAI em http://localhost:9337/v1, mas fazer a requisição rodar na máquina local, num par que já hospeda o modelo ou numa cadeia de máquinas, cada uma responsável por uma faixa de camadas.

Na descrição do projeto, a conectividade usa endpoints iroh, QUIC autenticado, travessia de NAT e relay como fallback. O modo de pipeline move ativações de estágio em estágio — no exemplo, cada nó recebe uma faixa contígua de camadas. A página cita mais de 40 modelos e chama esse transporte de split de skippy-stage/2.

O detalhe que salva muita expectativa irreal é separar capacidade de latência. Dividir camadas pode tornar possível usar um modelo que não cabe em uma máquina. Não transforma uma WAN, hardware heterogêneo, nós que entram e saem, agendamento e responsabilidade operacional em uma GPU gigante e instantânea. As ativações ainda precisam viajar.

Mesmo assim, a compatibilidade de endpoint tem valor real. Para quem tem hardware espalhado entre casa, escritório ou amigos, a ideia de usar uma interface local conhecida enquanto a topologia fica por baixo é atraente. Só vale tratar as promessas de desempenho, privacidade e confiabilidade como descrição do projeto, ainda não como garantias independentes.

Fonte: lançamento do Mesh LLM pela Iroh.

Quick hits

reaction 2.5.1: ações para padrões repetidos em logs

O reaction é um daemon Rust 2.5.1 para observar saída de programas — logs de SSH e web server são exemplos — e tomar uma ação configurada quando um padrão se repete. Ele se apresenta como alternativa mais leve ao fail2ban e aceita configuração YAML ou JSONnet. A promessa de “mais de 10x mais rápido” é do projeto, que também avisa não ter auditoria externa de segurança. Em VPS, parece uma boa peça para testar filtros e regras de firewall com cuidado antes de substituir qualquer proteção existente.

Fonte: repositório do reaction.

sqlite-utils 4.1: pequenos controles que evitam gambiarra

A versão 4.1 traz geradores de linhas em Python via --code para insert e upsert, tipos explícitos em tabelas inferidas — adeus, CEP perdendo zero à esquerda —, remoção de índices, SQL pela entrada padrão, inferência de chave primária no upsert e troca entre STRICT e não-STRICT por transform. É continuação da cobertura do 4.0, então o interessante é esse delta prático, não recontar o lançamento anterior.

Fonte: notas do sqlite-utils 4.1.

sqlsure: uma porta semântica antes do SQL do agente

O sqlsure transforma restrições declaradas — testes dbt, chaves PK/FK ou modelos fornecidos — em checagens determinísticas para fan-out, chasm joins, aditividade insegura, chaves de junção e colunas sensíveis. Pode entrar como biblioteca, CI ou servidor MCP e devolver correções acionáveis por máquina. É um padrão interessante: agente escreve, verificador determinístico barra, agente repara. Só não peça ao verificador que adivinhe uma regra de negócio que ninguém declarou.

Fonte: repositório do sqlsure.

mindwalk: replay local da sessão de um coding agent

O mindwalk é um binário Go local que lê logs de sessão de Claude Code e Codex, monta um mapa determinístico do repositório e reproduz buscas, leituras, edições, verificações, erros e marcações numa interface web. Pode ajudar uma revisão a enxergar escopo e churn sem enviar as sessões para fora. Mas é replay de pegadas, não raio-X de entendimento: visualizar o caminho não prova que o patch está correto.

Fonte: repositório do mindwalk.

enable_sort: diagnóstico do PostgreSQL, não receita de tuning

Desligar esse GUC afeta mais do que ORDER BY: entram na conversa agrupamentos baseados em sort, DISTINCT, operações de conjunto e merge joins. O uso sensato é por sessão, com EXPLAIN (ANALYZE), para testar uma hipótese e depois corrigir o problema real com work_mem ou índice. Um plano sem sort não é automaticamente melhor, sobretudo quando se lê uma fração grande da tabela.

Fonte: explicação do enable_sort.

Ant: runtime JavaScript pequeno, sandbox que pede teste

O site do Ant descreve um runtime JavaScript de 9 MB, construído sobre engine própria, com APIs compatíveis com Node e sandbox isolado por VM. É uma pista interessante para a camada de runtime/sandbox sob workflows de código com IA. Mas compatibilidade, limites de isolamento e maturidade precisam de avaliação independente antes de rodar código não confiável gerado por agente em produção.

Fonte: site oficial do Ant.

Goeteia: Scheme para Wasm direto no navegador

Goeteia compila Scheme para WebAssembly no browser. O site diz que o compilador é escrito no subconjunto de Scheme que ele próprio compila, verifica saída auto-hospedada byte a byte e usa Wasm GC e tail calls; também lista suporte atual em Node, Chrome, Firefox, Safari e wasmtime. É uma demonstração técnica deliciosa, mas não resolve sozinha as perguntas de ecossistema e alvo de navegador de uma aplicação de produção.

Fonte: site do Goeteia.

A tendência do dia: tornar fronteiras observáveis

Não são projetos com a mesma arquitetura nem com o mesmo nível de risco, mas há uma conexão útil entre eles. O relatório sobre o Grok pede visibilidade sobre dados que deixam o workspace. O qMLX mostra que estado de cache é parte palpável da experiência. O agente em Lisp torna a fronteira de execução explícita. O sqlsure põe uma trava determinística antes de SQL potencialmente errado; o mindwalk torna a pegada de uma sessão revisável.

Se existe uma pequena regra para levar daqui, é menos glamourosa que “dê mais autonomia ao agente”: observe tráfego e estado, restrinja execução, e crie verificações determinísticas antes de tratar a saída como confiável. É daí que a utilidade começa a sobreviver ao demo.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.