La pestaña de Schrödinger de Claude in Chrome: solo trabaja mientras la miras

Por qué los agentes de IA que trabajan en pestañas en segundo plano de Chrome se ralentizan, se quedan dormidos e incluso pueden hacer que se corte un chat de atención al cliente.

Suelo hacer varias cosas a la vez. Una tarde de mediados de julio le encargué a Claude in Chrome tres trabajos al mismo tiempo. En la primera pestaña estaba comprobando la función de detección de ventanas emergentes de nuestro navegador, en la segunda buscaba música de fondo que le fuera bien a un video y en la tercera redactaba una reclamación para el servicio de atención al cliente de Origin Energy, porque me habían calculado mal una factura de la luz. Cuando los tres estuvieron en marcha, dejé el navegador en segundo plano y volví a la terminal, donde uso Claude Code para dirigir a mi equipo de desarrollo de IA. Para mí esa es justamente la gracia de los agentes: varios trabajan por su cuenta y yo no tengo que estar encima de cada uno.

Cuando volví al navegador un rato después, solo uno de los tres trabajos había avanzado. Los otros dos parecían haberse quedado dormidos, y siguieron así aunque esperé un poco más y pasé varias veces de una pestaña a otra.

Lo primero que pensaría casi cualquiera es que ese día iba lenta la red o iba lento el modelo. Pero si el problema fuera la red o el modelo, los tres trabajos se habrían ralentizado a la vez, y aquí solo uno se movía. Llevo muchos años trabajando en navegadores, y enseguida se me ocurrió otra explicación: Chrome estaba ralentizando las pestañas en segundo plano.

Eso no es realmente un defecto de Chrome. Un navegador tiene que hacerlo. Una página que no estás mirando no tiene por qué ir a toda velocidad, y la gente tiene decenas de pestañas abiertas, así que si todas funcionaran a tope estuvieran delante o no, la batería de un portátil se acabaría en media jornada. El problema es que las páginas de un navegador ya no están ahí solo para que las miren las personas. Los agentes de IA también trabajan en ellas. Para una persona, una pestaña en segundo plano es algo que ahora mismo no necesita. Para un agente, esa misma pestaña puede estar esperando una descarga, sacando adelante un reembolso o sosteniendo un chat de atención al cliente que no se puede cortar. Que nadie mire una pestaña no quiere decir que no tenga trabajo que hacer.

Las reglas del navegador se escribieron para personas, y a los agentes les quedan mal.

El 16 de julio lo probé a mano y confirmé que el problema era ese. Ese mismo día decidimos añadir una función llamada «pestañas de IA» a Embiody, el navegador que construimos para agentes de IA. Hace poco volví a hacer aquellas pruebas como es debido, para responder tres preguntas: cuánto ralentiza Chrome una pestaña en segundo plano; cuándo congela Chrome una página por completo; y la más fea, si un agente puede leer algo equivocado en una página que sigue abierta. Los resultados fueron peores de lo que esperaba.

1. Pasan ocho minutos y la página cree que ha pasado minuto y medio#

Empecé por la página de cuenta atrás más corriente, que avanza una vez por segundo y está escrita igual que las cuentas atrás de las páginas de compra y de pago. En cada paso, la página informa de su progreso a un pequeño servidor en la misma máquina, así que aunque el navegador congele la página, el servidor sigue teniendo constancia de lo que pasó de verdad.

Abrí dos copias de esta página, una abierta por Claude in Chrome y otra que abrí yo para comparar, y luego las mantuve fuera de la vista durante 8 minutos. Probé tres maneras de ocultarlas: cambiar a otra pestaña, tapar la ventana por completo con otra ventana y minimizar la ventana. Las tres dieron casi exactamente el mismo resultado.

Durante el primer minuto después de que la página dejara de verse no cambió nada, y la cuenta atrás seguía avanzando una vez por segundo. Pasado más o menos un minuto, bajó a un paso por minuto. A los 8 minutos, en el mundo real habían pasado 480 segundos, pero la página creía que solo habían pasado unos 90, así que iba 390 segundos por detrás. Es como salir 8 minutos a desayunar y volver a casa para encontrarte un reloj que solo ha avanzado minuto y medio. Y cuando volví a traer la ventana al frente, la cuenta atrás recuperó el ritmo de un paso por segundo, pero los minutos perdidos no se recuperaron nunca.

