Claude, MRC e vm2: compute, rede e sandbox no limite

Tem uma parte da IA que parece mágica porque fica na tela: o chat responde, o agente edita arquivo, o modelo escreve código, a demo anda. Hoje, as notícias boas estão quase todas na parte que fica atrás disso: limite de uso, datacenter, rede, GPU, memória, teste, sandbox, API server e conta de energia.

É menos cinematográfico, eu sei. Mas também é onde a brincadeira vira produto.

Claude Code ganhou mais fôlego depois de um acordo de compute com a SpaceX. A OpenAI publicou um protocolo de rede para clusters gigantes de GPU. A Unsloth e a NVIDIA mostraram ganho de treino mexendo em desperdício de sincronização e cópia. E o vm2 apareceu com outra leva de escapes de sandbox para lembrar que “rodar código não confiável” continua sendo uma frase pequena demais para o tamanho do problema.

O fio do dia é esse: a IA está batendo em limite físico e operacional. Às vezes o limite é GPU. Às vezes é rede. Às vezes é o host rodando um pedaço de JavaScript que ninguém deveria tratar como bichinho doméstico. Vamos com calma, porque tem bastante coisa útil.

Claude Code ganhou limite, mas a história maior é o encanamento do agente

A Anthropic anunciou em 6 de maio de 2026 aumento de limites para Claude Code e para a API do Claude Opus. Segundo a empresa, os limites de cinco horas do Claude Code foram dobrados para planos Pro, Max, Team e Enterprise baseado em assentos. No Pro e no Max, a Anthropic também removeu as reduções de limite em horários de pico. Para quem usa Claude Code no dia a dia, isso tende a aparecer como menos interrupção justamente naquela hora em que o agente estava no meio de uma refatoração e decidiu pedir água, café e mais tokens.

Esse aumento veio junto de um acordo com a SpaceX para uso da capacidade do Colossus 1. O post da Anthropic fala em mais de 300 MW e mais de 220 mil GPUs NVIDIA adicionadas dentro do mês. A xAI também publicou sobre a parceria e lista aceleradores H100, H200 e GB200 no Colossus 1.

O ponto prático é simples: produto de IA virou produto de capacidade. Não adianta o modelo ser ótimo se o usuário bate no limite, se a fila cresce, se a sessão longa perde fôlego, se a API fica estreita ou se o custo torna a automação inviável. A experiência “o agente trabalhou sozinho por meia hora” depende de inferência sobrando, memória útil, ferramentas boas e uma forma decente de verificar se o trabalho prestou.

Por isso a outra metade do anúncio importa. No evento Code with Claude, a Anthropic também apresentou novidades em Claude Managed Agents: dreaming, outcomes, orquestração multiagente e webhooks. O nome “dreaming” tem um perfume perigoso de marketing, então vamos tirar o incenso da sala. Pela documentação, dreams podem ler uma memory store existente e até 100 sessões, depois produzir uma nova memory store separada. Em termos menos místicos, é uma rotina para reorganizar memória entre sessões sem sair remexendo no estado original.

Outcomes tenta resolver outro problema conhecido: o mesmo contexto que faz o trabalho nem sempre é o melhor contexto para julgar o trabalho. A Anthropic descreve um grader separado, usando critérios definidos pelo usuário. Isso conversa com engenharia real. Se você pede para um agente mexer em um app, quer algum tipo de rubrica externa: testes passando, arquivo esperado alterado, comportamento preservado, documentação atualizada, diff pequeno quando couber, essas coisas que parecem chatas até salvarem sua tarde.

A orquestração multiagente delega partes do trabalho para especialistas com modelo, prompt e ferramentas próprias. Webhooks entram para avisar conclusão ou mudança de estado sem depender de polling constante. Parece detalhe de produto, mas é a diferença entre “um chat esperto” e “uma peça dentro de um sistema”. Agente em produção precisa avisar, registrar, receber tarefa, terminar, falhar de um jeito auditável e não sumir dentro de uma aba.

