Stagehand v4: qué pasa de verdad cuando lo corrés Instalamos Stagehand 4.0.0, lo corrimos contra una página real, medimos cada token que gastó, y lo rompimos a propósito. Esta nota arranca exactamente donde termina nuestro : ya no "qué es", sino "qué pasa cuando escribís y empezás a llamarlo". Cada número de acá abajo sale de un script que podés encontrar y volver a correr, no de la documentación. Para más análisis como este, visitá nuestro . Cómo lo verificamos. Stagehand 4.0.0, Ubuntu 24.04, Node 22, Chrome 151, probado en local y en Browserbase, contra 4geeks.com y otras páginas reales, en agosto de 2026. Donde un hallazgo contradice notas anteriores de esta misma investigación, lo aclaramos. Instalación: más rápida de lo esperado, con un borde filoso baja 51 paquetes en unos 4.5 segundos y no descarga ningún navegador . Si venís de Playwright, esa es la primera sorpresa: v4 maneja el Chrome que ya tenés instalado, vía , no un navegador que administra por vos. Lo único que te va a frenar en seco: escribe en el . corepack rechaza ese rango directamente: corepack quiere una versión exacta, y no la da. evita todo el problema. Dos trampas más de configuración, antes de tocar código: Stagehand no lee tus variables de entorno , a pesar de que la documentación tiene una tabla de proveedores con una columna "Environment Variable" que parece indicar detección automática. Configurás y listo, pensás, pero te encontrás con , un error que apunta a autenticación cuando el problema real es que nunca leyó la variable. El registro en Browserbase pide verificación de número de teléfono . No una tarjeta, pero sí una barrera real que conviene mencionar antes de que alguien llegue ahí a mitad de un tutorial. La documentación te manda a la página equivocada primero Buscá la configuración de modelos de Stagehand y el primer resultado es , que sirve la página de v3 : 13 proveedores listados. La página actual, en , lista 5. Quien sigue el link obvio termina con una lista de proveedores que ya no existe. Esa misma superficie desactualizada es de donde sale el error más común. El propio ejemplo de Model Gateway en la documentación dice: En v4, un string a secas para tira un : . La forma real es: Ese snippet no está mal, en rigor. Es Python válido (el SDK de Python sí acepta un string, con la clave como argumento aparte), pegado en una página de documentación de TypeScript. tiene el mismo problema, y es peor por cómo se lee el error. Todos los ejemplos en circulación, incluyendo la documentación oficial, escriben: El error que tira nombra : . Se lee como si tu instrucción estuviera mal escrita. No es así. La firma real es posicional: Sin schema, devuelve , un string plano sin estructura. Vale la pena saberlo antes de asumir que falló en silencio. Algunas costumbres de Playwright más chicas que también se rompen: ahora es async (código portado de Playwright imprime en vez de una URL), solo acepta , y no es una opción real; es . Lo que realmente cuesta, por llamada Cada llamada de inferencia envía el árbol de accesibilidad completo de la página al modelo. En la home de 4geeks.com, ese árbol pesa 67.347 caracteres, unos 21.000 tokens , antes de sumar tu instrucción. Ese número es la historia completa: el costo sigue el tamaño de la página, no lo que pediste. | Método | Tokens de entrada | Tokens de salida | Tiempo | Llamadas al modelo | | | | | | | | | 20.956 | 38–758 | 5–8 s | 1 | | por instrucción | 16.006 | 32 | 9.8 s | 1 | | replay (acción cacheada) | 0 | 0 | 0 s | 0 | | | 16.419 | 104 | 13.3 s | 2 | | self heal | 21.410 | 44 | 1.4 s | 1 | La fila de tiene un costo escondido que nada muestra por sí solo: hace dos llamadas al modelo, no una. La primera extrae según tu schema. La segunda revisa su propio trabajo contra un schema interno, , decidiendo si el objetivo está "ahora cumplido". reporta ambas llamadas como si fueran una sola, así que un presupuesto armado sobre "una llamada por " está mal desde la primera corrida. Una secuencia + son tres solicitudes, no dos, y eso importa más que nada en un plan gratuito que cuenta solicitudes. La única configuración que mueve la aguja de verdad: Acotar una llamada a una subrama en vez de entregar la página entera es la palanca más grande de toda la librería, y no aparece en la guía rápida. | Variante | Tokens de entrada | Cambio | | | | | | Página completa | 15.883–20.957 | base | | | 481–950 | −94% a −98% | | | 471–941 | −94% a −98% | | | 12.482–15.746 | −1% a −40%, según la página | Acotar hacia adentro le gana a excluir hacia afuera. solo ayuda en proporción a qué tan grande sea la subrama excluida, algo que varía por página; da un recorte predecible y casi total en cada llamada. Una trampa de la API: toma una instancia de Locator real, el objeto que devuelve . Pasar tira error. Esa forma de objeto no es el formato que espera. Una contra a tener presente: cambia el caché del lado del servidor a para esa llamada. El ahorro del 94% en tokens y un acierto de caché son mutuamente excluyent