Más importante todavía: la página que abrió Claude in Chrome se comportó exactamente igual que la que abrí yo a mano (entre 387 y 391 segundos de retraso la de Claude, 392 la mía). Así que esto no tiene nada que ver con Claude. Cualquier página abierta en Chrome que nadie esté mirando acaba así, lo que significa que cualquiera que ejecute un agente en Chrome se lo va a encontrar.

(Windows 11, Chrome 157.0.8103.39, extensión de Claude 1.0.106, 11 de noviembre de 2026, una sola máquina, entre 1 y 2 ejecuciones por caso.)

Y eso plantea una pregunta evidente. Las pestañas de Claude in Chrome están en segundo plano casi todo el tiempo. Si una pestaña en segundo plano solo avanza una vez por minuto, ¿cómo consigue terminar algo? Y sin embargo está claro que termina su trabajo.

2. Solo sigue despierta la pestaña que el agente está tocando#

Para averiguarlo, preparé una página de prueba más parecida a una tarea real, con los dos tipos de espera que más se ven en las webs. La primera es una descarga: la página dice «Tu descarga empezará en 90 segundos», y el botón de descarga solo se puede pulsar cuando la cuenta atrás llega a 0. La segunda es una exportación: la página dice «Exportación en curso», pregunta al servidor cada 2 segundos si ya está, y el servidor responde que sí a los 90 segundos.

Luego le pedí a Claude in Chrome que hiciera dos de estas tareas a la vez, una en la pestaña A y otra en la pestaña B. Se puso primero con A, y B se quedó en segundo plano sin que nadie la tocara. Esto es lo que pasó:

Esta es B en la segunda ejecución, en el momento en que traje la ventana al frente. Fíjate en cuánto tiempo dice la página que lleva esperando:

La página había esperado 378 segundos de tiempo real y todavía le faltaban 6. Una espera de 90 segundos se convirtió en seis o siete minutos, y eso es exactamente lo que me pasó aquella tarde de julio. El agente estuvo trabajando todo el rato, pero siempre en A, mientras B se arrastraba en segundo plano a un paso por minuto. Cuando por fin miró B, una cuenta atrás que tendría que haber terminado hacía tiempo seguía corriendo. Y ese era el caso con suerte. Si el agente no hubiera vuelto nunca a B, a un paso por minuto esa cuenta atrás de 90 segundos habría tardado una media hora.

Lo curioso es que la exportación apenas se vio afectada. El servidor dijo que estaba lista a los 90 segundos y el agente se dio cuenta solo 3 segundos después.

Las dos eran esperas en una pestaña en segundo plano, así que ¿por qué Chrome ralentizó la cuenta atrás de la descarga y dejó en paz la exportación?

La diferencia está en cómo están escritas las dos esperas. La cuenta atrás se pone su propia alarma: cuando suena la alarma de este segundo pone la siguiente, y cuando suena esa pone la de después, cada alarma encadenada a la anterior. La exportación espera a que le devuelvan la llamada: pregunta al servidor, y solo cuando el servidor contesta programa la siguiente pregunta, así que cada ronda empieza de cero a partir de la respuesta de otro. Chrome tiene una regla pensada precisamente para las alarmas encadenadas. Cuando una página lleva un rato fuera de la vista, esas alarmas solo pueden sonar una vez por minuto. Por eso la cuenta atrás se ralentizó, mientras que la exportación, que espera a que le devuelvan la llamada, no entra en esa regla.

Así que la ralentización en segundo plano no frena la página entera por igual. Es la forma en que está escrita la página la que decide si se ralentiza. Pero eso no es lo peor.

3. A los 20 segundos, la página se detiene por completo#

La ralentización de antes, por lo menos, acaba llegando. La siguiente me asustó de verdad. Claude in Chrome abre las pestañas nuevas en segundo plano por defecto, detrás de la pestaña que estás mirando. Le pedí que abriera una pestaña de prueba y luego la dejé en paz, y a los 20 segundos la página se paró del todo. La cuenta atrás no avanzaba una vez por minuto, no avanzaba en absoluto, hasta que el agente volvía y hacía algo en ella. Lo vi cuatro veces, siempre hacia los 20 segundos, y la ventana del navegador estuvo todo el rato a la vista en la pantalla, ni tapada ni minimizada.

La ventana está a la vista, así que ¿por qué una página dentro de ella se iba a quedar parada de golpe?

