A aba de Schrödinger do Claude in Chrome: ela só trabalha enquanto você olha

Por que agentes de IA que trabalham em abas em segundo plano do Chrome ficam lentos, pegam no sono e podem até derrubar um chat de atendimento.

Eu costumo tocar várias coisas ao mesmo tempo. Numa tarde de meados de julho, dei três tarefas de uma vez ao Claude in Chrome. Na primeira aba ele estava conferindo o recurso de detecção de pop-ups do nosso navegador, na segunda estava procurando uma música de fundo que combinasse com um vídeo, e na terceira estava redigindo uma reclamação para o atendimento da Origin Energy, porque eles tinham calculado errado uma das minhas contas de luz. Com as três em andamento, deixei o navegador em segundo plano e voltei para o terminal, onde uso o Claude Code para tocar o meu time de desenvolvimento feito de IA. É para isso que eu quero agentes: vários trabalhando sozinhos, sem eu ter que ficar de babá de cada um.

Quando voltei para o navegador um tempo depois, só uma das três tarefas tinha andado. As outras duas pareciam ter cochilado, e continuaram assim mesmo depois de eu esperar um pouco e clicar entre as abas algumas vezes.

O primeiro palpite da maioria das pessoas seria internet lenta ou modelo lento naquele dia. Só que, se o problema fosse a internet ou o modelo, as três tarefas teriam ficado lentas juntas, e ali só uma estava andando. Trabalho com navegadores há muitos anos, e me veio na hora outra explicação: o Chrome estava reduzindo a velocidade das abas em segundo plano.

Isso nem é bem um defeito do Chrome. Um navegador deve fazer isso mesmo. Uma página que você não está olhando não tem por que rodar em velocidade total, e as pessoas deixam dezenas de abas abertas; se todas rodassem a todo vapor, estando na frente ou não, a bateria do notebook acabava em meio dia. O problema é que as páginas do navegador não existem mais só para as pessoas olharem. Agentes de IA também trabalham nelas. Para uma pessoa, uma aba em segundo plano é algo de que ela não precisa agora. Para um agente, essa mesma aba pode estar esperando um download, encaminhando um reembolso ou segurando um chat de atendimento que não pode cair. Uma aba que ninguém está olhando ainda pode ter trabalho a fazer.

As regras do navegador foram escritas para pessoas, e servem mal nos agentes.

Em 16 de julho testei na mão e confirmei que o problema era esse. Foi também o dia em que decidimos colocar um recurso chamado "abas de IA" no Embiody, o navegador que fazemos para agentes de IA. Há pouco tempo refiz esses testes direito, para responder a três perguntas: quanto o Chrome desacelera uma aba em segundo plano; quando o Chrome congela uma página por completo; e a mais chata, se um agente pode ler a coisa errada numa página que continua aberta. Os resultados foram piores do que eu esperava.

1. Passam oito minutos, a página acha que foi um minuto e meio#

Comecei pela página de contagem regressiva mais comum que existe, andando uma vez por segundo, escrita do mesmo jeito que as contagens das páginas de checkout e de pagamento. A cada passo, a página informa o progresso a um pequeno servidor na mesma máquina, então, mesmo que o navegador congele a página, o servidor continua com o registro do que aconteceu de verdade.

Abri duas cópias dessa página, uma aberta pelo Claude in Chrome e outra aberta por mim para comparar, e deixei as duas fora de vista por 8 minutos. Testei três jeitos de escondê-las: trocar para outra aba, cobrir a janela inteira com outra janela e minimizar a janela. Os três deram praticamente o mesmo resultado.

No primeiro minuto depois que a página saiu de vista, nada mudou, e a contagem continuou andando uma vez por segundo. Depois de mais ou menos um minuto, ela caiu para um passo por minuto. Depois de 8 minutos, tinham se passado 480 segundos no mundo real, mas a página achava que só uns 90 tinham passado, então estava 390 segundos atrasada. É como sair para tomar um café da manhã de 8 minutos e voltar para um relógio que andou um minuto e meio. E quando trouxe a janela de volta, a contagem voltou a andar uma vez por segundo, mas os minutos perdidos nunca foram recuperados.