As cautelas continuam do tamanho certo. Dreaming está como research preview. Outcomes, multiagente e webhooks aparecem em superfícies beta ou public beta. Mais compute não significa trabalho ilimitado, nem revisão automática perfeita, nem segurança resolvida. Ainda tem custo, isolamento, autorização, qualidade e governança. Mas a direção está ficando bem clara: a próxima melhora visível em agentes deve vir de capacidade, memória, avaliação e orquestração, além de modelos melhores.

Fontes: Anthropic, xAI, Claude Managed Agents e documentação de Dreams.

OpenAI colocou a briga das GPUs dentro da rede

A OpenAI publicou o MRC, Multipath Reliable Connection, um protocolo de rede para treinamento em escala grande. O post diz que o MRC foi desenvolvido com AMD, Broadcom, Intel, Microsoft e NVIDIA, e liberado pelo Open Compute Project. A peça técnica é bem específica: estender RoCE, RDMA over Converged Ethernet, com packet spraying, source routing via SRv6 e desenho multi-plane para redes de GPUs.

Isso soa distante de quem está fazendo CRUD, bot, SaaS ou curso no fim da noite. Só que a história conecta direto com o anúncio da Anthropic. Quando você junta dezenas ou centenas de milhares de GPUs para treinar modelo, o problema deixa de ser apenas “tem GPU suficiente?”. Uma transferência lenta, congestionamento, falha em link ou switch e caminho ruim podem deixar hardware caríssimo ocioso. GPU parada em cluster grande é dinheiro queimando com ventilador.

O MRC ataca esse gargalo espalhando uma transferência por centenas de caminhos. Em vez de apostar que um caminho vai estar livre, ele distribui pacotes e tenta evitar hot spots. O source routing ajuda a escolher rotas e contornar falhas rapidamente. A OpenAI fala em reação a falhas na escala de microssegundos e em redes multi-plane com NICs de 800 Gb/s divididas em planos de 100 Gb/s.

O número que chama atenção é o de aproximadamente 131 mil GPUs conectadas com dois níveis de switches, segundo a própria OpenAI, dentro desse desenho multi-plane. O post também cita implantação em supercomputadores GB200 da OpenAI, incluindo OCI Abilene e Microsoft Fairwater.

Aqui vale segurar a empolgação no lugar certo. O dev médio não vai instalar MRC com npm add depois do almoço. Também não dá para tratar o post como resolução completa da infraestrutura de IA. A peça descrita pela OpenAI mora na rede de datacenters de escala absurda, com NIC, topologia, parceiros e operação especializados.

Mesmo assim, ela explica o momento. A corrida de IA está descendo camada por camada. Primeiro a gente falava do modelo. Depois virou inferência, cache, quantização, memória, prompt, ferramenta, agente. Agora a discussão aparece em switch, caminho de pacote, congestionamento, falha e topologia física. Parece menos glamouroso, mas é ali que produto de IA caro ganha ou perde viabilidade.

Tem uma frase mental útil para ler esse tipo de notícia: modelo grande também é problema distribuído. O treinamento síncrono faz a rede virar parte do algoritmo prático. Se a rede engasga, o treinamento sente. Se a rede recupera rápido e usa caminho melhor, o cluster aproveita melhor o compute que já comprou. A infraestrutura não fica embaixo do produto. Ela é parte do produto.

Fonte: OpenAI.

Unsloth e NVIDIA acharam ganho onde a GPU estava esperando

A Unsloth publicou uma colaboração com a NVIDIA sobre otimizações para treino e fine-tuning de LLMs. O tipo de notícia é ótimo porque não tenta vender “um novo cérebro artificial”. Ela mexe em uma parte mais honesta do desempenho: tirar trabalho repetido, sincronização desnecessária e cópia serializada de onde já existe kernel rápido fazendo a matemática pesada.