Para comparar, abrí la misma página en una pestaña en segundo plano de la forma normal. A los 3 minutos seguía funcionando, solo que a un paso por minuto, así que los 20 segundos tenían que tener algo que ver con Claude in Chrome. Estuve un rato mirando la barra de pestañas y por fin lo vi: unos 20 segundos después del último comando del agente, el grupo de pestañas de Claude se contraía solo, y en cuanto un grupo de pestañas se contrae, Chrome congela las pestañas de dentro que nunca se han mostrado. No pierdas de vista la barra de pestañas en este clip:

Cada una de estas cosas tiene sentido por separado. Claude in Chrome no quiere que su montón de pestañas se adueñe de tu barra de pestañas, así que recoge el grupo cuando se queda inactivo. Chrome trata un grupo contraído como las cosas que guardas en un cajón porque no las vas a necesitar en un tiempo, así que le corta la corriente para ahorrar memoria. Pero junta esas dos reglas sensatas y resulta que todas las pestañas que el agente abrió en segundo plano se duermen en cuanto el agente hace una pausa.

¿Seguro que la pestaña en la que el agente está trabajando sí está bien? Le pedí al agente que se ocupara de dos pestañas, A y B, leyendo A cada 30 segundos durante los 3 primeros minutos. A funcionó con normalidad todo el tiempo, mientras que B, que nadie tocaba, estaba prácticamente parada a partir del segundo minuto. Luego le pedí que pasara a leer B. B se despertó enseguida, pero unos 30 segundos después A, a la que acababa de dejar sola, también estaba congelada.

O sea, cuando un agente toca una pestaña, esa pestaña solo se mantiene despierta veinte o treinta segundos. En cuanto el agente se pone con otra cosa, o simplemente se para a pensar un poco más, el grupo se contrae y la pestaña se duerme con él. Para una persona, eso no es más que el navegador ahorrando un poco de memoria. Para un agente es mucho peor, porque no tiene ni idea de que la página que acaba de dejar ha dejado de funcionar.

4. Atención al cliente nunca recibió el YES#

Una cuenta atrás congelada solo significa que algo termina tarde. Un chat de atención al cliente congelado significa que el trámite fracasa. Los chats de atención al cliente en directo, la banca en línea, las páginas de exámenes y las colas para comprar entradas esperan que sigas presente, y cada pocos segundos le dicen discretamente al servidor «sigo aquí». Ponte un momento en el lugar de quien atiende el chat. Si al otro lado no hay ninguna señal de vida durante 45 segundos, ¿qué piensas? Que se ha ido, y cierras la sesión. Mi reclamación a Origin Energy en julio pasó justamente por un chat de este tipo.

Monté una página de atención al cliente así. Se reporta al servidor cada 10 segundos, y el servidor cierra el chat si no oye nada en 45 segundos. Al minuto de empezar el chat, atención al cliente envía: «Reply YES and I will refund it today.» (Responde YES y te lo reembolso hoy.)

De nuevo le pedí a Claude que se ocupara de dos pestañas. Primero terminó otro trabajo en A, que le llevó minuto y medio. Luego, como hace cuando se va a ejecutar comandos en la terminal, dejó el navegador en paz durante minuto y medio. Por último volvió a la página de atención al cliente en B para responder YES. La ventana estuvo a la vista todo el tiempo, mi propia pestaña estaba delante y el grupo de pestañas de Claude detrás. Así es como funciona normalmente, nada fuera de lo común.

Veinte segundos después de que el agente se detuviera, el grupo de pestañas de Claude se contrajo, la página de atención al cliente en B quedó congelada y los avisos al servidor se interrumpieron. Cuando el agente volvió a B un minuto y pico después, se encontró esto:

Chat ended: no check-in from this page for 83 s. Please sign in again to start a new chat. (Chat finalizado: esta página no ha dado señales en 83 s. Vuelve a iniciar sesión para empezar un chat nuevo.)

Fíjate en que al servidor le importa cuánto tiempo lleva callada la página, no cuánto tiempo lleva abierto el chat. Mientras la página siga dando señales, puede estar ahí todo el tiempo que quieras. B se cortó porque, una vez congelada, estuvo 83 segundos sin decir nada.