Mais importante: a página que o Claude in Chrome abriu se comportou exatamente como a que abri na mão, 387 a 391 segundos de atraso na do Claude, 392 na minha. Ou seja, isso não tem nada a ver com o Claude. Qualquer página aberta no Chrome que ninguém esteja olhando acaba assim, o que quer dizer que qualquer um que rode um agente no Chrome vai dar de cara com isso.

(Windows 11, Chrome 157.0.8103.39, extensão do Claude 1.0.106, 11 de novembro de 2026, uma máquina, 1 a 2 execuções por caso.)

Isso levanta uma pergunta óbvia. As abas do Claude in Chrome ficam em segundo plano quase o tempo todo. Se uma aba em segundo plano só anda uma vez por minuto, como é que ele consegue fazer alguma coisa? E, no entanto, ele claramente termina o trabalho.

2. Só a aba em que o agente está mexendo fica acordada#

Para descobrir, montei uma página de teste mais parecida com uma tarefa real, com os dois tipos de espera mais comuns em sites. O primeiro é um download: a página diz "Seu download vai começar em 90 segundos", e o botão de download só fica clicável quando a contagem chega a 0. O segundo é uma exportação: a página diz "Exportação em andamento", pergunta ao servidor a cada 2 segundos se já terminou, e o servidor diz que sim depois de 90 segundos.

Aí pedi ao Claude in Chrome que fizesse duas dessas tarefas ao mesmo tempo, uma na aba A e outra na aba B. Ele trabalhou primeiro na A, e a B ficou em segundo plano sem ninguém mexer. Foi isto que aconteceu:

Aqui está a B da segunda execução, no momento em que trouxe a janela de volta. Repare quanto tempo a página diz que esperou:

A página tinha esperado 378 segundos de tempo real e ainda faltavam 6. Uma espera de 90 segundos virou seis, sete minutos, e foi exatamente isso que aconteceu comigo naquela tarde de julho. O agente trabalhou o tempo todo, só que sempre na A, enquanto a B se arrastava em segundo plano a um passo por minuto. Quando ele finalmente olhou para a B, uma contagem que deveria ter acabado fazia tempo ainda estava correndo. E esse foi o caso de sorte. Se o agente nunca voltasse para a B, a um passo por minuto aquela contagem de 90 segundos levaria cerca de meia hora.

O curioso é que a exportação quase não foi afetada. O servidor disse que tinha terminado aos 90 segundos e o agente percebeu só 3 segundos depois.

As duas eram esperas numa aba em segundo plano, então por que o Chrome desacelerou a contagem do download e deixou a exportação em paz?

A diferença está em como as duas esperas são escritas. A contagem põe o próprio despertador: quando o despertador deste segundo toca, ela programa o próximo, e quando esse toca, programa o seguinte, cada despertador encadeado no anterior. A exportação espera alguém retornar a ligação: ela pergunta ao servidor, e só depois que o servidor responde é que agenda a próxima pergunta, então cada rodada começa do zero a partir da resposta de outra pessoa. O Chrome tem uma regra feita especificamente para despertadores encadeados. Depois que uma página fica um tempo fora de vista, esses despertadores só podem tocar uma vez por minuto. Por isso a contagem ficou lenta, enquanto a exportação, que espera o retorno da ligação, não entra na regra.

Então a desaceleração em segundo plano não deixa a página inteira lenta por igual. É o jeito como a página foi escrita que decide se ela fica lenta. Mas isso ainda não é o pior.

3. Depois de 20 segundos, a página para de vez#

A lentidão de cima pelo menos chega lá uma hora. A próxima realmente me assustou. O Claude in Chrome abre abas novas em segundo plano por padrão, atrás da aba que você está olhando. Pedi a ele que abrisse uma aba de teste e depois não mexi mais em nada, e depois de só 20 segundos a página parou completamente. A contagem não andava uma vez por minuto, não andava nada, até o agente voltar e fazer alguma coisa nela. Vi isso quatro vezes, sempre por volta dos 20 segundos, e a janela do navegador estava ali na tela o tempo todo, nem coberta nem minimizada.

A janela está à vista, então por que uma página dentro dela pararia de repente?

