Co-escrito com @VaishShrivas
Ensinámos agentes CLI a prever respostas do terminal durante RL, juntamente com a perda GRPO habitual nas ações. A alteração é minúscula: o mesmo rollout e forward pass, mas paramos de mascarar os tokens de saída do terminal. O efeito é enorme: todas as avaliações melhoram, e os modelos resultantes aprendem de forma mensurável como o terminal se comporta.
Os agentes CLI podem aprender um modelo do terminal gratuitamente — e usá-lo para agir melhor!
Isto é o ECHO: um objetivo híbrido que treina em ambos os lados da interação: o que o agente escreve, e o que o terminal responde.
Consulte o artigo completo, e o código baseado no SkyRL.
Se não tiver tempo para ler este post inteiro, aqui está o que descobrimos:
- O RL padrão de agentes deita fora a resposta do ambiente. O GRPO treina em tokens de ação e mascara as respostas do terminal, apesar de estas já estarem no contexto, já passarem pelo modelo, e serem sinais de ground truth sobre como as ações do agente afetaram o ambiente.
- O ECHO corrige isto ao treinar em ambos os lados da interação. Mantém a perda GRPO habitual nos tokens de ação e adiciona uma simples perda de entropia cruzada do ambiente nos tokens de saída do terminal. São apenas algumas linhas de código sobre qualquer trainer GRPO. O mesmo rollout e forward pass, apenas uma máscara diferente sobre os logits.
- O ECHO funciona, e é grátis! O ECHO melhora o Qwen3-8B, o OpenThinker-Agent-v1-SFT e o Qwen3-14B em todos os benchmarks que testámos. O ECHO também treina até 2,3× mais rápido para o mesmo desempenho. O TerminalBench-2.0 pass@1 quase duplica tanto em 8B (2,7 → 5,2) como em 14B (5,2 → 10,8).
- O ECHO ensina dinâmicas do terminal! Em trajetórias retidas, a entropia cruzada dos tokens do ambiente cai drasticamente com o ECHO e mal se move com GRPO puro. Evidência direta de que o ECHO ensina o modelo como o terminal realmente responde. Os mesmos checkpoints que preveem melhor as saídas do terminal também resolvem mais tarefas.
- O ECHO pode substituir um professor especialista. A partir de um Qwen3-8B base sem demonstrações de especialista, o ECHO iguala quase o que o GRPO após SFT em demonstrações de especialista alcança.
- O ECHO permite que os agentes se auto-aprimorem sem recompensas do verificador! Sem quaisquer recompensas do verificador, o ECHO (sem qualquer GRPO) permite que o agente melhore ainda mais apenas ao agir no ambiente e prever o que acontece.
Isto começou como uma pergunta simples: se cada comando produz uma resposta do terminal, porque é que o RL treina apenas no comando?
A Vaish fez todo o trabalho para descobrir. Eu contribuí com uma experiência parva de labirinto*, uma opinião forte sobre o título, e dizer "caramba" quando ela me mostrou o primeiro resultado. Agradecimentos ao Ahmed Awadallah por nos dar espaço — e GPUs — para perseguir ideias como esta, mesmo quando começam apenas como uma comichão de investigação.
Vale a pena notar: a primeira execução em cluster para o ECHO foi lançada a 29 de março 😊
Este trabalho foi feito na AI Frontiers, um laboratório de investigação boutique dentro da Microsoft Research.
Como é que se aprende continuamente?
A primeira vez que esta ideia apareceu foi motivada por uma pergunta simples sobre auto-aprimoramento e aprendizagem contínua. Como é que um agente melhora apenas por agir no mundo?
A Vaish e eu conversávamos desde o outono passado sobre auto-aprimoramento em agentes CLI, ou seja, o que significaria melhorar através da interação com o ambiente (aka o terminal), especialmente sem um verificador.
RL sem verificador é um problema em que as pessoas trabalham há anos, e a maioria das tentativas enfrenta o mesmo problema: de onde vem a supervisão, se não há recompensa?
Mais ou menos ao mesmo tempo, um post parvo meu no Twitter levou a uma chamada com @willccbb a discutir novamente aprendizagem contínua. Durante esta conversa, lembro-me de dizer algo parvo como isto:
Talvez a aprendizagem contínua seja treinar naquilo que o ambiente te devolve como resposta às tuas ações.
Isso deve ensinar algo ao modelo, certo?
Acontece que sim!
O mundo é uma função de perda!
Quando um agente age num ambiente, a resposta do ambiente a essa ação é sempre verdadeira.
Um exemplo do mundo físico: se ligares um interruptor de luz, a luz acende-se, ou não. Se não acender, essa é uma resposta legítima: diz-te algo sobre a lâmpada, ou a cablagem, ou o disjuntor, etc. De qualquer forma, o que volta é um pequeno pedaço de informação sobre como o mundo mudou devido às tuas ações sobre ele. Não estás exposto ao mecanismo completo de como a eletricidade, os interruptores e as lâmpadas funcionam, mas vês o resultado. A luz acendeu-se? E isso é suficiente para começares a construir um modelo mental de como ligar interruptores acende luzes.
O terminal funciona mais ou menos da mesma maneira.
A saída após um comando bash é um pequeno resumo de como o estado do computador/contentor mudou depois de o comando ser executado. Vês stdout, stderr, códigos de saída, listagens de ficheiros, etc. Não vês o estado do kernel ou a árvore de processos ou nada muito detalhado.
O que vês de volta é uma projeção de baixa dimensão do que aconteceu em segundo plano, que é também o que o agente CLI usará para escolher uma próxima ação em direção à tarefa que está a tentar realizar. E tal como com o interruptor de luz, isso é sinal suficiente para construir um modelo mental — ou, se preferires, um modelo do mundo — de como o sistema se comporta.
A melhor parte é que a saída do terminal, que novamente é um reflexo de como o estado do sistema mudou, é um sinal de supervisão, calculado para ti, em cada turno, gratuitamente.
Fix!
O problema é que o RL padrão de agentes (ex: GRPO no SkyRL) empurra gradientes apenas através dos tokens de ação e ignora os tokens de saída do terminal. Apesar de a saída do terminal já estar no contexto. O modelo presta-lhe atenção, o forward pass calcula logits para ela, mas o trainer mascara-a da perda.
Que desperdício de bons tokens 😊
Então, e se não o fizéssemos?
O modelo já está condicionado a esses tokens. Já produz uma distribuição de probabilidade sobre eles. Adicionar uma perda de entropia cruzada não custa praticamente nada.
E se o fizermos… o modelo tem razão para aprender como o terminal realmente se comporta e pode, portanto, construir, dentro de si, um modelo implícito do sistema sobre o qual está a agir. Para prever o que o ls irá devolver, o modelo tem de acompanhar que ficheiros acabou de criar, o que vive onde, etc.
Como Ilya disse:
Prever bem o próximo token significa que compreendes a realidade subjacente que levou à criação desse token.
No nosso cenário, isso significaria: um agente que é bom a prever saídas do terminal construiu, num sentido pequeno mas real, um modelo implícito do terminal.
Então, como é que fazemos o agente prever saídas do terminal?
ECHO: Aprende um modelo do mundo sem pagar por ele
Um rollout de agente terminal já intercala dois fluxos de tokens: os tokens de ação do agente e os tokens de observação do ambiente. O GRPO padrão aplica perda apenas nos tokens de ação.
Isto é especialmente desperdiçador porque as recompensas do terminal são esparsas, atrasadas e binárias. No nosso cenário Qwen3-8B, para muitas tarefas, menos de 15% dos rollouts on-policy são bem-sucedidos. Mas as trajetórias falhadas não são dados falhados: ainda contêm listagens de ficheiros, erros, logs, stack traces, saídas de grep e outras consequências dos comandos do agente.
O nosso método é a maneira mais embaraçosamente simples de aprender com essas consequências 😊
Adicionamos uma perda de entropia cruzada normalizada pelo comprimento nos tokens de observação do ambiente, juntamente com a perda GRPO padrão nos tokens de ação. O ECHO é o objetivo híbrido:
onde Actions são as posições das ações do agente e Observations são as posições de saída do terminal.
Alguns pequenos detalhes técnicos:
- O ECHO aprende on-policy. Em vez de treinar num conjunto fixo de transcrições do terminal do modelo base ou de um professor, o ECHO aprende a partir de respostas do terminal produzidas pelo modelo atual durante o RL. À medida que o agente melhora, explora novas partes do ambiente e obtém supervisão fresca de novas transições ação → observação. Políticas melhores induzem melhor feedback; melhor previsão de feedback dá à política melhores prioris de ação. Um ciclo! Que divertido?
- No objetivo conjunto, λ é importante. Se for muito pequeno, a perda do ambiente não molda muito o modelo. Se for muito grande, a política pode otimizar para saídas previsíveis em vez de progresso na tarefa. É preciso equilibrar!
- Os tokens alvo importam. Treinamos na saída real do terminal, não em avisos do harness. Avisos são fáceis de memorizar; o sinal útil é a resposta real do terminal — nomes de ficheiros, stack traces e mensagens de erro.
Então, quanto é que isto custa?
Um leitor astuto pode perguntar:
o backward pass não é mais caro se estás a retropropagar gradientes em mais posições de tokens?
Quase que não. A parte cara da retropropagação são as matmuls através das camadas de atenção e MLP, e estas percorrem a mesma sequência de tokens independentemente de quais posições de saída contribuem para a perda. Os logits em cada posição de resposta já são calculados para o GRPO. A máscara de ação e a máscara de observação apenas recolhem subconjuntos diferentes deles para diferentes termos de perda.
Pausa aqui por um segundo: Adicionámos uma perda de modelação do mundo, e o custo é basicamente ZERO! Sem rollouts extra, modelo professor e sem forward pass extra.
O ECHO ajuda a treinar um melhor Agente CLI?
Fizemos a comparação mais limpa possível em tarefas de terminal multi-turn: mesmos modelos, mesma receita GRPO, mesmas tarefas, mesmo orçamento de rollout e turnos, mesmo número de passos de treino. Recompensa=1 se o agente passar nos casos de teste após n turnos, 0 se falhar.
A única diferença é se os tokens de saída do terminal também entram na perda.
As curvas cor-de-rosa são ECHO e verde-azulado GRPO. Em todos os tamanhos de modelo e fatias de avaliação, a resposta é a mesma: adicionar previsão do ambiente torna o agente substancialmente melhor.
O ECHO melhora consistentemente o desempenho em todos os três conjuntos de validação retidos — as curvas cor-de-rosa separam-se do verde-azulado desde cedo e geralmente mantêm-se acima.
O ECHO também aprende substancialmente mais rápido: o ECHO iguala o desempenho do GRPO aos 500 passos no Terminal-Bench Lite 280 passos mais rápido! Uma aceleração de 2,3x e continua a subir 😊
Estes resultados corroboram a nossa intuição por detrás do ECHO. O GRPO treina apenas com recompensas de resultado binárias e esparsas. Para domínios difíceis como tarefas de terminal onde a taxa de sucesso é baixa para modelos pequenos, isto traduz-se em pouco ou nenhum sinal para muitas tarefas.
O ECHO torna o treino muito mais eficiente em termos de amostras ao transformar ações falhadas em supervisão. Mesmo quando uma ação não resolve a tarefa, a resposta do terminal ainda ensina ao modelo o que essa ação causou! E prever as consequências de ações falhadas pode ajudar o agente a escolher melhores.
Se preferires ver os números nas avaliações, a mesma história em forma de tabela:
Olha para a última linha em cada bloco: ECHO. TerminalBench-2.0 pass@1 quase duplica em escalas 8B (2,7 → 5,2) e 14B (5,2 → 10,8). E, importantemente, isto não vem de dados extra, rollouts, um modelo professor, ou um verificador diferente. O rollout já continha a resposta do terminal. O ECHO apenas aprende com ela.
"Desempenho quase duplica sem custo extra" é uma frase que raramente se lê em toda uma carreira de investigação 😊.
O ECHO supera substancialmente o desempenho do GRPO em todos os benchmarks e tamanhos de modelo, é muito mais eficiente em termos de amostras e custa basicamente nada. Aprendes um modelo do mundo à medida que a tua política melhora, o que a ajuda a melhorar mais rápido.
Os céticos, no entanto, podem contestar: aprendes realmente um modelo do mundo?
Vamos ver!
O ECHO aprende realmente as dinâmicas do terminal?
Vamos ser um pouco cautelosos aqui porque a comunidade de modelação do mundo pode ser um pouco intensa.
Não vamos afirmar que o ECHO aprende um modelo do mundo no sentido mais forte. Mas vamos afirmar que o ECHO treina uma política cujos estados ocultos absorveram algo sobre como o terminal se comporta, e cuja capacidade de prever o que o terminal fará melhorou de forma mensurável.
Se inverteres a citação do Ilya, obténs uma versão mais falseável. Para o nosso cenário, seria algo como:
Se o modelo aprendeu as dinâmicas do terminal, tem de ser bom a prever a saída do terminal.
Porque não há outra maneira de atribuir consistentemente alta probabilidade aos tokens certos. Um modelo que é um melhor preditor é, em termos de teoria da informação, um melhor compressor do sistema que está a prever.
Então a questão torna-se empírica: o ECHO torna realmente o modelo um melhor preditor da saída do terminal?
Sim. Muito.
Para tornar este teste limpo, usamos um modelo professor mais forte, Qwen 3 32B (não usado em nenhum dos nossos treinos), para gerar trajetórias para cada um dos nossos conjuntos de validação. Depois avaliámos as nossas políticas iniciais, políticas treinadas com GRPO e políticas treinadas com ECHO, e medimos o quão "surpreendido" cada modelo ficou pelos tokens de saída do terminal resultantes.
O padrão é o mesmo em todos os painéis: o GRPO mal altera a entropia cruzada dos tokens do ambiente em relação à política inicial. O ECHO reduz-a drasticamente.
Portanto, não vamos dizer modelo do mundo com M maiúsculo. Mas vamos dizer isto:
O ECHO produz políticas que são mensuravelmente melhores a comprimir as dinâmicas do terminal, em trajetórias que não geraram.
Que é a versão operacional da afirmação que o título está a fazer, e a versão que é totalmente defensável.
Descoberta surpreendente 1: O ECHO reduz a dependência de SFT especialista
Uma receita comum para RL de agentes é: primeiro, clonar comportamento de trajetórias de especialista de um modelo mais forte, depois executar RL. Isto é especialmente comum para agentes de terminal, onde a recompensa é esparsa e o espaço de ação é enorme.
No nosso cenário, a baseline SFT especialista é OpenThoughts-Agent-v1-SFT (OT-SFT): Qwen3-8B afinado em demonstrações de agente terminal geradas por um professor GLM-4.6 mais forte.
Então perguntámos: quanto desse benefício do SFT especialista pode o ECHO recuperar sem clonar o comportamento do professor?
Pode o ECHO permitir saltar o SFT especialista? No nosso cenário, maioritariamente sim!
Esta figura compara três execuções: GRPO puro no modelo base, ECHO no modelo base e GRPO no modelo com SFT (SFT + GRPO). Relativamente ao fosso entre GRPO e SFT+GRPO (ex: o ganho obtido a partir de SFT), o ECHO recupera 104% do ganho no ITD, 89% no Terminal Bench Lite (TBLite) e 50% no TerminalBench-2.0 (TB2) pass@1.
O resultado sugere que grande parte do valor do SFT especialista pode vir de ensinar ao modelo um prior de interação, não apenas um prior de estratégia especialista. As demonstrações de especialista mostram tanto como comportar-se como um agente de terminal — inspecionar ficheiros, executar testes, seguir tracebacks, etc — como o que um especialista faria em estados específicos. O ECHO não imita essas escolhas de especialista. Em vez disso, treina o modelo para prever as consequências terminais das suas próprias ações, aprendendo assim quais comandos expõem estado útil, quais erros são diagnósticos e quais tokens de saída do terminal sinalizam progresso. Melhores estratégias podem então emergir através da interação em vez da imitação.
Isto também ajuda a interpretar a divisão dos benchmarks. No ITD e TBLite, o ECHO quase iguala o SFT especialista, sugerindo que grande parte da vantagem do SFT aí vem de um melhor modelo de interação com o terminal. No TB2, o ECHO ainda recupera uns substanciais 50% do fosso sem demonstrações. O fosso restante é consistente com o TB2 ser mais difícil e distribucionalmente mais afastado do conjunto de treino.
Não trataríamos isto como um teto fixo: treino mais amplo ou mais longo em tarefas semelhantes ao TB2 deverá melhorar ainda mais o agente.
Portanto, a conclusão não é que o SFT especialista está obsoleto, mas que grande parte do que o SFT especialista compra pode ser um melhor modelo de interação com o terminal, e essa parte pode ser aprendida diretamente do ambiente.
Conclusão: O terminal é o professor!
Descoberta surpreendente 2: Faíscas de Auto-Aprimoramento sem Recompensas
Até agora, o ECHO tem sido GRPO com uma perda auxiliar do ambiente. O verificador ainda diz ao agente se resolveu a tarefa, e o GRPO atualiza o modelo nos tokens de ação. Portanto, configuração RL padrão, com um pequeno termo extra.
Mas se o ECHO está genuinamente a ensinar algo à política sobre como o terminal se comporta, talvez não precisemos do sinal do verificador de todo.
Perguntamos: O que acontece se desligarmos o verificador? Sem recompensas para aprender, apenas isto:
Isto é: o modelo age, observa, atualiza apenas ao prever as saídas do terminal como consequência das suas próprias ações.
Isto parece que não deveria melhorar o desempenho da tarefa. Não há rótulo a dizer qual ação foi boa. Se a política melhorar, tem de ser porque aprender a prever o terminal remodela indiretamente os prioris de ação da política.
Então, experimentámos!
Pegámos no nosso checkpoint mais forte Qwen3-8B+ECHO, removemos o termo GRPO inteiramente e treinámos por mais 100 passos em tarefas retidas usando apenas a perda de entropia cruzada do ambiente. A questão era se o modelo conseguia melhorar em tarefas OOD que nunca tinha visto, puramente ao interagir com o ambiente e prever o que voltava.
Será que esta ideia maluca funcionou? Mais ou menos!
No val100 (dentro da distribuição): +3,8 pp. No ITD: +5,2 pp. No PyTerm (um conjunto OOD retido de tarefas de terminal com muita Python): +10,0 pp após filtrar para trajetórias de tool-call limpas.
O treino apenas com o ambiente melhora a política quando a saída do terminal é uma supervisão útil. Sem sinal de recompensa, o modelo treina apenas para prever as saídas causadas pelas suas próprias ações, pelo que os ganhos dependem de essas saídas exporem dinâmicas úteis.
No val100, que está próximo da mistura de treino, o ganho é real mas pequeno: +3,8 pp antes da saturação. A política já aprendeu a maioria das dinâmicas locais durante o treino ECHO.
No ITD, a política inicial mais fraca produz trajetórias ruidosas — comandos inválidos, erros de parsing, loops sem saída. Filtrar para rollouts limpos desruido o sinal e dá +5,2 pp.
Apenas trajetórias limpas não são suficientes, no entanto. A mesma filtragem não melhorou consistentemente o TBLite, enquanto o PyTerm começou com uma taxa de sucesso semelhante mas melhorou sob a mesma receita — sugerindo que o gargalo não é apenas a força da política. A diferença chave é o quão informativas são as observações: tarefas Python dão feedback denso ligado a ações — código → traceback → correção — enquanto tarefas de terminal mais amplas revelam estado de forma mais indireta através de ficheiros, configurações e configuração multi-passo.
Acreditamos que a adaptação sem verificador é possível: uma vez que o RL produziu um modelo explorador decente, o agente pode por vezes continuar a melhorar apenas a partir de consequências — mas apenas quando os seus rollouts são limpos e o feedback do terminal é informativo. ISSO é a parte surpreendente. Não que o agente se auto-aprimore perfeitamente, mas que se auto-aprimore de todo, a partir de nada mais do que agir e prever o que volta.
Onde isto nos deixa
A lição central do ECHO é simples: os rollouts de agentes contêm mais supervisão do que apenas a recompensa final, e devemos usá-la.
Cada comando que um agente executa produz uma resposta do terminal — stdout, erros, traces, ficheiros, logs, etc — e o RL padrão usa esses tokens apenas como contexto para a próxima ação. O ECHO transforma-os em alvos de treino. Sem modelo professor, rollouts extra ou modelo do mundo separado necessários. Apenas paramos de deitar fora os tokens do ambiente que já estão na transcrição.
Essa pequena alteração levou a três resultados surpreendentes: desempenho RL mais forte, muito menos dependência de SFT especialista e, em alguns cenários, auto-aprimoramento sem verificador apenas a partir da interação com o ambiente. Não achamos que isto signifique que recompensas ou demonstrações estejam obsoletas. Trajetórias de especialista ainda ensinam estratégia e verificadores fornecem o sinal de tarefa mais limpo. Mas o ECHO sugere que entre "imitar o especialista" e "esperar pela recompensa esparsa", existe uma fonte densa e subutilizada de supervisão: as consequências das próprias ações do agente.
A ideia mais ampla é uma continuação da previsão auxiliar que tem uma longa história em RL, e o trabalho recente reavivou objetivos de modelação do mundo para agentes LLM, ex: Agent Learning via Early Experience usa sinal ação-consequência como uma fase pré-RL, VAGEN adiciona uma recompensa de modelação do mundo para agentes VLM, RWML pré-treina em previsão do próximo estado, e CWM treina um modelo de código em trajetórias observação-ação. O ECHO é a versão online, dentro do loop RL, com sabor CLI, da mesma ideia.
Até onde pode esta ideia ir?
O próximo passo é tornar este sinal do ambiente mais potente — e testar até onde generaliza. O ECHO usa saídas brutas do terminal porque já estão no rollout, mas o melhor alvo de aprendizagem pode ser uma representação mais limpa e compacta: resumos ou vistas relevantes para a tarefa do estado. Também: Em que observações devemos treinar? Quando devemos filtrar trajetórias? Como devemos pesar a previsão do ambiente contra a otimização da política? Pode a mesma ideia funcionar para além de terminais: para agentes de browser, sistemas multi-ferramenta, agentes de codificação de longo horizonte, ou assistentes virados para o utilizador onde follow-ups, correções e preferências são outra forma de feedback de interação?
A nossa aposta é que em qualquer lugar onde um agente age e o mundo responde em tokens, esses tokens de resposta — ou melhores representações deles — devem fazer parte do sinal de aprendizagem. O ECHO é a versão mais simples dessa ideia que conseguimos imaginar, e suspeitamos que alguma forma de previsão de tokens do ambiente será padrão em trainers de RL de agentes até ao final de 2026.
Consulte o artigo completo e o código baseado no SkyRL.
Experimenta o ECHO e diz-nos quão mais rápido o teu agente treinou.
Nota de rodapé: treinar um modelo do mundo de labirinto no meu portátil… mais ou menos
Lembram-se quando eu disse que "contribuí com uma experiência parva de labirinto"? Aqui está a experiência parva de labirinto
A configuração era uma versão minúscula do ECHO: Um labirinto de grelha num terminal minúsculo. O agente (um transformer de 10M num loop) emite uma direção — cima, baixo, esquerda, direita — e o terminal responde com onde o agente está em relação aos seus "vizinhos" (é basicamente um problema de encontrar caminho numa grelha 2D) e a distância ao destino. Portanto, o rollout parece exatamente (para valores pequenos de exatamente) como um rollout de agente CLI, apenas muito mais simples 😊: ação → resposta do ambiente → ação → resposta do ambiente, etc.
Testei duas condições num transformer de 10M parâmetros treinado de raiz: 1) treinar apenas nos tokens de ação 2) treinar nos tokens de ação e na resposta do terminal (vizinhos, distância, etc). Todos treinados em labirintos novos 6×6 / 7×7 / 8×8
É esta coisa do labirinto um artigo na Nature? Não. Mas: acho que há um ponto que tenho feito que continua a generalizar.
Quase todas as ideias limpas têm um microcosmo: uma versão reduzida que podes executar num portátil numa noite e que te diz se vale a pena escalar a ideia.
O labirinto não provou que o ECHO funcionaria. Deu-me convicção suficiente para enviar uma mensagem no Teams à Vaish em vez de esquecer a ideia. Acontece que a Vaish andava a rondar a mesma ideia independentemente e quando a primeira execução em cluster dela voltou com resultados, fiquei entusiasmado e genuinamente surpreendido. O labirinto ECHO tinha sugerido que a direção estava certa, mas não poderia ter previsto duplicar as pontuações do TerminalBench, recuperar a maior parte do SFT especialista, ou auto-aprimoramento sem recompensas. Esses foram os resultados da Vaish. "Resolver mais ou menos um labirinto 6×6" e "duplicar no TerminalBench" são estados epistémicos muito diferentes.
Mas o objetivo deste adendo não é que o laptop substitua o experimento com cluster. O ponto é que a maioria das minhas ideias está errada e o experimento com laptop (com a ajuda do Claude Code e do Codex) me diz quais descartar antes que elas custem tempo a outras pessoas. De vez em quando, uma ideia sobrevive, e quando isso acontece, ela talvez ganhe o direito ao tempo e aos GPUs de um colaborador.
ECHO é uma delas.