El cuadro de texto y el botón de enviar ya estaban en gris. El YES ya no se podía enviar, atención al cliente había colgado y el reembolso se quedó en nada. El agente tampoco puede volver a iniciar sesión por ti, así que esto queda pendiente hasta que vuelvas y te pongas otra vez a la cola desde el principio. Ejecuté la misma tarea en Embiody, con el agente ausente el mismo minuto y medio. Allí la página de atención al cliente siguió dando señales cada 10 segundos y mostró Connected (conectado) todo el tiempo, el YES se envió y atención al cliente respondió «Done, the refund is on its way.» (Hecho, el reembolso está en camino.) Aquí están los dos lado a lado, a la izquierda Chrome y a la derecha Embiody:

Podrías objetar que antes dije que esperar la respuesta del servidor es inmune a la ralentización, y que los avisos de atención al cliente funcionan exactamente así, así que ¿cómo se cortó? Tienes razón: solo con la ralentización, la página de atención al cliente seguiría dando señales cada 10 segundos. Lo que la rompió fue la congelación. La ralentización solo hace que las alarmas que se pone la propia página suenen una vez por minuto. La congelación le corta la corriente a toda la página. Todo lo que hay dentro se para, tanto las alarmas propias como las esperas a que te devuelvan la llamada, así que, claro, los avisos también se paran.

Entonces, ¿por qué no hacer simplemente que la extensión deje de contraer el grupo? En realidad solo lo contrae en una situación: cuando la pestaña que se muestra delante en la ventana es una de las tuyas. Probé a mover el grupo de pestañas de Claude a una ventana propia, de modo que la pestaña de delante fuera una de Claude. Entonces la extensión no lo contrajo, la página de atención al cliente solo se ralentizó y siguió conectada 11 minutos seguidos. Pero ¿quién abre una ventana aparte solo para eso? Su grupo de pestañas vive en la ventana que estás usando.

Míralo desde el lado de Claude in Chrome y verás que está atrapado. Comparte contigo un navegador y una ventana. Si no contrae el grupo, sus pestañas se quedan desparramadas por tu barra de pestañas y te estorban. Si lo contrae, Chrome las congela según sus propias reglas. Contraer es una decisión de producto de la propia extensión y congelar es una regla de Chrome, y la extensión solo puede cambiar lo primero. Aunque nunca contrajera el grupo, sus pestañas seguirían detrás de las tuyas, seguirían fuera de la vista y seguirían ralentizadas.

Mientras los agentes vivan de prestado en un navegador diseñado para personas, esto no tiene salida. Y los agentes no pueden prescindir del navegador, porque la web se hizo para las personas, y está claro que hacia donde vamos es a personas y agentes trabajando codo con codo, en el mismo navegador y en los mismos sitios.

(12 de noviembre de 2026, Chrome 157.0.8103.51, extensión 1.0.106, una ejecución por caso.)

5. La página cree que alguien la está mirando, pero no se está dibujando nada#

Si eso fuera todo, ya sería un problema serio. Pero encontré otro más sutil. Esta vez la página no estaba congelada, los temporizadores iban exactos y la página incluso se consideraba visible, y aun así su imagen apenas se movía.

Hice una página con dos barras de progreso. La verde avanza con el tiempo, un paso por segundo. La roja avanza con los fotogramas que el navegador dibuja de verdad, un poco por cada fotograma. Le pedí a Claude que trabajara en esta página en una pestaña en segundo plano durante dos minutos: un clic para poner música y luego desplazar una lista y leer la página cada 10 segundos. Al final traje la pestaña al frente.

En el momento en que pasó al frente, la barra verde estaba llena y la roja apenas había empezado. El temporizador decía que habían pasado 184 segundos, pero solo se habían dibujado unos 620 fotogramas, cuando a unos 60 fotogramas por segundo normales deberían haber sido alrededor de 11.000. En los primeros 100 segundos solo dibujó 387 fotogramas, menos de 4 por segundo de media, lo que a una persona le parecería una presentación de diapositivas. La página creía que la estaban mirando, pero el renderizador en realidad no la estaba dibujando.

Así que la imagen se dibuja despacio. ¿Importa? Muchos sitios web muestran cifras con animación. Piensa en las «98.765 empresas atendidas» de la página de inicio de una empresa, que cuentan desde 0 al abrir la página y se quedan en la cifra final dos o tres segundos después. Si un agente abre una página así en segundo plano, donde no se dibuja nada, la cifra se puede quedar a medio camino.