Para comparar, abri a mesma página numa aba em segundo plano do jeito normal. Depois de 3 minutos ela ainda estava rodando, só que reduzida a um passo por minuto, então os 20 segundos tinham que ter alguma coisa a ver com o Claude in Chrome. Fiquei de olho na barra de abas por um tempo e finalmente vi: uns 20 segundos depois do último comando do agente, o grupo de abas do Claude se recolheu sozinho, e quando um grupo de abas se recolhe, o Chrome congela as abas dele que nunca foram exibidas. Fique de olho na barra de abas neste clipe:

Cada uma dessas coisas faz sentido sozinha. O Claude in Chrome não quer a pilha de abas dele tomando conta da sua barra de abas, então guarda o grupo quando fica parado. O Chrome trata um grupo recolhido como coisas guardadas numa gaveta de que você não vai precisar por um tempo, então corta a energia para economizar memória. Junte as duas regras sensatas, porém, e toda aba que o agente abriu em segundo plano cai no sono assim que o agente faz uma pausa.

Mas a aba em que o agente está trabalhando de fato deve estar bem, não? Pedi ao agente que cuidasse de duas abas, A e B, lendo a A a cada 30 segundos nos primeiros 3 minutos. A rodou normalmente o tempo todo, enquanto a B, que ninguém tocou, praticamente parou a partir do segundo minuto. Aí pedi que ele passasse a ler a B. A B acordou na hora, mas uns 30 segundos depois a A, que tinha acabado de ser deixada de lado, também estava congelada.

Ou seja, quando um agente mexe numa aba, essa aba fica acordada só uns vinte, trinta segundos. Assim que o agente vai cuidar de outra coisa, ou só para para pensar um pouco mais, o grupo se recolhe e a aba vai dormir junto. Para uma pessoa, é só o navegador economizando um pouco de memória. Para um agente é bem pior, porque ele não faz ideia de que a página que acabou de deixar parou de funcionar.

4. O atendimento nunca recebeu o YES#

Uma contagem congelada só quer dizer que algo termina atrasado. Um chat de atendimento congelado quer dizer que a tarefa fracassa. Chats de atendimento ao vivo, internet banking, páginas de prova e filas de ingressos esperam que você continue presente, e a cada poucos segundos avisam o servidor, em silêncio, "ainda estou aqui". Ponha-se por um momento do lado do atendente. Se do outro lado ninguém dá sinal de vida há 45 segundos, o que você conclui? Que a pessoa foi embora, e você encerra a sessão. A minha reclamação para a Origin Energy em julho passou justamente por um chat desses.

Montei uma página de atendimento assim. Ela dá sinal de vida ao servidor a cada 10 segundos, e o servidor encerra o chat se não ouvir nada por 45 segundos. Um minuto depois de o chat começar, o atendimento manda: "Reply YES and I will refund it today." (Responda YES e eu faço o reembolso hoje.)

De novo pedi ao Claude que cuidasse de duas abas. Primeiro ele terminou outra tarefa na A, o que levou um minuto e meio. Depois, do jeito que faz quando vai rodar comandos no terminal, deixou o navegador de lado por um minuto e meio. Por fim, voltou à página de atendimento na B para responder YES. A janela ficou na tela o tempo todo, a minha aba estava na frente e o grupo de abas do Claude estava atrás dela. É assim que ele trabalha normalmente, nada de diferente.

Vinte segundos depois de o agente parar, o grupo de abas do Claude se recolheu, a página de atendimento na B foi congelada e os sinais de vida pararam. Quando o agente voltou à B, mais ou menos um minuto depois, encontrou isto:

Chat ended: no check-in from this page for 83 s. Please sign in again to start a new chat. (Chat encerrado: esta página não deu sinal de vida por 83 s. Entre de novo para começar um novo chat.)

Repare que o servidor se importa com quanto tempo a página ficou em silêncio, não com quanto tempo o chat está aberto. Enquanto a página continuar dando sinal de vida, ela pode ficar ali o quanto você quiser. A B caiu porque, depois de congelada, ficou 83 segundos sem dizer nada.

