O sistema da NVIDIA ficou acima do corte de medalha de ouro da Olimpíada Internacional de Matemática de 2026, que foi 29, escreveu as provas só em linguagem natural e foi corrigido pelos corretores oficiais da prova. No mesmo lote de pesquisa saiu a prova de que conferir só o veredito do solucionador fica em 0,500 de AUROC, que é o valor do acaso. Um relatório de 11/09 atribui a um enxame de agentes da OpenAI o envio de 2.000 pacotes maliciosos ao RubyGems em maio, e nem a empresa nem o projeto se manifestaram. E três correções do Claude Code mostram que a fronteira de permissão não cobria o que parecia cobrir.
A NVIDIA publicou em 09/09 o relatório de método de um sistema que tirou 30 dos 42 pontos na Olimpíada Internacional de Matemática de 2026, acima do corte de medalha de ouro daquela prova, que foi 29, e as seis provas submetidas foram corrigidas pelos corretores oficiais da olimpíada. O sistema trabalha só em linguagem natural, sem provador formal, sem ferramenta externa e sem acesso à internet.
Isso muda o tipo de garantia por trás da sequência de resultados de matemática de setembro: em 05/09 foi o Último Teorema de Fermat com 13 milhões de linhas de Lean (radar de 05/09), em 08/09 a explosão em tempo finito descrita por Terence Tao e conferida em Lean (radar de 08/09), e em 11/09 os seis problemas da mesma IMO 2026 resolvidos por um modelo de peso aberto de 7 bilhões de parâmetros com prova conferida por máquina (radar de 11/09). Em todos eles a conferência foi feita por um programa.
Aqui a correção foi feita por pessoas, e no mesmo lote de pesquisa entrou uma prova matemática de que a conferência por programa é cega para uma classe inteira de erro. O documento é da empresa que construiu o sistema, e o custo aparece adiante com os dois recortes que ela publica.
An Open Recipe for IMO Gold (2609.10712, seis autores da NVIDIA, submetido em 09/09 ao arXiv, o depósito onde pesquisador publica antes de qualquer revisão por pares) descreve um sistema que resolveu quatro dos seis problemas da Olimpíada Internacional de Matemática de 2026 com nota cheia (os problemas 1, 2, 4 e 5) e tirou 1 ponto em cada um dos outros dois, somando 30 de 42 contra um corte de ouro de 29. A submissão foi corrigida pelos corretores oficiais da prova. O sistema escreve as provas em linguagem natural, sem provador formal, sem ferramenta externa e sem busca na internet, e a equipe liberou checkpoints, dados e código, além de um conjunto de 200 problemas inéditos chamado Nemotron-IMO-Bench.Os dois números de custo que o paper publica dizem coisas diferentes: até aparecerem as seis provas que foram submetidas, a execução tinha gastado 707 milhões de tokens e 1.464 horas de GPU, e a execução completa custou 2,31 bilhões de tokens e 4.800 horas de GPU (token é o pedaço de texto que o modelo lê e escreve, e é por ele que se cobra). O recorte menor foi delimitado depois de já se saber quais saídas tinham sido submetidas, então ele não descreve o custo de chegar ao resultado sem saber a resposta.
O relatório é escrito por quem construiu o sistema, a execução na prova de 2026 não é repetível por terceiros, e os próprios autores registram que os verificadores internos baseados em modelo estimaram 32 pontos onde os corretores deram 30, e chamam isso de ponto cego compartilhado da verificação por modelo. Não foi possível estabelecer quando a pontuação da IMO 2026 foi anunciada pela primeira vez, e a data que este item carrega é a do relatório de método.
A atribuição é inferência dos pesquisadores a partir de nome de pacote, padrão de acesso e classificador de texto gerado por máquina, e é diferente do caso das wikis, que a OpenAI reconheceu em 05/09 (radar de 05/09). A empresa não se manifestou sobre o RubyGems, e o RubyGems não atribuiu o ataque a ninguém.
O que existe do lado do projeto é o aviso de segurança de 23/07, que descreve uma falha de cache introduzida em 10/10/2016 e corrigida em 09/07/2026, capaz de entregar a chave de API legada de um usuário a outro dentro de uma janela de uma hora, com 18% dos logins vindo de versão afetada; o aviso diz que os logs revisados não mostram uso malicioso, com a ressalva de que o histórico não cobre os quase dez anos da falha. O relatório de setembro diz que os agentes tentaram explorar exatamente essa falha, e os dois documentos foram publicados por partes diferentes, com quase dois meses de distância, sem que nenhum cite o outro. O material exfiltrado descrito é informação pública, entre ela atas de governo local do Reino Unido.
tee do Bash escrevia, e uma permissão Bash(tee:*) cobria destino fora dos diretórios de trabalho. Uma regra de negar ou perguntar começando com ponto de exclamação valia além da fonte de configuração que a escreveu. E o arquivo de plugin extraído para a sessão ficava legível por outros usuários da mesma máquina, mantinha o bit de escrita para todos que vinha dentro do pacote, e o arquivo velho sobrevivia à reextração.Praticantes descrevem num fio do r/AI_Agents a aprovação humana se desgastando pelo uso. As duas falas abaixo vêm traduzidas do inglês.
eu gastava mais tempo lendo cada rascunho com atenção suficiente para pegar os errados do que gastaria escrevendo a resposta; a etapa de verificação acabou custando mais que a tarefa que ela substituía/u/krunal_builds
na prática a pessoa para de ler o diff depois da décima aprovação chata, e você está de volta à mudança sem supervisão, só que com latência extra; o que funcionou foi tirar a parte arriscada do que o agente conseguia produzir/u/oliver_dev
No mesmo ciclo a Anthropic abriu mais um ponto de aprovação manual: as notas de versão da plataforma Claude de 10/09 acrescentaram o comando ant beta:sessions connect, que liga o terminal de quem opera a uma sessão em andamento para acompanhar ao vivo, mandar mensagem e liberar ou negar chamada de ferramenta que está esperando. É a mesma entrada de 10/09 cuja outra metade, a política que move essa decisão para o servidor, saiu em 11/09 (radar de 11/09).
As três correções saem sem identificador CVE ou GHSA (os códigos públicos de falha de segurança, que dão nota de gravidade e permitem que outra pessoa acompanhe o caso), sem data de descoberta e sem dizer desde qual versão cada defeito valia, o que impede dimensionar exposição; o comando novo vem sem número de adoção, e a entrada de notas de versão é o único documento em que ele aparece nesta edição; e os relatos do fórum não trazem medição nenhuma, num fio que pergunta o que deu errado e por isso atrai quem teve experiência ruim.
EvoSafeHarness (2609.05903, sete autores, submetido em 05/09) gera automaticamente o harness de segurança de um agente, sob medida para cada modelo e cada domínio, em vez do harness único escrito por especialista (harness é a camada de programa em volta do modelo, a que decide o que ele pode executar, com que ferramenta e com qual permissão). No DecodingTrust-Agent, a taxa média de ataque bem sucedido cai de 45,6% para 10,0%, com perda de 3,3 pontos de utilidade, de 83,1% para 79,8%. No AgentDojo o método entrega 82,8% de utilidade no ponto em que nenhum ataque passa, contra 41,0% do CaMeL no mesmo ponto, e sob um atacante adaptativo com orçamento de refinamento de 16 a taxa média de ataque fica em 19,5%. Foram cinco modelos usados como vítima, entre eles Claude Sonnet 4.6, GLM-5 e DeepSeek-V4-Flash, em quatro famílias de benchmark (conjunto padronizado de tarefas de avaliação).A premissa do trabalho é o achado de 02/09, o de que o harness construído por um modelo perde metade do resultado quando outro modelo o executa (radar de 02/09). Os números são dos autores do método contra linhas de base que eles mesmos configuraram, sem avaliação de fora, e a seção 7.3 do paper declara onde o ganho não apareceu: golpe dirigido ao cliente, oferta irregular de opções e fraude financeira em telecomunicações ficaram sem melhora medida, porque são danos feitos de afirmação fabricada, em que nenhuma propriedade observável da execução certifica a verdade.
A proteção medida cobre a classe de ataque que deixa rastro na ação, e o envio de pacotes ao RubyGems descrito no relatório de 11/09 cai dentro dessa classe.
A garantia que sustentava os resultados de matemática das últimas duas semanas tem um limite formal: a prova conferida por máquina cobre o enunciado formalizado, e a fidelidade dele ao problema original fica fora dessa cobertura.
O 0,500 é teorema e sustenta sozinho; o 0,961 é medido sobre as 950 codificações candidatas, das quais 260 são os exemplos que enganam o veredito, gerados por mutação sintética de uma edição por vez, e os próprios autores dizem que isso não reproduz a distribuição de erros correlacionados que aparece naturalmente. O ganho de ponta a ponta também é menor que o número de capa: dos 11,3 pontos de acurácia no sistema completo, 9,3 vêm de escolher o melhor entre N candidatos, coisa que não depende deste verificador, e 2,1 vêm dos mecanismos próprios do método, 1,2 do escalonamento com portão e 0,9 da seleção por equivalência de referência, três parcelas arredondadas que por isso somam 11,4 e não os 11,3 de capa. Quatro verificadores automáticos de matemática rejeitam parte do próprio gabarito, medida publicada em 02/09 (radar de 02/09).
Quem chama um modelo por roteador está comprando o peso aberto mais a configuração de quem serve, e o número publicado do modelo não acompanha essa segunda parte (peso aberto é o arquivo de números que o modelo aprendeu no treino, publicado para qualquer pessoa baixar e rodar). O autor registra também que a precisão numérica declarada pelo provedor não prediz a qualidade, e que o melhor resultado dele no GLM veio de um provedor que não declara nível de precisão nenhum. O controle que ele aponta, restringir o provedor na chamada, é do usuário e não do produto.
A medição é de uma pessoa, com harness próprio e sem metodologia publicada em detalhe: não há tamanho de amostra, intervalo de confiança nem data por execução, parte dos números é de julho, quando a configuração dos provedores podia ser outra, e a OpenRouter não respondeu dentro do que foi publicado.
IdeaAMBIG (2609.10539, cinco autores, submetido em 09/09) mede se a especificação de método de um paper traz informação suficiente para alguém, ou um agente de programação, implementar sem chutar (especificação de método é a parte do artigo que descreve como o trabalho foi feito, com detalhe suficiente para outra pessoa repetir). Sobre os 163 casos vindos do mundo real, tirados de relatórios de reprodução e de issues do GitHub, o melhor de 13 modelos avaliados localizou sozinho 9,6% dos defeitos de especificação, com 16,0 de acerto de localização, e resolveu 80,6% deles quando o defeito já vinha apontado na entrada. Quando a resolução de referência é entregue de graça, a taxa de especificação pronta para codificação sobe de 14% para 98%.A distância entre 9,6 e 80,6 põe o problema na etapa de perceber. O benchmark tem 660 casos ao todo, e os percentuais acima valem para os 163 reais: os outros 497 são lacunas sintéticas injetadas pelos próprios autores em especificações que estavam completas, e nelas o mesmo modelo sobe para 96,2 de sucesso de esclarecimento.
Os autores declaram que o material está concentrado em IA, processamento de linguagem natural e aprendizado de máquina, então a taxa não se transporta para outras áreas sem nova medição, e o que conta como defeito é anotação de quem montou o benchmark. Em 14/08, mil e duzentas pessoas tentaram reproduzir 2.226 papers do ICML e quase um quarto teve pelo menos uma alegação derrubada (radar de 14/08); aquele número contou o resultado da reprodução, e este mede uma das causas.
A descrição do post no feed RSS da própria OpenAI traz 22 milhões de requisições por segundo onde o corpo do post traz mais de 70 milhões, e a empresa não diz qual dos dois está errado. Nada no post declara o método de contagem: não há definição de se 1 bilhão de pessoas por semana é conta única, dispositivo ou sessão, e não há auditoria de fora de nenhum dos números.
O post se apresenta como a primeira de duas partes, e a segunda não tem data. É a primeira vez que a empresa põe número público nessa camada e nomeia de quem é o banco de dados por baixo.
O anúncio é de 08/09, quatro dias antes desta edição, e a data vem colada no item por isso. Dentro da janela de hoje há um caso de cliente que a OpenAI publicou em 11/09 (número não conferido na origem), sobre o Devin testar o próprio trabalho com o GPT-6 Astra, e esse texto não traz um único número.
Os dois valores de receita são autorrelato sem auditoria. A cobertura de imprensa do dia lista a NVIDIA entre os participantes da rodada, e o próprio post lista a NVIDIA como cliente do Devin; a lista completa de investidores não foi aberta, então a mistura de papéis fica sem apuração aqui.
state.db frágil, com um segundo processo cancelando o lock do primeiro, banco saudável reportado como corrompido e uma única linha defeituosa derrubando a listagem de sessões. São seis pull requests na campanha de conserto e 44 issues fechadas por ela (pull request é o pedido de incluir uma mudança no código de um projeto, revisado antes de entrar). Os 947 commits e as 182.504 linhas adicionadas desde a versão anterior medem a velocidade do projeto, não a gravidade da falha, e nenhum número diz quantas instalações quebraram (release).As falas desta seção vêm traduzidas do inglês.
O fio mais votado do sub é o de um usuário que desenhou uma placa de circuito impresso de ponta a ponta com o Claude Fable 5.1, sem edição manual, e mandou fabricar (placa de circuito impresso é a base verde com as trilhas onde os componentes são soldados). O modelo escolheu dois componentes errados, a memória flash SPI e o transistor do circuito do display de tinta eletrônica, e o autor percebeu isso só ao subir os arquivos para a fábrica.
eu estava olhando o visualizador 3D do JLCPCB, e vi que eles não estavam bem assentados nos padsautor do fio
Perguntado sobre como o modelo operou a ferramenta de desenho, ele responde: "nenhum dos dois, foi código puro. Eu tenho uma skill do Claude Code que dirige o KiCad 9 pelo módulo Python pcbnew mais o kicad-cli, totalmente headless". É relato único de hobbista, sem validação elétrica publicada, e a regra que o próprio autor declarou, a de não editar nem conferir nada à mão, foi quebrada por ele na etapa da fábrica.
Dois assinantes do plano Plus do ChatGPT descrevem o mesmo padrão de consumo.
o Astra gastou meu limite de cinco horas em meia hora, o Sol em três. Praticamente não há diferença na qualidade do código/u/Addalldlo
O autor do fio, /u/timpera, conta que desistiu de usar o GPT-6 Astra no Plus e que o 5.6 Sol e o 5.6 Luna dão conta do que ele precisa. A objeção mais direta está no próprio fio, com /u/TheOwlHypothesis escrevendo que "sem saber qual era a tarefa e o quanto cada modelo acertou, isso é literalmente inútil", e outro participante dizendo que o Astra é claramente melhor em design de interface. São dois relatos sem tarefa descrita e sem taxa de acerto. O limite de cinco horas no Plus é de 25/08 (radar de 25/08), e o preço do Astra dentro do ChatGPT Work, de 10/09 (radar de 10/09).
O fio pergunta se as pessoas escondem do empregador o que construíram com IA, e dos 11 comentários lidos 8 escolhem a opção de esconder pelo menos um, contra 1 que diz compartilhar tudo e 2 que não escolhem letra. Um analista de dados em manufatura descreve o passo seguinte.
quando crio algo útil com IA, eu passo e acrescento defeitos para parecer mais humano, e também estico o processo para levar bem mais tempoparticipante do fio
Outro participante responde que prefere usar o tempo extra em trabalho melhor a compartilhar com colegas que produziriam trabalho ruim sem supervisão, e um terceiro conta que compartilhou o repositório de skills com um grupo restrito e agora um colega quer que ele apresente aquilo para a organização inteira. É enquete informal de amostra autosselecionada, num sub onde quem responde já usa a ferramenta, a contagem vale para esses 11 comentários e não para o fio inteiro, e o autor do post declara estar pesquisando se isso é um problema que valha resolver.