Hice una página que cuenta de 0 a 98.765 en 3 segundos, le pedí a Claude que la abriera en una pestaña nueva en segundo plano, hiciera otra cosa y volviera 10 segundos después a leer la cifra. Los resultados:

Este clip muestra lo que hacían las dos pestañas en segundo plano mientras el agente estaba ocupado en otra parte:

Chrome dio tres cifras distintas en tres ejecuciones porque la página estuvo oculta en segundo plano sin dibujar un solo fotograma, así que la cifra se quedó en 0. En el momento en que el agente vino a leerla, la extensión hizo la página «visible», la cifra empezó a subir solo entonces, y el agente no esperó a que terminara, así que leyó lo que hubiera alcanzado la cuenta. Es como hacerle una foto a alguien en plena carrera: aprietes el disparador cuando lo aprietes, lo pillas a mitad de pista.

Lo peor es que el agente no te va a decir que la cifra puede estar mal. No hay ningún error, y no tiene forma de saber que ha visto una animación sin terminar. Desde donde está él, la página se abrió, la cifra se leyó, todo bien. Si la lee una sola vez, te entrega la cifra equivocada como un hecho. Y esto es solo mi propia página de prueba. Imagina a un agente en una pestaña en segundo plano intentando conseguirte entradas para un concierto o un artículo de una oferta relámpago.

(12 de noviembre de 2026, Chrome 157.0.8103.51, extensión 1.0.106.)

6. La pestaña de Schrödinger#

Todo esto me recordó al gato de Schrödinger. En aquel famoso experimento mental, hasta que se abre la caja nadie puede decir si el gato está vivo o muerto. La pestaña de un agente en Chrome es bastante parecida. Mientras la miras, funciona bien. Cuando no la miras, puede que avance una vez por minuto, o puede que ya esté congelada. Cuando el agente opera en la pestaña, es como abrir la caja para echar un vistazo, y la pestaña se despierta un rato. Cuando el agente se aleja, la caja se vuelve a cerrar, y esta vez hasta puedes ver la caja: es el grupo de pestañas que se contrae solo.

Cuando un agente lleva varios trabajos a la vez, solo puede operar una pestaña cada vez, y las demás quedan encerradas en sus cajas. Algunas solo van más lentas, otras ya están congeladas y otras parecen normales pero ni siquiera se están dibujando, y el propio agente no tiene ni idea de en qué estado está cada una. Así que esto va de algo más que de que las cosas vayan un poco más rápido o más despacio. Decide si te puedes fiar de lo que el agente te entrega.

Para entender qué había detrás, repasé el código fuente de Chromium 156 (se comporta igual que el 157 que probé) junto con el código de la extensión Claude in Chrome 1.0.106, y encontré siete reglas apiladas unas sobre otras.

7. Qué dicen exactamente las siete reglas#

Esta sección repasa una a una, contra el código fuente de Chromium, las siete reglas de la historia anterior. Es para quien quiera llegar al fondo del asunto o comprobar el código por su cuenta. Si solo te interesa lo que pasa, con «las pestañas en segundo plano se ralentizan, se congelan y no se dibujan» tienes suficiente, y puedes saltar directamente a la sección 8, «¿No se pueden desactivar sin más los límites de Chrome?», sin perderte nada de lo que viene después.

1. Los temporizadores encadenados de una página oculta, pasado un periodo de gracia, solo pueden despertarse una vez por minuto. El código fuente de Chrome llama a esto intensive wake-up throttling (limitación intensiva de despertares). ¿Qué quiere decir? Es la alarma que se pone la propia página, la de antes: un temporizador salta, y su función de retorno programa el siguiente temporizador. Chrome cuenta lo profunda que es la cadena, y a partir del 7.º nivel, una vez que la página lleva un rato oculta, esos temporizadores solo pueden saltar una vez por minuto. La cuenta atrás está escrita exactamente así, así que cae en la regla. Un temporizador programado tras la respuesta del servidor vuelve a contar desde el nivel 1, así que la exportación y los avisos de atención al cliente no se ven afectados. El periodo de gracia después de que una página se oculte suele ser de 60 segundos, y una pestaña que el agente abrió en segundo plano y que nunca se ha mostrado también tiene 60 segundos. Cambiar a otra pestaña, tener la ventana completamente tapada y minimizar la ventana cuentan todos como oculta. Hay además dos límites más suaves: ningún temporizador se despierta más de una vez por segundo, y tras 10 segundos oculta, todas las funciones de retorno de los temporizadores juntas solo pueden usar el 1 % de la CPU, lo que solo importa a las páginas que hacen trabajo pesado en esas funciones. (third_party/blink/renderer/platform/scheduler/main_thread/page_scheduler_impl.cc; nivel de anidamiento en third_party/blink/renderer/core/scheduler/dom_timer.cc)