A caixa de texto e o botão de enviar já estavam acinzentados. O YES nunca mais poderia ser enviado, o atendimento tinha desligado e o reembolso não foi a lugar nenhum. O agente também não consegue entrar de novo no seu lugar, então isso fica esperando você voltar e entrar na fila do zero. Rodei a mesma tarefa no Embiody, com o agente afastado pelo mesmo minuto e meio. Lá a página de atendimento continuou dando sinal de vida a cada 10 segundos e mostrou Connected o tempo todo, o YES foi enviado, e o atendimento respondeu "Done, the refund is on its way." (Pronto, o reembolso está a caminho.) Aqui estão os dois lado a lado, Chrome à esquerda, Embiody à direita:

Você pode objetar que antes eu disse que esperar a resposta do servidor é imune à desaceleração, e o sinal de vida do atendimento funciona exatamente assim, então como é que caiu? Certo: só com a desaceleração, a página de atendimento continuaria dando sinal de vida a cada 10 segundos. O que quebrou foi o congelamento. A desaceleração só faz os despertadores que a página põe sozinha tocarem uma vez por minuto. O congelamento corta a energia da página inteira. Tudo nela para, despertadores próprios e esperas por retorno de ligação do mesmo jeito, então é claro que os sinais de vida param também.

Então por que não fazer a extensão simplesmente parar de recolher o grupo? Na verdade ela só recolhe numa situação: quando a aba que aparece na frente da janela é uma das suas. Tentei mover o grupo de abas do Claude para uma janela só dele, de modo que a aba da frente fosse uma do Claude. A extensão então não recolheu, a página de atendimento só foi desacelerada e ficou conectada por 11 minutos seguidos. Mas quem abre uma janela separada só para ele? O grupo de abas dele mora na janela que você está usando.

Olhe do lado do Claude in Chrome e ele está encurralado. Ele divide um navegador e uma janela com você. Se não recolher, as abas dele ficam espalhadas pela sua barra de abas e atrapalham você. Se recolher, o Chrome as congela pelas próprias regras. Recolher é uma decisão de produto da própria extensão e congelar é regra do Chrome, e a extensão só consegue mudar a primeira. Mesmo que nunca recolhesse, as abas dela continuariam atrás das suas, continuariam fora de vista e continuariam sendo desaceleradas.

Enquanto os agentes forem inquilinos de um navegador projetado para pessoas, não tem saída. E os agentes não podem abrir mão do navegador, porque a web foi feita para pessoas, e pessoas e agentes trabalhando lado a lado, no mesmo navegador e nos mesmos sites, é claramente para onde as coisas estão indo.

(12 de novembro de 2026, Chrome 157.0.8103.51, extensão 1.0.106, uma execução cada.)

5. A página acha que alguém está olhando, mas nada está sendo desenhado#

Se fosse só isso, já seria um problemão. Mas encontrei um mais sutil. Dessa vez a página não estava congelada, os timers estavam exatos e a página até se considerava visível, mas a imagem dela quase não se mexia.

Fiz uma página com duas barras de progresso. A verde anda com o tempo, um passo por segundo. A vermelha anda com os quadros que o navegador de fato desenha, um pouquinho a cada quadro. Pedi ao Claude que trabalhasse nessa página numa aba em segundo plano por dois minutos: clicar uma vez para tocar uma música e depois, a cada 10 segundos, rolar uma lista e ler a página. No fim, trouxe a aba para a frente.

No instante em que ela veio para a frente, a barra verde estava cheia e a vermelha mal tinha começado. O timer dizia que tinham se passado 184 segundos, mas só uns 620 quadros tinham sido desenhados, quando, nos 60 quadros por segundo normais, deveriam ser por volta de 11.000. Nos primeiros 100 segundos ela desenhou só 387 quadros, menos de 4 por segundo em média, o que para uma pessoa parece uma apresentação de slides. A página acreditava que estava sendo vista, mas o renderizador não estava de fato desenhando-a.

Então a imagem é desenhada devagar. Isso importa? Muitos sites gostam de mostrar números com animação. Pense no "98.765 empresas atendidas" da página inicial de uma empresa, que sobe a partir de 0 quando a página abre e para no número final dois ou três segundos depois. Se um agente abrir uma página dessas em segundo plano, onde nada está sendo desenhado, o número pode ficar parado no meio do caminho.