O caso principal citado envolve Qwen3-14B em QLoRA SFT, com sequências empacotadas. A otimização de packed-sequence metadata caching evita reconstruir metadados camada por camada. Em treino empacotado, esse tipo de metadado ajuda a dizer onde cada sequência começa, termina e deve ser mascarada. Fazer isso de novo várias vezes custa tempo, sincroniza stream e rouba atenção da GPU.

No benchmark informado pela Unsloth, esse caminho gerou ganho de 43,3% no forward, 5,8% no backward e 14,3% por batch. A manchete de “25% mais rápido” pode ser útil como atalho, mas os números por caminho são mais importantes. Eles mostram que o ganho não cai igualmente em tudo. O forward se beneficia muito mais nesse cenário específico. O backward melhora menos. O batch completo fica no meio.

Também aparece double-buffered checkpoint reload. Gradient checkpointing economiza memória recomputando partes do grafo em vez de guardar tudo. Só que essa economia pode cobrar caro quando ativações precisam voltar da memória para a GPU em série. A ideia do double-buffering é sobrepor cópia e computação: enquanto uma parte está sendo usada no backward, a próxima já pode estar sendo preparada. É o tipo de coisa que lembra cozinha profissional. A panela certa no fogo certo evita que todo mundo espere pela mesma boca do fogão.

A terceira peça é MoE routing mais simples, usando operações de agrupamento como argsort e bincount para reduzir sincronizações repetidas. Em modelos mixture-of-experts, o roteamento decide qual token vai para qual especialista. Quando essa decisão gera muito vai e volta entre CPU, GPU e streams, a arquitetura bonita começa a pagar pedágio em coordenação.

Para quem treina ou ajusta modelo local, a notícia é interessante porque fala de consumer GPUs e de fine-tuning realista. Nem todo mundo tem cluster de GB200 com rede desenhada em parceria com cinco empresas. Muita gente tem uma placa forte, pouco VRAM sobrando e uma vontade perigosa de rodar experimento à noite. Melhorar o uso do que já existe pode esticar bastante o alcance desses fluxos.

A cautela é obrigatória. Não dá para sair dizendo que todo treino de LLM em toda GPU ficou 25% mais rápido. O ganho depende do modelo, do formato do batch, do uso de packed sequences, do caminho de checkpointing, da implementação e do runtime. O valor público da notícia está justamente no mecanismo: quando os kernels principais já estão otimizados, sobra desempenho escondido em metadado, cópia, sincronização e roteamento. Otimização de IA, muitas vezes, tem cara de engenharia de sistemas com avental de laboratório.

Fonte: Unsloth.

vm2 voltou a mostrar o limite frágil do sandbox de linguagem

O vm2 é uma biblioteca conhecida no ecossistema Node.js para executar JavaScript em uma sandbox. Esse tipo de ferramenta aparece em plugin runner, judge online, plataforma de automação, ferramenta dev, serviço que deixa usuário escrever script e, cada vez mais, em volta de agentes que precisam rodar código gerado ou recebido de fora.

Em maio de 2026, uma nova leva de vulnerabilidades no vm2 voltou a acender o alerta. The Hacker News reportou uma dúzia de falhas, com vários casos críticos e recomendação de atualização para vm2 3.11.2. Entre os problemas citados nas fontes aparecem escapes de sandbox e caminhos para execução arbitrária no host. Um advisory do GitHub para CVE-2026-24118 descreve breakout usando __lookupGetter__, afetando vm2 até 3.10.4 e corrigido em 3.11.0. A release 3.11.2 trouxe novas correções de segurança e atualizou invariantes de defesa.

O detalhe importante é o modelo mental. Sandbox de JavaScript tenta cercar objetos, protótipos, builtins, coerções e acesso ao ambiente. Isso é um trabalho ingrato. JavaScript é poderoso, flexível e cheio de cantos que parecem inocentes até alguém fazer Symbol-to-string coercion virar passagem secreta. Quando uma sandbox baseada em proxies e objetos falha, o código que parecia preso pode alcançar coisas do host, inclusive child_process, dependendo do bug e das permissões do processo ao redor.