2. Cuando un grupo de pestañas se contrae, las pestañas que contiene se congelan. En cuanto un grupo se contrae, Chrome emite un voto de «congelar» por cada pestaña que hay en él. Las pestañas mostradas en los últimos 5 minutos están protegidas, y las que nunca se han mostrado se congelan en el acto. Congelada significa que se para hasta el último trozo de código de la página. No va más lenta, no se mueve en absoluto, como cortarle la corriente a ese cajón. (chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc emite el voto; components/performance_manager/freezing/freezing_policy.cc decide)

3. Tras unos 20 segundos de inactividad, Claude in Chrome contrae su propio grupo de pestañas. Esto solo ocurre cuando la pestaña de delante en la ventana no es una de las suyas, y la próxima vez que tiene trabajo, la extensión expande primero el grupo. La regla 3 más la regla 2 es el «muerta a los 20 segundos» que vimos antes: la extensión contrae el grupo y Chrome congela las pestañas que hay dentro.

4. La extensión hace creer a la pestaña en la que trabaja que «alguien la está mirando». Antes de cada acción, la extensión usa el protocolo de depuración para activar un interruptor llamado emulación de foco (Emulation.setFocusEmulationEnabled). ¿Qué hace eso? Le dice a Chrome «esta pestaña la están mirando», así que el visibilityState de la página pasa a visible y sus temporizadores ya no se limitan como los de las páginas ocultas, aunque toda la ventana esté minimizada. Unos 20 segundos después de la acción, la extensión vuelve a apagar el interruptor.

Las reglas 3 y 4 juntas explican además algo raro: por qué la última pestaña en la que trabajó el agente a veces no se congela cuando el grupo se contrae. Supuse que la extensión la protegía a propósito, pero el código mostró que es pura casualidad. Cuando el grupo se contrae, Chrome envía una orden de congelación a cada pestaña que contiene. La pestaña que el agente tocó por última vez todavía tiene la emulación de foco activada en ese momento, cree que la están mirando y rechaza la orden. Pero el lado de Chrome no se da cuenta del rechazo, anota la pestaña como «congelada» de todos modos y no vuelve a enviar la orden nunca más. Cuando la emulación de foco se apaga y la pestaña de verdad queda fuera de la vista, nadie vuelve nunca a congelarla.

Dicho de otra manera: el celador de la residencia pasa por la noche a apagar las luces, tú gritas «¡todavía hay alguien aquí!», el celador apunta «luces apagadas» en su cuaderno y sigue su ronda, para no volver nunca, y cuando te quedas dormido la luz se queda encendida toda la noche. Esta pestaña sigue despierta solo porque «el grupo se contrae» y «la emulación de foco se apaga» ocurren justo en ese orden, y ni la extensión ni Chrome lo diseñaron así. Antes, cuando el agente pasó de A a B, a A le tocó el orden contrario: su emulación de foco se apagó primero, así que cuando el grupo se contrajo A ya estaba fuera de la vista, y la congelación hizo efecto en cuanto llegó.

5. A una página que no se dibuja de verdad en la pantalla le recortan los fotogramas a uno por segundo. La emulación de foco puede engañar a la página para que crea que la están mirando, pero no puede engañar a la parte que dibuja la imagen. Chrome tiene un servicio de composición llamado viz que envía a cada pestaña una señal de «empieza a dibujar el siguiente fotograma» (BeginFrame) al ritmo de la pantalla. Si 3 fotogramas seguidos de una pestaña no han llegado a dibujarse en la pantalla en ninguna ventana, esa señal baja a una vez por segundo, y el comentario del código fuente lo dice sin rodeos: «we throttle BeginFrames to 1 per second» (limitamos los BeginFrames a 1 por segundo) (components/viz/service/frame_sinks/compositor_frame_sink_support.h, kUndrawnFrameLimit = 3). Así que las pestañas que están detrás de otras o en una ventana minimizada solo pueden ejecutar requestAnimationFrame (la función que usan las páginas web para dibujar animaciones) una o dos veces por segundo, aunque sus temporizadores funcionen con normalidad. Es como una cámara que apunta a un escenario: los actores siguen actuando, pero la cámara nota que nadie está viendo la emisión y pasa a sacar una imagen por segundo. De los menos de 4 fotogramas por segundo que medí, los dos o tres de más probablemente se dibujan como efecto secundario de las capturas de pantalla de la extensión.