Montei uma página que conta de 0 a 98.765 em 3 segundos, pedi ao Claude que a abrisse numa nova aba em segundo plano, fizesse outra coisa e voltasse 10 segundos depois para ler o número. Os resultados:

Este clipe mostra o que as duas abas em segundo plano estavam fazendo enquanto o agente estava ocupado em outro lugar:

O Chrome deu três números diferentes em três execuções porque a página ficou escondida em segundo plano sem desenhar um único quadro, então o número ficou em 0. No momento em que o agente veio ler, a extensão tornou a página "visível", o número só então começou a subir, e o agente não esperou terminar, então leu até onde a contagem tinha chegado. É como fotografar alguém no meio de uma corrida: seja quando for que você aperte o botão, pega a pessoa no meio da pista.

O pior é que o agente não vai avisar que o número pode estar errado. Não aparece erro nenhum, e ele não tem como saber que viu uma animação que ainda não tinha terminado. Do ponto de vista dele, a página abriu, o número foi lido, tudo certo. Se ele ler uma vez só, entrega o número errado a você como fato. E isso é só a minha própria página de teste. Imagine um agente numa aba em segundo plano tentando garantir ingressos de show ou um item de promoção relâmpago para você.

(12 de novembro de 2026, Chrome 157.0.8103.51, extensão 1.0.106.)

6. A aba de Schrödinger#

Tudo isso me lembrou o gato de Schrödinger. Naquele famoso experimento mental, até a caixa ser aberta ninguém sabe dizer se o gato está vivo ou morto. A aba de um agente no Chrome é bem parecida. Enquanto você olha, ela funciona direito. Quando você não olha, ela pode estar andando uma vez por minuto, ou pode já estar congelada. Quando o agente mexe na aba, é como abrir a caixa para dar uma olhada, e a aba acorda por um tempo. Quando o agente se afasta, a caixa se fecha de novo, e dessa vez dá até para ver a caixa: é o grupo de abas que se recolhe sozinho.

Quando um agente toca várias tarefas ao mesmo tempo, ele só consegue mexer numa aba por vez, e as outras ficam trancadas em caixas. Algumas só estão lentas, outras já estão congeladas, e outras parecem normais mas nem estão sendo desenhadas, e o próprio agente não faz ideia de em que estado cada uma está. Então a questão vai além de as coisas ficarem um pouco mais rápidas ou mais lentas. Ela decide se você pode confiar no que o agente entrega a você.

Para entender o que estava por trás disso, li o código-fonte do Chromium 156 (ele se comporta igual ao 157 que testei) junto com o código da extensão Claude in Chrome 1.0.106, e encontrei sete regras empilhadas umas sobre as outras.

7. O que as sete regras dizem de fato#

Esta seção repassa, uma por uma e com o código-fonte do Chromium na mão, as sete regras da história acima. É para quem quer ir até o fundo ou conferir o código-fonte por conta própria. Se você só se importa com o que acontece, "abas em segundo plano são desaceleradas, congeladas e não são desenhadas" é tudo de que precisa, e pode pular direto para a seção 8, "Não dá para simplesmente desligar os limites do Chrome?", sem perder nada do que vem depois.

1. Timers encadeados numa página oculta, passado um período de tolerância, só podem acordar uma vez por minuto. O código-fonte do Chrome chama isso de intensive wake-up throttling (limitação intensiva de despertares). O que isso quer dizer? É o despertador que a página põe sozinha, de que falei antes: um timer dispara, e o callback dele programa o próximo timer. O Chrome conta a profundidade da corrente, e a partir do 7º nível, depois que a página fica oculta por um tempo, esses timers só podem disparar uma vez por minuto. A contagem regressiva é escrita exatamente assim, então cai na regra. Um timer programado depois da resposta do servidor volta a contar do nível 1, então a exportação e os sinais de vida do atendimento não são afetados. O período de tolerância depois que a página fica oculta costuma ser de 60 segundos, e uma aba que o agente abriu em segundo plano e nunca foi exibida também ganha 60 segundos. Trocar para outra aba, ter a janela totalmente coberta e minimizar a janela contam todos como oculta. Há ainda dois limites mais leves: nenhum timer acorda mais de uma vez por segundo, e depois de 10 segundos oculta, todos os callbacks de timer juntos só podem usar 1% da CPU, o que só pesa para páginas que fazem trabalho pesado nos callbacks. (third_party/blink/renderer/platform/scheduler/main_thread/page_scheduler_impl.cc; nível de aninhamento em third_party/blink/renderer/core/scheduler/dom_timer.cc)