Isso não quer dizer que todo app Node usando vm2 foi comprometido. O risco depende de atacante conseguir executar código controlado dentro da sandbox, da versão usada e do privilégio do processo hospedeiro. Mas para quem constrói agente, extensão, ferramenta de automação ou plataforma de execução, a pergunta certa é mais dura: se esse código escapar da sandbox de linguagem, o que ele encontra?

Se encontra um processo com token de produção, filesystem amplo, rede aberta e permissão para chamar shell, o sandbox era uma cerca bonita em frente a um portão aberto. Se encontra processo descartável, container com privilégio baixo, microVM, rede limitada, secrets fora do ambiente e timeout agressivo, o bug ainda é ruim, mas o raio da explosão muda.

A ação imediata é atualizar vm2 para versões corrigidas, com atenção especial para 3.11.2 nas fontes checadas. A ação menos confortável é auditar arquitetura. Online judge, plugin de usuário, CI helper, agente que roda snippet, ferramenta que “só avalia código rapidinho”: tudo isso merece isolamento em processo, container, microVM ou fronteira do sistema operacional. Linguagem ajuda. Processo segura melhor. Host com permissão demais continua sendo convite para sofrimento.

Fonte: The Hacker News, GitHub Advisory CVE-2026-24118 e release vm2 3.11.2.

Destaques rápidos para hoje.

• O X oficial do Ubuntu parece ter sido usado para divulgar um falso agente de IA chamado Numbat, com domínio parecido, ai-ubuntu.com, linguagem de Solana e pedido de conexão de carteira. A leitura cuidadosa aqui importa: as fontes checadas falam de phishing em canal social depois de um período de DDoS, sem evidência pública de comprometimento de APT, ISOs, chaves de assinatura ou do Ubuntu em si. Fontes: It’s FOSS, TechCrunch e Cyber Kendra.

• Daniel Stenberg, criador do curl, voltou a bater na tecla de verificar software em vez de confiar só no nome do projeto. Na prática, isso significa releases assinadas, documentação de verificação, CI, fuzzing, SBOM e uma cultura em que dependência famosa também precisa deixar rastro conferível. SBOM sozinho não salva ninguém, mas inventário sem verificação também é só lista bonita. Fontes: InfoQ, Daniel Stenberg e curl.

• O Microcks virou projeto incubado da CNCF em 7 de maio de 2026. Ele trabalha com API mocking e testes de contrato, que ficam mais importantes quando agentes começam a chamar serviços de verdade e você precisa de ambiente falso que se comporte direito. Incubação é sinal de maturidade comunitária, não certificado mágico de encaixe em toda stack. Fonte: CNCF.

• A Prompt API do Chrome chegou cercada por debate de padrões. O texto de Mat Marquis aponta preocupações de Mozilla, WebKit e W3C TAG, além do acoplamento prático com Gemini Nano no Chrome. Para dev web, tratar isso apenas como “oba, LLM no navegador” deixa metade do problema fora: entram permissão, privacidade, fingerprinting, custo local de recurso e risco de depender de uma API que nasce com cara de um fornecedor só. Fontes: Mat Marquis, Chrome Developers, ChromeStatus, Mozilla e WebKit.

• Simon Willison escreveu que “vibe coding” e engenharia agentic estão ficando mais próximos do que ele gostaria, inclusive porque ele já não revisa cada linha gerada pelo Claude Code em alguns trabalhos de produção. A leitura responsável passa longe de usar isso como autorização para largar código no mundo sem olhar. Confiança hoje passa por escopo, teste, documentação, uso real, reputação e responsabilidade de quem envia o resultado. Fonte: Simon Willison.