6. Una ventana tapada o minimizada también cuenta como fuera de la vista. En Windows, Chrome calcula por su cuenta si una ventana está completamente tapada por otras ventanas y, si lo está, trata sus pestañas como ocultas (ui/aura/native_window_occlusion_tracker_win.cc, activado por defecto). Cuando una ventana se minimiza, toda su área de composición pasa a ser de 0×0 (desktop_window_tree_host_win.cc).

7. Los procesos de renderizado en segundo plano también se degradan. Si un proceso de renderizado no tiene ninguna pestaña visible, Chrome lo baja a la prioridad más baja y le pide a Windows EcoQoS, lo que significa ejecutarlo a la frecuencia de CPU de mayor eficiencia energética y poner su trabajo en los núcleos de eficiencia, a costa de la velocidad (base/process/process_win.cc, kUseEcoQoSForBackgroundProcess activado por defecto). Esta regla mira si la ventana es visible de verdad, así que la emulación de foco no puede engañarla.

Cada una de estas siete reglas es razonable por sí sola, pero apiladas dejan la pestaña de un agente en una situación incómoda. La página cree que es visible, y sin embargo sus temporizadores pueden estar limitados. El agente acaba de trabajar en ella, y sin embargo un poco después puede estar congelada. No está congelada, y sin embargo su imagen apenas se mueve. Qué pestañas están despiertas y cuáles dormidas es algo que quizá ni siquiera sabrían decir quienes escribieron la extensión. Al final todo vuelve a lo mismo: las reglas del navegador se escribieron para personas.

8. ¿No se pueden desactivar sin más los límites de Chrome?#

Podrías pensar que, como la culpa es de las reglas de Chrome, podrías desactivarlas con parámetros de arranque. En parte, sí. --disable-background-timer-throttling, --intensive-wake-up-throttling-policy=0, --disable-renderer-backgrounding y --disable-backgrounding-occluded-windows desactivan la limitación de temporizadores y la degradación de procesos. Pero la regla de los fotogramas no se puede desactivar. Una pestaña que no se dibuja en la pantalla no recupera sus fotogramas normales porque hayas desactivado la limitación de temporizadores, así que leer una cuenta a medio terminar sigue pasando.

9. Las mismas pruebas en Embiody#

Nosotros hacemos Embiody, un navegador para Windows hecho para agentes de IA. Los agentes trabajan en él a través de BrowserDo, un servidor MCP creado para él. Claude Code y Codex se conectan con un solo comando, y Cursor y Claude Desktop con unas pocas líneas de configuración. La función de pestañas de IA nació de aquella tarde de julio: quería que los agentes hicieran varias cosas a la vez mientras yo seguía con mi propio trabajo.

Así que ejecuté todas las pruebas anteriores en Embiody en las mismas condiciones, cambiando solo el navegador por Embiody y la herramienta por BrowserDo. Los resultados:

En Embiody, la tarea B termina a tiempo aunque esté detrás de otras pestañas, sin que nadie la toque, en una ventana minimizada. La página en la que el agente trabaja en segundo plano se sigue dibujando, la cifra de estadísticas se lee bien a la primera y el chat de atención al cliente sigue conectado. Eso sí, esto solo se aplica a las pestañas que usa el agente. Las pestañas que abres tú se siguen ralentizando en segundo plano con las reglas de ahorro de energía de siempre, así que tener un agente en el navegador no hace que tus propias pestañas gasten más energía. El gato de la caja sigue despierto. Para ser justos, fue una sola máquina con Windows y entre 1 y 2 ejecuciones por prueba en Embiody, nada parecido a una prueba a gran escala, pero en estos escenarios, al menos, la diferencia está clara.