2. Quando um grupo de abas se recolhe, as abas dele são congeladas. Assim que um grupo se recolhe, o Chrome dá um voto de "congelar" para cada aba dele. Abas exibidas nos últimos 5 minutos ficam protegidas, e abas nunca exibidas são congeladas na hora. Congelada quer dizer que todo o código da página para. Não fica mais lenta, não se mexe nada, como cortar a energia daquela gaveta. (chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc dá o voto; components/performance_manager/freezing/freezing_policy.cc decide)

3. Depois de uns 20 segundos parado, o Claude in Chrome recolhe o próprio grupo de abas. Isso só acontece quando a aba na frente da janela não é uma das dele, e na próxima vez que tiver trabalho a extensão primeiro expande o grupo. A regra 3 mais a regra 2 dá o "morta depois de 20 segundos" que vimos acima: a extensão recolhe o grupo, e o Chrome congela as abas dele.

4. A extensão faz a aba em que está trabalhando acreditar que "tem alguém olhando". Antes de cada ação, a extensão usa o protocolo de depuração para ligar uma chave chamada emulação de foco (Emulation.setFocusEmulationEnabled). O que isso faz? Diz ao Chrome "esta aba está sendo olhada", então o visibilityState da página vira visible e os timers dela deixam de ser desacelerados como os de páginas ocultas, mesmo que a janela inteira esteja minimizada. Uns 20 segundos depois da ação, a extensão desliga a chave de novo.

As regras 3 e 4 juntas também explicam uma coisa estranha: por que a aba em que o agente trabalhou por último às vezes não é congelada quando o grupo se recolhe. Achei que a extensão estivesse protegendo-a de propósito, mas o código mostrou que é pura coincidência. Quando o grupo se recolhe, o Chrome manda um comando de congelar para cada aba dele. A aba que o agente tocou por último ainda está com a emulação de foco ligada nesse momento, acredita que está sendo vista e recusa o comando. Mas o lado do Chrome não percebe a recusa, registra a aba como "congelada" mesmo assim e nunca mais manda o comando. Quando a emulação de foco é desligada e a aba fica fora de vista de verdade, ninguém nunca volta para congelá-la.

Dizendo de outro jeito: o inspetor do alojamento faz a ronda do apagar das luzes, você grita "ainda tem gente aqui", o inspetor anota "luzes apagadas" no caderno e segue em frente, para nunca mais voltar, e depois que você pega no sono a luz fica acesa a noite inteira. Essa aba só fica acordada porque "o grupo se recolhe" e "a emulação de foco é desligada" acontecem nessa ordem por acaso, e nem a extensão nem o Chrome planejaram isso. Antes, quando o agente passou da A para a B, a A pegou a ordem contrária: a emulação de foco dela foi desligada primeiro, então quando o grupo se recolheu a A já estava fora de vista, e o congelamento valeu assim que chegou.

5. Uma página que não é de fato desenhada na tela tem os quadros cortados para um por segundo. A emulação de foco consegue enganar a página e fazê-la achar que está sendo vista, mas não consegue enganar a parte que desenha a imagem. O Chrome tem um serviço de composição chamado viz que manda para cada aba um sinal de "comece a desenhar o próximo quadro" (BeginFrame) no ritmo da tela. Se 3 quadros seguidos de uma aba não foram de fato desenhados na tela por nenhuma janela, esse sinal cai para uma vez por segundo, e o comentário no código-fonte diz isso com todas as letras: "we throttle BeginFrames to 1 per second" (components/viz/service/frame_sinks/compositor_frame_sink_support.h, kUndrawnFrameLimit = 3). Então abas que ficam atrás de outras ou numa janela minimizada só conseguem rodar o requestAnimationFrame (a função que as páginas usam para desenhar animações) uma ou duas vezes por segundo, mesmo com os timers rodando normalmente. É como uma câmera apontada para um palco: os atores continuam atuando, mas a câmera percebe que ninguém está assistindo à transmissão e passa a tirar uma foto por segundo. Dos menos de 4 quadros por segundo que medi, os dois ou três a mais provavelmente são desenhados como efeito colateral das capturas de tela da extensão.