• A SecurityWeek publicou que atacantes usaram Claude e modelos GPT como motor operacional durante uma intrusão ligada a uma companhia municipal de água e drenagem em Monterrey, no México, dentro de uma campanha mais ampla entre dezembro de 2025 e fevereiro de 2026. Nada de imaginar uma IA invadindo tudo sozinha, com trilha sonora de filme ruim. A parte séria é outra: modelos já aparecem como aceleradores de análise, script e navegação em ambiente comprometido, inclusive com contexto OT/SCADA. Fontes: SecurityWeek e Los Angeles Times.

• A discussão sobre infraestrutura física de IA apareceu de novo em cobertura da TechCrunch sobre chip shortage, energia, refrigeração, rede e até data centers orbitais como ideia exploratória. Essa nota ajuda a ler o resto do dia: Anthropic compra capacidade, OpenAI mexe na rede, Unsloth espreme treino em GPU existente. A IA parece software, mas está cada vez mais presa em coisas bem materiais: tomada, calor, distância e silício. Fontes: TechCrunch, OpenAI e Anthropic.

• O Kubernetes 1.36 trouxe server-side sharded list and watch como recurso alpha. O problema é antigo em clusters grandes: você escala controladores horizontalmente, mas cada réplica ainda recebe o fluxo inteiro de objetos e joga fora o que não é dela. Com sharding no API server, cada réplica pode receber sua fatia direto da origem. Ótimo para acompanhar, cedo demais para vender como garantia madura de produção. Fonte: Kubernetes.

Acompanhamento de tendências do dia.

O padrão mais forte do dia é que agentes estão virando sistemas cercados por harness, não só prompts longos. Claude Managed Agents entra com memória curada, outcomes e orquestração. ProgramBench entra como balde de água fria: em 200 tarefas que vão de ferramentas CLI a FFmpeg, SQLite e um interpretador PHP, o paper reporta que nenhum dos nove modelos avaliados resolveu completamente qualquer tarefa. Os modelos tendiam a produzir implementações monolíticas, de arquivo único, que se afastavam do desenho humano original. Para quem acha que agente de código já “entendeu arquitetura”, esse resultado pede um cafezinho e revisão.

LongSeeker vai pelo lado do contexto. Ele propõe operações como Skip, Compress, Rollback, Snippet e Delete para agentes de busca de horizonte longo. Uno-Orchestra olha para decomposição e roteamento, aprendendo seleção de modelo e primitiva junto da divisão de tarefa. A mensagem combinada é boa: contexto grande demais também vira ruído, e delegar trabalho para agente especializado sem critério pode ser só terceirizar confusão.

Na segurança, DTap aparece como plataforma de red teaming para agentes em ambientes simulados. AgentTrust propõe interceptar chamadas de ferramenta antes da execução e devolver decisões como allow, warn, block ou review, com servidor compatível com MCP. SLYP usa um fluxo agentic para raciocínio sobre vulnerabilidades em Windows COM e reporta 16 CVEs atribuídas pela MSRC. É pesquisa e ferramenta inicial, então convém não vender como verdade de produção. Mas o rumo é claro: agente precisa de ambiente, política, verificador e freio.

Esse é um bom fechamento para o dia porque junta quase tudo. A Anthropic aumenta compute e cria primitivas de agente. A OpenAI publica rede para escalar treino. Unsloth corta desperdício em GPU menor. vm2 lembra que execução de código precisa de fronteira forte. Kubernetes mexe em sharding no API server. curl insiste em verificação. Microcks amadurece mocks de API.

No fim, “deixa o agente fazer” está virando uma frase perigosa quando vem sozinha. A versão mais útil é: deixe o agente fazer dentro de um sistema que mede, limita, simula, registra, testa e interrompe. Eu sei, falando assim perde um pouco a poesia. Mas ganha uma chance maior de não destruir o ambiente na terça-feira.

Fontes: ProgramBench, LongSeeker, Uno-Orchestra, DTap, AgentTrust, SLYP e Claude Managed Agents.

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