Una cosa más que conviene dejar clara: estos problemas no son exclusivos de Claude in Chrome. Uses la extensión o la herramienta de automatización que uses, un agente que trabaja en Chrome tiene que vivir con las reglas de Chrome. En la prueba de la cuenta atrás del principio, la pestaña que abrí a mano se quedó más de 390 segundos atrás en 8 minutos, igual que la de Claude. Hay además dos reglas con las que esta vez no me topé. Cuando la computadora anda corta de memoria, Chrome descarga la pestaña en segundo plano que lleva más tiempo sin que nadie la mire, y se vuelve a cargar cuando regresas. Y cuando un portátil está desenchufado con la batería por debajo del 20 %, las pestañas en segundo plano que usan bastante CPU se congelan. Una persona que se aparta un rato y se topa con una de estas recarga la página al volver y listo. Un agente que se pasa toda la tarde ocupándose de varias páginas a la vez se las va a encontrar tarde o temprano.

10. La IA necesita su propio navegador#

Después de unos años sacando trabajo adelante con IA, cada vez estoy más seguro de una cosa: la IA necesita su propio navegador, y apañarse con Chrome es un parche provisional.

No digo que Chrome lo haga mal. Estas reglas se fueron puliendo durante muchos años para que la persona sentada delante de la pantalla esté más a gusto: las pestañas que no ves deberían gastar menos, las animaciones que nadie ve no hace falta dibujarlas, y las páginas que llevan mucho tiempo sin usarse deberían congelarse o incluso descargarse. Lo único que puede hacer una extensión es añadir otra capa encima de esas reglas, como usar la emulación de foco para que una página crea que alguien la está mirando, o contraer su grupo de pestañas para que las pestañas del agente no te estorben. Pero las reglas son de Chrome, y la arquitectura de Chrome se diseñó para personas. Sin cambiarla desde la base, una extensión solo puede ir poniendo parches.

La pestaña de antes, aquella en la que el celador apuntó «luces apagadas», es lo que se consigue a base de parches. Sigue despierta solo porque dos cosas ocurrieron en un orden concreto. Cualquier versión nueva de Chrome podría cambiar ese orden, y casualidades así no se pueden evitar ni prever, porque Chrome nunca se diseñó para agentes.

Para dejar de depender de la casualidad, las propias reglas del navegador tienen que tener en cuenta a los agentes. Para una persona, que una pestaña se vea o no decide si debe seguir gastando recursos. Para un agente, una pestaña que nadie mira puede estar a mitad de algo que está haciendo por ti y que no se puede poner en pausa, y debería seguir trabajando haya o no alguien delante de la pantalla. Eso solo se puede resolver en el propio motor del navegador, y es el principio sobre el que están construidas las pestañas de IA de Embiody.

(Embiody: entre 1 y 2 ejecuciones por prueba, del 11 al 12 de noviembre de 2026, misma máquina.)

Lo que no probé#

• Una sola máquina con Windows y una sola versión de Chrome. Cuando lo probé a mano en julio, recuerdo que la ralentización solo se notaba claramente a partir de los 5 minutos; esta vez (Chrome 157) fue hacia el minuto. No sé si cambió Chrome o si lo recuerdo mal.
• Nada en Mac ni en Linux, y nada con el Ahorro de memoria activado.
• La descarga de pestañas con poca memoria y la congelación de pestañas con poca batería salen solo de leer el código fuente, no las he medido.

Pruébalo tú mismo en dos minutos#

Abre https://embiody.com/lab/background-tab/. Empieza una cuenta atrás de 15 minutos. Cambia a otra pestaña (tapar o minimizar la ventana también sirve), vuelve al cabo de dos minutos y mira «Behind by» (retraso): son los segundos que perdió la cuenta atrás mientras no estabas. Si marca 0 s, la página siguió funcionando a tiempo. La página de prueba está en inglés.

Para terminar#

No sé si Chrome cambiará algún día estas reglas pensando en los agentes. Sus motivos son buenos: ahorrar energía, ahorrar memoria y mantener fluido lo que tienes delante es exactamente lo que debe hacer un navegador. Lo que pasa es que el navegador daba por hecho que había una persona delante de la pantalla, mirando una pestaña cada vez, y ahora puede que no haya nadie delante de la pantalla, sino un agente detrás de las pestañas ocupándose de varias páginas a la vez.

Si no lo miras, no trabaja. Pero el trabajo de un agente es justamente el que se hace mientras no estás mirando.