6. Uma janela coberta ou minimizada também conta como fora de vista. No Windows, o Chrome calcula sozinho se uma janela está totalmente coberta por outras janelas e, se estiver, trata as abas dela como ocultas (ui/aura/native_window_occlusion_tracker_win.cc, ativado por padrão). Quando uma janela é minimizada, toda a área de composição dela vira 0×0 (desktop_window_tree_host_win.cc).

7. Processos de renderização em segundo plano também são rebaixados. Se um processo de renderização não tem nenhuma aba visível, o Chrome o rebaixa para a prioridade mais baixa e pede ao Windows o EcoQoS, que quer dizer rodá-lo na frequência de CPU que mais economiza energia e colocar o trabalho dele nos núcleos de eficiência, ao custo de velocidade (base/process/process_win.cc, kUseEcoQoSForBackgroundProcess ativado por padrão). Essa regra olha se a janela está realmente visível, então a emulação de foco não consegue enganá-la.

Cada uma dessas sete regras é razoável sozinha, mas empilhadas elas deixam a aba de um agente numa situação esquisita. A página acha que está visível, mas os timers dela podem estar sendo limitados. O agente acabou de trabalhar nela, mas um pouco depois ela pode estar congelada. Ela não está congelada, mas a imagem dela quase não se mexe. Quais abas estão acordadas e quais estão dormindo é algo que nem quem escreveu a extensão talvez saiba dizer. No fim, volta tudo para a mesma coisa: as regras do navegador foram escritas para pessoas.

8. Não dá para simplesmente desligar os limites do Chrome?#

Você pode pensar que, já que a culpa é das regras do Chrome, daria para desligá-las com parâmetros de inicialização. Em parte, sim. --disable-background-timer-throttling, --intensive-wake-up-throttling-policy=0, --disable-renderer-backgrounding e --disable-backgrounding-occluded-windows desligam a desaceleração dos timers e o rebaixamento de processos. Mas a regra dos quadros não pode ser desligada. Uma aba que não é desenhada na tela não recebe os quadros normais de volta porque você desligou a desaceleração dos timers, então ler uma contagem pela metade continua acontecendo.

9. Os mesmos testes no Embiody#

Nós fazemos o Embiody, um navegador para Windows feito para agentes de IA. Os agentes trabalham nele por meio do BrowserDo, um servidor MCP feito para ele. O Claude Code e o Codex se conectam com um único comando, e o Cursor e o Claude Desktop com algumas linhas de configuração. O recurso de abas de IA começou naquela tarde de julho: eu queria que os agentes fizessem várias coisas ao mesmo tempo enquanto eu seguia com o meu próprio trabalho.

Então rodei todos os testes acima no Embiody nas mesmas condições, trocando só o navegador para o Embiody e a ferramenta para o BrowserDo. Os resultados:

No Embiody, a tarefa B termina no tempo certo mesmo atrás de outras abas, sem ninguém mexer, numa janela minimizada. A página em que o agente trabalha em segundo plano continua sendo desenhada, o número da página de estatísticas é lido certo na primeira vez e o chat de atendimento continua conectado. Mas isso só vale para as abas que o agente está usando. As abas que você mesmo abre continuam sendo desaceleradas em segundo plano pelas regras de economia de energia de sempre, então ter um agente no navegador não faz as suas próprias abas gastarem mais energia. O gato na caixa continua acordado. Para ser justo, foi uma máquina com Windows e 1 a 2 execuções por teste no Embiody, nada parecido com um teste em larga escala, mas pelo menos nesses cenários a diferença é clara.

Mais uma coisa para deixar claro: esses problemas não são exclusivos do Claude in Chrome. Seja qual for a extensão ou ferramenta de automação que você use, um agente trabalhando no Chrome tem que viver pelas regras do Chrome. No teste da contagem regressiva do começo, a aba que abri na mão ficou mais de 390 segundos atrasada em 8 minutos, igual à do Claude. Há também duas regras com que não esbarrei desta vez. Quando o computador está com pouca memória, o Chrome descarrega a aba em segundo plano que está há mais tempo sem ser olhada, e ela recarrega quando você volta. E quando um notebook está fora da tomada com a bateria abaixo de 20%, abas em segundo plano que usam bastante CPU são congeladas. Uma pessoa que sai um pouco e esbarra numa dessas só atualiza a página quando volta. Um agente que roda a tarde inteira cuidando de várias páginas ao mesmo tempo vai esbarrar nelas mais cedo ou mais tarde.

10. A IA precisa do próprio navegador#

Depois de alguns anos trabalhando com IA, tenho cada vez mais certeza de uma coisa: a IA precisa do próprio navegador, e se virar com o Chrome é um quebra-galho.

Não estou dizendo que o Chrome faz um trabalho ruim. Essas regras foram refinadas ao longo de muitos anos para que a pessoa sentada diante da tela tenha uma experiência melhor: abas que você não vê devem gastar menos, animações que ninguém vê não precisam ser desenhadas, e páginas largadas por muito tempo devem ser congeladas ou até descarregadas. Tudo o que uma extensão pode fazer é pôr mais uma camada por cima dessas regras, como usar a emulação de foco para a página achar que alguém está olhando, ou recolher o grupo de abas para as abas do agente não ficarem no seu caminho. Mas as regras são do Chrome, e a arquitetura do Chrome foi projetada para pessoas. Sem mudá-la na base, uma extensão só consegue remendar.

Aquela aba de antes, aquela em que o inspetor anotou "luzes apagadas", é o que o remendo entrega. Ela só fica acordada porque duas coisas aconteceram por acaso numa certa ordem. Qualquer nova versão do Chrome pode mudar essa ordem, e coincidências assim não dá para evitar nem prever, porque o Chrome nunca foi projetado para agentes.

Para parar de depender da sorte, as próprias regras do navegador têm que levar os agentes em conta. Para uma pessoa, se uma aba está visível decide se ela deve continuar usando recursos. Para um agente, uma aba que ninguém está olhando pode estar no meio de algo para você que não pode ser pausado, e ela deve continuar trabalhando tenha ou não alguém diante da tela. Isso só pode ser resolvido no próprio motor do navegador, e é o princípio sobre o qual as abas de IA do Embiody foram construídas.

(Embiody: 1 a 2 execuções por teste, 11 a 12 de novembro de 2026, mesma máquina.)

O que eu não testei#

• Uma máquina com Windows e uma versão do Chrome. Quando testei na mão em julho, minha lembrança é que a lentidão só ficou evidente depois de 5 minutos; desta vez (Chrome 157) foi cerca de 1 minuto. Não sei se o Chrome mudou ou se lembrei errado.
• Nada de Mac ou Linux, e nada com a "Economia de memória" (Memory Saver) ligada.
• Descarregar abas sob pressão de memória e congelar abas com bateria baixa vêm só da leitura do código-fonte, não foram medidos.

Teste você mesmo em dois minutos#

Abra https://embiody.com/lab/background-tab/. Ela começa uma contagem regressiva de 15 minutos. Troque para outra aba (cobrir ou minimizar a janela também serve), volte depois de dois minutos e olhe o "Behind by" (atrasado em): é quantos segundos a contagem perdeu enquanto você estava fora. 0 s quer dizer que a página continuou no horário. A página de teste está em inglês.

Por fim#

Não sei se o Chrome um dia vai mudar essas regras pensando nos agentes. Os motivos dele são bons: economizar energia, economizar memória e manter o primeiro plano fluido são exatamente o que um navegador deve fazer. Só que o navegador partiu do princípio de que havia uma pessoa diante da tela, olhando uma aba de cada vez, e agora pode não haver ninguém diante da tela, com um agente por trás das abas cuidando de várias páginas ao mesmo tempo.

Se você não olha, ela não trabalha. Mas o trabalho de um agente é justamente o que acontece enquanto você não está olhando.