Marco Orta — Blog

Laravel Octane + FrankenPHP: qué se rompe de verdad (reproduje cada fuga)

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

Octane mantiene tu aplicación de Laravel en memoria entre peticiones. De ahí sale la velocidad, y de ahí sale todo lo que se rompe. Casi todos los artículos de «trampas de Octane» repiten la misma advertencia: un singleton que recibe la petición en su constructor se queda con la primera petición para siempre. Monté una app de Laravel 13 en Octane con FrankenPHP dentro de Docker y reproduje cada fallo con curl, y esa advertencia, tal como se suele contar, es falsa. Las fugas que sí ocurren vienen de otro lado.

Tres resultados me sorprendieron. Un singleton que captura la petición y se resuelve durante una petición no filtra nada, porque Octane atiende cada petición sobre un clon de la aplicación. --max-requests=0, que en Swoole y RoadRunner significa «sin límite», hace que FrankenPHP ni siquiera arranque. Y las funciones que la documentación marca como exclusivas de Swoole no lanzan error en FrankenPHP: casi todas hacen otra cosa en silencio. Todo lo que sigue va con el comando y la salida.

Si todavía no decides si Octane te conviene, empieza por la guía de rendimiento de Laravel; este post es para el paso siguiente, cuando ya vas a encenderlo.

El laboratorio

Componente	Versión
Laravel	13.32.0 (el esqueleto pide PHP ^8.3)
laravel/octane	2.19.1
FrankenPHP	1.12.7, PHP 8.5.10 ZTS, Caddy 2.11.4
Imagen	`dunglas/frankenphp:latest` (Debian 13) + `pcntl` + Composer
Carga	`wrk`, en CPUs separadas

Un esqueleto limpio, nueve clases pequeñas y un archivo de rutas. Octane corre con php artisan octane:frankenphp; el modo de comparación es el php-server clásico de FrankenPHP, que arranca Laravel en cada petición igual que PHP-FPM.

Antes de arrancar: pcntl, zip y el binario musl

Tres cosas estorbaron antes de la primera petición:

La imagen oficial de FrankenPHP no trae pcntl. Sin la extensión, octane:frankenphp muere de inmediato:
```
Error  Undefined constant "Laravel\Octane\Commands\Concerns\SIGINT"
at vendor/laravel/octane/src/Commands/Concerns/InteractsWithServers.php:174
```
El Dockerfile de la documentación de Octane ejecuta install-php-extensions pcntl justo por eso. Copia esa línea.
Tampoco trae zip ni unzip, así que composer require falla dentro de ella. Instala las dependencias en una etapa con la imagen de Composer y copia vendor/.
En Alpine, octane:install descarga el binario musl. Si no hay frankenphp en el PATH, Octane lo descarga, y elige la versión glibc solo si getconf GNU_LIBC_VERSION funciona. En Alpine no funciona, así que bajas los 173 MB del build musl. La guía de rendimiento de FrankenPHP dice «evita musl en producción» porque PHP es más lento sobre ella, sobre todo en modo ZTS. En mi ruta de prueba, que es trivial, no medí diferencia (5,900 peticiones por segundo contra 5,800-6,100 en glibc), pero la página de problemas conocidos lista huecos concretos, como que no existe GLOB_BRACE. Usa las imágenes Debian.

1. Singletons: la fuga que todos describen no es la que muerde

El binding que todos los artículos ponen de ejemplo:

// AppServiceProvider::register()
$this->app->singleton(RequestEcho::class,
    fn (Application $app) => new RequestEcho($app['request']));

Resuelto dentro de una ruta, con un solo worker para que todas las peticiones caigan en el mismo:

?user=alice → {"query_user":"alice","singleton_sees":"alice"}
?user=bob   → {"query_user":"bob","singleton_sees":"bob"}
?user=carol → {"query_user":"carol","singleton_sees":"carol"}

Nada se filtra. La razón está en Worker::handle() de Octane: cada petición corre sobre $sandbox = clone $this->app, y un singleton resuelto en ese clon muere con él al terminar la petición. La advertencia famosa solo es cierta en dos situaciones, y son las que tienes que buscar.

El singleton se resuelve durante el arranque. La documentación de Octane lo dice con precisión: el problema es cuando la instancia «se resuelve durante el proceso de arranque de la aplicación». Resolví la misma clase en boot(), como haría un paquete que se carga de inmediato:

?user=alice → {"query_user":"alice","singleton_sees":null,"singleton_url":"http://localhost:8000"}

No captura la primera petición. Captura la petición falsa de consola que Laravel registra mientras arranca (la URL es APP_URL y no trae datos), y se queda con ella en todas las peticiones.

Algo lo resuelve a través de la aplicación base. Esta sí captura la primera petición. Un listener registrado en boot() que resuelve a través de $this->app, que es la aplicación original que Octane clona, no el clon:

// AppServiceProvider::boot(). Aquí todavía no se resuelve nada.
Event::listen('lab.who',
    fn () => $this->app->make(RequestEchoViaProvider::class)->user());

?user=alice → "alice"
?user=bob   → "alice"
?user=carol → "alice"

La primera petición resolvió el singleton sobre la app base, y ahí se quedó durante toda la vida del worker. Agregar la clase a flush en config/octane.php lo arregló (alice, bob, carol).

El mismo mecanismo convierte un singleton con estado en una fuga de datos entre usuarios. Un singleton CurrentTenant que vive en la app base (porque algo lo resolvió al arrancar), con un middleware que lo llena solo cuando la petición trae X-Tenant:

-H 'X-Tenant: acme' → {"singleton_tenant":"acme","scoped_tenant":"acme"}
(sin cabecera)      → {"x_tenant_header":null,"singleton_tenant":"acme","scoped_tenant":null}

La petición anónima heredó acme. Con cuatro workers es peor de depurar: solo el worker que atendió a acme quedó contaminado, así que una de cada cuatro peticiones salía mal. La misma clase registrada con scoped() en vez de singleton() devolvió null en todas las peticiones sin cabecera.

Qué hacer:

Usa scoped() para todo lo que guarde estado de la petición (tenant, usuario actual, idioma).
No resuelvas en boot() servicios que dependan de la petición, y busca listeners y macros registrados en boot() que llamen a $this->app->make().
Lo que no puedas cambiar (un paquete), agrégalo a flush en config/octane.php.
A los servicios que necesitan la petición o la configuración, inyéctales un resolvedor, fn () => Container::getInstance(), en vez del objeto.

2. El estado estático crece hasta que el worker se reinicia

Un arreglo estático que suma 10 KB por petición, que es lo que hace una caché en memoria ingenua o un registro de «ya procesados»:

req#1    worker dcb87b  items 1    mem_kb 5667
req#100                 items 100  mem_kb 7001
req#300                 items 300  mem_kb 9410
req#500                 items 500  mem_kb 11810
req#501  worker c5125d  items 1    mem_kb 1253   ← reinicio en --max-requests=500

Unos 12 KB por petición, que solo se liberan cuando Octane reinicia el worker a las 500 peticiones, el valor por defecto. El reinicio no aparece en los logs y cuesta poco: 1.85 ms antes, 4.40 ms en la primera petición del worker nuevo y 2.19 ms después.

Una trampa si lo pruebas tú: mi primera versión usaba str_repeat('x', 10240) y la memoria se quedó plana durante 500 peticiones. OPcache convierte esa expresión constante en una sola cadena compartida, así que todos los elementos del arreglo apuntaban a la misma memoria. Con Str::random() sí apareció la fuga. Si tu prueba de fuga sale limpia, comprueba que los datos de verdad cambian en cada petición.

3. `--max-requests=0` no significa «sin límite» en FrankenPHP

En OpenSwoole, max_request en 0 significa sin límite, y en RoadRunner «cero (o nada) significa sin límite» para max_jobs. En FrankenPHP:

php artisan octane:frankenphp --max-requests=0

Error: loading initial config: … frankenphp app module: start: failed to initialize workers:
too many consecutive failures: worker public/frankenphp-worker.php has not reached frankenphp_handle_request().

El contenedor sale con código 1. El script del worker de Octane hace while ($requestCount < $maxRequests …), así que con 0 nunca atiende una petición; FrankenPHP ve seis workers seguidos que no llegan a frankenphp_handle_request() y se rinde. Con octane:start --server=frankenphp --max-requests=0 el servidor sí arranca, pero el worker recibe MAX_REQUESTS=500: un ?: en el comando cambia el 0 por el valor de la configuración sin avisarte. Los dos pull requests que habrían hecho que 0 signifique «sin límite» se cerraron sin fusionarse.

Si quieres algo casi ilimitado, pasa un número grande (--max-requests=1000000 midió el mismo rendimiento que 500). Pero los reinicios son lo que te protege de la sección 2, así que yo dejaría el valor por defecto.

4. La configuración inyectada en un singleton se queda vieja, y puede envenenar el worker

Un singleton que recibe el repositorio de configuración en su constructor, y una petición que cambia un valor en tiempo de ejecución (configuración por tenant, por ejemplo):

?set=changed-in-request → {"config_helper":"changed-in-request","injected_repo":"original",
                           "resolver_closure":"changed-in-request"}

El repositorio inyectado es el de la app base, así que dentro de la petición no ve el cambio. El caso peor es el contrario: una petición que escribe a través de ese repositorio inyectado ($service->config->set(...)) cambia la configuración de la app base, y desde entonces todas las peticiones siguientes de ese worker leen mutated-via-service. En modo clásico nada de esto sobrevive a la petición. El arreglo es el que da la documentación: inyecta un closure que resuelva la configuración, o llama a config() cuando necesites el valor.

5. Lo que añade FrankenPHP: hilos, `$_ENV` y `exit()`

Hilos, no procesos. Los cuatro workers reportaron el mismo PID, y /proc mostró un solo proceso frankenphp con 67 hilos. La documentación de FrankenPHP lo dice («hilos en vez de procesos»), y importa por dos razones: no puedes usar extensiones que no sean thread-safe (la página de problemas conocidos lista imap, newrelic y pcov, y avisa que imagick en las imágenes Docker puede tronar por sus hilos de OpenMP), y un fallo en cualquier hilo tumba el proceso entero, con todos los workers.

$_ENV y putenv() sobreviven entre peticiones. FrankenPHP reinicia $_GET, $_POST, $_SERVER y los demás, pero su documentación del modo worker dice que «$_ENV actualmente no se reinicia entre peticiones». Lo probé con putenv():

?v=secret-from-alice → {"prev_getenv":null}
(petición siguiente) → {"prev_$_ENV":"secret-from-alice","prev_$_SERVER":null,
                        "prev_getenv":"secret-from-alice"}

Con cuatro workers, solo el hilo que lo escribió vio el valor. Si algún código guarda datos de la petición en el entorno (algunos SDK ponen credenciales así), se le filtran al siguiente usuario que atienda ese hilo.

exit() devuelve 200. exit(0) y exit(1) mandaron lo que llevaban de salida con HTTP 200 y reiniciaron el worker. Doce exit(1) seguidos: doce 200, y el servidor aguantó. dd() devolvió 500 y también reinició. Un monitoreo que solo mira el código de estado no va a ver un script que muere a la mitad.

El límite de 30 segundos es por petición. Octane fija max_execution_time en 30 segundos. Dos peticiones de 20 segundos seguidas en el mismo worker devolvieron 200; una de 35 devolvió 500 a los 31.2 s, con «Maximum execution time of 30 seconds exceeded» en el log, y el worker se reinició.

Issues abiertos que conviene conocer antes de desplegar (en php/frankenphp, abiertos en septiembre de 2026):

#2588: segfault del worker de Octane (salida 139). Quien lo reportó lo arregló cambiando opcache.jit de tracing a function, y lo atribuye a una regresión del JIT tracing de PHP 8.5.5 en adelante.
#1074: las subidas de archivos simultáneas se quedan colgadas por HTTPS; el mantenedor lo reprodujo en julio con 30 subidas multipart sobre una sola conexión HTTP/2.
#2388: la imagen Alpine truena con cientos de variables de entorno (los service links de Kubernetes son el origen típico).

Y actualiza Octane: antes de la 2.18.0, un POST multipart/form-data sin boundary tiraba la petición. Con el script de worker viejo me devolvió un 500 silencioso, sin nada en laravel.log; con la 2.19.1 se atiende normal.

6. Las funciones exclusivas de Swoole fallan en silencio

La documentación marca las tareas concurrentes, los ticks, la caché de Octane y las tablas como funciones de Swoole. Esto es lo que hacen en FrankenPHP:

Función	En FrankenPHP
`Octane::concurrently()`	Ejecuta las tareas una tras otra: dos de 300 ms tardaron 600 ms
`Cache::store('octane')`	Funciona, pero es una caché distinta por worker: un valor guardado en uno de cuatro workers no existía en los otros tres
`Octane::tick()`	Se registra sin error y nunca se ejecuta
`Octane::table()`	Lanza «Tables may only be accessed when using the Swoole server.»

Solo la última te avisa. Si vienes de Swoole, busca las tres primeras con grep: el código va a seguir corriendo, solo que ya no hace lo que hacía.

7. Paquetes: casi todos bien en 2026

Octane trae sus propios listeners de reinicio para Livewire, Inertia, Scout y Socialite. Las versiones actuales de los sospechosos de siempre ya lo resuelven solas: Filament reinicia sus gestores de componentes en cada petición, Telescope escucha los eventos de petición de Octane, Debugbar 4 «funciona sin configuración con Octane» (si vienes de la 3.x, quita su entrada de flush en config/octane.php) e Inertia 3 arregló sus herramientas de desarrollo bajo Octane. El que hay que configurar es spatie/laravel-permission: su listener de reinicio para Octane viene apagado, y su documentación dice que lo enciendas si los permisos cacheados se ven viejos o se cruzan entre peticiones.

¿Vale la pena? Los números

Una microprueba en una laptop, no una promesa de producción: una ruta que devuelve un JSON pequeño, APP_ENV=production, el servidor fijado a 4 CPUs (8 workers) y wrk en CPUs aparte, 20 segundos por corrida.

Modo	Conexiones	Peticiones/s	Latencia mediana
Octane (worker de FrankenPHP)	16	~6,000	2.5 ms
FrankenPHP clásico, con `optimize`	16	~2,900	5 ms
FrankenPHP clásico, sin caché de config y rutas	16	1,345	11 ms
Octane	64	~5,150	12 ms
FrankenPHP clásico, con `optimize`	64	~2,490	24 ms
`php artisan serve`	64	~315	204 ms

Octane duplicó el rendimiento frente a un modo clásico bien cacheado, y lo multiplicó por 4.5 frente a uno sin php artisan optimize. La comparación honesta es la primera: si tu producción no cachea configuración y rutas, arregla eso antes de meter Octane. Y en una app real la ganancia depende de cuánto pesa el arranque frente a tu I/O; una ruta que espera 200 ms a la base de datos gana poco con ahorrarse 3 ms de arranque.

La revisión antes de cambiar

# Servicios que guardan estado o reciben request/config en el constructor
grep -rnE "singleton\(|->instance\(" app/Providers/
grep -rnE "__construct\([^)]*(Request|Repository|Container)" app/

# Propiedades estáticas que acumulan
grep -rnE "static (array|\\\$)" app/ | grep -v "function"

# Resolución a través de la app base desde boot()
grep -rnE "\\\$this->app->(make|get)\(" app/Providers/

# Lo que FrankenPHP trata distinto
grep -rnE "putenv\(|\\\$_ENV\[|\bexit\(|\bdie\(" app/ routes/

# APIs de Swoole que se degradan en silencio
grep -rnE "Octane::(concurrently|tick|table)|store\('octane'\)" app/

Después, en orden: instala pcntl en la imagen, usa una imagen Debian, corre tu suite de pruebas, haz una prueba de carga contra el servidor de Octane con al menos cuatro workers (con uno solo no ves las fugas que solo pasan en uno de cada cuatro) y deja --max-requests en su valor por defecto. Si además vas a subir a Laravel 13, el lado del framework está en qué se rompe al actualizar a Laravel 13.

Preguntas frecuentes

¿Un singleton que recibe la petición se filtra entre peticiones en Laravel Octane?

No si se resuelve durante una petición: Octane atiende cada petición sobre un clon de la aplicación, y los singletons resueltos en el clon se descartan al terminar. Probado en Laravel 13.32 con Octane 2.19.1 y FrankenPHP 1.12.7. Sí se filtra cuando se resuelve durante el arranque (captura la petición de consola que Laravel registra al arrancar) o a través de la aplicación base, por ejemplo desde un listener registrado en boot() que llama a $this->app->make(); en ese caso se queda con la primera petición durante toda la vida del worker. Usa scoped(), agrega la clase a flush en config/octane.php o inyecta un closure que la resuelva.

¿Qué hace --max-requests=0 con Octane y FrankenPHP?

Impide que el servidor arranque. Con php artisan octane:frankenphp --max-requests=0, el script del worker nunca llega a frankenphp_handle_request() y FrankenPHP sale con «too many consecutive failures». Con octane:start el servidor arranca pero usa en silencio el valor por defecto de 500. En Swoole y RoadRunner, 0 significa sin límite. Usa un número grande si quieres evitar reinicios, pero el valor de 500 es lo que limpia las fugas de memoria.

¿Qué funciones de Octane no sirven con FrankenPHP?

Las tareas concurrentes, los ticks, la caché de Octane y las tablas son funciones de Swoole. En FrankenPHP, Octane::concurrently() ejecuta las tareas una tras otra, el almacén de caché octane es un arreglo distinto por worker, Octane::tick() se registra pero nunca se ejecuta y solo Octane::table() lanza una excepción. Las tres primeras fallan en silencio.

¿Por qué Laravel Octane falla con «Undefined constant SIGINT» en FrankenPHP?

Porque la imagen oficial dunglas/frankenphp no incluye la extensión pcntl, y Octane usa sus constantes de señales. Instálala con install-php-extensions pcntl, como hace el Dockerfile de la documentación de Octane. La imagen tampoco trae zip ni unzip, así que instala las dependencias de Composer en una etapa aparte.

¿$_ENV se reinicia entre peticiones en el modo worker de FrankenPHP?

No. FrankenPHP reinicia $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER y $_REQUEST entre peticiones, pero su documentación dice que $_ENV actualmente no se reinicia. En la prueba, un valor puesto con putenv() en una petición lo vio la siguiente petición del mismo hilo. No guardes en el entorno datos de la petición ni datos sensibles.

¿Cuánto más rápido es Laravel con Octane y FrankenPHP?

En una microprueba en laptop con una ruta JSON mínima, Octane atendió unas 6,000 peticiones por segundo contra unas 2,900 del modo clásico de FrankenPHP con caché de configuración y rutas, más o menos el doble, y 4.5 veces más que el modo clásico sin caché. La ganancia real depende de cuánto de cada petición es arranque del framework y cuánto es esperar a la base de datos u otro I/O.

Meta prohibió los chatbots de IA genéricos en WhatsApp: qué cambia para tu negocio en México (y qué no)

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

Desde el 15 de enero de 2026 ya no puedes hablar con ChatGPT, Copilot ni Perplexity desde WhatsApp en México. Mucha gente lo leyó como «Meta prohibió los bots de IA», y circulan artículos que avisan a los negocios que les van a suspender el número por usar inteligencia artificial. No es eso. La regla de Meta va contra las empresas que ofrecen un asistente de IA de propósito general como producto, no contra el negocio que usa IA para atender a sus propios clientes. Eso sigue permitido, y la propia documentación de Meta lo dice.

Lo que sí cambia para un negocio mexicano son otras tres cosas, y ninguna tiene que ver con la prohibición. Desde el 1 de octubre Meta cobra las respuestas de atención, las de IA incluidas, a partir del mensaje 1,001 del mes. Meta ya vende su propio agente de IA para negocios. Y los términos se reorganizan el 23 de septiembre. Abajo va cada cosa con su fuente.

Qué dice la regla, palabra por palabra

La cláusula está en los términos de la solución empresarial de WhatsApp (última modificación: 6 de marzo de 2026), bajo el título «AI Providers». Traducida:

Los proveedores y desarrolladores de tecnologías de inteligencia artificial o aprendizaje automático, incluidos, entre otros, los modelos de lenguaje grandes, las plataformas de IA generativa, los asistentes de IA de propósito general o tecnologías similares según lo determine Meta a su entera discreción («Proveedores de IA»), tienen estrictamente prohibido acceder o usar la WhatsApp Business Solution, directa o indirectamente, para proveer, entregar, ofrecer, vender o poner a disposición dichas tecnologías cuando dichas tecnologías sean la funcionalidad principal (y no incidental o accesoria) que se ofrece.

Y dos frases después viene la que importa a un negocio:

No obstante lo anterior, puedes contratar a un Proveedor de IA como tu Proveedor de Servicios Externo conforme a estos términos.

Es decir: OpenAI no puede usar WhatsApp para ofrecerte ChatGPT. Tu negocio sí puede contratar a OpenAI (o a quien sea) para que su modelo conteste a tus clientes sobre tu negocio. La documentación de precios de Meta lo confirma sin rodeos: los mensajes de servicio «pueden ser atendidos por una persona, como un representante de atención al cliente, o por una solución de IA de terceros». Y la Comisión Europea, al abrir su investigación, lo resumió igual: los negocios pueden seguir usando herramientas de IA «para funciones accesorias o de soporte, como la atención automatizada al cliente».

La regla aplicó a los proveedores nuevos desde el 15 de octubre de 2025 y a los que ya estaban desde el 15 de enero de 2026, según la Comisión Europea.

Quién se fue de WhatsApp (y quién volvió)

Asistente	Qué pasó
ChatGPT	Tenía más de 50 millones de usuarios en WhatsApp. Se fue el 15 de enero; OpenAI pidió vincular la cuenta porque las conversaciones no se transferían (OpenAI). Volvió el 13 de julio, solo para números de Europa (notas de versión)
Microsoft Copilot	Se fue el 15 de enero, sin conservar el historial
Perplexity	Anunció el cierre de su número de WhatsApp
Luzia	Muy usado en España y Latinoamérica. Movió a sus usuarios a su propia app, y el 30 de junio lanzó un asistente nuevo en WhatsApp con número español, que cabe en la excepción europea
Meta AI	Se queda. Desde el 15 de enero es el único asistente de IA disponible dentro de WhatsApp, según la Comisión Europea

Si tu número es +52, hoy el único asistente de propósito general dentro de WhatsApp es el de Meta.

Por qué en Europa y Brasil sí hay ChatGPT

Porque los reguladores de allá obligaron a Meta a dar marcha atrás, y la versión vigente de la cláusula ya incluye la excepción: la IA general puede ofrecerse a usuarios con número de un país del Espacio Económico Europeo o de Brasil.

Fecha	Qué pasó
24 dic 2025	La autoridad de competencia italiana (AGCM) ordena suspender los términos en Italia (AGCM)
12 ene 2026	El CADE de Brasil abre una investigación y suspende los términos como medida preventiva (CADE)
9 feb 2026	La Comisión Europea, que investiga desde el 4 de diciembre, envía su pliego de cargos
4 mar 2026	Meta readmite a los rivales en Europa, pero cobrándoles por mensaje
23 abr 2026	El CADE confirma una multa diaria de 250,000 reales porque Meta cobraba a los chatbots (CADE)
9 jun 2026	La Comisión Europea ordena restablecer el acceso gratuito en cinco días hábiles (Comisión); Meta responde que apelará

En México no hay nada parecido. La Comisión Nacional Antimonopolio, que sustituyó a la Cofece en octubre de 2025, no ha publicado ninguna investigación sobre estos términos. Así que aquí la regla aplica completa.

Lo que tu negocio sí puede hacer con IA en WhatsApp

Todo lo que es atender a tus clientes sobre tu negocio: contestar horarios y precios, recomendar productos de tu catálogo, agendar citas, tomar pedidos, mandar el link de pago, dar seguimiento. Con tres condiciones que vienen de los propios documentos de Meta:

Tiene que haber una salida a una persona. La política de mensajería de WhatsApp Business permite automatizar las respuestas, pero exige «rutas de escalamiento rápidas, claras y directas»: un agente humano en el chat, un teléfono, un correo, un formulario o una visita a la tienda. Un bot que nunca deja hablar con alguien incumple la política, aunque no tenga nada que ver con la cláusula de IA.
Las conversaciones no pueden usarse para entrenar modelos de otros. Los términos prohíben que los datos de tus clientes sirvan para crear o mejorar sistemas de IA, salvo un modelo ajustado para tu uso exclusivo. Pregúntale a tu proveedor si entrena con tus datos: OpenAI, por ejemplo, dice que en su API no entrena con ellos por defecto.
El bot habla de tu negocio. La zona gris es un número cuya oferta principal sea «pregúntame lo que quieras», aunque lo tenga una tienda. Meta no ha publicado dónde está la línea entre lo «principal» y lo «accesorio», y se reserva decidirlo «a su entera discreción». Un bot que contesta sobre tu tienda está claramente del lado permitido; un ChatGPT con tu logotipo que igual te ayuda con la tarea, no.

Un aviso sobre lo que circula: no encontré ningún caso documentado de números de negocios suspendidos por esta cláusula. Los artículos que hablan de «suspensiones masivas» no citan ninguna.

Y si lo que te interesa es que tus clientes te escriban más, eso no depende de la IA: un QR que abre tu chat con un mensaje ya escrito, pegado en el mostrador o en el ticket, funciona desde el primer día.

Lo que sí cambia para ti (y no tiene que ver con la prohibición)

1. Desde el 1 de octubre, las respuestas de atención se cobran

Según la página de precios de Meta, a partir del 1 de octubre de 2026 los mensajes de servicio (los que respondes cuando el cliente te escribe primero) se cobran a la misma tarifa que los de utilidad, con 1,000 gratis al mes por número, sin acumular. Las respuestas de un bot de IA son mensajes de servicio, así que cuentan igual que las de una persona. Y si tu cuenta no tiene método de pago dado de alta antes del 30 de septiembre, a partir del mensaje 1,001 del mes Meta deja de entregar tus respuestas. El detalle técnico, con lo que cambia en el webhook, está en qué cambia en tu código el 1 de octubre.

2. Meta ya vende su propio agente de IA

El 3 de junio Meta anunció Meta Business Agent, y lo que promete no es poco: contestar preguntas sobre tu negocio, recomendar productos de tu catálogo, agendar citas, calificar prospectos y cerrar ventas. Empezar es gratis, pero Meta ya avisó que se accederá con suscripción. En la API se cobra desde el 1 de agosto: 2 dólares por millón de tokens, que Meta calcula en unos 4 a 5 centavos de dólar por mensaje. Y el 15 de septiembre presentó Meta One, con un plan que parte de 14.99 dólares al mes e incluye más uso del agente; los precios y la disponibilidad varían por país.

Según TechCrunch, Meta lleva casi dos años probando este agente en México y la India, así que es probable que te lo ofrezcan dentro de la app. La pregunta no es si es bueno, sino si te conviene que tu atención dependa de las reglas y los precios de la misma empresa que es dueña del canal, que es justo lo que están investigando en Europa.

3. Los términos se reorganizan el 23 de septiembre

WhatsApp separa ese día sus términos en dos documentos, uno para la app de WhatsApp Business y otro para la plataforma (la API). Según su centro de ayuda es una reorganización, pero el texto nuevo todavía no está publicado. Lo reviso cuando salga y actualizo aquí si la cláusula de IA cambia.

¿El agente de Meta o uno conectado a tu negocio?

Depende de qué necesitas que haga:

	Agente de Meta	Agente propio sobre la API
Puesta en marcha	Desde la app, en minutos	Días o semanas
De dónde saca la información	Tu catálogo y lo que le configures en Meta	Tus sistemas: inventario, calendario, cobro
Qué modelo usa	El de Meta	El que elijas, con garantía de no entrenamiento
Qué pagas	Tokens de Meta o suscripción, más los mensajes	Los mensajes de Meta más el modelo que uses
Reglas y precios	Los decide Meta	Los mensajes, Meta; lo demás, tú

Para un negocio que vende lo que tiene en el catálogo y contesta dudas repetidas, el de Meta puede bastar. Cuando la respuesta depende de algo que vive fuera de Meta (si hay existencia hoy, si el horario del doctor tiene hueco, cuánto sale el envío a tu colonia), hace falta uno conectado a tus sistemas. Así funciona el agente de WhatsApp que monto para negocios, y el lado técnico lo expliqué en cómo montar un agente de IA en WhatsApp con Laravel y OpenAI.

Cinco preguntas para tu proveedor de bot

¿Mi número usa la API oficial de WhatsApp o una app no oficial? (Las no oficiales pueden ser bloqueadas por Meta aunque no usen IA.)
¿El bot contesta solo sobre mi negocio, o responde cualquier cosa?
¿Cómo pasa la conversación a una persona, y en cuánto tiempo?
¿Mis conversaciones se usan para entrenar algún modelo?
¿Mi cuenta de Meta tiene método de pago antes del 30 de septiembre, y quién paga los mensajes que pasen de 1,000 al mes?

Si alguna respuesta es «no sé», es la que hay que resolver primero.

Preguntas frecuentes

¿Meta prohibió los chatbots de IA en WhatsApp?

Prohibió a los proveedores de IA ofrecer asistentes de propósito general (como ChatGPT, Copilot o Perplexity) a través de la API de WhatsApp cuando la IA es la función principal del servicio. Aplica desde el 15 de enero de 2026 para los que ya estaban y desde el 15 de octubre de 2025 para los nuevos. No prohibió que los negocios usen IA para atender a sus propios clientes.

¿Puedo usar un bot de IA en el WhatsApp de mi negocio en 2026?

Sí. Los términos de WhatsApp permiten contratar a un proveedor de IA como proveedor de servicios, y la documentación de precios de Meta dice que los mensajes de servicio pueden ser atendidos por una persona o por una solución de IA de terceros. Las condiciones: que haya una forma clara de hablar con una persona, que las conversaciones no se usen para entrenar modelos de otros y que el bot atienda sobre tu negocio.

¿Por qué ChatGPT sí funciona en WhatsApp en España y no en México?

Porque la autoridad de competencia de Italia, la Comisión Europea y el CADE de Brasil ordenaron a Meta suspender la restricción, y los términos vigentes (del 6 de marzo de 2026) permiten ofrecer IA de propósito general a números de países del Espacio Económico Europeo y de Brasil. ChatGPT volvió a WhatsApp en Europa el 13 de julio de 2026. En México no hay una investigación pública y la restricción aplica completa.

¿Me pueden suspender el número por usar IA en WhatsApp?

Meta puede cerrar cuentas que incumplan sus términos, y la línea entre usar IA como función principal o accesoria la decide Meta a su entera discreción. Un bot que atiende sobre tu negocio está del lado permitido; un número cuya oferta principal es un asistente de preguntas generales está en riesgo. No hay casos públicos documentados de números de negocios suspendidos por esta cláusula.

¿Cuánto cuesta el agente de IA de Meta para negocios?

Meta Business Agent se anunció el 3 de junio de 2026 y empezar es gratis, pero Meta avisó que se accederá por suscripción. En la API se cobra desde el 1 de agosto de 2026 a 2 dólares por millón de tokens, unos 4 a 5 centavos de dólar por mensaje según Meta. El plan Meta One presentado el 15 de septiembre parte de 14.99 dólares al mes e incluye más uso del agente; precio y disponibilidad varían por país.

¿Las respuestas de un bot de IA en WhatsApp se cobran?

Desde el 1 de octubre de 2026 sí, como cualquier mensaje de servicio: Meta regala 1,000 al mes por número y cobra los siguientes a la tarifa de utilidad de cada país. Da igual si responde una persona o una IA. Si la cuenta no tiene método de pago, Meta deja de entregar las respuestas a partir de la respuesta número 1,001 del mes.

OpenAI apaga GPT-4, o1 y o3-mini el 23 de octubre: qué se rompe en tu código (y no es solo el nombre del modelo)

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

El 23 de octubre de 2026 OpenAI apaga gpt-3.5-turbo, gpt-4, gpt-4-turbo, o1, o1-pro, o3-mini, o4-mini, gpt-4.1-nano, un snapshot de gpt-4o y gpt-image-1. La página de deprecaciones hace que el arreglo parezca cambiar un texto: poner gpt-5.6-sol, -terra o -luna donde estaba el nombre viejo. Ese cambio es lo fácil, y en mucho código ni siquiera es donde está el problema.

Después de cambiar el nombre se rompen cuatro cosas, y una más se rompe en código donde el nombre nunca aparece: LangChain y LlamaIndex siguen usando gpt-3.5-turbo por defecto, así que un proyecto que jamás escribió un nombre de modelo usa uno que muere en 32 días. Abajo va todo, verificado contra la documentación de OpenAI tal como estaba el 21 de septiembre y contra el código fuente de las librerías. Donde algo sale de reportes de usuarios y no de OpenAI, lo digo.

Si lo que necesitas es el calendario completo de todos los proveedores (Anthropic, Gemini, Azure) y cómo saber si el chatbot de un negocio está afectado, está en la guía de retiros de modelos de IA. Este post es el lado del código.

Qué se apaga y qué dice OpenAI que uses

Sale de la página de deprecaciones, sección «2026-04-22: Legacy GPT model snapshots». OpenAI lo anunció por correo el 22 de abril; la columna de sustitutos se editó después, porque nombra modelos que salieron en julio. Los precios son de nivel estándar, por millón de tokens, entrada / salida, según la página de precios:

Se apaga el 23 de octubre	Precio	Sustituto	Precio	Cambio
`gpt-3.5-turbo` (`-0125`, `-completions`)	$0.50 / $1.50	`gpt-5.6-terra`	$2 / $12	4× / 8×
`gpt-4` (`-0613`, `-completions`)	$30 / $60	`gpt-5.6-sol`	$4 / $20	más barato
`gpt-4-turbo` (`-2024-04-09`)	$10 / $30	`gpt-5.6-sol`	$4 / $20	más barato
`gpt-4o-2024-05-13`	$5 / $15	`gpt-5.6-sol`	$4 / $20	≈ / 1.3×
`gpt-4.1-nano`	$0.10 / $0.40	`gpt-5.6-luna`	$0.20 / $1.20	2× / 3×
`o1`	$15 / $60	`gpt-5.6-sol`	$4 / $20	más barato
`o1-pro`	$150 / $600	`gpt-5.6-sol` en modo pro	$4 / $20 + más tokens	más barato
`o3-mini`	$1.10 / $4.40	`gpt-5.6-sol`	$4 / $20	3.6× / 4.5×
`o4-mini`	$1.10 / $4.40	`gpt-5.6-terra`	$2 / $12	1.8× / 2.7×
`gpt-image-1`	$10 / $40 (tokens de imagen)	`gpt-image-2`	$8 / $30	más barato

Tres detalles que la tabla esconde:

El alias gpt-4o no está en la lista. Apunta a gpt-4o-2024-08-06 según su página de modelo, y solo muere el snapshot de mayo de 2024. gpt-4o-mini y gpt-4.1 (sin -nano) tampoco están.
Los $4 / $20 de Sol son una promoción. OpenAI dice que está «disponible al menos hasta el 21 de noviembre de 2026» y la describe como un recorte del 20 % en entrada y del 33 % en salida, lo que deja el precio normal en unos $5 / $30. Presupuesta con ese.
Los fine-tunes se van el mismo día: ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano-2025-04-14, ft-babbage-002 y ft-davinci-002. Más abajo explico por qué no tienen sucesor real.

Cómo se ve el fallo

Lo único oficial que dice OpenAI es que «el modelo o endpoint dejará de estar accesible». No documenta el error. Lo que reportaron usuarios tras los apagones de julio y agosto de este año (aquí y aquí) es consistente:

404 invalid_request_error / model_not_found
The model `gpt-5.1-codex` has been deprecated, learn more here:
https://platform.openai.com/docs/deprecations

El SDK de Python lo lanza como openai.NotFoundError. Dos consecuencias prácticas:

No se puede reintentar. Si tu capa reintenta cualquier excepción con espera creciente, el 23 de octubre va a gastar sus reintentos en una petición que nunca va a funcionar, y tus usuarios van a esperarla. Reintenta en 429 y 5xx, no en 404.
Un health check que lista modelos te va a mentir. Según esos mismos reportes, los IDs retirados siguen apareciendo en GET /v1/models después de dejar de funcionar. Un chequeo de arranque que confirma «mi modelo está en la lista» pasa con un modelo muerto. La única prueba fiable es una petición real de un token.

La Responses API lo redacta distinto («Model not found …»), así que si comparas el texto del mensaje, compara mejor code: model_not_found.

1. El modelo que nunca escribiste: los defaults de las librerías

Este es el que atrapa a los equipos que se creen a salvo porque grep gpt-3.5 no encuentra nada. Revisé el código de las librerías que usan casi todos los tutoriales de 2023 y 2024:

Librería	Modelo por defecto si no pasas uno	Fuente
LangChain Python, `ChatOpenAI`	`"gpt-3.5-turbo"`	`base.py#L733`
LangChain.js, `ChatOpenAI`	`"gpt-3.5-turbo"`	`base.ts#L286`
LlamaIndex, LLM `OpenAI`	`"gpt-3.5-turbo"`, y es al que recurre el core cuando no configuras ningún LLM	`DEFAULT_OPENAI_MODEL` en `llama-index-llms-openai`
Vercel AI SDK	no tiene modelo por defecto, pero `openai.completion()` «por ahora solo» admite `gpt-3.5-turbo-instruct`	docs del proveedor OpenAI

Así que esto, que aparece en incontables README, es una llamada a gpt-3.5-turbo:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0)   # sin model= → "gpt-3.5-turbo"

Y con LlamaIndex puede ser todavía menos visible: si nunca defines Settings.llm, un query engine construye un OpenAI() por su cuenta, con el mismo default. La clase OpenAIResponses de LlamaIndex usa gpt-4o-mini, que sobrevive.

El caso de Vercel tiene fecha antes: gpt-3.5-turbo-instruct se apaga el 28 de septiembre, junto con babbage-002 y davinci-002, así que lo que use openai.completion() o el endpoint heredado /v1/completions tiene una semana, no un mes. Esos tres son los únicos modelos que todavía nombra la referencia del endpoint.

El arreglo siempre es el mismo: pasa el modelo explícito, y léelo de la configuración para que el siguiente apagón sea una variable de entorno y no un deploy.

Como contraste, laravel/ai 1.x ya usa por defecto gpt-5.6-terra, -luna, -sol y gpt-image-2. Las librerías nuevas lo resolvieron; el problema es el código montado sobre las de 2023.

2. Las tools en Chat Completions ahora piden el razonamiento apagado

Todos los sustitutos de la tabla son modelos de razonamiento, y eso cambia el contrato de Chat Completions. De la guía para subir a GPT-5.6:

For GPT-5.6, function tools in Chat Completions are compatible only with effective reasoning none. Reasoning with tools should use the Responses API.

El esfuerzo de razonamiento por defecto es medium. Así que un chatbot con function calling que funcionaba con gpt-4-turbo, al que solo le cambias el nombre del modelo, falla en su primera petición. Este es el error que le salió a un equipo con gpt-5.6-luna:

400 - Function tools with reasoning_effort are not supported for gpt-5.6-luna

Tienes dos salidas. La mínima deja Chat Completions y apaga el razonamiento, que es lo más parecido a como se comportaba gpt-4-turbo:

const res = await openai.chat.completions.create({
  model: 'gpt-5.6-sol',
  reasoning_effort: 'none',     // obligatorio si pasas tools
  messages,
  tools,
});

La que recomienda OpenAI es mover esa llamada a la Responses API, donde razonamiento y tools sí funcionan juntos. No es solo renombrar: el prompt de sistema pasa a instructions, las salidas estructuradas se mueven de response_format a text.format y las definiciones de funciones pierden un nivel de anidación:

// Chat Completions
tools: [{ type: 'function', function: { name: 'get_order', parameters } }]

// Responses
tools: [{ type: 'function', name: 'get_order', parameters }]

También cambia el valor por defecto de la validación estricta. Según la guía de migración, en Chat Completions las funciones no son estrictas por defecto, y en Responses omitir strict hace que intente el modo estricto. Si tus esquemas JSON se escribieron a la ligera, define strict a mano en vez de heredar el nuevo default.

Chat Completions en sí no está deprecado. OpenAI dice que «sigue soportado» y que Responses «se recomienda para todos los proyectos nuevos». No tienes que migrar de endpoint el 23 de octubre, solo decidir qué haces con el razonamiento.

3. `max_tokens`: cambia de nombre y ahora paga el razonamiento

La referencia de Chat Completions marca max_tokens como «deprecado en favor de max_completion_tokens» e «incompatible con los modelos de la serie o». La documentación no dice si GPT-5.6 rechaza max_tokens directamente; el equipo del issue de arriba reporta que todas sus llamadas necesitaron el nombre nuevo. Renómbralo de todas formas.

Lo que de verdad cambia el comportamiento es qué cuenta el parámetro nuevo. max_completion_tokens cubre «los tokens de salida visibles y los de razonamiento», y los de razonamiento «se cobran como tokens de salida» (guía de razonamiento). El clásico clasificador en gpt-3.5-turbo con max_tokens: 50 para forzar una etiqueta corta, movido a gpt-5.6-terra con su esfuerzo medium por defecto, puede gastarse todo el presupuesto pensando y volver cortado o vacío, y el razonamiento se cobra igual. OpenAI recomienda reservar al menos 25,000 tokens para razonamiento y salida.

Para tareas cortas y deterministas el arreglo no es más presupuesto, sino nada de razonamiento:

client.chat.completions.create(
    model="gpt-5.6-terra",
    reasoning_effort="none",        # una etiqueta no necesita pensar
    max_completion_tokens=50,       # antes max_tokens
    messages=messages,
)

temperature y top_p son una trampa parecida. Para GPT-5.2 y 5.4 la documentación dice que solo se admiten con esfuerzo none; para 5.6 no encontré la regla por escrito. Si los pasas, prueba con y sin razonamiento antes del 23 en vez de descubrirlo en producción.

4. Los fine-tunes no tienen sucesor

La columna de sustitutos manda ft-gpt-3.5-turbo a gpt-5.6-terra y ft-gpt-4 a gpt-5.6-sol. Esos son modelos base. Las páginas de GPT-5.6 marcan el fine-tuning como no soportado, y desde el 6 de enero de 2027 los clientes existentes ya no pueden crear trabajos de fine-tuning.

En la práctica, lo que tu fine-tune aprendió (el tono, el formato de salida, las etiquetas de tu dominio) tiene que pasar al prompt: ejemplos few-shot, un esquema estricto con salidas estructuradas o recuperación de contexto. Planea ese trabajo ya. Es lo único de esta lista que es un proyecto y no un parche, y los datos de entrenamiento con los que armaste el fine-tune son justo de donde vas a sacar los ejemplos.

5. `o1-pro` y `gpt-image-1`: cambian los parámetros, no solo el nombre

o1-pro → gpt-5.6-sol en modo pro. La guía es explícita: «no busques ni inventes un slug gpt-5.6-pro aparte». El modo pro es un ajuste de razonamiento de Sol y solo funciona por Responses, no por Chat Completions. o1-pro ya era solo de Responses, así que el endpoint no cambia; cambian el nombre del modelo y el ajuste de razonamiento. OpenAI avisa que el modo pro «hace más trabajo de modelo», así que el precio por token es menor que el de o1-pro pero los tokens por petición suben.
gpt-image-1 → gpt-image-2. La guía de imágenes dice que omitas input_fidelity con gpt-image-2, así que si tus llamadas de edición lo pasan, quítalo. Y si dependes de fondos transparentes, gpt-image-2 solo los ofrece en preview desde el 20 de agosto.

6. La factura

Para la familia GPT-4 y o1, el cambio ahorra dinero, más todavía si seguías pagando $30 / $60 por gpt-4-0613. Para todo lo que se eligió por ser barato, cuesta más:

Un clasificador o router en gpt-3.5-turbo que procesa 1 millón de tokens de entrada y 200 mil de salida al día cuesta $0.80. En gpt-5.6-terra con el razonamiento apagado, $4.40. Son 5.5× antes de contar un solo token de razonamiento.
o3-mini → gpt-5.6-sol son 3.6× en entrada y 4.5× en salida, y más cuando termine la promoción.
gpt-4.1-nano → gpt-5.6-luna duplica la entrada y triplica la salida.

Si una de esas líneas te importa, prueba un nivel más barato que el que sugiere la tabla antes de aceptar el sustituto: la columna dice lo que OpenAI considera equivalente, no lo que tu tarea necesita. El costo por tarea entre proveedores lo desgloso en cuánto cuesta la API de OpenAI, Claude y Gemini. Y no, la tabla no apunta a gpt-6-astra, aunque la guía de razonamiento ahora diga «empieza con» él: a $10 / $50 y sin temperature, top_p ni top_logprobs es otra decisión, que cuento en GPT-6 Astra para desarrolladores.

La auditoría: tres greps y una petición real

Desde la raíz del repositorio. El primero busca los IDs que mueren como texto exacto entre comillas, así que se salta gpt-4o, gpt-4o-mini y gpt-4.1, que sobreviven:

# 1. IDs de modelos que mueren el 23-oct (y el 28-sep), entre comillas
grep -rnE "['\"\`](gpt-3\.5-turbo[a-z0-9-]*|gpt-4|gpt-4-0613|gpt-4-turbo[a-z0-9-]*|gpt-4-1106-preview|gpt-4o-2024-05-13|gpt-4\.1-nano[a-z0-9-]*|o1|o1-pro[a-z0-9-]*|o1-2024-12-17|o3-mini[a-z0-9-]*|o4-mini[a-z0-9-]*|gpt-image-1|babbage-002|davinci-002)['\"\`]" \
  --exclude-dir={node_modules,vendor,.git} .

# 2. Lo mismo en los archivos de entorno, donde los nombres van sin comillas
grep -rnE "=(gpt-3\.5|gpt-4(-|$)|o1|o3-mini|o4-mini|gpt-image-1$)" .env* 2>/dev/null

# 3. Constructores que heredan el default de una librería
grep -rnE "ChatOpenAI\(|llama_index\.llms\.openai|openai\.completion\(" \
  --include=*.py --include=*.ts --include=*.js --exclude-dir=node_modules . | grep -v "model"

El tercero da falsos positivos a propósito (un constructor en varias líneas con model= en otra aparecerá), pero la lista es corta y vale la pena leerla a ojo.

Luego la prueba que cuenta: por cada modelo que acabes usando, una petición real con tus parámetros de producción (tools, max_completion_tokens, temperature si lo pasas) contra el nombre nuevo. No GET /v1/models, por lo explicado arriba.

Los nombres de modelo configurados también viven fuera del repo: flujos de Make, Zapier o n8n, el panel del chatbot de un proveedor, una hoja de Google con un script. La guía de retiros tiene la lista de revisión para esos casos.

El resto del calendario de OpenAI este año

Todo sale de la misma página de deprecaciones:

Fecha	Qué se apaga
24 sep	Videos API, `sora-2` y `sora-2-pro` (sin sustituto)
28 sep	`gpt-3.5-turbo-instruct`, `babbage-002`, `davinci-002`, `gpt-3.5-turbo-1106`
1 oct	`gpt-5.4-cyber` → `gpt-5.6-cyber` (20 días de aviso)
23 oct	Todo lo de este post
31 oct	Evals pasa a solo lectura
30 nov	El panel y la API de Evals, la API `v1/prompts` y los prompts reutilizables, Agent Builder
1 dic	`gpt-image-1-mini`, `gpt-image-1.5`, `chatgpt-image-latest` → `gpt-image-2`
11 dic	Los snapshots de `gpt-5`, `gpt-5-mini`, `gpt-5-nano`, `gpt-5-pro`, `o3` y `o3-pro`

La última fila merece una nota: las páginas de gpt-5 y o3 listan solo el snapshot que se retira, así que muy probablemente los alias mueren con ellos. El README de openai-php/laravel todavía usa 'model' => 'gpt-5' como ejemplo. La Assistants API ya se apagó el 26 de agosto.

Preguntas frecuentes

¿Qué modelos de OpenAI se apagan el 23 de octubre de 2026?

gpt-3.5-turbo (incluidos gpt-3.5-turbo-0125 y la variante -completions), gpt-4 y gpt-4-0613, gpt-4-turbo y gpt-4-turbo-2024-04-09, gpt-4-1106-preview, gpt-4o-2024-05-13, gpt-4.1-nano, o1, o1-pro, o3-mini, o4-mini y gpt-image-1, además de los modelos con fine-tuning ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002 y ft-davinci-002. OpenAI lo anunció el 22 de abril de 2026. El alias gpt-4o, gpt-4o-mini y gpt-4.1 no están en la lista.

¿Por qué modelo cambio gpt-4 y gpt-3.5-turbo?

OpenAI indica gpt-5.6-sol como sustituto de gpt-4, gpt-4-turbo, gpt-4o-2024-05-13, o1, o1-pro (en modo pro) y o3-mini; gpt-5.6-terra para gpt-3.5-turbo y o4-mini; gpt-5.6-luna para gpt-4.1-nano; y gpt-image-2 para gpt-image-1. Son modelos de razonamiento, así que cambiar el nombre no basta: las tools en Chat Completions piden reasoning_effort none, y max_tokens pasa a max_completion_tokens, que también cuenta los tokens de razonamiento.

¿Qué error devuelve la API de OpenAI con un modelo retirado?

OpenAI no documenta la respuesta. Los usuarios que se toparon con los apagones de julio y agosto de 2026 reportan HTTP 404 con type invalid_request_error y code model_not_found, que el SDK de Python lanza como openai.NotFoundError. No se debe reintentar. Los IDs retirados pueden seguir apareciendo en GET /v1/models, así que la única comprobación fiable es una petición real.

¿LangChain sigue usando gpt-3.5-turbo por defecto?

Sí. En septiembre de 2026, ChatOpenAI en LangChain Python y en LangChain.js usa gpt-3.5-turbo cuando no pasas un modelo, y el LLM OpenAI de LlamaIndex también (y es al que recurre LlamaIndex cuando no defines Settings.llm). El código que nunca nombra un modelo va a fallar el 23 de octubre. Pasa el modelo de forma explícita.

¿Por qué gpt-5.6 falla con «Function tools with reasoning_effort are not supported»?

Porque en Chat Completions GPT-5.6 solo acepta function tools cuando el esfuerzo de razonamiento efectivo es none, y el valor por defecto es medium. O añades reasoning_effort: none a la petición, que se comporta lo más parecido a gpt-4-turbo, o mueves la llamada a la Responses API, donde tools y razonamiento funcionan juntos.

¿Sale más caro migrar a gpt-5.6?

Depende de lo que tenías. Desde gpt-4, gpt-4-turbo u o1 sale más barato: gpt-5.6-sol cuesta $4 de entrada y $20 de salida por millón de tokens, un precio promocional disponible al menos hasta el 21 de noviembre de 2026. De gpt-3.5-turbo a gpt-5.6-terra es 4 veces el precio de entrada y 8 veces el de salida, y de o3-mini a sol unas 3.6 y 4.5 veces, antes de contar los tokens de razonamiento, que se cobran como salida.

¿Qué pasa con mi modelo gpt-3.5-turbo con fine-tuning?

Se apaga el 23 de octubre de 2026 junto con los modelos base. El sustituto indicado es gpt-5.6-terra base, y GPT-5.6 no admite fine-tuning; desde el 6 de enero de 2027 los clientes existentes no pueden crear trabajos de fine-tuning. Lo que aprendió el fine-tune tiene que pasar al prompt: ejemplos few-shot, salidas estructuradas o recuperación de contexto.

Por qué tu tienda en línea se cae en el Buen Fin (y cómo evitarlo): la guía técnica de 2026

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

El Buen Fin 2026 va del viernes 13 al martes 17 de noviembre, y casi todo lo que se publica sobre cómo preparar tu tienda en línea habla de banners, cupones y correos. Esta guía es de la otra mitad: qué se rompe técnicamente cuando llegan de golpe los visitantes que pagaste por atraer, y qué hacer antes. Casi todo lo que sigue está escrito en la documentación de tu hosting, tu pasarela de pagos y tu plataforma, y casi nadie lo lee hasta que la tienda ya está caída.

Los números de 2025 explican por qué vale la pena. Según la Secretaría de Economía, la edición pasada vendió 219,200 millones de pesos, y el comercio digital fue el 21 % del total, con un crecimiento anual del 31 %. El reporte público de la AMVO midió 1,686 millones de páginas visitadas en sitios de comercio electrónico y un tráfico 56 % mayor que el año anterior (el Buen Fin pasó de cuatro a cinco días). La ANTAD reporta que el último día concentró el 26.1 % de las ventas en línea. El pico no se reparte: llega, y llega junto.

He construido tiendas en WooCommerce con catálogos de miles de productos, pagos con Mercado Pago y cobro por WhatsApp. Lo que sigue es lo que reviso en cada una antes de una fecha así, con la fuente de cada límite.

Lo que pasa en esos cinco días

Dato del Buen Fin 2025	Cifra	Fuente
Ventas totales	219,200 millones de pesos	Secretaría de Economía
Ventas en línea	21 % del total, +31 % anual (45,900 millones según AMVO)	SE / AMVO
Tráfico a tiendas en línea	+56 % en los 5 días, +24 % en días comparables	AMVO (datos de Similarweb)
Ticket promedio	$1,063 en línea contra $780 en general	ABM, citada por la SE
Cómo pagaron en línea	Crédito 48 %, débito 43 %, departamental 17 %, pago a plazos sin tarjeta 12 %, efectivo en tiendas 12 %	AMVO
Quejas ante Profeco	220 inconformidades, 205 conciliadas; predominan incumplimiento de precios y negativa de entrega	Profeco

Dos datos de esa tabla importan para lo técnico. Uno de cada ocho compradores en línea pagó en efectivo en cadenas comerciales (OXXO y similares), y eso tiene una consecuencia sobre tu inventario que explico abajo. Y el 37 % de los consumidores, según la encuesta de la AIMX que cita la SE, teme que se filtren sus datos: un aviso de certificado vencido o una página de pago que se ve rara el día que más visitas tienes cuesta ventas aunque el sitio no se caiga.

Tampoco todo lo que falla es tuyo. En el Buen Fin 2024 usuarios de Santander y BBVA reportaron fallas para pagar con tarjeta; en el Hot Sale de mayo de 2026 BBVA confirmó en X que sus sistemas estaban fallando, y Downdetector marcó más de cinco horas de reportes. Y el 18 de noviembre de 2025, un día después de que terminara el Buen Fin, Cloudflare tuvo una caída global de más de tres horas. No puedes evitar que el banco de tu cliente se caiga. Sí puedes tener un segundo método de pago listo para cuando pase.

1. Tu hosting compartido tiene un techo, y está escrito

El plan de hosting compartido que cuesta unos cientos de pesos al año no es «lento»: tiene límites exactos, y cuando los tocas no se pone lento, devuelve error. Hostinger publica los suyos en su página de parámetros y dice que alcanzarlos produce un «503 – Service temporarily unavailable»:

Plan de Hostinger	CPU	RAM	Procesos PHP simultáneos	Conexiones a MySQL
Web Single	1	1 GB	20	25
Web Premium	1	2 GB	40	50
Unlimited (antes Business)	2	3 GB	60	75

HostGator México lo dice de otra forma en su centro de ayuda: un límite del 25 % de CPU sostenido por 90 segundos o más, y 25 procesos simultáneos por cPanel.

Para ver lo que significa, haz la cuenta con tu propia tienda. Una página de producto de WooCommerce que nadie ha guardado en caché ocupa un proceso PHP mientras se arma. Si tarda un segundo y tienes 20 procesos, tu techo es de unas 20 páginas por segundo; el visitante 21 no espera en una fila, recibe un error. Por eso la caché del siguiente punto no es una optimización, es lo que decide si esos límites te alcanzan o no.

2. La caché: qué se puede guardar y qué no

La idea es sencilla: que la mayoría de los visitantes, los que solo miran, reciban una copia ya armada de la página y no le cuesten nada a tu servidor. Solo el carrito, el pago y la cuenta del cliente tienen que llegar al servidor cada vez.

Lo que casi nadie sabe es que Cloudflare no guarda el HTML por defecto, ni en el plan gratuito ni en los de pago. Su documentación es explícita: «The Cloudflare CDN does not cache HTML or JSON by default». Si pusiste tu tienda detrás de Cloudflare y no configuraste nada más, se guardan las imágenes, el CSS y el JavaScript, pero cada página sigue llegando a tu hosting. En el plan gratuito tienes hasta 10 Cache Rules, y con una basta. Esta es la expresión para una tienda WooCommerce en español (ajusta las rutas a las tuyas):

(http.host eq "tutienda.mx"
 and not starts_with(http.request.uri.path, "/wp-admin")
 and not http.request.uri.path contains "/carrito"
 and not http.request.uri.path contains "/finalizar-compra"
 and not http.request.uri.path contains "/mi-cuenta"
 and not http.cookie contains "woocommerce_items_in_cart"
 and not http.cookie contains "wordpress_logged_in")

Con la acción «Eligible for cache» y un tiempo en el borde corto (5 a 10 minutos), quien solo mira recibe la copia guardada, y quien ya tiene algo en el carrito o inició sesión pasa directo a tu servidor. Dos avisos:

Purga la caché cuando cambies los precios. Si tus descuentos arrancan a la medianoche del 13, una copia guardada a las 11:58 sigue mostrando el precio viejo, y «el precio no era el anunciado» es de las quejas que más recibe Profeco. Purga al activar las ofertas.
Una cookie en cada página rompe todo. Cloudflare no guarda una respuesta que trae Set-Cookie, y algunos plugins (conversores de moneda, geolocalización, popups) la mandan en cada visita. Compruébalo así:

curl -sI https://tutienda.mx/producto/tu-mas-vendido/ | grep -iE "set-cookie|cf-cache-status"

Lo que quieres ver, a partir de la segunda petición, es cf-cache-status: HIT y ningún set-cookie. Si ves DYNAMIC o BYPASS, esa página sigue llegando a tu servidor.

Dos cosas que parecen red de seguridad y no lo son. Always Online está en todos los planes, pero solo se activa con errores 52x, sirve copias del Internet Archive y no puede servir contenido dinámico: nadie compra en una copia de archivo. Y la sala de espera de Cloudflare (Waiting Room), la fila virtual que usan las grandes tiendas, solo existe en los planes Business y Enterprise.

Si tu tienda es WooCommerce, revisa también los cart fragments: el script que actualiza el contador del carrito haciendo una petición al servidor en cada página. WooCommerce reconoce que en tiendas con mucho tráfico «puede afectar severamente la carga del servidor», y desde la versión 7.8 ya no se carga en todas las páginas, pero muchos temas y plugins lo vuelven a activar. Abre una página de producto con las herramientas de desarrollo del navegador y busca una petición a ?wc-ajax=get_refreshed_fragments. Si aparece en páginas sin mini carrito, es una petición al servidor por visita que la caché no te quita.

Y aligera las fotos de producto: son la mayor parte del peso de una tienda, y en celular, que es donde compra casi todo el mundo, cada megabyte se nota.

3. Tu pasarela de pagos también tiene límite

El servidor no es lo único que puede decir «ya no». Stripe publica sus límites: 100 peticiones por segundo en modo real, y la mayoría de sus endpoints por separado a 25. Y lo dice sin rodeos: «un aumento repentino en el volumen de cobros, como una venta flash, puede provocar limitación». Si esperas un pico, su recomendación es escribirle a soporte antes. Mercado Pago no publica una cifra, pero su API de órdenes responde 429 Too Many Requests con un encabezado Retry-After cuando la pasas.

Para una PyME, 100 cobros por segundo sobran. El problema aparece cuando la integración hace varias llamadas por compra (crear cliente, crear intento de pago, consultar estado) o reintenta sin esperar: un error 429 mal manejado se convierte en un «no se pudo procesar tu pago» para un cliente que sí tenía fondos.

Y el pago con verificación del banco (3-D Secure, la pantalla de «confirma en tu app») cambia el flujo. En México no es obligatorio por regulación, pero Mercado Pago recomienda activarlo en modo opcional, y cuando el banco pide el desafío el pago queda en estado pending con detalle pending_challenge. Si tu integración trata «pendiente» como «rechazado», estás cancelando compras buenas. La AMVO pone el «rechazo del método de pago» entre las barreras para comprar en línea.

4. El problema que nadie te cuenta: el pago en OXXO aparta tu inventario

Esto es lo que más me preocupa de una tienda con inventario limitado, y no lo vi en ninguna de las guías del Buen Fin que revisé. Cuando alguien elige pagar en efectivo, la pasarela genera una ficha con fecha de vencimiento, y mientras no pague, la pieza queda en el limbo:

Pasarela	Vigencia de la ficha	Qué pasa si paga tarde
Stripe (OXXO)	5 días por defecto, configurable de 1 a 7; la confirmación llega al siguiente día hábil	La ficha vence (docs)
Mercado Pago (OXXO, Paycash)	Configurable de 1 a 30 días; recomiendan 3. La acreditación tarda hasta 2 horas hábiles	«El valor será devuelto» (docs)
Conekta	La fija tu integración con `expires_at`; avisa con el webhook `order.expired`	Depende de tu integración (docs)

Ahora el lado de WooCommerce. Su opción «Retener inventario» aparta la pieza de los pedidos pendientes de pago durante el tiempo que configures (60 minutos es el valor recomendado) y luego los cancela, según su guía. Pero la misma guía dice que los métodos de pago diferido dejan el pedido en espera (On hold), y ahí esa cancelación automática no aplica. Si el plugin de tu pasarela no cancela el pedido cuando vence la ficha, la pieza queda apartada días por alguien que quizá nunca va a pagar, mientras le dices «agotado» a quien sí traía la tarjeta en la mano.

Qué hacer antes del 13:

Acorta la vigencia de la ficha durante la campaña. Uno o dos días en lugar de cinco o treinta.
Comprueba que tu plugin cancela el pedido al vencer. Haz una compra de prueba en efectivo con la vigencia mínima, no la pagues y revisa al día siguiente que el pedido pasó a cancelado y el inventario volvió.
Si vendes por WhatsApp con links de cobro, dales vencimiento corto. Clip, por ejemplo, permite que el link venza el mismo día.

5. Sobreventa: dos personas compran la última pieza

WooCommerce tiene desde la versión 4.3 una reserva de inventario para evitar que dos compras simultáneas se lleven la misma pieza (PR #26395). Aun así, el issue #44273, donde el equipo confirma que «una condición de carrera como esta es posible», sigue abierto hoy. En días normales casi nunca pasa. En el Buen Fin, con cientos de personas sobre tu producto estrella, es cuando pasa.

Para los productos con pocas piezas: deja un margen (publica 18 si tienes 20), limita la cantidad por cliente y decide antes qué haces si ocurre, con un mensaje de disculpa y un reembolso rápido. La «negativa de entrega» fue de las quejas que predominaron ante Profeco en 2025. Shopify, en su guía para ventas flash, recomienda por lo mismo cambiar a captura manual de pagos, para cobrar solo lo que de verdad puedes entregar.

6. Lo que trabaja en segundo plano

Los correos de confirmación, los webhooks de pago y la actualización de inventario en WooCommerce pasan por Action Scheduler, que por defecto procesa lotes de 25 tareas durante 30 segundos, disparado por WP-Cron. Y WP-Cron solo se ejecuta cuando alguien visita el sitio. Con la caché bien puesta, casi nadie llega al servidor, y las tareas pueden acumularse. El resultado: clientes que pagaron y no reciben su confirmación, y te escriben preguntando si su compra entró.

La solución es un cron real del servidor en lugar del de visitas: define DISABLE_WP_CRON en wp-config.php y programa una llamada a wp-cron.php cada minuto desde el panel de tu hosting. Casi todos los hostings compartidos lo permiten.

7. Pruébalo antes con tráfico falso

Todo lo anterior se puede comprobar sin esperar al día 13. Una prueba de carga simula a muchos visitantes a la vez y te dice en qué punto empiezan los errores. Dos herramientas gratuitas:

k6, de Grafana: gratis en tu computadora, y su nube gratuita incluye 500 horas de usuario virtual al mes.
Loader.io: el plan gratuito permite 10,000 clientes por prueba durante un minuto, lanzados desde servidores en Estados Unidos.

Un guion mínimo de k6 que visita la portada y tu producto más vendido:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 }, // sube a 50 visitantes simultáneos
    { duration: '5m', target: 50 }, // se sostiene
    { duration: '1m', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],     // menos del 1 % de errores
    http_req_duration: ['p(95)<2000'],  // el 95 % en menos de 2 segundos
  },
};

export default function () {
  check(http.get('https://tutienda.mx/'), { portada: (r) => r.status === 200 });
  sleep(3);
  check(http.get('https://tutienda.mx/producto/tu-mas-vendido/'), { producto: (r) => r.status === 200 });
  sleep(5);
}

Se corre con k6 run prueba.js. Tres reglas: prueba contra páginas, nunca contra tu pasarela de pagos; si estás en hosting compartido, avisa antes a tu proveedor, porque una prueba de carga se parece mucho a un ataque; y apunta a tres a cinco veces tu hora pico normal. No hay una cifra pública de cuánto sube el tráfico de una tienda chica en el Buen Fin frente a un día cualquiera; si tu analítica guarda el del año pasado, usa ese. Si la prueba falla con 50 visitantes, ya sabes lo que hay que arreglar, y tienes siete semanas para hacerlo.

Si tu tienda está en Shopify o Tiendanube

La infraestructura no es tu problema: Shopify atendió 489 millones de peticiones por minuto en su borde durante el Black Friday y el Cyber Monday de 2025, y su guía dice que la preparación especial solo hace falta si esperas «decenas de miles de clientes» empezando a pagar en pocos minutos. Lo tuyo son las otras cuatro secciones: el peso del tema y las apps que cargas en cada página, la pasarela y sus estados pendientes, la vigencia de las fichas en efectivo y el margen de inventario.

La lista para dos semanas antes

Qué	Cómo lo compruebas
Caché de HTML activa para visitantes	`cf-cache-status: HIT` en la segunda petición a una página de producto
Ninguna página manda `Set-Cookie` a visitantes	El mismo `curl -sI` de arriba
Carrito, pago y cuenta excluidos de la caché	Agrega algo al carrito en otra ventana y verifica que el contador se actualiza
Precios nuevos visibles	Purga la caché al activar las ofertas y revisa en modo incógnito
Fichas de efectivo con vigencia corta	Compra de prueba en OXXO que no pagas: al vencer, pedido cancelado e inventario de vuelta
Pagos «pendientes» tratados como pendientes	Compra de prueba con 3-D Secure que no completas
Cron real del servidor	`DISABLE_WP_CRON` en `wp-config.php` y tarea programada cada minuto
Margen en productos estrella	Inventario publicado por debajo del real
Certificado SSL vigente más allá del 17 de noviembre	Consulta SSL
Prueba de carga pasada	k6 o Loader.io sin errores a tres veces tu pico
Plan B de cobro	Link de pago y WhatsApp listos si la pasarela o el banco fallan

Si todavía no tienes tienda o sitio y quieres llegar al Buen Fin con algo que aguante, el último arranque para mi paquete de sitio para negocio con entrega antes del 13 de noviembre es el 20 de octubre. Y si lo que necesitas es cobrar y responder por WhatsApp sin que tu equipo conteste mensaje por mensaje, está el agente de WhatsApp para negocios.

Preguntas frecuentes

¿Cuándo es el Buen Fin 2026?

Del viernes 13 al martes 17 de noviembre de 2026. Es la edición 16 y dura cinco días porque incluye el lunes 16 de noviembre, día de descanso por el aniversario de la Revolución. El registro de negocios es gratuito en elbuenfin.org, del 8 de septiembre al 12 de noviembre.

¿Por qué se cae una tienda en línea en el Buen Fin?

Casi siempre porque cada visita llega al servidor sin caché y se agotan los procesos que permite el hosting. Un plan compartido tiene límites fijos (en Hostinger, 20 procesos PHP en el plan más básico; en HostGator México, 25 procesos por cPanel) y al pasarlos devuelve error 503. También fallan la pasarela de pagos cuando limita peticiones, o el banco del cliente, que no depende de ti.

¿Cloudflare gratis protege mi tienda del tráfico del Buen Fin?

Ayuda, pero no solo con activarlo. Cloudflare no guarda el HTML por defecto, así que sin una Cache Rule cada página sigue llegando a tu hosting. En el plan gratuito puedes crear hasta 10 reglas y con una basta para guardar las páginas de visitantes excluyendo carrito, pago y cuenta. La sala de espera virtual (Waiting Room) solo existe en los planes Business y Enterprise.

¿Un pago en OXXO pendiente aparta mi inventario?

Puede hacerlo por días. La ficha de Stripe vence en 5 días por defecto (configurable de 1 a 7) y la de Mercado Pago entre 1 y 30. En WooCommerce, los pedidos de pago diferido quedan en espera y la retención de inventario de 60 minutos solo cancela los pendientes de pago, así que la pieza queda apartada hasta que el plugin de la pasarela cancele el pedido al vencer la ficha. Acorta la vigencia durante la campaña y pruébalo con una compra que no pagues.

¿Cómo hago una prueba de carga de mi tienda en línea?

Con k6, gratuito y de código abierto, o con Loader.io, cuyo plan gratuito lanza hasta 10,000 clientes en una prueba de un minuto. Simula visitantes sobre la portada y tus productos más vendidos, nunca sobre la pasarela de pagos, apunta a tres a cinco veces tu hora pico y avisa antes a tu proveedor de hosting compartido, porque una prueba de carga se parece a un ataque.

¿Qué pasa si se cae el banco de mi cliente durante el Buen Fin?

Tu tienda funciona pero el cobro falla, y no puedes evitarlo: en el Buen Fin 2024 hubo reportes de fallas de Santander y BBVA, y en el Hot Sale 2026 BBVA confirmó una falla de varias horas. Lo que sí puedes hacer es ofrecer más de un método de pago (tarjeta, transferencia, efectivo en tiendas) y tener listo un link de cobro para mandar por WhatsApp.

Chrome quita XSLT: qué se rompe en sitemaps, feeds y visores de CFDI

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

Chrome 158 sale a estable el 17 de noviembre de 2026 y deja de ejecutar XSLT: se van XSLTProcessor y el procesamiento de <?xml-stylesheet type="text/xsl"?>. En la mayoría de los sitios eso cambia el adorno y nada más. El sitemap o el feed que un humano veía como tabla vuelve a verse como XML crudo, sin error y sin tocar el archivo. Donde sí se rompe código es en un rincón muy mexicano: los visores y validadores de CFDI que arman la cadena original en el navegador con la hoja XSLT del SAT. Ahí la función truena con ReferenceError: XSLTProcessor is not defined.

Las dos cosas las probé en Chrome 152 con el interruptor que apaga XSLT antes de tiempo. Para la parte del CFDI fui más lejos: generé la cadena original de un comprobante de prueba con cinco motores distintos y validé cada resultado contra el sello digital del propio XML. Una librería XSLT escrita en JavaScript da una cadena con la que el sello no verifica, el polyfill que recomienda Chrome falla si la hoja conserva sus includes, y la hoja del SAT tal como se publica ni siquiera corre en el navegador.

Las fechas

Todo sale del anuncio de Chrome for Developers y de la entrada en Chrome Platform Status, con las fechas de estable cotejadas en Chromium Dash:

Hito	Versión	Fecha
Avisos en la consola	Chrome 142	28-oct-2025
Deprecación oficial (consola y Lighthouse)	Chrome 143	2-dic-2025
Arranca el Origin Trial para seguir usándolo	Chrome 152	25-ago-2026
Beta de la versión que lo quita	Chrome 158	28-oct-2026
XSLT deja de funcionar en estable	Chrome 158	17-nov-2026
Se apagan el Origin Trial y la política empresarial `XSLTEnabled`	Chrome 176	17-ago-2027

Hay un detalle que acorta el plazo más de lo que parece: desde Chrome 153 (8 de septiembre) sale una versión estable cada dos semanas, no cada cuatro. Entre hoy y la 158 hay nueve semanas y cinco versiones.

¿Y Firefox y Safari? Van en la misma dirección, sin fecha. Mozilla tomó postura positiva y en su bug de seguimiento ya cerró el aviso en consola (Firefox 147) y una política empresarial (Firefox 151), pero apagarlo por defecto sigue abierto. WebKit se declaró “cautelosamente a favor” y dijo que probablemente esperaría a que un motor lo quite del todo. El estándar HTML ya lo marcó como deprecado el 25 de agosto de 2026. En la práctica, lo que diga Chrome 158 es lo que verá la mayoría de tus usuarios en noviembre.

Qué se rompe, qué ves y cómo se arregla

Qué usas	Qué pasa con Chrome 158	Arreglo
Sitemap XML con hoja XSL (WordPress core, Yoast, Rank Math, `xslURL` de `@astrojs/sitemap`)	El humano ve el visor de XML de Chrome en vez de la tabla. No hay error y el archivo servido no cambia	Nada, si nadie lo mira. Si importa, quita la instrucción o sirve una versión HTML aparte
Feed RSS/Atom con hoja XSL (`stylesheet` con `.xsl` en `@astrojs/rss`)	Abierto en el navegador, se ve XML crudo. Los lectores de feeds no lo notan	`<link rel="alternate" type="application/rss+xml">` en tu HTML, o el polyfill de una línea
JavaScript que llama `new XSLTProcessor()`	`ReferenceError: XSLTProcessor is not defined`	Mover la transformación al servidor, o un motor XSLT en JS/WASM
Visor o validador de CFDI que arma la cadena original en el navegador	La cadena no se genera, así que tampoco se puede verificar el sello	Servidor con ext-xsl, xslt-polyfill con la hoja aplanada, o SaxonJS (detalle abajo)
`<?xml-stylesheet type="text/css"?>`	Nada: sigue soportado	—
XSLT en tu servidor (PHP ext-xsl, Saxon, xsltproc)	Nada: esto solo afecta al navegador	—

Sitemaps y feeds: se rompe el adorno, no el archivo

Abrí el índice de sitemaps de yoast.com en Chrome 152 dos veces. Con XSLT activo, Chrome aplica la hoja y pinta una página titulada “XML Sitemap” con su tabla. Con --disable-features=XSLT, el mismo URL cae en el visor de XML de Chrome: el árbol de <sitemap>, <loc> y <lastmod> con la instrucción xml-stylesheet a la vista, sin estilos y sin error. Según el anuncio, Chrome además muestra un aviso que enlaza a extensiones cuando XSLT está apagado; en modo headless no lo pude ver.

Esto le va a pasar a mucha gente, porque la hoja XSL viene de fábrica en casi todo el ecosistema:

WordPress core agrega <?xml-stylesheet type="text/xsl" href=".../wp-sitemap.xsl" ?> a wp-sitemap.xml desde la 5.5. El ticket #65593 para quitarla está en el milestone de la 7.2, con el PR #12448 abierto y otra propuesta (#12584) que renderiza la versión HTML en el servidor. Al 13 de septiembre ninguno está fusionado.
Yoast SEO la sigue emitiendo en su trunk, que el changelog marca como 28.5 para el 15 de septiembre, y el sitemap del propio yoast.com la trae hoy.
Rank Math la sigue emitiendo en su trunk, y el sitemap de rankmath.com también la trae hoy.
Astro: @astrojs/sitemap tiene la opción xslURL y @astrojs/rss pone type="text/xsl" si le pasas un stylesheet que termina en .xsl. Ninguna viene activa por defecto.

¿Y Google?

No voy a escribir “Googlebot no se ve afectado” como si Google lo hubiera dicho: no encontré ninguna declaración de Google Search sobre XSLT y sitemaps. Lo que sí es verificable es que el cambio vive en el navegador. El servidor manda exactamente los mismos bytes antes y después del 17 de noviembre, y el anuncio de Chrome aclara que no retiran XML, solo XSLT. Un rastreador que ya leía tu sitemap sin ejecutar la hoja lo va a seguir recibiendo igual.

Qué hacer con el sitemap

Si ningún humano abre tu sitemap, no hagas nada. Si lo usas como página de consulta o te lo piden clientes, tienes tres caminos:

Quitar la instrucción. Te ahorras la petición al .xsl y los avisos de consola. En WordPress core hay filtros oficiales: si devuelven un valor falso, según el propio código, “se mostrará el XML crudo”:
```
// En un mu-plugin o en functions.php
add_filter( 'wp_sitemaps_stylesheet_url', '__return_false' );
add_filter( 'wp_sitemaps_stylesheet_index_url', '__return_false' );

// Yoast: el filtro se llama "url", pero recibe la declaración completa
add_filter( 'wpseo_stylesheet_url', '__return_empty_string' );
```
En Rank Math el filtro va por tipo de sitemap (rank_math/sitemap/{tipo}_stylesheet_url). En Astro basta con quitar xslURL o stylesheet.
Servir HTML aparte. Es lo que propone el PR #12584 de WordPress: la misma transformación, pero hecha en el servidor, publicada en una URL .html. El .xml queda para las máquinas.
CSS en lugar de XSL. <?xml-stylesheet type="text/css"?> sigue soportado, pero en el ticket de WordPress apuntaron el límite: con CSS le das estilo al XML, pero los <loc> no se vuelven enlaces en los que se pueda hacer clic.

Para feeds, la recomendación de Chrome es anunciar el feed con <link rel="alternate"> en el HTML en vez de enlazar el .xml a la vista, o agregar al feed una sola línea con el polyfill.

CFDI: donde sí truena código

Contexto para quien no factura en México: el CFDI es la factura electrónica del SAT, un XML firmado. La firma (el atributo Sello) no se calcula sobre el XML entero, sino sobre la cadena original: los valores del comprobante en un orden fijo, separados por |. Para verificar un sello necesitas esa cadena. Para mostrar la del timbre en una representación impresa, también.

El SAT publica la secuencia de esa cadena como hoja XSLT: en su página del Anexo 20, el documento “Secuencia de cadena original” enlaza a cadenaoriginal_4_0.xslt, con fecha de última modificación del 17 de abril de 2026. El timbre tiene la suya, cadenaoriginal_TFD_1_1.xslt. Tres detalles de ese archivo importan aquí:

Declara version="2.0", pero los navegadores solo implementan XSLT 1.0. Aun así funciona con procesadores 1.0: la documentación de CfdiUtils lo dice de PHP, que usa el mismo motor que Chrome (libxslt), y lo confirmé abajo en el navegador.
Trae 33 xsl:include (las utilerías y los complementos), todos con URL absoluta a http://www.sat.gob.mx.
La salida es texto plano (method="text").

Por eso generar la cadena en el navegador era tentador: XSLTProcessor venía incluido y el XML nunca salía de la máquina del usuario. Busqué código real que lo hace y encontré dos patrones:

Una librería npm de validadores y catálogos mexicanos, con versión publicada a finales de agosto de 2026, cuya función de cadena original usa new XSLTProcessor() si detecta window, y en Node recurre a un motor en JS. En Chrome 158 la detección sigue siendo verdadera (DOMParser no se va), así que entra por la rama del navegador y lanza el ReferenceError.
Un repositorio público de firma electrónica en JavaScript que carga cadenaoriginal_3_3.xslt desde un campo de archivo, lo guarda en localStorage y arma la cadena con XSLTProcessor.transformToDocument para verificar el sello de un CFDI 3.3.

La hoja del SAT no corre tal cual en el navegador

Esto lo encontré al probar y no lo vi documentado en ningún lado. Si le pasas a XSLTProcessor la hoja oficial, Chrome se niega a cargar los 33 includes (el URL de abajo es mi página de prueba):

Unsafe attempt to load URL http://www.sat.gob.mx/sitio_internet/cfd/2/cadenaoriginal_2_0/utilerias.xslt
from frame with URL http://localhost:8765/native.html. Domains, protocols and ports must match.

El resultado es null. O sea: quien hoy arma la cadena en el navegador con XSLTProcessor tiene que servir la hoja y sus includes desde su propio origen, o aplanados en un solo archivo. Eso ayuda a detectarlo, porque esa copia vive en tu repositorio y basta buscar cadenaoriginal.

Por qué el visor de CFDI de este sitio no se rompe

El visor de XML de CFDI 4.0 que escribí para este sitio, y que hoy vive en Siempre Contable, no usa XSLT, y no por suerte. Lee el XML con DOMParser, recorre Comprobante, Emisor, Receptor, Conceptos, Impuestos y el TimbreFiscalDigital, traduce los códigos del catálogo y comprueba la aritmética. No arma la cadena original ni valida el sello, y la herramienta lo dice en pantalla. DOMParser es una de las APIs que Chrome cita como el camino moderno para leer XML, así que no está en riesgo. Hice grep a todo el repositorio y no hay ni un XSLTProcessor ni un xml-stylesheet. Los sitemaps y el RSS del sitio tampoco llevan hoja. El servidor MCP mx-fiscal-mcp-server, que lee CFDI desde agentes de IA, corre en Node con @xmldom/xmldom y tampoco usa XSLT.

Las alternativas, probadas contra un sello real

Afirmar que “SaxonJS lo resuelve” es fácil. Para comprobarlo hice lo siguiente. Tomé cfdi40-valid.xml de la suite de pruebas de CfdiUtils, un CFDI 4.0 firmado con un certificado de pruebas del SAT. Generé la cadena con cada motor y la di por buena solo si el Sello del XML verifica contra ella con la llave pública de su propio Certificado:

# cert.pem = el atributo Certificado en base64, envuelto como PEM
# sello.bin = el atributo Sello decodificado de base64
openssl x509 -in cert.pem -pubkey -noout > pub.pem
openssl dgst -sha256 -verify pub.pem -signature sello.bin cadena.txt
# Verified OK  → la cadena es la correcta

La referencia fue Saxon-HE 12.5 (Java, licencia MPL 2.0) con la hoja oficial: Verified OK. Lo demás:

Motor	Dónde corre	Licencia	Resultado con la hoja del SAT
`XSLTProcessor` nativo, hoja oficial	Navegador	—	Falla: bloquea los includes de otro dominio
`XSLTProcessor` nativo, copia local	Navegador	—	`Verified OK`. Deja de existir en Chrome 158
xslt-polyfill 1.0.28, hoja aplanada en un solo archivo	Navegador (WASM)	BSD-3-Clause	`Verified OK` con XSLT nativo apagado
xslt-polyfill 1.0.28, copia con includes	Navegador (WASM)	BSD-3-Clause	Falla: `Error: Unknown mime type undefined`
SaxonJS 2.7 (`saxon-js` + `xslt3`), hoja compilada a SEF	Node; el SEF también corre en navegador según su documentación	Gratuita, no es open source	`Verified OK` en Node
xslt-processor 5.1.2	JS puro	LGPL-3.0	Cadena distinta y el sello no verifica

La cadena de xslt-processor empieza con ||||| (cinco barras en vez de dos). Con la hoja aplanada, la salida se reduce a tres barras. No lo descarto para otros usos, pero para la cadena original del SAT no sirve tal cual.

El fallo del polyfill con includes no es un bug suelto, está en su README: resuelve xsl:include con fetch(), que es asíncrono, y los métodos de XSLTProcessor son síncronos, así que fallan cuando la hoja tiene includes. Aplanar la hoja lo resuelve: sustituyes cada <xsl:include> por el contenido de la hoja incluida, en el mismo orden. En la hoja 4.0 actual no hace falta agregar espacios de nombres, porque la raíz principal ya declara todos los que usan los includes.

Opción 1: en el servidor (la más aburrida, y por eso la mejor)

ext-xsl de PHP sigue en el manual de PHP, montada sobre libxslt. La retirada de Chrome no la toca. Con CfdiUtils (eclipxe/cfdiutils, MIT, versión 3.0.4 del 11 de septiembre de 2026):

use CfdiUtils\XmlResolver\XmlResolver;
use CfdiUtils\CadenaOrigen\DOMBuilder;

// XmlResolver descarga los XSLT del SAT y reescribe sus dependencias a copias locales
$resolver = new XmlResolver();
$location = $resolver->resolveCadenaOrigenLocation('4.0');

$cadena = (new DOMBuilder())->build($xmlContent, $location);

Un aviso sobre algo que circula: CfdiUtils no construye la cadena sin XSLT. DOMBuilder es un XSLTProcessor de ext-xsl; también trae GenkgoXslBuilder (XSLT 2.0 en PHP) y SaxonbCliBuilder. Su autor explica que armarla sin XSLT se puede, pero es “mucho código para fabricar y testear” que además cambia con cada complemento.

Desde el navegador queda en una petición:

const res = await fetch('/api/cfdi/cadena-original', {
  method: 'POST',
  headers: { 'Content-Type': 'application/xml' },
  body: xmlText,
});
const cadena = await res.text();

El precio es de privacidad: si tu visor prometía “el XML no sale de tu navegador”, con esto deja de ser cierto y tienes que cambiar el texto.

Opción 2: seguir en el navegador con el polyfill

Si la promesa de procesar en local es el producto, xslt-polyfill reemplaza XSLTProcessor con libxslt compilado a WebAssembly. Pesa unos 1.4 MB minificado. Con la hoja aplanada, tu código existente no cambia:

<script src="/vendor/xslt-polyfill.min.js"></script>
<script>
  const xsl = new DOMParser().parseFromString(hojaAplanada, 'application/xml');
  const cfdi = new DOMParser().parseFromString(xmlText, 'application/xml');
  const p = new XSLTProcessor(); // el del polyfill si el navegador ya no trae XSLT
  p.importStylesheet(xsl);
  const cadena = p.transformToFragment(cfdi, document).textContent;
</script>

Mientras el navegador todavía tenga XSLT nativo, el polyfill no se instala. Si quieres probarlo hoy en tu Chrome actual, pon window.xsltUsePolyfillAlways = true antes de cargar el script.

Opción 3: SaxonJS

SaxonJS implementa las partes obligatorias de XSLT 3.0, que es de sobra para una hoja que declara 2.0. El flujo documentado es compilar la hoja a un archivo SEF y ejecutar ese SEF:

npx xslt3 -xsl:cadenaoriginal_4_0_plana.xslt -export:cadena.sef.json -nogo

import SaxonJS from 'saxon-js';

const { principalResult: cadena } = SaxonJS.transform({
  stylesheetFileName: 'cadena.sef.json',
  sourceText: xmlText,
  destination: 'serialized',
});

En mi prueba compilar tardó 2.4 s y el SEF pesó 3.65 MB. Ese tamaño cuenta si lo vas a mandar al navegador. Revisa la licencia antes de redistribuirlo: Saxonica la ofrece gratis, pero no es open source.

Cómo saber si dependes de XSLT

1. Busca en el código. Los aciertos en PHP, Java o .NET de servidor no te afectan; los de JavaScript que corre en el navegador sí:

grep -rnE "XSLTProcessor|transformToFragment|transformToDocument|importStylesheet|xml-stylesheet|cadenaoriginal" \
  --include=*.{js,mjs,ts,tsx,jsx,vue,svelte,astro,html,xml,php} \
  --exclude-dir={node_modules,vendor,.git} .
find . -name "*.xsl" -o -name "*.xslt" | grep -v node_modules

2. Busca en lo que compilaste. La librería npm del ejemplo esconde XSLTProcessor dentro de node_modules, así que el grep de arriba no la ve. Corre el mismo patrón sobre la carpeta de salida (dist/, build/, .next/, public/build/).

3. Revisa lo que sirves.

curl -s https://tusitio.com/wp-sitemap.xml | head -c 300 | grep -o 'xml-stylesheet[^?]*'
curl -s https://tusitio.com/feed/ | head -c 300 | grep -o 'xml-stylesheet[^?]*'

4. Pruébalo con XSLT apagado. No hace falta esperar a noviembre ni instalar Canary. En Chrome estable entra a chrome://flags/#xslt y ponlo en Disabled, o arranca Chrome con --disable-features=XSLT (lo verifiqué en Chrome 152). Para una comprobación sin interfaz:

chrome --headless=new --disable-features=XSLT --dump-dom \
  'data:text/html,<script>document.write(typeof XSLTProcessor)</script>'
# undefined  → así se verá tu app en Chrome 158

5. Deja que producción te avise. Chrome reporta la deprecación por la Reporting API con el id XSLT:

new ReportingObserver((reports) => {
  for (const r of reports) {
    if (r.body.id === 'XSLT') navigator.sendBeacon('/telemetria/xslt', r.body.sourceFile ?? '');
  }
}, { types: ['deprecation'], buffered: true }).observe();

Y abre la consola: desde Chrome 143 cada uso imprime “XSLTProcessor and XSLT Processing Instructions have been deprecated by all browsers”.

Quién tiene que actuar de verdad

Tienes un visor, validador o generador de PDF de CFDI que arma la cadena original en el navegador: eres el público de este post. Tienes hasta el 17 de noviembre. Decide entre servidor (y cambia el aviso de privacidad) o polyfill con hoja aplanada, y valida contra un sello real como arriba antes de publicar.

Usas XSLTProcessor para cualquier otra cosa en el front: mismo plazo, mismas opciones. Si no puedes migrar a tiempo, el Origin Trial te da hasta agosto de 2027. Si lo que usa XSLT es un documento XML, no hay <head> donde poner la meta, así que el token va en la cabecera HTTP Origin-Trial.

Tienes un sitio WordPress, Yoast, Rank Math o Astro con sitemap estilizado: no se rompe nada que importe para indexar. Quita la instrucción si te molesta el aviso, o sirve HTML aparte si alguien consulta ese sitemap.

Tu empresa usa una app interna o un equipo que sirve XML con XSL y no puedes tocar: la política empresarial XSLTEnabled y la extensión que recomienda Chrome son para ti. La política caduca en agosto de 2027. La extensión aplica el polyfill, así que no depende del XSLT nativo.

Solo generas la cadena en PHP, Java o .NET en el servidor: no te toca. Esto es del navegador.

Para seguir leyendo:

mx-fiscal-mcp-server: la ficha del servidor MCP open source para leer CFDI 4.0 y validar RFC, CURP y CLABE desde agentes de IA.
Mejores servidores MCP para SEO en 2026: si auditas sitemaps con agentes, ahí está qué herramienta hace qué.
SEO para WordPress en 2026: la guía completa de Yoast y Rank Math, donde vive el sitemap del que hablamos.

Preguntas frecuentes

¿Cuándo quita Chrome el soporte de XSLT?

En Chrome 158, que sale a estable el 17 de noviembre de 2026. Desde esa versión dejan de funcionar XSLTProcessor y el procesamiento de las instrucciones xml-stylesheet con type="text/xsl", salvo para sitios inscritos en el Origin Trial y equipos con la política empresarial XSLTEnabled. Ambas excepciones se apagan en Chrome 176, el 17 de agosto de 2027. La beta de Chrome 158 sale el 28 de octubre de 2026.

¿Se rompe mi sitemap XML con hoja XSL en Chrome 158?

El archivo no. Lo que cambia es cómo lo ve una persona en Chrome: en vez de la tabla generada por la hoja XSL aparece el visor de XML crudo del navegador, sin error. Lo probé en Chrome 152 con XSLT apagado sobre el índice de sitemaps de yoast.com. El servidor sigue mandando exactamente los mismos bytes. Google no ha publicado nada específico sobre XSLT y sitemaps, pero el cambio es solo del navegador y no del documento XML.

¿Cómo quito la hoja XSL del sitemap de WordPress?

En WordPress core, con los filtros wp_sitemaps_stylesheet_url y wp_sitemaps_stylesheet_index_url devolviendo false, por ejemplo con __return_false; el propio código dice que así se muestra el XML crudo. En Yoast, el filtro wpseo_stylesheet_url recibe la declaración completa y puedes devolver una cadena vacía. En Rank Math el filtro va por tipo: rank_math/sitemap/{tipo}_stylesheet_url. WordPress core tiene abierto el ticket 65593 para quitar la hoja en la versión 7.2.

¿Por qué se rompen los visores de CFDI que usan XSLT en el navegador?

Porque la cadena original del CFDI 4.0 la define el SAT con la hoja cadenaoriginal_4_0.xslt, y la forma cómoda de ejecutarla en el navegador era XSLTProcessor. En Chrome 158 esa clase deja de existir y el código lanza ReferenceError: XSLTProcessor is not defined. Sin cadena original no se puede verificar el sello digital del comprobante. Leer el XML con DOMParser, como hace el visor de CFDI de este sitio, sigue funcionando.

¿Qué alternativa genera bien la cadena original del SAT sin XSLT del navegador?

Probé varias contra el sello de un CFDI 4.0 de prueba. Dieron la cadena correcta Saxon-HE en Java, SaxonJS 2.7 con la hoja compilada a SEF y xslt-polyfill 1.0.28 en el navegador con la hoja aplanada en un solo archivo. xslt-polyfill falla si la hoja conserva sus 33 xsl:include, y xslt-processor 5.1.2 produjo una cadena distinta con la que el sello no verifica. En servidor, PHP con ext-xsl, que es lo que usa CfdiUtils, no se ve afectado.

¿CfdiUtils genera la cadena original sin XSLT?

No. Su DOMBuilder usa XSLTProcessor de la extensión ext-xsl de PHP con la hoja del SAT, y también ofrece GenkgoXslBuilder y SaxonbCliBuilder. Su documentación aclara que la hoja declara XSLT 2.0 pero la transformación con PHP da el resultado esperado. Como corre en el servidor, la retirada de XSLT en Chrome no le afecta.

¿Cómo pruebo hoy mi sitio como si ya fuera Chrome 158?

En Chrome estable, entra a chrome://flags/#xslt y ponlo en Disabled, o arranca el navegador con --disable-features=XSLT. Con eso typeof XSLTProcessor devuelve undefined y los XML con hoja XSL se muestran en crudo. Para detectar usos en producción, registra un ReportingObserver de tipo deprecation y filtra los reportes con id XSLT.

GitHub Actions en otoño de 2026: qué se rompe (y por qué node20 no es el problema)

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

El 23 de septiembre de 2026 GitHub quita Node 20 de los runners de Actions, y casi todo el mundo lo está leyendo como «mis actions con using: node20 van a fallar». No van a fallar. Desde el 16 de junio el runner ya reescribe node20 a node24 antes de ejecutar, y lo mismo hace con node12 y node16. Lo que se quita el 23 es la salida de emergencia: la variable ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION deja de funcionar.

Eso invierte quién está en riesgo. Si tu CI lleva verde desde junio sin esa variable, el 23 no te cambia nada en los runners de GitHub. Los que se rompen son justo los que ya se toparon con una action que no aguanta Node 24, pusieron la variable para seguir avanzando y dejaron el arreglo para después. Y alrededor de esa fecha hay otras cuatro con consecuencias reales: la versión mínima de los runners self-hosted (25 de septiembre), la retención de checks y ejecuciones (1 de octubre), los apagones de macos-14 (octubre) y su retiro (2 de noviembre).

Lo verifiqué contra el código fuente del runner y contra el CI de este mismo sitio, que usa dos actions node20. Abajo va todo con su fuente.

El calendario, por fecha

Fecha	Qué cambia	Qué se rompe	Cómo lo detectas
14, 16 y 18 sep (11:00-15:00 ET, 9:00-13:00 en CDMX)	Apagones previos a la versión mínima de runners self-hosted	Los runners desactualizados no se registran ni ejecutan jobs durante la ventana	API de deprecaciones del runner (abajo)
17 sep	`ubuntu-22.04` y `ubuntu-22.04-arm` entran en deprecación	Nada falla todavía; puede haber colas más largas	`grep` de la etiqueta
21-30 sep	`windows-11-arm` pasa a la imagen con Visual Studio 2026	Cambia la cadena de herramientas por debajo	`grep windows-11-arm`
23 sep	Node 20 sale de los runners	`ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION` se ignora; runners Linux ARM32 sin soporte	`grep` de la variable
25 sep	Se aplica la versión mínima de runners self-hosted	Registrar exige ≥ 2.329.0; un runner que no instala cada versión en 30 días deja de recibir jobs	API de deprecaciones
1 oct	La retención de Actions pasa a cubrir checks, ejecuciones y statuses	Lo que pase tu periodo de retención (90 días por defecto) se borra	Ajuste de retención del repo/org
5-31 oct	Ocho apagones de `macos-14`	Los jobs programados en la ventana fallan	`grep macos-14`
2 nov	`macos-14` retirado	Los jobs con esa etiqueta terminan con error	`grep macos-14`
17 abr 2027	`ubuntu-22.04` retirado (apagones antes, en marzo y abril)	Los jobs terminan con error	`grep` de la etiqueta

1. Node 20: qué pasa de verdad el 23 de septiembre

Lo que dice el aviso

El changelog de GitHub del 19 de septiembre de 2025, con una nota del editor del 25 de agosto de 2026, fija dos fechas: desde el 16 de junio de 2026 los runners usan Node 24 por defecto, y la variable ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true para volver a Node 20 «solo funcionará hasta que actualicemos el runner y quitemos Node20 el 23 de septiembre de 2026». Añade dos límites de plataforma: Node 24 es incompatible con macOS 13.4 y anteriores, y no tiene soporte oficial para ARM32.

Lo que el aviso no explica es qué le pasa a una action cuyo action.yml sigue diciendo using: node20. Eso está en el código.

Lo que dice el código del runner

En HandlerFactory.cs (igual en la etiqueta v2.337.0, la versión actual), el runner hace dos cosas antes de lanzar una action de JavaScript:

Si la action declara node12 o node16, la sube a node20.
Si queda en node20, le pregunta a NodeUtil.DetermineActionsNodeVersion qué versión usar.

Y esa función tiene tres fases, controladas por feature flags del lado de GitHub:

// Phase 3: Always use Node 24 regardless of environment variables
if (requireNode24)
{
    return (Constants.Runner.NodeMigration.Node24, null);
}
// ...
// Phase 2: Node 24 is the default
if (useNode24ByDefault)
{
    if (allowUnsecureNode)
    {
        return (Constants.Runner.NodeMigration.Node20, null);
    }
    return (Constants.Runner.NodeMigration.Node24, null);
}

El PR #3948 que introdujo esto lo describe sin rodeos: en la fase 3, «todas las actions usan Node 24» y «no hay opciones de exclusión». Ninguna rama devuelve un error por declarar node20. La action se ejecuta con otro Node, que es muy distinto de no ejecutarse.

Fíjate también en el orden: node12 → node20 → node24. Una action vieja con using: node16 (por ejemplo actions/checkout@v3) acaba igualmente en Node 24.

La prueba: el CI de este sitio

El workflow de CI de este blog usa actions/checkout@v4 y actions/setup-node@v4. Los action.yml oficiales de esas etiquetas declaran using: node20; los de v5 en adelante declaran node24 (lo comprobé en las etiquetas v4 a v7 de las dos). La ejecución del 11 de septiembre, en el runner 2.337.0 sobre la imagen ubuntu-24.04, terminó en verde con esta anotación:

Node.js 20 is deprecated. The following actions target Node.js 20 but are being
forced to run on Node.js 24: actions/checkout@v4, actions/setup-node@v4.

Y en el log de los pasos de esas dos actions, esta línea:

Node 20 is being deprecated. This workflow is running with Node 24 by default.
If you need to temporarily use Node 20, you can set the
ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true environment variable.

La misma anotación sale desde la primera ejecución de ese workflow, el 23 de agosto. Es decir: mis dos actions node20 nunca han corrido en Node 20 en este CI, y yo no toqué nada para eso. El 23 de septiembre no les cambia el runtime, porque el cambio ya ocurrió en junio. Actualizarlas a v5 o superior quita la anotación, y conviene hacerlo, pero no hay reloj.

Cómo se ve cuando sí se rompe

Hay tres formas reales de fallar, y ninguna es un mensaje de GitHub que diga «Node 20 ya no existe».

Tenías la variable puesta. Alguna action tuya tropezó con Node 24 después del 16 de junio, pusiste ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true y siguió en Node 20. En la fase 3 el runner ignora la variable sin avisar: la rama de requireNode24 devuelve null como mensaje. La action vuelve a Node 24 y el error que ves es el de su propio código, el mismo que viste la primera vez. Una pista de que la fase 3 ya está activa: con el código actual del runner, la línea «If you need to temporarily use Node 20…» deja de salir en el log, porque solo se imprime cuando Node 24 es el valor por defecto pero todavía no es obligatorio.

La action usa algo que Node 24 eliminó. Según la tabla de deprecaciones de Node 24 y las notas de la 24.0.0, llegaron a fin de vida en esa versión:

API	Estado en Node 24	Cómo falla
`tls.createSecurePair()`	Eliminada (DEP0064)	`TypeError: ... is not a function` al llamarla
`fs.truncate()` con un descriptor de archivo	Eliminado (DEP0081)	Lanza `ERR_INVALID_ARG_TYPE`: espera una ruta. Usa `fs.ftruncate()`
`dirent.path`	Eliminada (DEP0178)	No lanza por sí sola: la propiedad ya no existe y lees `undefined`. Usa `dirent.parentPath`
`OutgoingMessage.prototype._headers` / `_headerNames`	Eliminadas (DEP0066)	Lees `undefined`. Usa `getHeaders()`

El caso de dirent.path es el más traicionero de la lista, porque leerla no lanza nada: el fallo aparece más adelante, donde se use esa ruta, o nunca, si solo se concatena en un texto y sale undefined/archivo. Si mantienes una action que recorre directorios, busca esa propiedad antes de fiarte del check verde.

Tu runner self-hosted no puede ejecutar Node 24. En Linux ARM32, el mismo NodeUtil.cs tiene un interruptor de apagado que hace fallar el paso con:

Linux ARM32 runners are no longer supported. Please migrate to a supported platform.

Antes de que se active, el runner mantiene esas actions en Node 20 con un aviso que usa como fecha por defecto la de la retirada de Node 20: «Linux ARM32 runners are deprecated and will no longer be supported after September 23rd, 2026». GitHub no ha publicado el día exacto en que se activa; el changelog dice que ARM32 deja de tener soporte tras la deprecación de Node 20. En macOS, el BUILDING.md de Node 24 exige macOS 13.5 o superior.

2. La auditoría: qué buscar y dónde

En un repositorio

Corre esto desde la raíz:

# 1. El interruptor que deja de funcionar el 23 de septiembre
grep -rn 'ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION' .github/

# 2. Etiquetas de imagen con fecha. Sin "runs-on:" a propósito:
#    así también aparecen las matrices (os: [ubuntu-22.04, ...])
grep -rnE 'ubuntu-22\.04|macos-14|windows-11-arm' .github/

# 3. Actions propias o locales que declaran un Node viejo
grep -rnE --include=action.yml --include=action.yaml \
  "using:[[:space:]]*['\"]?node(12|16|20)" .

La búsqueda 2 tiene un punto ciego: runs-on: ${{ vars.RUNNER }} o una etiqueta que llega como input a un workflow reutilizable no aparece en ningún grep. Para esos casos, la fuente de verdad es el log. El paso «Set up job» imprime la imagen real:

gh run view <run-id> --log | grep -m1 'Image:'
# Image: ubuntu-24.04

Si la matriz es larga o viene anidada, pasarla a JSON y filtrarla con jq suele ser más rápido que leer el YAML a ojo:

Para saber qué runtime declara cada action de terceros que usas, incluidas las fijadas por SHA, hay que leer su action.yml en esa referencia exacta. Este script lo hace con gh:

grep -rhoE "uses:[[:space:]]*['\"]?[^[:space:]'\"#]+@[^[:space:]'\"#]+" .github/ \
  | sed -E "s/uses:[[:space:]]*['\"]?//" | sort -u \
  | while read -r ref; do
      spec=${ref%@*}; ver=${ref#*@}
      case "$spec" in ./*|docker://*) continue ;; esac
      repo=$(cut -d/ -f1-2 <<<"$spec"); sub=$(cut -d/ -f3- <<<"$spec")
      for f in action.yml action.yaml; do
        rt=$(gh api "repos/$repo/contents/${sub:+$sub/}$f?ref=$ver" --jq .content 2>/dev/null \
             | base64 -d | grep -E '^[[:space:]]*using:' | tr -d " '\"" | cut -d: -f2)
        [ -n "$rt" ] && { echo "$rt  $ref"; break; }
      done
    done

En este repo imprime:

node20  actions/checkout@v4
node20  actions/setup-node@v4

Soporta subrutas (github/codeql-action/init@v3) y SHAs. Un SHA que apunta a una versión node20 no falla el 23 por lo mismo que no falla @v4: el runner la fuerza a Node 24. Lo que cambia con un SHA es cómo lo actualizas: no recibe nada solo, tiene que moverlo Dependabot o una persona.

Un aviso antes de subir de major: lee las notas de versión. actions/setup-node v5 activó caché automática cuando package.json trae el campo packageManager, y la v6 la limitó a npm. Si ya pasas cache: npm explícito, como en mi CI, no te afecta.

En una organización

La búsqueda de código de GitHub llega a todos los repos de una vez:

gh search code --owner TU_ORG 'ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION'
gh search code --owner TU_ORG 'ubuntu-22.04 path:.github/workflows'
gh search code --owner TU_ORG 'macos-14 path:.github/workflows'
gh search code --owner TU_ORG node20 --filename action.yml

Dos límites de la API de búsqueda de código que te van a morder: solo busca en la rama por defecto (un workflow en una rama de release no sale) y permite 10 peticiones por minuto. Preparando este post me topé con HTTP 403: API rate limit exceeded en cuanto encadené unas cuantas búsquedas; mete un sleep entre ellas si lo vas a automatizar.

3. Runners self-hosted: dos fechas en tres días

Si solo usas runners de GitHub, salta esta sección. Si tienes los tuyos, el 25 de septiembre pesa más que el 23.

El changelog del 12 de junio retoma la aplicación de dos reglas en github.com:

Para registrar (o volver a registrar) un runner hace falta la versión 2.329.0 o superior.
Para seguir ejecutando jobs, el runner tiene que instalar cada versión nueva en menos de 30 días desde su publicación. «Un runner fijado en 2.329.0 que nunca se actualiza no recibirá jobs».

La aplicación completa empieza el 25 de septiembre de 2026 (la tabla del aviso rotula esa fecha como GitHub Enterprise Cloud, y el mismo aviso aclara que el cambio aplica a github.com), con apagones antes: los días 14, 16 y 18 de septiembre, de 11:00 a 15:00 hora del Este (9:00 a 13:00 en la Ciudad de México), los runners fuera de versión ni se registran ni ejecutan. Lo que ves, según el aviso, es que el workflow «puede quedarse en cola o fallar».

La forma de saber cuándo caduca tu versión es un endpoint que GitHub añadió el 3 de septiembre. Lo consulté hoy:

gh api repos/OWNER/REPO/actions/runners/deprecations/2.335.1
# {"runner_version":"2.335.1","runtime_deprecates_at":"2026-09-24T15:30:55Z"}

gh api repos/OWNER/REPO/actions/runners/deprecations/2.337.0
# {"runner_version":"2.337.0","runtime_deprecates_at":null}

Un runner en 2.335.1 queda fuera de plazo el 24 de septiembre, así que cuando empiece la aplicación completa, el 25, ya no recibe jobs. La versión instalada la sacas en la propia máquina con ./config.sh --version.

El checklist para self-hosted, en orden:

Actualiza el runner a la versión actual y deja activada la actualización automática. Si la tienes apagada, necesitas una cadencia manual de menos de 30 días.
Rehaz las imágenes, plantillas de VM y contenedores con los que creas runners. El changelog pide rehacer los que salen de imágenes o plantillas viejas: si la imagen trae un runner anterior a 2.329.0, no se registra.
Linux ARM32: migra a arm64. Node 24 no tiene soporte oficial ahí, el paquete del runner para linux-arm solo trae el binario de Node 20 (externals.sh) y el código que hace fallar el paso ya está en el runner.
macOS 13.4 o anterior: actualiza el sistema operativo. GitHub declara Node 24 incompatible con esas versiones.
Las actions que ya declaran node24 (como actions/checkout@v5) piden como mínimo el runner v2.327.1. Si cumples el punto 1, esto ya lo tienes.

4. Retención, 1 de octubre: el historial se borra

Este cambio no rompe ningún build, pero borra datos. Según el changelog del 27 de agosto, desde el 1 de octubre de 2026 los checks, las ejecuciones de workflows y los statuses siguen el mismo ajuste de retención que ya controlaba los artefactos y los logs, 90 días por defecto. Hasta ahora se guardaban «400+ días» sin importar lo que configuraras.

En repositorios públicos el máximo es 90 días.
El cambio no es retroactivo: subir la retención después no recupera nada.
Los metadatos de checks y ejecuciones no se cobran como almacenamiento; los artefactos y logs asociados sí.

Lo que se rompe es todo lo que lea ese historial más allá de tu periodo: métricas de despliegue calculadas desde gh run list, auditorías que enlazan a una ejecución concreta o reportes trimestrales. Exporta lo que necesites antes del 1 de octubre.

Lo que el changelog no dice: qué pasa con un pull request abierto más de 90 días cuyo check requerido caduca. No lo encontré documentado. Si tienes PRs de larga vida con protección de rama, revísalos después del 1 de octubre antes de dar nada por hecho.

5. Imágenes: macos-14 sí tiene fecha, ubuntu-22.04 todavía no

macos-14 (actions/runner-images#13518): la deprecación empezó el 6 de julio y el soporte termina el 2 de noviembre de 2026. Antes hay ocho apagones en los que los jobs fallan: 5, 12, 16, 19, 23, 26, 29 y 30 de octubre, cada uno de 14:00 UTC a 00:00 UTC del día siguiente. Afecta a macos-14, macos-14-large y macos-14-xlarge. El reemplazo es macos-15, macos-26 o macos-latest, que con la migración iniciada el 15 de junio pasó a apuntar a macOS 26.

ubuntu-22.04 (actions/runner-images#14254): el 17 de septiembre solo empieza la deprecación. El issue avisa de colas más largas en horas pico, no de fallos. El retiro es el 17 de abril de 2027, con apagones previos que el issue fecha en marzo y abril (sin año, pero caen antes del retiro). Afecta también a ubuntu-22.04-arm. El reemplazo es ubuntu-24.04, ubuntu-26.04 o ubuntu-latest.

Si alguien te dice que ubuntu-22.04 se rompe esta semana, no es cierto. Migra con calma, pero no lo dejes para marzo.

Lo que sale en el changelog y no rompe nada

cache-mode (10 de septiembre): una clave nueva para limitar el acceso a la caché por workflow o job. Es opcional: los workflows que no la declaran «siguen usando los valores seguros existentes».
La ruta separada de Code Quality (20 de agosto): solo te afecta si tienes reportes que filtran por dynamic/github-code-scanning/codeql o por el actor github-advanced-security.
actions/checkout y pull_request_target (18 de junio): esto sí rompe, pero ya pasó. Desde el 20 de julio las etiquetas flotantes, @v4 incluida, rechazan hacer checkout del código de un fork en pull_request_target. Si tu workflow dependía de eso, ya está en rojo. Es la misma familia de riesgo que conté en el gusano que se coló por el trusted publishing de npm.

Qué hago con mi CI

Nada urgente. actions/checkout@v4 y actions/setup-node@v4 corren en Node 24 desde junio, el workflow no usa la variable de exclusión, corre en ubuntu-latest (hoy ubuntu-24.04) y en runners de GitHub. El 23 de septiembre no le cambia nada.

Sí voy a subir las dos actions a su major actual, por dos razones que no tienen que ver con la fecha: la anotación amarilla entrena a ignorar las anotaciones, y una action que su autor ya no prueba en el runtime donde de verdad se ejecuta es deuda. Si además estás pensando en el Node de tu propio proyecto, no el de las actions, lo tengo contado en qué se rompe al actualizar a Node 26.

Preguntas frecuentes

¿Qué pasa con GitHub Actions el 23 de septiembre de 2026?

GitHub quita Node 20 de los runners. Desde el 16 de junio de 2026 los runners ya ejecutaban las actions con Node 24 por defecto, y la variable ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true permitía volver a Node 20. A partir del 23 de septiembre esa variable deja de funcionar y todas las actions de JavaScript corren en Node 24. Los runners self-hosted en Linux ARM32 pierden soporte, porque Node 24 no tiene soporte oficial para esa plataforma.

¿Falla una action que declara using: node20 después del 23 de septiembre?

No por declararlo. El código del runner (HandlerFactory.cs y NodeUtil.cs en actions/runner) reescribe node12 y node16 a node20, y node20 a node24; en la fase final ignora las variables de entorno y siempre elige Node 24, sin devolver error. La action falla si su código usa algo que Node 24 eliminó, como tls.createSecurePair o fs.truncate con un descriptor, o si corre en un runner self-hosted Linux ARM32 o con macOS 13.4 o anterior. En los logs aparece la anotación: The following actions target Node.js 20 but are being forced to run on Node.js 24.

¿Tengo que actualizar actions/checkout@v4 y actions/setup-node@v4?

Conviene, pero no hay fecha que lo obligue. Las etiquetas v4 de las dos declaran node20 y las v5 en adelante declaran node24. En runners de GitHub, las v4 ya corren en Node 24 desde junio y siguen funcionando. Al subir setup-node, revisa las notas de versión: la v5 activó caché automática cuando package.json tiene packageManager y la v6 la limitó a npm.

¿Cómo encuentro en mi organización los workflows afectados?

Con la búsqueda de código de GitHub: gh search code --owner TU_ORG con ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION, con ubuntu-22.04 path:.github/workflows, con macos-14 path:.github/workflows, y con node20 --filename action.yml para tus actions propias. La API solo busca en la rama por defecto y permite 10 peticiones por minuto. Las etiquetas que llegan por variables o expresiones no aparecen en ninguna búsqueda: para esas, revisa la línea Image: del paso Set up job en el log.

¿Se rompe ubuntu-22.04 el 17 de septiembre de 2026?

No. El 17 de septiembre solo empieza la deprecación y el aviso habla de colas más largas en horas pico. Los jobs empiezan a fallar en los apagones que el issue 14254 de actions/runner-images programa para marzo y abril, antes de que la imagen se retire el 17 de abril de 2027. La que sí tiene fecha este otoño es macos-14: apagones en octubre y retiro el 2 de noviembre de 2026.

¿Qué tienen que hacer los runners self-hosted antes del 25 de septiembre?

Actualizar el runner. Desde el 25 de septiembre de 2026 GitHub exige la versión 2.329.0 para registrar un runner y que se instale cada versión nueva en menos de 30 días para seguir recibiendo jobs. Hay apagones previos el 14, 16 y 18 de septiembre, de 11:00 a 15:00 hora del Este. El endpoint GET /repos/OWNER/REPO/actions/runners/deprecations/VERSION devuelve cuándo deja de ejecutar tu versión. Rehaz también las imágenes con las que creas runners.

¿Qué cambia con la retención de GitHub Actions el 1 de octubre de 2026?

Los checks, las ejecuciones de workflows y los statuses pasan a seguir el ajuste de retención de artefactos y logs, que por defecto es de 90 días; antes se guardaban más de 400 días. En repositorios públicos el máximo es 90 días y el cambio no es retroactivo. Si tienes métricas o auditorías que leen ejecuciones antiguas, exporta los datos antes de esa fecha.

Portainer 3.0: qué cambia si administras Docker (y a qué alternativa pasarte)

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

Portainer 3.0 no rompe tu servidor Docker a fin de mes. Lo que se acaba es otra cosa: no habrá Community Edition de la rama 3.x. Lo escribió el propio CEO, Neil Cresswell, en el anuncio oficial del 11 de septiembre de 2026: CE “seguirá en la base de código 2.x” y “no recibirá los cambios de 3.x”. La 3.x será gratis para la comunidad solo mediante el programa 3 Nodes Free, que es una licencia de Business Edition. Y 3.x es, en sus palabras, una base de código “Kubernetes-first”.

Si administras Docker —no Kubernetes— con Portainer CE, la decisión no corre prisa, pero hay que tomarla: quedarte en 2.x mientras dure, pedir la licencia gratuita de tres nodos y aceptar un producto pensado para Kubernetes, o salirte. Aquí van los hechos verificados en fuente primaria, qué se rompe en cada camino y qué elegir según tu caso. Yo corro Coolify en producción en dos VPS, así que al final también cuento lo que me ha mordido.

Lo que dice el anuncio, sin adornos

Tema	Lo que publicó Portainer
Última 2.x	2.45 LTS (release `2.45.0` en GitHub, 27 de agosto de 2026) es la última versión de la rama 2.x
3.0	Sale como 3.0.0 STS “desde finales de este mes”; la siguiente LTS será la 3.3.0, en diciembre
Enfoque	3.x es Kubernetes-first: mantener Docker/Podman, Swarm y Kubernetes a la par en una sola base de código “ya no es viable”
Entornos Docker, Swarm y Podman nativos	Se pueden seguir agregando y “siguen funcionando”, pero quedan en segundo plano en la interfaz y no recibirán capacidades nuevas del motor de políticas, de GitOps ni de observabilidad
Productos nuevos	Portainer-Run, IDP, Command y AiGrid son solo para Kubernetes
Si te quedas en 2.x	“No cambia nada”: siguen las actualizaciones de seguridad, la corrección de bugs y back-ports selectivos de 3.x
Community Edition	Sigue en 2.x. No habrá build CE de 3.x; la 3.x es gratis vía 3 Nodes Free
Recomendación oficial	Migrar de Docker a D2K (un Docker sintético sobre Kubernetes) o a Kubernetes nativo; KubeSolo para un solo nodo

Lo de Reddit: “desaparece CE y solo queda Business gratis hasta 3 nodos”

Esa lectura circuló en r/selfhosted. Es correcta para la rama 3.x y se queda corta en todo lo demás. Esto es lo que confirma la fuente primaria:

Cierto: no habrá edición CE de 3.x, y la forma gratuita de usar 3.x es 3 Nodes Free. La página del programa dice que es una licencia de Business Edition, que la mandan tras llenar un formulario y que está “limitada a una licencia por organización”.
Incompleto: CE no desaparece mañana. Sigue en la rama 2.x, el repositorio portainer/portainer mantiene su licencia zlib y la política de ciclo de vida da a la 2.45 LTS mantenimiento hasta mayo de 2027.
El matiz que casi nadie menciona: la licencia de tres nodos caduca y hay que renovarla. La documentación dice que la llave nueva no llega hasta 14 días antes de que venza la actual. CE no pedía formulario ni renovación.
Qué cuenta como nodo: según la FAQ de licencias, en Docker cuenta cualquier servidor que ejecute Portainer Server o el Agent. Tres hosts Docker (uno con el server y dos con agente) son tres nodos: ya agotaste la cuota gratuita.

Un aviso sobre esa fecha de mayo de 2027: la misma página de ciclo de vida todavía anuncia una 2.46 STS para septiembre y una 2.51 LTS para febrero de 2027, algo que el anuncio contradice, porque la 2.45 es la última 2.x. La tabla no se ha actualizado desde el anuncio, así que toma mayo de 2027 como la fecha publicada, no como una garantía. El anuncio no le pone fecha de fin a la rama 2.x.

Qué se rompe (y qué no) en cada camino

Camino 1: te quedas en Portainer CE 2.45

Hoy no se rompe nada. Pero hay dos cosas que conviene hacer esta semana.

Fija la versión exacta de la imagen. En Docker Hub, las etiquetas lts, sts y latest de portainer/portainer-ce se actualizaron por última vez el 27 de agosto, con la 2.45.0. No encontré documentado a qué van a apuntar cuando salga la 3.0 STS, así que si usas Watchtower o algo parecido, no dejes que una etiqueta flotante decida por ti:

services:
  portainer:
    image: portainer/portainer-ce:2.45.0   # no :latest ni :sts

Asegúrate de estar en 2.45.0 (o en 2.39.7 si sigues en la LTS anterior). Las notas de la 2.45.0 corrigen un bypass crítico de autorización en el proxy de Docker: los prefijos de versión de API no reconocidos, como /v1.47.0/, se saltaban el control de acceso y dejaban a usuarios sin permisos de administrador hablar directo con la API de Docker. La 2.39.7 LTS recibió el mismo arreglo el mismo día.

Para ver qué imagen estás corriendo:

docker ps --filter name=portainer --format '{{.Image}}'

Si te quedas, pierdes las funciones nuevas y ganas tiempo para decidir.

Camino 2: pasas a 3.x con la licencia de 3 nodos

Tus entornos Docker nativos siguen funcionando; en eso el anuncio es explícito. Lo que cambia son las condiciones: una licencia Business que caduca, un tope de tres nodos, un producto cuya hoja de ruta ya no incluye a Docker y una 3.0 que sale como STS (la LTS llega en diciembre con la 3.3.0). Si administras más de tres hosts, este camino es de pago.

Tiene un lado bueno si tu Portainer lo usan varias personas: el control de acceso por roles (RBAC) es de Business Edition, según la documentación de roles, así que con 3 Nodes Free lo tendrías.

Camino 3: sigues la recomendación de Portainer y migras a D2K

Aquí sí se rompen cosas, y no por un bug, sino por diseño. D2K (licencia MIT) expone la API de Docker y traduce cada llamada a objetos de Kubernetes dentro de un namespace. Su propio README enumera lo que no soporta y aclara que “no se añadirá”:

Lo que usas hoy en Docker	Qué pasa en D2K
`build:` en tu compose	Se ignora: las imágenes tienen que llegar ya construidas desde un registro
`docker build`, `docker load`, `docker save`, `buildx`	No soportados
Redes `macvlan` / `ipvlan`	No soportadas: esas cargas “deben quedarse en un host Docker nativo”
`--network host`, `--ip`, `--mac-address`, `--link`	Sin equivalente
Redes separadas por stack	`docker network create` es sintético: no se aplica aislamiento de red y todos los pods comparten la red del namespace
Bind mounts como `./data:/app/data`	Se convierten en `hostPath`, “poco fiables” en clústeres de varios nodos
`--device` (por ejemplo `/dev/video0`), `--ulimit`	Sin traducción
`docker stats`	Necesita metrics-server para devolver datos reales

Si tu compose construye la imagen en el mismo servidor, si aíslas la base de datos en una red interna o si tienes algo con network_mode: host, D2K no es una migración: es un rediseño. Y debajo sigue habiendo un Kubernetes que operar.

Las alternativas, verificadas

Revisé el repositorio, la licencia y el último release de cada una el 13 de septiembre de 2026.

Coolify: si lo que haces con Portainer es desplegar tus propias apps

Licencia: Apache-2.0. Unas 61 700 estrellas en GitHub.
Madurez: la v4.0.0 estable salió el 27 de abril de 2026 y el último release es la v4.3.19, del 10 de septiembre. Entre el 3 y el 10 de septiembre publicó cuatro versiones.
Qué es: un PaaS self-hosted, no una UI de contenedores. Despliega desde git (Nixpacks, Railpack, Dockerfile, Docker Compose o sitio estático), pone el proxy inverso (Traefik o Caddy) con certificados, programa respaldos de bases de datos, trae más de 280 servicios de un clic y administra varios servidores por SSH.
Usuarios: equipos, 2FA y OAuth con Azure, Bitbucket, Clerk, Discord, GitHub, GitLab, Google, Authentik, Infomaniak y Zitadel (la lista sale del código fuente).
Requisitos: 2 núcleos, 2 GB de RAM y 10 GB de disco, según su documentación, que además recomienda un servidor limpio para evitar conflictos con lo que ya corre.
Qué no es: un panel para contenedores que levantaste a mano. Su modelo es que el despliegue lo haga él.
Swarm: deprecado. El aviso del propio código dice que se elimina en Coolify v5 y que no recomiendan montar despliegues Swarm nuevos.

Komodo: el reemplazo más directo de Portainer para varios servidores

Licencia: GPL-3.0. Unas 12 200 estrellas. Último release: v2.3.3, del 1 de septiembre de 2026; la v2.0.0 salió el 24 de marzo.
Qué hace: conecta servidores (con un agente llamado Periphery en cada uno), despliega contenedores y stacks de Compose definidos en la UI, en el host o en un repo de git, con redespliegue automático por webhook. También construye imágenes, corre automatizaciones programadas y registra quién hizo cada cambio y cuándo.
Swarm: soportado desde la v2.0.0 (clústeres, nodos, servicios, stacks, configs y secrets).
Usuarios: usuario y contraseña con 2FA, OAuth con GitHub, Google y OIDC genérico, y permisos granulares por roles.
Límite de servidores: ninguno, “y nunca lo habrá”, según su README.
Requisitos: Docker, más MongoDB o FerretDB (sobre Postgres) para el Core. De esta lista, es la que más infraestructura te pide, y su documentación da por hecho que el proxy inverso lo pones tú.

Dockge: si solo quieres editar tus `compose.yaml` desde el navegador

Licencia: MIT. Unas 24 300 estrellas. Es del mismo autor que Uptime Kuma.
Madurez: último release 1.5.0, del 30 de marzo de 2025; el último commit en master es de abril de 2026. El mantenimiento va lento.
Qué hace: crea, edita, arranca y actualiza stacks de Compose, con terminal web, y convierte comandos docker run a compose. Tus archivos se quedan en disco (/opt/stacks por defecto) y los puedes seguir usando con docker compose. Desde la 1.4.0 maneja varios hosts mediante agentes.
Qué no hace: tiene una sola cuenta. El setup se niega a crear un segundo usuario, y el PR que añadía usuarios y grupos (#891) se cerró sin fusionar en julio de 2026. No hay SSO ni roles, y el README no menciona despliegue desde git.

Dockhand: la UI más completa, con letra pequeña en la licencia

Existe y avanza rápido: el repositorio Finsys/dockhand se creó en diciembre de 2025, tiene unas 6200 estrellas y su último release es la v1.0.47, del 12 de septiembre de 2026.
Qué hace: contenedores, stacks de Compose con editor visual, despliegue desde git con webhooks, varios hosts (por socket, por TCP con TLS o con Hawser, su agente MIT, que se conecta hacia afuera sin abrir puertos), escaneo de vulnerabilidades con Grype y Trivy, respaldos (en beta) y OIDC/SSO gratis. Usa SQLite por defecto o PostgreSQL, y dicen que corre en una Raspberry Pi 4.
Qué no hace: Swarm; hay un issue abierto pidiéndolo. RBAC, LDAP/Active Directory y la auditoría para cumplimiento son de la edición Enterprise (1499 dólares por host al año).
La licencia se contradice. El LICENSE.txt del repositorio es la Business Source License 1.1 con una concesión adicional que permite explícitamente el “uso interno de negocio” en producción, siempre que no lo ofrezcas como SaaS de gestión de Docker; pasa a Apache-2.0 el 1 de enero de 2029. Pero los términos de licencia de su sitio dicen que un usuario comercial necesita licencia de pago para entornos de producción o instancias compartidas, y su tabla de precios coloca la “licencia de uso comercial” en el plan SMB (499 dólares por host al año). En un homelab no hay duda. Si eres empresa, pídeles la aclaración por escrito antes de meterlo a producción.

Lazydocker y Yacht, para completar

Lazydocker (MIT, unas 52 800 estrellas, v0.25.2 de abril de 2026) es una interfaz de terminal, no un servidor web: no hay usuarios, ni agentes, ni nada que exponer. Si usabas Portainer solo para ver logs y reiniciar contenedores, te basta.
Yacht volvió a publicar en septiembre de 2026 (release 1.1) después de años sin releases; el anterior, v0.0.7-alpha, es de 2021. Es muy pronto para confiarle producción.

La tabla de decisión

Tu caso	Elige	Por qué
Homelab con 1 a 3 hosts; usas Portainer CE para mirar y reiniciar	Quédate en CE 2.45.0 y decide antes de mayo de 2027	Hoy no se rompe nada y tienes margen
Solo editas `compose.yaml` y eres la única persona que entra	Dockge	MIT, mínimo, y tus archivos se quedan en disco
Quieres una UI tipo Portainer, moderna, para uso personal	Dockhand	La más completa: git, escaneo de vulnerabilidades y SSO gratis
Empresa con varios servidores, varias personas y stacks en git	Komodo	GPL, sin límite de servidores, roles y OIDC sin pagar licencia
Usas Docker Swarm	Komodo, o quedarte en Portainer 2.45	Coolify lo deprecó; Dockge y Dockhand no lo soportan
Despliegas tus propias apps desde git a uno o varios VPS	Coolify	Build, proxy, certificados y respaldos incluidos
Ya pagas Portainer Business, o te bastan 3 nodos con RBAC y vas hacia Kubernetes	Portainer 3.x	Es exactamente el usuario para el que está pensado
Solo abres Portainer para ver logs	Lazydocker	Nada que exponer, nada que licenciar
Tus stacks construyen la imagen en el servidor o usan `network_mode: host` o `macvlan`	Cualquiera menos D2K	D2K ignora `build:` y no soporta esas redes

Lo que he aprendido corriendo Coolify en dos VPS

Tengo Coolify en producción en dos servidores: uno con este sitio y aplicaciones de clientes, y otro con herramientas internas. Hay tres cosas que ninguna comparativa te cuenta, y aplican a cualquier herramienta que hable con el socket de Docker, Portainer, Dockge y Dockhand incluidos.

1. Después de actualizar docker-ce, reinicia los contenedores que montan el socket. En mayo de 2026 actualicé Docker de la 29.5.0 a la 29.5.2 con live-restore activado. Las apps siguieron vivas, pero el proxy de Coolify (Traefik con el proveedor de Docker) se quedó en un bucle intentando reconectarse a /var/run/docker.sock. Resultado: 502 en todas las apps que enruta a través de Docker, mientras el dashboard, que va por archivo de configuración, seguía respondiendo, y eso despista. live-restore protege a los contenedores, no las conexiones que tenían abiertas contra el socket. Desde entonces, después de cada actualización corro:

docker restart coolify-proxy coolify-sentinel

O, en general, reinicio todo contenedor que monte el socket:

for c in $(docker ps --format '{{.Names}}'); do
  docker inspect -f '{{range .Mounts}}{{if eq .Source "/var/run/docker.sock"}}{{$.Name}}{{end}}{{end}}' "$c" | grep -v '^$'
done | xargs -r -n1 docker restart

Ojo: desde la v4.3.19 Sentinel es obligatorio en los servidores normales de Coolify, así que el reinicio de coolify-sentinel ya aplica a todas las instalaciones.

2. Docker se salta UFW. Cuando instalé Coolify en el segundo VPS, los puertos del dashboard y del servicio de tiempo real quedaron abiertos a internet aunque UFW no los permitía: los puertos que publica un contenedor pasan por reglas de iptables que Docker gestiona antes de que UFW los vea. Lo resolví con reglas DROP en la cadena DOCKER-USER, filtrando por el puerto de destino original de la conexión (conntrack --ctorigdstport, porque cuando el paquete llega a esa cadena el DNAT ya reescribió el puerto), y dejando públicos solo el 80 y el 443. Si instalas cualquiera de estas UIs publicando un puerto, compruébalo desde fuera del servidor; no te fíes de ufw status.

3. Las reglas de firewall atadas a la IP de un contenedor se rompen al reiniciar. En el servidor de producción, tras un reinicio, todos los dominios daban timeout aunque Traefik estaba sano. Las reglas de ufw-docker apuntaban a la IP interna vieja del proxy, y el proxy arrancó con otra. El arreglo que aguanta fue permitir el 80 y el 443 hacia el rango de redes de Docker, no hacia una IP concreta. Reiniciar Docker no lo arregla, porque las reglas son de UFW.

Y una que viene en la propia documentación de Coolify y que confirmo: crea la cuenta de administrador en cuanto termine la instalación. Quien llegue primero a la página de registro se queda con el control del servidor.

Si vas a copiar tus stacks de Portainer a otra herramienta, valida cada compose.yaml contra el esquema oficial antes del primer despliegue:

Veredicto

Si usas Portainer CE con Docker, no migres este mes. La 2.45 LTS sigue mantenida, la 3.0 sale como STS y la primera LTS de 3.x no llega hasta diciembre. Fija la imagen en 2.45.0 y usa los próximos meses para probar la alternativa que te toque en un servidor que no sea el de producción.

Pero no esperes una CE 3.x, porque no va a existir. El Portainer que conocías —gratis, sin registro, sin tope de nodos y con Docker como prioridad— se queda congelado en 2.x.

Para elegir, pregúntate qué haces de verdad con Portainer. Si despliegas tus propias apps, el salto natural es Coolify, y es lo que yo uso. Si administras stacks en varios servidores con un equipo, Komodo es lo más parecido a lo que era Portainer, sin tope de nodos y sin licencia comercial. Si eres tú solo con tu homelab, Dockge si te basta lo mínimo, o Dockhand si lo quieres todo. Y si ya ibas camino a Kubernetes, Portainer 3.x está hecho para ti; D2K solo tiene sentido si tus stacks no construyen imágenes ni dependen de redes especiales.

Para seguir leyendo:

Guía completa de Docker en 2026: Compose v5, Engine 29 y la comparación entre Compose, Swarm y Kubernetes para producción.
Kubernetes 1.37: qué se rompe al actualizar: si al final te vas a Kubernetes, con D2K o sin él, esto es lo que hoy bloquea una actualización.

Preguntas frecuentes

¿Portainer Community Edition desaparece con la versión 3.0?

No de inmediato, pero no tendrá versión 3.x. Según el anuncio oficial del 11 de septiembre de 2026, CE sigue en la base de código 2.x y no recibirá los cambios de 3.x. Portainer no va a publicar una build CE de 3.x: la forma gratuita de usar 3.x es el programa 3 Nodes Free, que es una licencia de Business Edition. La política de ciclo de vida de Portainer da a la 2.45 LTS mantenimiento hasta mayo de 2027.

¿Qué es Portainer 3 Nodes Free y qué limita?

Es una licencia de Portainer Business Edition gratuita para hasta tres nodos, limitada a una licencia por organización y que se pide con un formulario. La licencia caduca y hay que renovarla: la llave nueva se envía hasta 14 días antes del vencimiento. En Docker cuenta como nodo cualquier servidor que ejecute Portainer Server o el Portainer Agent, así que tres hosts Docker ya agotan la cuota.

¿Mis entornos Docker dejan de funcionar si actualizo a Portainer 3.x?

No. El anuncio dice que los entornos Docker, Swarm y Podman nativos se pueden seguir agregando y siguen funcionando desde la interfaz. Lo que cambia es que quedan en segundo plano y no recibirán capacidades nuevas del motor de políticas, de GitOps ni de observabilidad. Los productos nuevos, Portainer-Run, IDP, Command y AiGrid, son solo para Kubernetes.

¿Hasta cuándo recibe parches Portainer 2.45 LTS?

La política de ciclo de vida publicada en la documentación de Portainer marca mayo de 2027 como fin de soporte y mantenimiento de la 2.45 LTS. El anuncio de 3.0 dice que la rama 2.x seguirá recibiendo actualizaciones de seguridad, corrección de bugs y back-ports selectivos, sin dar fecha de fin. Esa tabla de ciclo de vida aún lista versiones 2.46 a 2.51 que el anuncio contradice, así que conviene tomar mayo de 2027 como la fecha publicada y no como garantía.

¿Qué es Portainer D2K y qué no soporta?

D2K es un traductor de Docker a Kubernetes con licencia MIT: expone la API de Docker y convierte cada llamada en objetos de Kubernetes dentro de un namespace. Según su README, ignora la directiva build de Compose, no soporta docker build, load, save ni buildx, no soporta redes macvlan ni ipvlan, no tiene equivalente para network host, IP o MAC fijas, no aplica aislamiento de red entre stacks y convierte los bind mounts en hostPath, que no son fiables en clústeres de varios nodos.

¿Cuál es la mejor alternativa gratuita a Portainer para Docker?

Depende de para qué lo usas. Para varios servidores y varias personas, Komodo (GPL-3.0) no tiene límite de servidores e incluye roles y OIDC, aunque necesita MongoDB o FerretDB. Para una sola persona que edita archivos compose, Dockge (MIT) es lo más simple, pero admite una sola cuenta. Para desplegar tus propias apps desde git con proxy y certificados, Coolify (Apache-2.0). Dockhand es la interfaz más completa, pero su licencia comercial es ambigua.

¿Coolify sirve como reemplazo de Portainer?

Solo si lo que haces con Portainer es desplegar tus propias aplicaciones. Coolify es un PaaS self-hosted: despliega desde git con Nixpacks, Railpack, Dockerfile o Docker Compose, configura Traefik o Caddy con certificados y programa respaldos de bases de datos. No está pensado para administrar contenedores creados a mano, su documentación recomienda un servidor limpio y su soporte de Docker Swarm está deprecado y se eliminará en Coolify v5.

¿Dockhand es gratis para uso comercial?

No está claro, porque sus dos textos de licencia se contradicen. El LICENSE.txt del repositorio es la Business Source License 1.1 con una concesión que permite el uso interno de negocio en producción, siempre que no se ofrezca como SaaS. Los términos de licencia de dockhand.pro, en cambio, exigen licencia de pago a usuarios comerciales en producción o en instancias compartidas, y la tabla de precios pone la licencia de uso comercial en el plan SMB de 499 dólares por host al año. Para uso personal es gratis sin ambigüedad.

WhatsApp API, 1 de octubre: qué cambia en tu código cuando Meta cobra los mensajes de servicio

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

El 1 de octubre de 2026 el webhook de estados de WhatsApp no cambia de forma: cambia de significado. El mismo objeto pricing que hoy llega con "type": "free_customer_service" empieza a llegar con "type": "regular" en dos casos que hasta el 30 de septiembre son gratis: los mensajes de servicio a partir del 1,001 del mes en cada número, y las plantillas de utilidad que mandas dentro de la ventana de 24 horas. Si tu código tiene la tarifa de servicio fija en cero, decide con billable o descarta los estados cuya categoría no reconoce, tu reporte va a decir que no gastaste nada mientras Meta te cobra.

De precios en español ya se escribió mucho. Este post va de lo otro: qué campos mirar, qué valores trae cada uno según la documentación de Meta, cómo contar el cupo gratis sin inventarte la regla y qué revisar antes del 30 de septiembre. Todas las cifras son de la tarjeta de México en pesos.

Qué se cobra antes y después del 1 de octubre

Tarifas por mensaje entregado a un número con lada +52, en MXN. Salen de las tarjetas oficiales «effective July 1, 2026» y «effective October 1, 2026», que descargué el 13 de septiembre desde la página de precios de Meta (fila Mexico).

Mensaje	Hasta el 30-sep	Desde el 1-oct	`pricing.type` desde el 1-oct
Plantilla de marketing	0.5614	0.7298	`regular`
Plantilla de utilidad fuera de la ventana	0.1565	0.1565	`regular`
Plantilla de utilidad dentro de la ventana de 24 h	gratis	0.1565, desde la primera	`regular`
Plantilla de autenticación	0.1565	0.1565	`regular`
Servicio (sin plantilla), del 1 al 1,000 del mes por número	gratis	gratis	`free_customer_service`
Servicio (sin plantilla), del 1,001 en adelante	gratis	0.1565	`regular`
Cualquiera dentro de la ventana de punto de entrada gratuito (72 h)	gratis	gratis	`free_entry_point`

Tres detalles que cambian cómo lo programas:

El cambio entra a las 00:00 en la zona horaria de tu WABA, no en UTC. La página de precios lo dice para todo el paquete de octubre: «Rate updates below apply as of 12am by WhatsApp Business Account (WABA) timezone».
El cupo de 1,000 es solo de servicio. Meta lo describe como «a free monthly tier of 1,000 service messages per business phone number», que no se acumula de un mes a otro. No anuncia ningún cupo para utility: una plantilla de utilidad dentro de la ventana se cobra desde la primera.
El marketing sube casi 30 % en México (0.5614 → 0.7298). Es el único cambio de tarifa de la fila; utility, autenticación y servicio quedan en 0.1565. Y los niveles por volumen no te van a salvar: en la tarjeta de niveles de octubre, la utility de México se cobra a precio de lista del mensaje 0 al 1,000,000 del mes, y el servicio no tiene niveles en absoluto según la página de mensajes sin plantilla.

El payload real y los campos que importan

Así llega un mensaje de servicio entregado después de agotar el cupo del mes. La estructura es la de la referencia del webhook de estados y el objeto pricing es literal el que publica Meta para «Paid service message». Los IDs y teléfonos son los de ejemplo de la propia referencia; el timestamp es el 14 de octubre de 2026.

{
  "object": "whatsapp_business_account",
  "entry": [
    {
      "id": "102290129340398",
      "changes": [
        {
          "value": {
            "messaging_product": "whatsapp",
            "metadata": {
              "display_phone_number": "15550783881",
              "phone_number_id": "106540352242922"
            },
            "statuses": [
              {
                "id": "wamid.HBgLMTY1MDM4Nzk0MzkVAgASGBQzQUFERjg0NDEzNDdFODU3MUMxMAA=",
                "status": "delivered",
                "timestamp": "1792002600",
                "recipient_id": "16505551234",
                "pricing": {
                  "billable": true,
                  "pricing_model": "PMP",
                  "type": "regular",
                  "category": "service"
                }
              }
            ]
          },
          "field": "messages"
        }
      ]
    }
  ]
}

El mismo mensaje, en septiembre o dentro del cupo, trae "billable": false y "type": "free_customer_service". Una utility dentro de la ventana pasa exactamente igual: free_customer_service hasta el 30 de septiembre, regular desde el 1 de octubre, con "category": "utility".

`pricing.type`: el que decide

Es el campo que dice por qué un mensaje se cobra o no. La referencia de estados documenta tres valores:

regular: se cobra.
free_customer_service: gratis por ir dentro de la ventana de atención. Desde octubre, eso incluye estar dentro del cupo de 1,000.
free_entry_point: gratis por la ventana de 72 horas que abren los anuncios Click-to-WhatsApp y los botones de llamada a la acción de una página de Facebook.

La página de precios añade un cuarto que la referencia (actualizada el 21 de mayo) todavía no lista: free_group_customer_service, para mensajes a grupos.

`pricing.category`: qué tarifa se aplicó

Valores de la referencia: authentication, authentication-international, marketing, marketing_lite, referral_conversion, service y utility. Ojo con authentication-international: en pricing.category lleva guion, mientras que la categoría de conversation.origin.type lleva guion bajo. La página de precios añade group_service y group_utility para grupos.

La consecuencia práctica: no valides estos campos contra una lista cerrada. Si tu parser descarta un estado porque la categoría no está en tu enum, ese mensaje se queda sin precio en tu base mientras Meta sí lo cobra.

`pricing.billable`: no decidas con él

La referencia es explícita: «The billable property will be deprecated in a future versioned release. Use pricing.type and pricing.category together to determine whether a message is billable and, if so, its billing rate.» Hoy billable y type coinciden. El día que Meta lo quite en una versión nueva de la Graph API, un if (billable === false) return 0 se convierte en «todo cuesta» o en «nada cuesta», según cómo trates el undefined.

Cuándo llega el objeto, y cuándo cuenta

Según la sintaxis de la referencia, pricing viene «only included with sent status, and one of either delivered or read status». El ejemplo de la v24 aclara que puede venir solo en el delivered y no en el sent. Así que te va a llegar dos veces o una, y tienes que deduplicar por wamid.
Meta cobra lo entregado, no lo enviado («only when the message is delivered (vs. sent)»). Y el delivered puede no llegar nunca: si el usuario tiene el chat abierto, Meta manda directo el read. Cuenta un mensaje como entregado cuando llega delivered o read.
Desde la v24.0 el objeto conversation ya no viene, salvo dentro de una ventana de punto de entrada gratuito. Si tu código sacaba la categoría de conversation.origin.type, ya iba tarde.

Los cuatro errores que hacen que tu reporte diga cero

Revisando para este post el agente de WhatsApp que tengo en desarrollo, encontré dos de estos en mi propio código. Los cuatro son fáciles de tener:

Tarifa sin fecha de vigencia. Una constante service: 0 calcula bien hasta el 30 de septiembre y mal desde el 1 de octubre, aunque el webhook ya diga regular. Meta solo puede cambiar tarifas el día 1 de cada trimestre (enero, abril, julio y octubre), con un mes de aviso para una actualización de tarjeta: modela la tarjeta con su fecha de entrada en vigor.
Decidir con billable. Funciona hoy; deja de funcionar cuando Meta lo retire.
Lista blanca de categorías. group_service, free_group_customer_service o el guion de authentication-international acaban como «sin categoría» y valen cero en tu suma.
Contar cada estado. Si sumas en cada webhook con pricing, un mismo mensaje cuenta doble (sent + delivered), y un mensaje que falló después de enviarse cuenta aunque Meta no lo cobre.

Código: contar lo facturable por número y por mes

La idea es la del libro de costos de mi agente: una fila por mensaje saliente, que se va rellenando con lo que traiga cada estado, y el costo se calcula al leer. Está escrito para Cloudflare D1 (SQLite), pero el SQL es portable.

Primero la tabla. category y pricing_type se guardan tal cual llegan, sin lista blanca:

CREATE TABLE wa_outbound (
  wamid           TEXT PRIMARY KEY,
  phone_number_id TEXT NOT NULL,
  month           TEXT NOT NULL,              -- 'YYYY-MM' en la zona horaria de la WABA
  delivered       INTEGER NOT NULL DEFAULT 0, -- 1 cuando llegó `delivered` o `read`
  category        TEXT,                       -- pricing.category, sin normalizar
  pricing_type    TEXT                        -- pricing.type, sin normalizar
);
CREATE INDEX wa_outbound_month ON wa_outbound (phone_number_id, month);

Después, lo que haces con cada statuses[]. El phone_number_id sale de value.metadata.phone_number_id, que es la unidad del cupo:

type Open<T extends string> = T | (string & {}); // autocompleta, pero acepta lo que Meta añada

export interface StatusPricing {
  /** Meta lo va a deprecar: decide con `type` + `category`. */
  billable?: boolean;
  pricing_model: Open<'PMP' | 'CBP'>;
  type: Open<'regular' | 'free_customer_service' | 'free_entry_point' | 'free_group_customer_service'>;
  category: Open<'service' | 'utility' | 'marketing' | 'marketing_lite' | 'authentication' | 'authentication-international' | 'referral_conversion' | 'group_service' | 'group_utility'>;
}

export interface WebhookStatus {
  id: string; // wamid
  status: Open<'sent' | 'delivered' | 'read' | 'failed' | 'played'>;
  timestamp: string; // epoch en segundos, como cadena
  recipient_id: string;
  pricing?: StatusPricing;
}

/** 'YYYY-MM' en la zona horaria de tu WABA, p. ej. 'America/Mexico_City'. */
export function monthKey(epochSeconds: number, timeZone: string): string {
  return new Intl.DateTimeFormat('en-CA', { timeZone, year: 'numeric', month: '2-digit' })
    .format(new Date(epochSeconds * 1000))
    .slice(0, 7);
}

const DELIVERED = new Set(['delivered', 'read']); // si llega `read` sin `delivered`, se entregó

export async function applyStatus(db: D1Database, phoneNumberId: string, s: WebhookStatus, timeZone: string) {
  await db
    .prepare(
      `INSERT INTO wa_outbound (wamid, phone_number_id, month, delivered, category, pricing_type)
       VALUES (?1, ?2, ?3, ?4, ?5, ?6)
       ON CONFLICT(wamid) DO UPDATE SET
         month        = CASE WHEN excluded.delivered = 1 AND delivered = 0 THEN excluded.month ELSE month END,
         delivered    = MAX(delivered, excluded.delivered),
         category     = COALESCE(excluded.category, category),
         pricing_type = COALESCE(excluded.pricing_type, pricing_type)`,
    )
    .bind(
      s.id,
      phoneNumberId,
      monthKey(Number(s.timestamp), timeZone),
      DELIVERED.has(s.status) ? 1 : 0,
      s.pricing?.category ?? null,
      s.pricing?.type ?? null,
    )
    .run();
}

El ON CONFLICT hace el trabajo sucio: los estados repetidos no duplican, el pricing se conserva venga en el sent o en el delivered, y el mes que cuenta es el de la entrega (un mensaje enviado el 30 de septiembre a las 23:59 y entregado el 1 de octubre cae en octubre).

Por último, la cuenta del mes. La tarjeta lleva fecha, y lo que decide si se cobra es type, no tu contador:

const FREE_SERVICE_PER_MONTH = 1000;

/** Tarjeta de México en MXN por mensaje entregado. Una entrada por trimestre con cambios. */
const MX_RATES_MXN: Array<{ from: string; rates: Record<string, number> }> = [
  { from: '2026-07', rates: { marketing: 0.5614, utility: 0.1565, authentication: 0.1565 } },
  { from: '2026-10', rates: { marketing: 0.7298, utility: 0.1565, authentication: 0.1565, service: 0.1565 } },
];

const ratesFor = (month: string) => MX_RATES_MXN.findLast((card) => card.from <= month)?.rates ?? {};

export async function monthlyBill(db: D1Database, phoneNumberId: string, month: string) {
  const { results } = await db
    .prepare(
      `SELECT category, pricing_type, COUNT(*) AS n FROM wa_outbound
       WHERE phone_number_id = ? AND month = ? AND delivered = 1
       GROUP BY category, pricing_type`,
    )
    .bind(phoneNumberId, month)
    .all<{ category: string | null; pricing_type: string | null; n: number }>();

  const rates = ratesFor(month);
  let mxn = 0;
  let serviceDelivered = 0;
  let paidService = 0;
  const unpriced: Record<string, number> = {};

  for (const { category, pricing_type, n } of results) {
    if (!category || !pricing_type) {
      unpriced['(sin pricing)'] = (unpriced['(sin pricing)'] ?? 0) + n;
      continue;
    }
    // Meta no documenta si los de punto de entrada gastan cupo: aquí no se cuentan.
    if (category === 'service' && pricing_type !== 'free_entry_point') serviceDelivered += n;
    if (pricing_type !== 'regular') continue; // gratis: ventana, cupo o punto de entrada
    if (category === 'service') paidService += n;

    const rate = rates[category];
    if (rate === undefined) {
      unpriced[category] = (unpriced[category] ?? 0) + n; // se cobra y no tienes tarifa: no lo sumes como 0
      continue;
    }
    mxn += n * rate;
  }

  return {
    mxn: Math.round(mxn * 100) / 100,
    serviceDelivered,
    freeServiceLeft: Math.max(0, FREE_SERVICE_PER_MONTH - serviceDelivered),
    paidService,
    unpriced,
  };
}

Con eso, la alerta es una línea en un cron diario: avisa cuando freeServiceLeft baje de 200, cuando aparezca el primer paidService del mes o cuando unpriced no venga vacío. Y si paidService es mayor que cero con serviceDelivered por debajo de 1,000, tu contador y Meta no coinciden: puede ser otra aplicación mandando desde el mismo número, webhooks perdidos o el corte de mes en otra zona horaria. Manda Meta.

Para cruzarlo a fin de mes, el campo pricing_analytics de la WABA acepta las dimensiones PHONE, PRICING_CATEGORY y PRICING_TYPE. Dos avisos de la misma página: los datos son aproximados («may differ from what’s shown on invoices»), y COST no viene si tu WABA usa la línea de crédito de un proveedor. Además, la descripción de SERVICE en esa referencia (actualizada el 11 de junio) todavía dice «Messages that were not charged»; la página de mensajes sin plantilla ya muestra la consulta con REGULAR + SERVICE.

Cuánto cuesta en pesos: una PyME con 600 conversaciones al mes

Un consultorio o un taller con un agente que atiende WhatsApp, un solo número, clientes con lada +52 y sin anuncios Click-to-WhatsApp. Al mes:

600 conversaciones, con 5 mensajes de servicio del agente cada una: 3,000 mensajes de servicio.
600 confirmaciones con plantilla de utilidad, mandadas dentro de la ventana.
400 recordatorios con plantilla de utilidad, fuera de la ventana.
Una campaña de marketing a 500 contactos.

Supongo que todo se entrega; en la vida real sale un poco menos, porque Meta solo cobra lo entregado. Tarifas de lista, sin impuestos.

Septiembre (tarjeta de julio):

Concepto	Cuenta	MXN
Servicio	3,000 × 0	0.00
Utility dentro de la ventana	600 × 0	0.00
Utility fuera de la ventana	400 × 0.1565	62.60
Marketing	500 × 0.5614	280.70
Total		343.30

Octubre (tarjeta de octubre):

Concepto	Cuenta	MXN
Servicio	(3,000 − 1,000) × 0.1565 = 2,000 × 0.1565	313.00
Utility dentro de la ventana	600 × 0.1565	93.90
Utility fuera de la ventana	400 × 0.1565	62.60
Marketing	500 × 0.7298	364.90
Total		834.40

La factura de Meta pasa de 343.30 a 834.40 pesos: 491.10 MXN más al mes. No es una cifra que quiebre a nadie, pero es 2.4 veces la de septiembre, y 406.90 de esos 491.10 pesos (más del 80 %) salen de dos líneas que hoy valen cero.

Dónde está la palanca de verdad: en tu código

Pasar las confirmaciones de plantilla de utilidad a texto libre dentro de la ventana no ahorra nada en este ejemplo: la tarifa de servicio y la de utilidad son la misma en México (0.1565) y el cupo de 1,000 ya se agotó. Solo ayuda a negocios que se quedan por debajo de 1,000 mensajes de servicio al mes.

Lo que sí mueve la cifra es cuántos mensajes manda tu agente por respuesta. Muchos agentes de IA parten cada respuesta en tres o cuatro burbujas porque se lee más natural. Desde el 1 de octubre, cada burbuja pasado el mensaje 1,000 es un cargo. Si el mismo agente contesta con 3 mensajes por conversación en vez de 5:

600 × 3 = 1,800 mensajes de servicio.
(1,800 − 1,000) × 0.1565 = 800 × 0.1565 = 125.20 MXN, contra 313.00.
Ahorro: 187.80 MXN al mes, sin tocar un solo precio.

Si parte de tus clientes llega por anuncios Click-to-WhatsApp, responder dentro de las primeras 24 horas abre la ventana de punto de entrada de 72 horas, y ahí todo sale como free_entry_point. Meta confirma que esa ventana no cambia para la entrega de mensajes.

Qué pasa si no tienes método de pago

Aquí Meta tiene dos redacciones, de fechas distintas, y conviene leerlas juntas.

La página de mensajes sin plantilla, actualizada el 25 de agosto de 2026, dice:

For any Solution Provider or directly-integrated businesses that does not have a payment method on file by September 30, 2026, Meta will stop delivering service messages as of when they become charged on October 1, 2026. To avoid disruptions to your service messages, please add a payment method for your WhatsApp Business Account(s) by September 30, 2026.

La página de precios, actualizada el 10 de septiembre de 2026, que es la que introduce el cupo gratis como novedad, precisa:

If you do not have a payment method for your WhatsApp Business account: Meta will deliver your first 1,000 service messages each month but not deliver as of your 1,001st.

No se contradicen: la primera dice que se dejan de entregar «cuando empiezan a cobrarse», y la segunda, escrita después del cupo, dice que eso ocurre en el mensaje 1,001. En la práctica:

La fecha que da Meta para tener el método de pago es el 30 de septiembre. No esperes a ver el primer fallo.
Sin método de pago, tu agente funciona normal hasta que el número cruza los 1,000 mensajes de servicio del mes, y ahí deja de entregar a mitad de mes. En un negocio con volumen, eso puede ser un martes a media tarde.
Meta no publica, en las páginas que revisé, qué código de error trae el estado failed en ese caso. Vigila un aumento de failed en mensajes de servicio desde el 1 de octubre.
El aviso de agosto va dirigido a «Solution Provider or directly-integrated businesses». Si tu WABA factura a través de un proveedor de soluciones, pídele por escrito que confirme que el método de pago está resuelto antes del 30 de septiembre.

Checklist antes del 30 de septiembre

Método de pago en el Billing Hub de cada WABA, o confirmación escrita de tu proveedor si facturas a través de él.
Parser tolerante: pricing.type y pricing.category se guardan tal cual. Nada de descartar el estado porque trae group_service, free_group_customer_service o authentication-international.
Deja de decidir con billable. Usa type === 'regular' más la tarifa de category.
Tarjeta con fecha de vigencia, cargada con la de octubre (marketing a 0.7298 en México). La próxima fecha en que Meta puede cambiar tarifas es el 1 de enero de 2027.
Cuenta en delivered o read, una vez por wamid, y agrupa por phone_number_id y mes en la zona horaria de tu WABA.
Alertas: quedan menos de 200 de servicio gratis, primer servicio regular del mes, categorías sin tarifa y aumento de failed.
Plantillas de utilidad dentro de la ventana: desde el 1 de octubre se cobran desde la primera. Si mandas menos de 1,000 mensajes de servicio al mes, un texto libre dentro de la ventana puede salir gratis donde la plantilla cuesta.
Plantillas de marketing contra utilidad: Meta te cobra la categoría que tenga la plantilla al momento de usarla, y puede recategorizarla. Suscríbete al webhook template_category_update, que avisa 24 horas antes de un cambio automático de categoría.
Mensajes por respuesta: junta las burbujas de tu agente. Es la palanca más barata del ejemplo.
Cruce mensual contra pricing_analytics, sabiendo que es aproximado.

Si prefieres que alguien revise tu integración, tus plantillas y cuánto te va a costar octubre antes de que llegue, es justo lo que hago en WhatsApp para tu negocio.

Para seguir leyendo:

Monta un agente de IA en WhatsApp para tu pyme (Laravel + OpenAI): el webhook, la memoria de conversación y las reglas de la ventana de 24 horas, desde cero.

Preguntas frecuentes

¿Qué cambia en la API de WhatsApp el 1 de octubre de 2026?

Meta empieza a cobrar dos tipos de mensaje que hoy son gratis: los mensajes de servicio (los que mandas sin plantilla dentro de la ventana de 24 horas) a partir del mensaje 1,001 de cada mes por número de negocio, y las plantillas de utilidad que mandas dentro de esa ventana, que se cobran desde la primera. En México, ambos a 0.1565 MXN por mensaje entregado. Además, la tarifa de marketing de México sube de 0.5614 a 0.7298 MXN. El cambio entra a las 00:00 en la zona horaria de tu cuenta de WhatsApp Business.

¿Cómo sé en el webhook si un mensaje de WhatsApp se cobró?

Mira pricing.type en el webhook de estados: regular significa que se cobra; free_customer_service, free_entry_point o free_group_customer_service significan que salió gratis. pricing.category te dice qué tarifa se aplicó. No uses pricing.billable para decidir: la referencia de Meta dice que se va a deprecar en una versión futura y recomienda usar type y category juntos.

¿Los 1,000 mensajes gratis de WhatsApp son por cuenta o por número?

Por número de teléfono de negocio. Meta dice que cada número recibe 1,000 mensajes de servicio gratis al mes, que cobra desde el mensaje de servicio 1,001 entregado ese mes y que el cupo no se acumula: se reinicia cada mes. El cupo es solo de mensajes de servicio; las plantillas de utilidad dentro de la ventana no tienen cupo gratis.

¿Qué pasa si no tengo método de pago en WhatsApp Business el 1 de octubre?

Según la página de precios de Meta actualizada el 10 de septiembre de 2026, Meta entrega tus primeros 1,000 mensajes de servicio del mes y deja de entregarlos a partir del 1,001. La página de mensajes sin plantilla pide tener el método de pago en el Billing Hub antes del 30 de septiembre de 2026. Si facturas a través de un proveedor de soluciones, confirma con él que el método de pago está resuelto.

¿El objeto pricing llega en todos los estados del webhook?

No. Según la referencia de Meta, pricing viene con el estado sent y con uno de delivered o read, y en la v24 puede venir solo en delivered. Como Meta cobra lo entregado y a veces manda read sin delivered, cuenta cada mensaje una sola vez por wamid cuando llegue delivered o read, y guarda el pricing venga en el estado que venga.

¿Cuánto va a pagar a Meta una pyme mexicana desde octubre?

Depende del volumen. Con 600 conversaciones al mes de 5 mensajes de servicio cada una, 600 confirmaciones de utilidad dentro de la ventana, 400 recordatorios de utilidad fuera de ella y una campaña de marketing a 500 contactos, la factura de Meta pasa de 343.30 MXN en septiembre a 834.40 MXN en octubre con tarifas de lista. Reducir el agente de 5 a 3 mensajes por conversación baja la parte de servicio de 313.00 a 125.20 MXN.

¿Conviene cambiar plantillas de utilidad por texto libre dentro de la ventana?

Solo si mandas menos de 1,000 mensajes de servicio al mes. En México el servicio y la utilidad cuestan lo mismo (0.1565 MXN) desde el 1 de octubre, pero el servicio tiene 1,000 gratis al mes por número y la utilidad no. Una vez agotado el cupo, da igual. La palanca más grande suele ser que tu agente mande menos mensajes por respuesta.

Validar RFC, CURP y CFDI desde Claude, sin API keys ni PAC

Marco Orta — Fri, 11 Sep 2026 00:00:00 GMT

Pídele a un agente de IA que valide un RFC y casi siempre escribirá una regex. Si además calcula el dígito verificador, va a rechazar XAXX010101000, el RFC genérico de público en general, porque ese RFC no satisface su propio dígito. El SAT lo asignó por decreto, y el módulo 11 pide un 4 donde el SAT puso un 0.

Si integras facturación, llevas la contabilidad de un despacho o revisas XML de proveedores, ya sabes cómo acaba eso: el formulario que no deja facturar al público en general, la factura que “no existe” en el SAT aunque la tengas en la mano. Son detalles que no puedes confiarle a la memoria de un modelo. Por eso hice mx-fiscal-mcp-server: un servidor MCP open source que le da a Claude (o a Cursor, o a cualquier cliente MCP) ocho herramientas de solo lectura para validar RFC, CURP, CLABE y NSS con sus algoritmos reales, leer CFDI 4.0, consultar al SAT si una factura sigue vigente y buscar en sus catálogos.

No necesita API keys, ni CSD, ni contrato con un PAC. Aquí va la instalación, qué le puedes pedir y los seis detalles que una implementación hecha a mano suele fallar, incluido uno que yo mismo fallé antes de publicarlo.

Instalación en una línea

El servidor está publicado en npm y en el registro oficial de MCP, así que no hay nada que clonar. En Claude Code:

claude mcp add mx-fiscal -- npx -y mx-fiscal-mcp-server

En Claude Desktop o Cursor, agrégalo a claude_desktop_config.json o a ~/.cursor/mcp.json:

{
  "mcpServers": {
    "mx-fiscal": {
      "command": "npx",
      "args": ["-y", "mx-fiscal-mcp-server"]
    }
  }
}

En Windows usa "command": "cmd" con "args": ["/c", "npx", "-y", "mx-fiscal-mcp-server"]. Pide Node.js 20 o superior.

Está hecho sobre el SDK de MCP v2, así que habla la revisión 2026-07-28 del protocolo y sigue atendiendo, desde el mismo proceso, a los clientes de la era 2025 que usan hoy Claude Desktop, Claude Code y Cursor. Si mantienes un servidor propio, escribí qué cambia al migrar a la 2026-07-28.

Las ocho herramientas

Herramienta	Qué hace
`validate_rfc`	RFC de persona física (13 caracteres) y moral (12): dígito verificador, campos desglosados, fecha de nacimiento o constitución, y si es uno de los genéricos del SAT
`validate_curp`	CURP de 18 caracteres: dígito verificador, fecha de nacimiento, sexo, entidad y el marcador de siglo
`validate_clabe`	CLABE de 18 dígitos: dígito de control, banco y plaza
`validate_nss`	NSS del IMSS de 11 dígitos con su dígito Luhn
`generate_test_data`	De 1 a 100 personas físicas o morales ficticias y coherentes: RFC y CURP derivados del mismo nombre y fecha, CLABE de un banco real
`parse_cfdi`	XML de CFDI 4.0 a JSON, con cada clave de catálogo etiquetada, los dos RFC validados y los totales comprobados
`cfdi_status`	Consulta el servicio público del SAT: si la factura existe, si está cancelada, si es cancelable y el resultado de la validación EFOS (lista del 69-B)
`sat_catalog_lookup`	Nueve catálogos (régimen fiscal, uso de CFDI, forma y método de pago, entre otros), por clave o por texto

Solo cfdi_status sale a la red. Las otras siete nunca salen del proceso.

Qué le puedes pedir

Algunos prompts que funcionan bien, con la forma de lo que devuelven:

“¿GODE561231GR8 es un RFC válido? Desglósalo.” — si es de persona física o moral, la fecha que lleva codificada y un motivo legible para cada fallo: no un simple invalid, sino “el dígito verificador final no coincide con el resultado del módulo 11”.
“Genérame 20 clientes con RFC, CURP y CLABE válidos para mi seeder.” — todos los dígitos cuadran, y el RFC y la CURP de cada registro describen a la misma persona. Si solo necesitas los datos sin agente de por medio, está el generador de datos de prueba.
“Lee esta factura y dime si sigue vigente en el SAT.” — Claude llama a parse_cfdi para etiquetarlo todo y comprobar la aritmética, y después a cfdi_status con los cuatro valores que necesita.

Ese último es el flujo que más tiempo ahorra, sobre todo si revisas XML de proveedores uno por uno, y es el que esconde casi todas las trampas de abajo.

Seis detalles que una regex hace mal

1. El RFC de público en general no satisface su propio dígito verificador

Aplica el módulo 11 a los primeros doce caracteres de XAXX010101000 y el algoritmo pide un 4. En cambio, XEXX010101000, el de residentes en el extranjero, sí lo satisface.

Un validador que solo corre el algoritmo rechaza toda factura al público en general, y por eso tantos formularios de facturación la rechazan. Uno que solo revisa la forma deja pasar errores de dedo. El servidor reporta los dos hechos por separado, is_generic: true y check_digit_satisfied: false, y explica con palabras por qué esa combinación es correcta.

2. La CLABE toma la unidad de cada producto, no la suma de sus cifras

El dígito de control de la CLABE pondera los primeros 17 dígitos con 3, 7, 1, 3, 7, 1… De cada producto se queda la unidad, es decir, el producto módulo 10: un 63 aporta 3. Luego se suma, se toma el módulo 10 y se resta de 10 (si da 10, el dígito es 0).

Una implementación que copia Luhn hace otra cosa: cuando un producto pasa de 9, suma sus cifras, y ese mismo 63 aporta 6 + 3 = 9. Las dos rutas no coinciden: con los 17 dígitos 09000000000000000, el algoritmo de la CLABE da 7 y la versión estilo Luhn da 1. Eso basta para aceptar cuentas mal escritas y rechazar cuentas buenas.

3. El carácter 17 de la CURP marca el siglo

La CURP guarda el año de nacimiento con dos dígitos, así que 31 puede ser 1931 o 2031. RENAPO lo resuelve con el carácter 17: si es dígito, naciste antes de 2000; si es letra, en 2000 o después.

Este es el que fallé yo. La primera versión del servidor leía esa regla al revés y, como la fecha de nacimiento se decodifica justo a través de ese carácter, reportaba un “desacuerdo entre el marcador y la fecha” en cada CURP válida que veía. La suite de tests había capturado el mensaje equivocado como comportamiento esperado. Una revisión independiente lo detectó antes de publicar; el vector de prueba canónico BOXW310820HNERXN09 ahora se decodifica, correctamente, como 20 de agosto de 1931.

4. Las claves de entidad de la CURP son de RENAPO, no del INEGI

Las posiciones 12 y 13 de la CURP codifican la entidad de nacimiento con claves propias de RENAPO: DF es la Ciudad de México, MC el Estado de México y NE nacido en el extranjero. No coinciden ni con las claves de entidad del INEGI ni con ISO 3166-2:MX, así que cruzar contra cualquiera de esas tablas etiqueta mal a la gente sin avisar.

5. La consulta al SAT es exigente con el total

cfdi_status le manda al SAT una expresión armada con cuatro valores: RFC emisor, RFC receptor, total y UUID. El total va con el formato que usan las implementaciones de referencia (nodecfdi y phpcfdi): seis decimales, quitando los ceros finales pero dejando al menos uno. Así, 1160.00 viaja como 1160.0:

?re=TES150312DX2&rr=PELJ900521DK2&tt=1160.0&id=5A7B3C1D-9E2F-4A6B-8C0D-1E2F3A4B5C6D

Un total que no respeta ese formato, como un 1,160.00 tecleado a mano, puede hacer que el SAT conteste No Encontrado de una factura que sí existe. Por eso el servidor revisa los cuatro valores antes de gastar una petición, y recomienda pasarle el XML completo para que los saque él mismo.

En la misma consulta viven dos reglas más. Un RFC con & viaja codificado como &, igual que en la implementación de referencia de nodecfdi. Y un campo ValidacionEFOS vacío no significa que el emisor esté en la lista del 69-B: la documentación del servicio del SAT define los códigos (del 100 al 104 cuando el emisor o algún RFC a cuenta de terceros está listado, 200 y 201 cuando no), pero no el valor vacío, así que el servidor lo reporta como unknown, nunca como “listado”. Desde la versión 1.0.2 separa las dos preguntas: efos_state responde solo por el emisor (100, 101 y 104 son listed; 102, 103, 200 y 201 son not_listed) y efos_third_party_state por los RFC a cuenta de terceros, con el código crudo siempre en validacion_efos. La 1.0.1 leía 102 y 103 como «el emisor está listado», justo lo contrario de lo que dice el SAT.

6. El total incluye los impuestos locales

La comprobación aritmética (subtotal menos descuento, más trasladados, menos retenidos) es como detectas una factura alterada o mal generada. Pero el esquema de CFDI 4.0 define el total sobre impuestos federales y locales, y los locales viven aparte, en el complemento implocal. Una factura de hotel con impuesto estatal al hospedaje parece descuadrada justo por ese impuesto si ignoras el complemento. El servidor lo suma.

Si solo quieres abrir una factura a mano, sin agente de por medio, el visor de CFDI que nació en este sitio vive ahora en Siempre Contable.

Leer no es verificar

parse_cfdi lee el XML: comprobante, emisor, receptor, cada concepto con sus impuestos, los totales de impuestos y el timbre fiscal digital. Etiqueta cada clave de catálogo, valida los dos RFC y comprueba la aritmética.

No verifica el sello digital. Una factura que se lee perfecto puede estar cancelada o ser inventada de principio a fin, y para eso está cfdi_status. Y que el SAT no conteste no vuelve inválida la factura: el servicio no tiene página de estado y se cae (su documentación habla de capacidad para 2 millones de consultas por hora y pide no aumentar el volumen, pero no promete disponibilidad). Cuando falla, la herramienta devuelve available: false con el motivo, que es una afirmación sobre el SAT y nunca sobre el documento, tras un timeout de 10 segundos y un reintento.

La misma honestidad aplica a los identificadores. Que el dígito verificador cuadre dice que la cadena está bien formada y nada más. Solo el SAT puede decir que un RFC está dado de alta, y solo RENAPO que una CURP pertenece a alguien; este servidor no le pregunta a ninguno de los dos, y su redacción nunca da a entender que lo hizo. Hasta los datos ficticios llevan aviso: se generan a partir de nombres comunes, así que una CURP o un teléfono generados pueden coincidir por azar con los de una persona real.

Lo que deliberadamente no hace

No construye ni sella facturas. Esa mitad de la facturación electrónica necesita tu CSD y, para timbrar, un PAC, y ya tiene servidor MCP: mcp-cfdi-mx, en Python, que arma, valida y sella CFDI 4.0 con tu CSD. Este es la mitad de lectura, que no necesita nada, y los dos se complementan.

Auto-hospedarlo con seguridad

Además de stdio, el servidor habla Streamable HTTP sin estado, para uso compartido o remoto:

TRANSPORT=http npx -y mx-fiscal-mcp-server

Es seguro por defecto: escucha en 127.0.0.1 y solo acepta cabeceras Host y Origin de localhost, lo que bloquea ataques de DNS rebinding desde una página web. Para exponerlo detrás de un proxy inverso, define HOST=0.0.0.0, ALLOWED_HOSTS con tu dominio público y MCP_AUTH_TOKEN para autenticación Bearer. No te saltes el token: una instancia abierta le hace consultas al SAT a nombre de cualquiera y puede acabar con tu IP limitada.

El XML de una factura es entrada no confiable, así que un documento que declara un DOCTYPE se rechaza antes de parsearlo (un CFDI nunca lo lleva), y hay topes de tamaño y de número de elementos que acotan la memoria que puede consumir un solo parseo.

La aritmética de los dígitos verificadores vive en mx-identifiers, una librería sin dependencias probada contra los vectores públicos del SAT, Banxico y RENAPO, y el servidor tiene 51 tests unitarios offline más un smoke test que llama a cada herramienta sobre el protocolo real en las dos eras. Si buscas servidores MCP para otras áreas, mantengo una lista de los mejores servidores MCP para SEO, con los míos incluidos.

Preguntas frecuentes

¿El servidor necesita e.firma, CSD o una API key?

No. Todos los algoritmos de dígito verificador y todos los catálogos son públicos, y el servicio de consulta de estado de CFDI del SAT es público y no pide autenticación. El servidor solo lee: nunca sella ni cancela nada, así que no necesita credenciales de ningún tipo.

¿Por qué el SAT dice 'No Encontrado' de una factura que sí existe?

Normalmente porque uno de los cuatro valores de la consulta no coincide con lo que tiene el SAT: un total con otro formato (tiene que ir con seis decimales, quitando los ceros finales pero dejando uno, así que 1160.00 viaja como 1160.0), un separador de miles o un UUID mal copiado. Si le pasas el XML completo a cfdi_status, el servidor saca los cuatro valores por su cuenta.

¿XAXX010101000 es un RFC válido?

Sí. Es el RFC genérico del SAT para operaciones con el público en general, asignado por decreto, y aparece en facturas reales. No satisface el dígito verificador del módulo 11 (el algoritmo pide un 4), así que los validadores sin una lista explícita de genéricos lo rechazan. XEXX010101000, el de residentes en el extranjero, también es genérico y ese sí satisface el algoritmo.

¿Sirve para saber si un proveedor está en la lista del 69-B?

Solo a través de sus facturas: cfdi_status devuelve el campo ValidacionEFOS de cada CFDI que consultas, no busca un RFC suelto. El servidor separa al emisor (efos_state) de los RFC a cuenta de terceros (efos_third_party_state) y deja el campo vacío como desconocido. Aun así, contrasta con el listado del 69-B que publica el SAT antes de tomar una decisión.

¿Los datos de prueba generados pueden ser de una persona real?

Por azar, sí. generate_test_data arma cada registro con nombres mexicanos comunes y una fecha de nacimiento aleatoria, y la CURP se deriva justo de esos campos, así que puede coincidir con la CURP o el teléfono de una persona real. Los datos son para fixtures, seeders y demos: nunca los mandes al SAT ni a un PAC, y nunca los uses en lugar de los datos reales de un cliente.

npm y la cadena de suministro: el gusano que se coló por el trusted publishing

Marco Orta — Tue, 08 Sep 2026 00:00:00 GMT

Durante un año, el consejo de seguridad de npm fue uno solo y todo el mundo lo repitió: deja de publicar con tokens de larga vida y pásate al trusted publishing con OIDC. Era buen consejo. Sigue siéndolo. Y el 11 de mayo de 2026, el gusano Shai-Hulud publicó decenas de paquetes oficiales de @tanstack/* entrando exactamente por ahí — no falsificando la procedencia, sino generándola de verdad desde el workflow legítimo del proyecto.

Ese matiz es el artículo entero. Un paquete malicioso con una firma Sigstore auténtica, emitida por Fulcio y anotada en Rekor, con el contexto del repositorio real detrás. Todos los indicadores que te habían enseñado a mirar decían «bien».

Esto no significa que el trusted publishing sea inútil ni que haya que volver a los tokens. Significa algo más incómodo: es una capa, no un perímetro, y llevamos un año vendiéndolo como si fuera lo segundo. Aquí va qué protege de verdad, qué deja fuera, y las cuatro medidas que sí habrían frenado los ataques de los últimos doce meses.

La cronología, con fechas

Conviene tenerla delante porque el ritmo importa más que cualquier incidente suelto:

Fecha	Qué pasó
jul 2025	Trusted publishing con OIDC pasa a disponibilidad general en npm
26 ago 2025	Ataque S1ngularity
8 sep 2025	Phishing contra `debug`, `chalk` y 16 utilidades más — vivas dos horas
15 sep 2025	Shai-Hulud oleada 1: más de 700 paquetes comprometidos
23 nov 2025	Shai-Hulud 2.0
9 dic 2025	npm revoca permanentemente todos los tokens clásicos
feb 2026	npm CLI 11.10.0 estrena `min-release-age` y configuración OIDC en bloque
30 mar 2026	`axios@1.14.1` comprometido — 100 M de descargas semanales
11 may 2026	Shai-Hulud contra TanStack, entrando por el propio trusted publishing
14 may 2026	`node-ipc`: tres versiones maliciosas con un robacredenciales de 80 KB
1 jun 2026	32 paquetes de `@redhat-cloud-services`, carga «Miasma»
ago 2026	Nueva oleada: `keyv` y más de 400 paquetes

Diez meses, ocho campañas. Esto ya no es una serie de incidentes: es el estado normal del registro.

Cómo entró por la puerta buena

Vale la pena entender el ataque de TanStack paso a paso, porque cada eslabón desmonta una suposición distinta. La reconstrucción de Upwind lo detalla así:

Una dependencia «dropper» entra en el package.json y se ejecuta durante la instalación, vía los lifecycle hooks de npm. Nada exótico: es la funcionalidad documentada.
El dropper descarga y ejecuta el runtime de Bun. Con eso no depende del Node instalado y esquiva la monitorización que vigila ejecuciones de Node.
Bajo Bun corre una carga de 2,3 MB muy ofuscada (router_init.js) que se demoniza y sigue viva después de que la instalación termine.
Barrido de credenciales: sistema de archivos, APIs de nube, y —esta es la buena— memoria del runner de GitHub Actions leyendo /proc/*/mem. Objetivo: claves de AWS, tokens de npm, cuentas de servicio de Kubernetes, configuraciones de asistentes de IA.
Abuso de OIDC: en vez de necesitar un token de npm guardado en algún sitio, canjea el token OIDC de GitHub Actions por acceso de publicación dinámico. El permiso id-token: write del workflow es la llave.
Propagación: con ese acceso descarga paquetes objetivo, se inyecta, sube la versión exactamente en +3 y republica.
Y por el camino, acuña un bundle Sigstore a través de Fulcio y Rekor — con lo cual el tarball malicioso sale con procedencia generada desde el contexto del workflow de confianza.

El punto 7 es el que hay que interiorizar. No hubo falsificación. La cadena de confianza funcionó exactamente como está diseñada; lo que estaba comprometido era el eslabón anterior, el runner de CI. La procedencia responde a «¿esto se construyó donde dice?», y la respuesta era sí. No responde a «¿lo que se construyó es lo que el mantenedor escribió?», que es la pregunta que importaba.

Los indicadores publicados, por si tienes que barrer: workflows que hablen con api.masscan[.]cloud o 83.142.209.194, y artefactos de persistencia llamados router_init.js, pgmonitor.py o pgsql-monitor.service.

Entonces, ¿sirve el trusted publishing?

Sí, y mucho. Pero conviene tener claro el reparto, porque el consejo genérico no lo hace:

Amenaza	¿Lo para OIDC?
Token de npm robado de un portátil	✅ Sí — no hay token que robar
Token filtrado en un log de CI o en un `.env`	✅ Sí
Phishing al mantenedor (el caso `debug`/`chalk`)	✅ En gran medida
Token válido meses después de que el mantenedor se vaya	✅ Sí
Runner de CI comprometido durante el build	⛔ No
Dependencia maliciosa que se ejecuta en `postinstall`	⛔ No
Envenenamiento de la caché de CI	⛔ No
Cuenta de GitHub del mantenedor comprometida	⛔ No

La lectura correcta: OIDC elimina el secreto de larga vida, que era el vector dominante hasta 2025. No defiende el proceso que emite la publicación. Y a medida que el primer vector se cierra, los ataques se mueven al segundo. Eso es exactamente lo que muestra la cronología de arriba.

Un dato para calibrar cuánta gente sigue en la primera casilla: según el análisis de Aikido, de los 51.370 paquetes más descargados solo 11.001 usan trusted publishing — un 21,4 %, que cubre apenas el 25 % del volumen de descargas. Tres cuartas partes de lo que instalas cada día sigue publicándose con tokens. Y la adopción se mueve a golpe de incidente: de una base de ~35 paquetes nuevos por semana se pasó a 372 la semana de Shai-Hulud 2.0, y luego la urgencia se desinfla otra vez.

Así que el mensaje no es «el trusted publishing falló». Es «migra igualmente, y además haz estas cuatro cosas».

Las cuatro medidas que sí habrían parado esto

1. Enfriamiento de dependencias: no instales lo que se publicó esta mañana

Esta es, con diferencia, la de mejor relación impacto/esfuerzo, y sigue siendo la menos usada.

La idea es de una simplicidad ofensiva: decirle al gestor de paquetes que ignore las versiones que llevan menos de N días publicadas. Casi todas estas campañas se detectan y se retiran en horas — las versiones de debug y chalk estuvieron vivas dos horas —, así que un retardo modesto te saca por completo de la ventana de exposición. De diez ataques analizados, ocho tuvieron ventanas de menos de una semana.

Ya está soportado de forma nativa en los cuatro gestores, con la trampa de que las unidades no coinciden:

Gestor	Clave	Unidad	Desde
npm	`min-release-age`	días	CLI 11.10.0 (feb 2026)
pnpm	`minimumReleaseAge`	minutos	10.16 (sep 2025)
Yarn	`npmMinimalAgeGate`	minutos	Berry 4.10.0
Bun	`minimumReleaseAge`	segundos	—

En npm, un .npmrc con una línea:

min-release-age=7

En pnpm, dentro de pnpm-workspace.yaml, con lista de excepciones para lo que publiques tú:

minimumReleaseAge: 10080          # 7 días en minutos
minimumReleaseAgeExclude:
  - '@mi-empresa/*'

Dos avisos prácticos. El primero: el enfriamiento se aplica en la instalación, no al sugerir actualizaciones, así que tu bot de dependencias puede abrir el PR y el npm ci fallar después; conviene configurar el mismo umbral en los dos sitios. El segundo: Bun cuenta en segundos, no en minutos: siete días son 604800, y quien copia el 10080 de pnpm se queda con un enfriamiento de menos de tres horas sin enterarse. Yarn sí acepta duraciones como 7d, y su lista de excepciones no se llama *Exclude sino npmPreapprovedPackages.

Si antes de activarlo quieres ver qué habría frenado en tu proyecto, dep-cooldown, una herramienta open source mía, lee tu lockfile de npm, pnpm, Yarn o Bun y te da la edad de cada versión resuelta, también el día en que instalaste (--as-of). Y npx dep-cooldown --config all imprime la clave de los cuatro gestores con la unidad ya convertida.

2. Separa el runner que instala del runner que publica

Esta es la que habría cortado el ataque de TanStack en seco.

El problema estructural es que en la mayoría de los workflows el mismo job hace npm ci y npm publish. Eso significa que el código de terceros que se ejecuta durante la instalación vive en el mismo proceso que tiene —o puede pedir— el token OIDC.

La forma correcta es partirlo, y que id-token: write exista solo en el job que publica, que no instala nada de terceros:

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read          # sin id-token aquí
    steps:
      - uses: actions/checkout@v5
      - run: npm ci --ignore-scripts
      - run: npm run build
      - run: npm pack
      - uses: actions/upload-artifact@v4
        with: { name: tarball, path: '*.tgz' }

  publish:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write         # el permiso vive solo aquí
    steps:
      - uses: actions/download-artifact@v4
        with: { name: tarball }
      - run: npm publish *.tgz --provenance

Fíjate en el --ignore-scripts del paso de instalación. Los lifecycle hooks son el punto 1 y el punto 2 del ataque; si tu build no los necesita —y muchos no— desactivarlos en CI es gratis. Si alguna dependencia sí los necesita, la lista de excepciones es más corta de lo que crees y merece la pena escribirla a mano.

3. Trata la caché de CI como entrada no confiable

El vector inicial de la oleada de mayo fue envenenamiento de caché. Es un vector poco intuitivo porque la caché parece infraestructura tuya, y no lo es: en GitHub Actions, una rama con menos privilegios puede escribir en una caché que luego lee la rama de release.

Lo mínimo:

Nunca uses pull_request_target sin un límite de confianza explícito. Ese disparador ejecuta con los secretos del repositorio base y con el código del PR delante; es el pie de la puerta.
Claves de caché segregadas por rama o por propósito. Que el workflow de release no comparta clave con el de PRs.
En el job de publicación, no restaures caché en absoluto. Ese job tiene que ser lo más aburrido posible: descarga un artefacto, lo sube. Nada más.

4. Deja de leer la insignia de procedencia como si fuera un veredicto

La procedencia sigue siendo útil: te dice dónde se construyó el paquete. Después de mayo, lo que no puedes hacer es leerla como «esto es seguro».

En la práctica esto significa que la revisión de dependencias no se delega a un badge. Lo que sí funciona:

Fija con package-lock.json y usa siempre npm ci en CI, nunca npm install. Es la diferencia entre reproducir un árbol y resolver uno nuevo cada vez.
Vigila los saltos de versión raros. El gusano incrementaba la versión exactamente en +3. Un patch que salta tres números sin changelog es una señal barata y sorprendentemente buena.
Rota credenciales cuando te toque una oleada, y rota todo: npm, GitHub, secretos de Actions, AWS, Vault, Kubernetes, SSH. Las cargas de estas campañas barren el runner entero, no solo el token de publicar.

Y lo que npm cambió por su cuenta

Parte del trabajo ya te lo hicieron, y conviene saberlo porque afecta a scripts que quizá tengas guardados:

Los tokens clásicos están revocados desde el 9 de diciembre de 2025. No deprecados: revocados. Si un pipeline viejo tuyo dejó de publicar en esa fecha, esta es la razón.
npm login ya no te da un token de larga vida, sino una sesión de dos horas que caduca sola y exige 2FA para publicar.
Los tokens granulares de escritura caducan como máximo a los 90 días. Ya no existe el token eterno, ni pidiéndolo.
Y desde npm CLI 11.10.0 puedes configurar OIDC en bloque para muchos paquetes a la vez, que era la fricción real de migrar una organización con cincuenta paquetes.

Si publicas paquetes, la migración a trusted publishing son literalmente cuatro líneas de YAML —el id-token: write y el --provenance del ejemplo de arriba— más marcar el publicador de confianza en la página del paquete. Hazlo. Pero hazlo sabiendo que acabas de cerrar el vector de 2025, no el de 2026.

Lo que yo haría este mes, en orden

Si tienes media hora, en este orden por rendimiento decreciente:

Pon min-release-age=7 (o el equivalente de tu gestor) en cada repositorio. Cinco minutos, corta la mayoría de las campañas conocidas.
Cambia npm install por npm ci --ignore-scripts en todos tus workflows de CI que no necesiten hooks.
Si publicas paquetes, parte el workflow en build y publish, con id-token: write solo en el segundo.
Migra a trusted publishing lo que aún publique con token granular.
Audita los pull_request_target que tengas y las claves de caché compartidas entre ramas.

Ninguna de las cinco es cara. Y la incómoda de aceptar: la primera, que es la más eficaz de todas, no requiere confiar en nadie ni entender ningún ataque. Solo esperar una semana.

Para seguir:

Vibe coding seguro: evitar vulnerabilidades en el código de IA — el otro frente por el que entra código que nadie revisó.
Guía completa de Docker en 2026 — aislar el build es la mitad de la defensa de este artículo.
Herramientas para auditar la seguridad de un dominio — el equivalente de esta revisión, pero hacia fuera.

Preguntas frecuentes

¿El trusted publishing con OIDC sigue mereciendo la pena después del ataque de mayo de 2026?

Sí, y hay que migrar igualmente. OIDC elimina por completo el token de larga vida, que fue el vector dominante hasta 2025: no hay nada que robar de un portátil, de un log de CI ni de un mantenedor mediante phishing. Lo que no cubre es el proceso que emite la publicación: si el runner de CI está comprometido durante el build, el atacante canjea el token OIDC igual que lo haría el workflow legítimo. Es una capa, no un perímetro.

¿Cómo pudo el gusano Shai-Hulud generar procedencia Sigstore válida?

Porque no la falsificó: la generó de verdad. La carga maliciosa se ejecutaba dentro del propio runner de GitHub Actions del proyecto, pidió un token OIDC con el permiso id-token: write del workflow, lo canjeó por acceso de publicación en npm, y acuñó un bundle Sigstore a través de Fulcio y Rekor desde ese contexto de confianza. La procedencia responde a «¿esto se construyó donde dice?», y la respuesta era sí. No responde a «¿lo construido es lo que escribió el mantenedor?».

¿Qué es el enfriamiento de dependencias y cómo se configura?

Es decirle al gestor de paquetes que ignore las versiones publicadas hace menos de N días, para no instalar nunca una versión maliciosa dentro de su ventana de vida (que suele ser de horas). En npm es min-release-age en el .npmrc y se mide en días (desde el CLI 11.10.0, febrero de 2026); en pnpm es minimumReleaseAge y se mide en minutos (desde 10.16); en Yarn es npmMinimalAgeGate en minutos y en Bun minimumReleaseAge en segundos. Un umbral de siete días habría bloqueado ocho de los diez últimos ataques analizados.

¿Por qué hay que separar el job que instala del que publica en CI?

Porque si el mismo job hace npm ci y npm publish, el código de terceros que se ejecuta durante la instalación vive en el mismo proceso que tiene acceso al token OIDC. Así entró el ataque contra TanStack: una dependencia maliciosa se ejecutó en un lifecycle hook, leyó la memoria del runner y canjeó el token. La solución es que id-token: write exista solo en un job de publicación que no instale nada de terceros y se limite a subir un artefacto ya construido.

¿Qué porcentaje de paquetes de npm usa ya trusted publishing?

Poco: de los 51.370 paquetes más descargados, 11.001 lo usan — un 21,4 %, que cubre alrededor del 25 % del volumen total de descargas. Es decir, tres cuartas partes de lo que se instala a diario sigue publicándose con tokens. La adopción sube a golpe de incidente (372 paquetes nuevos la semana de Shai-Hulud 2.0, frente a una base de unos 35 semanales) y vuelve a caer cuando pasa la urgencia.

¿Siguen funcionando los tokens clásicos de npm?

No. npm revocó permanentemente todos los tokens clásicos el 9 de diciembre de 2025. Desde entonces npm login entrega una sesión de dos horas en vez de un token de larga vida, y los tokens granulares de escritura caducan como máximo a los 90 días. Si un pipeline antiguo dejó de publicar en esas fechas, la causa es esa.

Ollama con GPU AMD: los cinco fallos que te dejan en CPU sin avisar

Marco Orta — Tue, 08 Sep 2026 00:00:00 GMT

El peor fallo de Ollama con una GPU AMD no es el que te tira el servidor. Es el que no te tira nada: Ollama arranca, responde, contesta bien — y lo hace en CPU, a 15,89 tokens por segundo en vez de 132,48. Un 8,3x de penalización que no aparece en ningún log salvo que lo busques, porque para Ollama eso no es un error: es un fallback.

Este artículo es el resumen de tres semanas midiendo una Radeon RX 7900 XTX de 24 GB sobre un Ryzen 9 7950X3D, en Windows, en Linux nativo y dentro de WSL2. No es una guía de instalación —de esas hay muchas— sino el inventario de las cinco formas en que este montaje se rompe sin decírtelo, con los números de cada una y con lo que probé que no las arregla, que suele ser más útil.

Los tok/s de aquí son de una tarjeta concreta con un entorno concreto. Lo que sí se traslada tal cual son los modos de fallo y el método para cazarlos.

Antes de nada: la comprobación de treinta segundos

Si te llevas una sola cosa del artículo, que sea esta. Ollama sondea la GPU una única vez, al arrancar, y no vuelve a mirar. Así que hay dos preguntas que responder siempre, y ninguna se contesta mirando si el chat va «rápido»:

1. ¿Qué backend declaró el servidor al arrancar? Está en el log de arranque (%LOCALAPPDATA%\Ollama\server.log en Windows, journalctl -u ollama en Linux):

library=Vulkan compute=0.0 name=Vulkan0 description="AMD Radeon RX 7900 XTX"
libdirs=ollama,vulkan  total="24.0 GiB" available="23.2 GiB"

Lo que buscas es library=. Si dice cpu, ya está: no hay GPU, y no te lo va a decir de otra forma.

2. ¿El modelo entró entero? ollama ps te da el reparto:

ollama ps
# NAME              SIZE     PROCESSOR
# gpt-oss:20b       16 GB    100% GPU

Cualquier cosa que no sea 100 % GPU es un modelo partido entre GPU y CPU, y eso no da error tampoco.

Un detalle que me costó un verificador entero: no exijas compute=gfx1100 ni un pci_id. El backend Vulkan reporta compute=0.0 y pci_id="" donde ROCm daba los valores reales, así que un script que compruebe esos campos suspende un sistema perfectamente sano. Lee library= y libdirs=, y nada más.

Fallo 1: la GPU integrada del procesador se lleva el trabajo

Este es el más traicionero porque el hardware culpable no es el que estás mirando.

Si tienes un Ryzen de escritorio con gráficos integrados —los 7000 en adelante los llevan casi todos— tu máquina tiene dos GPU AMD, no una. Y la enumeración de ROCm las ordena como le da la gana:

ROCm0: AMD Radeon(TM) Graphics (36694 MiB)   <- la integrada
ROCm1: AMD Radeon RX 7900 XTX (24560 MiB)

La integrada sale primera y reporta 36 GB de VRAM (que no tiene: es RAM del sistema). Los binarios de llama.cpp la eligen, cargan kernels compilados para gfx1100 y revientan:

ggml-cuda.cu:106: ROCm error
ROCm error: device kernel image is invalid
  current device: 1, in function ggml_cuda_kernel_launch

Lo que no lo arregla —y lo probé todo antes de rendirme:

Intento	Resultado
`--device ROCm1` (elegirla por nombre)	⛔ mismo error
`HIP_VISIBLE_DEVICES=0` y `=1`	⛔ mismo error o «no usable GPU found»
`ROCR_VISIBLE_DEVICES=1` + `--device ROCm0`	⛔ igual
`ROCBLAS_TENSILE_LIBPATH` al directorio de kernels	⛔ igual (los de `gfx1100` sí estaban)

Lo que sí lo arregla: desactivar la integrada en la BIOS. Con un solo dispositivo no hay nada que elegir mal y arranca a la primera, sin banderas:

	antes	después
`--list-devices`	integrada + dedicada	solo la RX 7900 XTX
`llama-server` suelto	⛔ `kernel image is invalid`	✅ 136 tok/s
Ollama	118 tok/s	132,5 tok/s

El miedo razonable era perder VRAM al mover el monitor a la dedicada. Medido: cuesta 0,2 GiB. Con la pantalla a 3440×1440 y 165 Hz colgando de la tarjeta grande, Ollama sigue reportando total 24.0 GiB / available 23.8 GiB. El intercambio sale gratis.

Y una nota para no volverse loco: bajo Ollama esto no pasa, porque Ollama enmascara la integrada por su cuenta y para él la dedicada es ROCm0. Por eso puedes tener a Ollama funcionando y a llama-server fallando en la misma máquina con los mismos pesos. No estás loco: son dos enumeraciones distintas.

Fallo 2: actualizar cualquier cosa devuelve el backend al principio

Ya lo he dicho arriba, pero merece su propia sección porque es el que más caro sale: Ollama sondea la GPU al arrancar y punto.

Tras una reinstalación de drivers de AMD, el servicio se quedó sirviendo así:

inference compute  id=cpu  library=cpu

Sin un error. Sin un aviso. 15,89 tok/s contra 132,48. Reiniciar Ollama lo devolvió a library=ROCm compute=gfx1100 y a los 132.

Hay una segunda versión de este mismo fallo, y es peor porque no la disparas tú: cada actualización de Ollama reinstala el bundle de ROCm. Si habías cambiado a Vulkan a propósito, el update te devuelve a ROCm en silencio. Nadie te avisa; simplemente el número que llevabas semanas midiendo deja de ser el mismo.

La regla operativa que salió de esto: pasa el comprobador después de tocar drivers, BIOS o versión de Ollama. No después de que algo vaya mal — después de tocar, siempre, aunque no vaya mal.

Fallo 3: dentro de WSL2 no hay GPU para Ollama, y no la va a haber

Esta es la que más tiempo me comió, así que va con detalle para que no se lo comas tú.

La pregunta era razonable: si el Linux nativo le saca a Windows entre un 6,7 y un 19,5 % en tok/s, ¿me lo llevo dentro de WSL y me ahorro reiniciar? La respuesta es que Ollama en WSL no usa la GPU en absoluto. Y no es un problema de drivers.

Lo medido, en orden:

Comprobación	Resultado
`/dev/kfd` y `/sys/class/kfd`	⛔ no existen
`/dev/dxg`	✅ existe (la vía de WSL)
¿HIP computa en WSL?	✅ SÍ — sonda con `hipcc`: `hipGetDeviceCount rc=0 n=1`, `gfx1100`
Ollama detecta GPU	⛔ `library=cpu`
`HSA_ENABLE_DXG_DETECTION=1`	⛔ no cambia nada
`llama-server --list-devices` con ROCm	⛔ `Available devices: (none)`
`llama-server --list-devices` con Vulkan	⛔ `Available devices: (none)`

La paradoja que lo explica: HIP sí funciona en WSL, a través de la runtime HSA que habla con /dev/dxg. Pero Ollama enumera GPUs leyendo la topología KFD de sysfs, que WSL no expone. No falta el driver — Ollama busca por una puerta que en WSL no existe.

Con OLLAMA_DEBUG=1 aparece la causa real, que de otro modo queda enterrada:

failure during llama-server GPU discovery
error="llama-server --list-devices failed: signal: segmentation fault (core dumped)"

Circula por ahí una receta —el issue 16551 de Ollama, que es el caso idéntico: misma tarjeta, mismo WSL2, misma ROCm 7.2— cuyo autor reporta library=ROCm compute=gfx1100 al 100 % de GPU colocando el bundle de ROCm y poniendo HSA_ENABLE_DXG_DETECTION=1. Probado aquí, no reproduce.

¿Y el backend Vulkan? En WSL exigiría el ICD dzn (Vulkan sobre D3D12), que Ubuntu no empaqueta. Se podría compilar Mesa con -Dvulkan-drivers=microsoft-experimental y ver qué pasa, pero es trabajo grande con pago incierto.

Conclusión práctica: para Ollama, WSL está descartado. Las dos salidas son el Ollama de Windows (que sí usa la GPU y es lo que hay hoy) o arrancar en Linux nativo. Y si desarrollas dentro de WSL como yo, la buena noticia es que no hace falta mover Ollama: con WSL2 en networkingMode=mirrored, localhost:11434 desde WSL alcanza el Ollama de Windows sin configurar nada.

Fallo 4: el modelo no cabe, se parte, y sigue contestando

Cuando pides más contexto del que entra en la VRAM, Ollama no te dice que no. Reparte el modelo entre GPU y CPU y sigue. El síntoma es size_vram < size en /api/ps, y nada más.

Medido con qwen3.8 (27,3B) en la 7900 XTX, con OLLAMA_FLASH_ATTENTION=1 y la caché KV en q8_0:

`num_ctx` pedido	En GPU
262.144	⛔ 63,4 % — un tercio en CPU
131.072	⛔ 92,4 %
122.880	✅ 100 % (con 0,6 GiB de margen)

Con 0,6 GiB libres, cualquier cosa que abras en el escritorio lo tira. Ese techo es de esa tarde y de esa pantalla, no una constante del modelo.

Y aquí va el aviso que casi me cuesta una decisión mal tomada: ollama ps subestima la VRAM real entre 4,3 y 6,8 GiB. Cruzado contra el contador del sistema, con cuatro modelos:

Modelo	`ollama ps`	VRAM real
`gpt-oss:20b`	12,33 GiB	16,59 GiB
`muse-glimmer` (27,9B)	15,49 GiB	20,77 GiB
`gemma4` (25,8B)	17,24 GiB	22,37 GiB
`qwen3.8` (27,3B)	16,61 GiB	23,36 GiB

Para decidir sobre memoria, la columna de ps no sirve. Solo sirve para saber si Ollama repartió a CPU. Si estás calculando si un modelo te cabe, mide la VRAM del sistema, no la que Ollama declara.

Fallo 5: te recorta el contexto y te deja creer que lo tienes

Variante fina del anterior. Si a muse-glimmer o a gpt-oss les pides num_ctx: 262144, cargan tan felices — y el context_length que devuelve /api/ps dice 131072. Lo que pediste no es lo que tienes.

La causa de fondo es que estos modelos tienen un techo de arquitectura por debajo del de la tarjeta. Y explica algo contraintuitivo que sale al medir: el tamaño en disco no predice el contexto máximo. Lo que decide es si el modelo usa ventana deslizante (SWA) o KV denso:

Modelo	SWA	Crecimiento de KV de 16K a 128K
`muse-glimmer`	2048	~0
`gpt-oss`	128	+0,36 GiB
`gemma4`	1024	+0,40 GiB
`qwen3.8`	— (KV denso)	+1,35 GiB

Tres de los cuatro tocan su techo de arquitectura y ni se enteran de la VRAM. El único que paga contexto de verdad es el único que se sale.

Lee siempre el context_length real de /api/ps, no el que mandaste.

ROCm o Vulkan en 2026: qué gana cada uno

Este es el cambio de fondo del año y por eso el artículo llega ahora. Ollama incorporó soporte Vulkan experimental en la 0.12.6 y a lo largo de 2026 ha ido llegando a los binarios, con el argumento de abrir la puerta a las GPU de AMD e Intel que ROCm nunca soportó — que son la mayoría de las de consumo.

En mi máquina, forzando cada backend con el mismo Ollama y los mismos pesos, Vulkan gana:

Modelo	Ganancia de Vulkan sobre ROCm
`gpt-oss:20b`	+17,8 %
`gemma4`	+30,1 %
`muse-glimmer`	+30,3 %

Rangos disjuntos en dos rondas independientes, así que la señal es real. Y encaja con lo que reportan otros: en una RX 9070 XT, Llama 2 7B Q4_0 decodifica a 137 tok/s con Vulkan contra 101 con ROCm.

Con dos advertencias que casi nadie pone.

La primera: el delta compara dos cosas a la vez. En Windows es ROCm 7.1 contra AMDVLK; en Linux es ROCm 7.2.4 contra RADV. Un ROCm peor infla exactamente el mismo número que un Vulkan mejor, y no están separados.

La segunda es un coste que no vi venir. Vulkan deja 0,6 GiB menos de VRAM disponible: 23,2 GiB declarados contra 23,8 con ROCm. Para tres de mis cuatro modelos da igual porque no apuraban la tarjeta. Para qwen3.8, que iba justo de 0,6 GiB, se lo come entero:

`num_ctx`	Con Vulkan
122.880 (el techo con ROCm)	⛔ 93,8 % en GPU
98.304	✅ 100 %

El intercambio real de esta palanca no es velocidad contra estabilidad: es velocidad contra contexto. Si tu modelo apura la tarjeta, Vulkan te cuesta ventana. Si no la apura, es gratis.

Lo que sigue sin medir —ni yo ni casi nadie— es la estabilidad de Vulkan en sesiones de horas. Para un chat de diez minutos da igual; para un agente que lleva toda la tarde en bucle, no.

El checklist, entero

Lo que hago ahora cada vez que toco esta máquina:

Desactiva la GPU integrada en la BIOS si tienes un Ryzen con gráficos. Cuesta 0,2 GiB y quita un eje entero de ambigüedad.
Reinicia Ollama después de tocar drivers, BIOS o versión. No es opcional: sondea una vez.
Comprueba library= en el log de arranque. No compute=, no pci_id.
Comprueba que ollama ps dice 100 % GPU antes de dar por buena cualquier medida.
Lee el context_length real de /api/ps, no el que enviaste.
Para decidir sobre memoria, mide la VRAM del sistema, no la columna de ollama ps.
En WSL, no lo intentes. Apunta a localhost:11434 contra el Ollama de Windows.
Cierra Chrome, Spotify y Slack antes de medir. No tanto por los tok/s como por el rango: una diferencia real del 2 % se pierde si el ruido lo ensancha.

Y la que resume todas: un vacío no es un cero. Cuando un instrumento no devuelve nada, la lectura no es «no hay»; es «no pude mirar». En esta máquina, Get-Process | Modules devolvió 0 módulos y estuve a punto de leerlo como «no hay capas cargadas». Eran 0 porque el proceso corría elevado y yo no podía verlo. Lo salvó tener un caso de control al lado —explorer, mismo usuario, 389 módulos—. Sin ese contraste, el cero se lee como un dato.

Si te estás planteando el hardware

La conclusión honesta después de todo esto: una Radeon de consumo corre modelos locales perfectamente bien en 2026, y las cifras están al nivel de lo que se publica para NVIDIA en el mismo rango. ROCm 7.2 es la primera versión donde Ollama, LM Studio, llama.cpp y vLLM funcionan sobre Radeon sin parchear a mano.

Lo que sigue costando más que en NVIDIA no son los tok/s: es el diagnóstico. Todo lo de este artículo es tiempo que en una 4090 no habrías gastado, no porque el hardware sea peor, sino porque el camino está menos pisado y los fallos son silenciosos en vez de ruidosos.

Si eso te cuadra —y a mí me cuadra, porque 24 GB de VRAM a este precio no existen en el otro lado— este artículo es el atajo por los cinco agujeros.

Para seguir:

IA sin mandar datos fuera: LLM local para despachos y PyMEs — el porqué de todo esto: qué resuelve de verdad un modelo local y qué no.
Cuánto cuesta la API de OpenAI, Claude y Gemini en 2026 — el número con el que comparar antes de comprar tarjeta.
Retiran el modelo de IA que usa tu negocio — la razón por la que tener el modelo en casa deja de ser un capricho.

Preguntas frecuentes

¿Cómo sé si Ollama está usando mi GPU AMD?

Con dos comprobaciones, no con una. Primero, el log de arranque del servidor (%LOCALAPPDATA%\Ollama\server.log en Windows, journalctl -u ollama en Linux) tiene que declarar library=ROCm o library=Vulkan; si dice library=cpu, no hay GPU. Segundo, ollama ps tiene que decir 100% GPU: cualquier otro valor significa que el modelo está partido entre GPU y CPU. Ollama no da error en ninguno de los dos casos, solo va más lento.

¿Por qué Ollama corre en CPU después de actualizar los drivers?

Porque Ollama sondea la GPU una sola vez, al arrancar, y no vuelve a mirar. Si actualizas drivers, cambias la BIOS o instalas una versión nueva mientras el servicio está en marcha, se queda con la detección vieja y pasa a CPU sin dar ningún error. Medido en una RX 7900 XTX: 15,89 tok/s en CPU contra 132,48 en GPU, un 8,3x. La solución es reiniciar Ollama y volver a comprobar la línea library= del log.

¿Se puede usar la GPU AMD con Ollama dentro de WSL2?

No. Comprobado en agosto de 2026 con una RX 7900 XTX y ROCm 7.2: Ollama enumera las GPU leyendo la topología KFD de sysfs, y WSL no expone /dev/kfd ni /sys/class/kfd. HIP sí computa en WSL a través de /dev/dxg, pero Ollama no busca por ahí, y HSA_ENABLE_DXG_DETECTION=1 no lo cambia. Tanto ROCm como Vulkan devuelven «Available devices: (none)». La salida práctica es apuntar a localhost:11434 contra el Ollama de Windows: con WSL2 en networkingMode=mirrored funciona sin configurar nada.

¿Es mejor ROCm o Vulkan para Ollama en una GPU AMD?

Depende de si tu modelo apura la VRAM. En una RX 7900 XTX, Vulkan gana entre un 17,8 % y un 30,3 % en tokens por segundo según el modelo, con rangos disjuntos en dos rondas. Pero Vulkan deja 0,6 GiB menos de VRAM disponible (23,2 frente a 23,8 GiB), así que un modelo que iba justo de contexto deja de caber. El intercambio no es velocidad contra estabilidad: es velocidad contra ventana de contexto.

¿Por qué falla llama.cpp con «device kernel image is invalid» en un Ryzen?

Porque la máquina tiene dos GPU AMD: la dedicada y la integrada del procesador. ROCm enumera la integrada primero, el binario la elige, y los kernels compilados para gfx1100 no valen para ese chip. Ni --device por nombre ni HIP_VISIBLE_DEVICES ni ROCR_VISIBLE_DEVICES lo arreglan. Lo único que funciona es desactivar la integrada en la BIOS, y cuesta solo 0,2 GiB de VRAM. Ollama no sufre esto porque enmascara la integrada por su cuenta.

¿Cuánta VRAM necesita de verdad un modelo en Ollama?

Más de la que dice ollama ps, que subestima entre 4,3 y 6,8 GiB. Medido con cuatro modelos en una tarjeta de 24 GB: gpt-oss:20b declara 12,33 GiB y ocupa 16,59; qwen3.8 declara 16,61 y ocupa 23,36. Para decidir si un modelo cabe hay que mirar el contador de VRAM del sistema; la columna de ollama ps solo sirve para saber si el modelo se repartió a CPU.

GPT-6 Astra para desarrolladores: el precipicio de precio que nadie puso en el titular

Marco Orta — Sat, 05 Sep 2026 00:00:00 GMT

OpenAI lanzó GPT-6 Astra el 3 de septiembre de 2026 con una ventana de contexto de 1,050,000 tokens. Lo que la cobertura del lanzamiento se saltó: en el momento en que una petición pasa de 272,000 tokens de entrada, se recobra la petición completa al doble de entrada y 1.5x de salida. No el excedente — todo. Un token después de la línea prácticamente duplica la cuenta de esa llamada. La ventana que te venden es la ventana que te cobran al doble por usar.

Esa es la primera de cinco cosas que importan si eres quien escribe el código y no quien lee la gráfica de benchmarks. Este post es la lectura del lado del desarrollador: precios, restricciones de acceso, lo que Astra explícitamente no soporta, el parámetro que te va a romper la validación y —la que más me importa por la gente que me escribe— por qué Astra es el destino equivocado para los modelos que OpenAI apaga el 23 de octubre.

Qué es Astra de verdad, en una sola tabla

	GPT-6 Astra
ID del modelo en la API	`gpt-6-astra` (un solo snapshot)
Ventana de contexto	1,050,000 tokens
Entrada máxima	922,000 tokens
Salida máxima	128,000 tokens
Corte de conocimiento	30 de abril de 2026
Entrada / salida	$10 / $50 por millón
Entrada en caché / escritura de caché	$1.00 / $12.50 por millón
Batch y Flex	50 % de la tarifa estándar
Modo Fast	2x estándar, hasta ~2.5x de velocidad
Arriba de 272K de entrada	2x entrada y caché, 1.5x salida — sobre la petición completa
Esfuerzo de razonamiento	`low`, `medium`, `high`, `xhigh`, `max`
Endpoints	Chat Completions, Responses, Batch
No soporta	Realtime, Assistants, fine-tuning, embeddings, generación de imágenes, audio, moderación, Completions legacy

La disponibilidad va por etapas: primero un grupo limitado de organizaciones (los programas Daybreak y Trusted Access de OpenAI), después ChatGPT Plus, Pro, Business y Enterprise “en los próximos días”, y luego la API y Amazon Bedrock. Los espacios de Enterprise lo traen apagado por defecto — un administrador tiene que prenderlo, que va a ser el primer ticket de soporte que levante tu equipo.

1. El precipicio de los 272K, con la aritmética

Esta es la parte que conviene interiorizar antes de conectar Astra a cualquier cosa que corra en bucle.

El recargo no es precio marginal. No es “los tokens arriba de 272K cuestan el doble”. Según la propia página del modelo de OpenAI, los prompts arriba de 272,000 tokens de entrada se cobran a 2x las tarifas de entrada y caché y 1.5x la de salida sobre la petición completa. Lo que produce esto:

Petición	Tokens de entrada	Tokens de salida	Costo entrada	Costo salida	Total
Justo debajo	272,000	8,000	$2.72	$0.40	$3.12
Justo arriba	273,000	8,000	$5.46	$0.60	$6.06
Entrada máxima	922,000	8,000	$18.44	$0.60	$19.04
Entrada y salida máximas	922,000	128,000	$18.44	$9.60	$28.04

Mil tokens extra de entrada —un archivo mediano, un par de resultados de herramienta— convierten una llamada de $3.12 en una de $6.06. Es un aumento del 94 % por un aumento del 0.4 % en la entrada.

Ahora mete eso en un bucle de agente. Los agentes no mandan un prompt grande: acumulan. El contexto crece con cada resultado de herramienta, cada archivo leído, cada reintento. Así que un agente que arranca cada sesión cómodamente debajo de la línea va a cruzarla en silencio como a la segunda hora de una refactorización larga — y cada llamada siguiente de esa sesión se cobra del lado caro. No truena nada. No te avisa nada. Te enteras en la factura.

Si alguna vez mediste lo que quema un agente de verdad, ya conoces la forma del problema: en 35 días de Claude Code registré 7,970 millones de tokens facturables. Aplícale una función escalón de 2x a una curva así y el número deja de ser teórico.

Qué hacer de verdad:

Pon un techo duro de entrada debajo de la línea, no en la línea. 260,000 deja espacio para el resultado de herramienta que no anticipaste. Imponlo en tu propio código antes de la llamada, porque la API no lo va a hacer por ti.
Cuenta antes de mandar. Contar tokens es barato y el precipicio no. Si tu stack todavía no mide la entrada por petición, esa es la instrumentación que va primero.
Acuérdate de que el caché de prompts está del mismo lado del precipicio. La entrada en caché son $1/M normalmente y $2/M pasando 272K. El caché suaviza la pendiente, no mueve el escalón.
Usa Batch donde la latencia lo permita. El 50 % de descuento aplica antes del multiplicador, así que batch con contexto largo sigue saliendo más barato que estándar con contexto largo.

Antes de mandar una plantilla de prompt a producción, revisa su tamaño. El precipicio es un número alrededor del cual puedes diseñar — pero solo si sabes de qué lado estás.

2. Las restricciones de acceso son reales, y pegan en trabajo no relacionado

Astra es el primer modelo que OpenAI clasifica en nivel Crítico de capacidad en ciberseguridad bajo su Preparedness Framework. En las propias palabras llanas de OpenAI: con las herramientas y el acceso correctos, puede encontrar fallas de seguridad desconocidas hasta ahora y desarrollar nuevas formas de explotarlas en muchos sistemas bien protegidos, sin que una persona guíe cada paso. Durante la evaluación desarrolló exploits para navegadores y sistemas operativos endurecidos, y encontró dos vulnerabilidades de V8 que nadie conocía.

La consecuencia para quien desarrolla no es abstracta:

El acceso estándar de la API rechaza de plano el trabajo avanzado de ciberseguridad. El descubrimiento y desarrollo de exploits no queda “en pausa para revisión” — se rechaza.
La capacidad avanzada está detrás de Daybreak y Trusted Access. Si haces trabajo legítimo de seguridad defensiva, aplicas; no basta con pagar.
Las cuentas fuera de esos programas pueden toparse con lentitud, pausas o bloqueos, y según los reportes “a veces durante trabajo no relacionado”. Esa última parte es la operativamente importante. Un clasificador de seguridad calibrado para una capacidad de nivel Crítico va a tener falsos positivos, y los falsos positivos sobre una llamada síncrona a la API son picos de latencia y peticiones fallidas dentro de tu producto.

Si vas a poner Astra detrás de una función que ve el usuario, constrúyelo para eso: timeouts, un modelo de respaldo y una ruta de reintento que degrade a un modelo más chico en lugar de sacar un error. Trata “la capa de seguridad dijo que no” como un modo de falla normal con su propia rama de código, no como una excepción que registras y olvidas.

Hay una segunda señal que vale leer con honestidad en vez de descartarla. La evaluación del AI Safety Institute del Reino Unido encontró comportamiento de ataque a la cadena de suministro en 2 de 500 corridas muestreadas, y la propia OpenAI apunta una caída sustancial en la monitoreabilidad de la cadena de razonamiento frente a modelos anteriores — es decir, el modelo puede completar tareas sin exponer su razonamiento. Si vas a correr Astra con acceso a shell dentro de CI, approval_policy = "never" ya no es un valor por defecto defendible. Es el mismo argumento que hice sobre revisar el código escrito por IA antes de que llegue a producción, solo que ahora el radio de daño incluye tu pipeline de build.

3. Lo que no soporta (la trampa del reemplazo directo)

Astra es un modelo de razonamiento, uso de computadora y contexto largo. No es un reemplazo general de tu cuenta de OpenAI. La lista de lo que no soporta es larga y específica:

Realtime. Assistants. Fine-tuning. Embeddings. Generación de imágenes. Audio. Moderación. Completions legacy.

Dos de esos merecen mención aparte porque cargan peso en sistemas reales:

Sin fine-tuning. Si tu producto depende de un modelo afinado, Astra no es un camino hacia adelante para él, y OpenAI además cierra la creación de nuevos trabajos de fine-tuning autoservicio el 6 de enero de 2027. Esos dos hechos juntos son una decisión de estrategia, no un cambio de configuración.
Sin embeddings. El paso de embeddings de tu pipeline de RAG se queda donde está. Astra cambia la mitad de generación de RAG y nada de la mitad de recuperación — y con una ventana de un millón de tokens, la pregunta más interesante es si partes de tu capa de RAG ya están resolviendo un problema que dejaste de tener. (Con los precios de arriba: probablemente no. Recuperar sigue siendo más barato que rellenar.)

4. `xhigh` y `max`: el parámetro que rompe tu validación

Astra agrega dos niveles de esfuerzo de razonamiento arriba de high: xhigh y max. Cinco en total, en orden: low, medium, high, xhigh, max.

Es un cambio chico con filo. Si en cualquier punto de tu stack validas reasoning_effort contra un enum quemado, una unión de TypeScript, un Literal de Pydantic, un esquema de Zod, un enum de JSON Schema o una restricción CHECK en base de datos — esa validación ahora rechaza valores válidos. La falla ocurre en tu capa, no en la de OpenAI, que es justo el tipo de ruptura que cuesta una tarde encontrar porque el mensaje de error apunta a tu propio código y parece un bug que tú metiste.

// Antes
type ReasoningEffort = 'low' | 'medium' | 'high';

// Después
type ReasoningEffort = 'low' | 'medium' | 'high' | 'xhigh' | 'max';

Busca la cadena 'high' junto a reasoning en tu código y en tu configuración de infraestructura antes de dejar que alguien seleccione Astra en un selector de modelos.

Sobre el costo: los tokens de razonamiento son tokens de salida, facturados a $50/M (o $75/M pasando el precipicio). max sobre una petición de contexto largo es la combinación más cara que existe hoy en la API. Resérvala para la decisión de arquitectura o la sesión de depuración que ya se comió un día — no para el valor por defecto de un archivo de configuración que nadie vuelve a mirar.

5. Las notas de contexto reemplazan la compactación — y eso cambia el comportamiento del agente

Este es el cambio que me parece genuinamente subestimado, y no es un número de benchmark.

Todo agente de larga duración pega contra la misma pared: el contexto se llena y el harness compacta — resume la conversación en una más corta y sigue. La compactación pierde información y la pérdida es irreversible. El texto exacto del error del tercer intento fallido, el enfoque que abandonaste y por qué, la aserción específica que se rompió: todo eso se aplana en “probamos varios enfoques para arreglar el bug de autenticación”. Y entonces el agente vuelve a intentar el enfoque abandonado, porque nada en su contexto dice que ya falló.

Astra reemplaza eso con notas persistentes más ventanas de contexto anteriores consultables. Mantiene notas corridas entre ventanas, y puede regresar a buscar en ventanas previas algo que la nota no alcanzó a capturar. En la práctica: el modelo puede recuperar un requisito o el resultado de una prueba de hace dos horas aunque en su momento no se le haya ocurrido anotarlo.

En Codex CLI (v0.153.1 o posterior, publicada el 3 de septiembre de 2026) la configuración es:

model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

# Deja que las notas de Astra hagan el trabajo en vez de la compactación de Codex
auto_compact_token_limit = 850000

[tui]
auto_recap = false

Por sesión: codex -m gpt-6-astra --reasoning-effort xhigh "tu tarea", o /model gpt-6-astra a media sesión. Corre codex models para confirmar que tu cuenta sí tiene acceso — el selector solo muestra lo que tu cuenta tiene habilitado, así que un modelo ausente es una respuesta sobre permisos, no un bug.

Fíjate en la tensión con la sección 1: auto_compact_token_limit = 850000 deja deliberadamente que el contexto corra muy por arriba de 272K, porque de eso se trata la función. Estás cambiando dinero por continuidad. Es un intercambio defendible para una sesión de depuración difícil e indefendible para un chatbot.

6. Leer los benchmarks con honestidad

El marcador, con las comparaciones que se publicaron junto a él:

Benchmark	GPT-6 Astra	GPT-5.6 Sol	Claude Opus 5	Claude Fable 5.1
OSWorld 2.0 (uso de computadora)	72.6 %	65.7 %	70.2 %	—
Terminal-Bench 4.0	57.7 %	37.3 %	52.3 %	55.8 %
FrontierMath Tier 4 v2	97.6 %	83.0 %	73.2 %	87.8 %
GPQA Diamond	96.0 %	94.6 %	93.7 %	93.7 %
ExploitBench	100 %	78.5 %	70.0 %	—
Humanity’s Last Exam (con herramientas)	57.2 %	—	63.6 %	65.0 %
DeepSWE v1.1 (programación)	74.1 %	72.7 %	—	—

Tres lecturas honestas:

La ganancia en uso de computadora es la noticia real. 72.6 % en OSWorld con el tiempo de completar tareas cayendo de ~75 minutos a ~40 es un cambio de escalón en lo que un agente puede terminar sin supervisión. Si tu caso de uso es “opera un navegador, una hoja de cálculo y una terminal para completar un trabajo de varios pasos”, esto es otra clase de herramienta.
La ganancia en programación es marginal. 74.1 % contra 72.7 % en DeepSWE está dentro del ruido de una tabla donde Gemini 3.8 Flash y Claude Opus 5 viven en la misma banda. Si estás eligiendo modelo para escribir código, Astra no es la respuesta evidente, y a $10/$50 tampoco es la respuesta barata.
El número de ARC-AGI-3 está haciendo trabajo de marketing. El 99.9 % del titular sale de un harness adaptador. Las llamadas sin estado a la API —que es lo que hace tu código— reportan entre 17 % y 63 % según el nivel de razonamiento. Cualquier benchmark citado con un harness propio es una afirmación sobre el harness tanto como sobre el modelo.

Astra también queda debajo de Claude Fable 5.1 en Humanity’s Last Exam con herramientas (57.2 % contra 65.0 %). “El modelo más capaz jamás desplegado” es una afirmación defendible en agregado; no es cierta en todos los ejes, y los ejes donde no lo es incluyen razonamiento con herramientas, que es lo que hacen los agentes todo el día.

La parte que de verdad necesita la mayoría: el 23 de octubre

Aquí es donde el ruido del lanzamiento choca con la fecha real.

El 23 de octubre de 2026 OpenAI apaga gpt-3.5-turbo, gpt-4, gpt-4-turbo, o1, o1-pro, o3-mini y o4-mini en la API. Después de esa fecha, las llamadas a esos IDs devuelven errores, no respuestas. Ese es el cambio con ruptura que tienes en el calendario, y está a 48 días de este post.

El lanzamiento de Astra va a empujar a mucha gente a migrar directo hacia él. Para la mayoría eso es un error caro.

Lo típico conectado a gpt-3.5-turbo es un chatbot de soporte o un clasificador construido en 2023. gpt-3.5-turbo cerró con un precio publicado de alrededor de $0.50 por millón de entrada y $1.50 por millón de salida. Astra son $10 y $50. Eso es 20 veces el costo de entrada y 33 veces el de salida — para una carga que se eligió precisamente porque era la barata. Migrar un clasificador de alto volumen de gpt-3.5 a Astra no lo moderniza: convierte una línea de $40 al mes en algo que sí vas a notar.

La escalera de migración que sí tiene sentido:

Chatbot o clasificador en gpt-3.5-turbo → el nivel small/mini actual. Más barato que lo que traes, y muchísimo más capaz. Astra ni entra en la conversación.
Carga general en gpt-4 / gpt-4-turbo → el nivel medio actual. Prueba regresiones de prompt; una década de folclore de prompt engineering se afinó contra las manías específicas de gpt-4.
Carga de razonamiento en o1 / o3-mini / o4-mini → aquí Astra sí es candidato genuino, porque ya aceptaste el costo de tokens de razonamiento. Mide con high antes de irte a xhigh.
Agente de horizonte largo que opera software → Astra, y este es el caso para el que se construyó. Presupuesta lo de la sección 1.

El calendario completo, la consulta de auditoría para saber si estás expuesto y la lista de migración están en el calendario de apagones de modelos de IA de 2026 — incluidas las dos fechas de septiembre que caen antes de que Astra siquiera esté disponible en general: la Videos API y sora-2 se retiran el 24 de septiembre, y los snapshots legacy el 28.

Entonces, ¿te cambias?

Traes un chatbot, un clasificador o cualquier cosa de alto volumen y contexto corto: no. Astra es la clase de precio equivocada. Vete al nivel chico, y vete antes del 23 de octubre.

Traes un agente de programación: no con estos números solos. La diferencia en programación contra la generación anterior es marginal y el precio no. Pruébalo en las tareas difíciles —las que hoy fallan— y deja el modelo más barato como predeterminado.

Traes un agente de horizonte largo que maneja un navegador, una terminal o un escritorio: sí, y es la única categoría donde la respuesta es un sí directo. El salto en OSWorld y la arquitectura de notas persistentes apuntan exactamente a ti. Pon el techo de tokens primero.

Haces trabajo de seguridad defensiva: sí, y empieza ya la solicitud a Trusted Access, porque la API estándar va a rechazar justo el trabajo para el que la necesitas.

Tienes algo afinado con fine-tuning: Astra no es tu camino. Planea eso aparte, con la fecha de enero de 2027 en la misma hoja.

Para seguir leyendo:

El calendario de apagones de modelos de IA de 2026 — la fecha del 23 de octubre completa, y cómo comprobar si tu código está expuesto.
Cuánto cuesta programar con agentes de IA — 7,970 millones de tokens medidos, y la aritmética que hace que el precipicio de 272K importe.
IA sin sacar tus datos: LLM locales — la otra respuesta cuando el precio del modelo insignia y la pregunta de retención de datos caen mal las dos.
Migrar tu servidor MCP a la spec 2026-07-28 — Astra soporta MCP y búsqueda de herramientas; la spec de abajo también se movió.

Preguntas frecuentes

¿Cuánto cuesta la API de GPT-6 Astra?

El precio estándar es de 10 dólares por millón de tokens de entrada y 50 dólares por millón de tokens de salida, con la entrada en caché a 1 dólar por millón y las escrituras de caché a 12.50 por millón. El procesamiento Batch y Flex corre al 50 % de la tarifa estándar, y el modo Fast cuesta el doble del estándar a cambio de hasta 2.5 veces la velocidad. Lo crítico: cualquier petición con más de 272,000 tokens de entrada se factura al doble de las tarifas de entrada y caché y a 1.5 veces la de salida sobre la petición completa, no solo sobre los tokens que pasan el umbral.

¿Cuál es la ventana de contexto de GPT-6 Astra?

La ventana de contexto es de 1,050,000 tokens, con un máximo de 922,000 tokens de entrada y 128,000 de salida en una sola petición. El corte de conocimiento es el 30 de abril de 2026. Ten en cuenta que usar más de 272,000 tokens de entrada dispara un recargo que aplica a la petición completa, así que la ventana usable y la ventana económicamente sensata no son el mismo número.

¿Por qué no veo gpt-6-astra en mi cuenta?

El acceso va por etapas. En el lanzamiento Astra llegó a un grupo limitado de organizaciones dentro de los programas Daybreak y Trusted Access de OpenAI, después a los usuarios de ChatGPT Plus, Pro, Business y Enterprise, y luego a la API y a Amazon Bedrock. Los espacios de Enterprise lo traen deshabilitado por defecto y un administrador tiene que activarlo. En Codex CLI, ejecutar "codex models" muestra solo lo que tu cuenta tiene habilitado, así que un modelo ausente normalmente significa restricción de acceso y no un bug.

¿Puedo usar GPT-6 Astra para investigación de seguridad o pruebas de penetración?

No a través del acceso estándar de la API. Astra es el primer modelo que OpenAI clasifica en nivel Crítico de ciberseguridad bajo su Preparedness Framework, y el acceso estándar rechaza de plano el trabajo avanzado de ciberseguridad, como el descubrimiento de exploits, en lugar de pausarlo para revisión. La capacidad avanzada está detrás de los programas Daybreak y Trusted Access. Las cuentas fuera de esos programas también pueden ver lentitud, pausas o bloqueos, según los reportes a veces durante trabajo no relacionado.

¿GPT-6 Astra soporta fine-tuning?

No. Astra soporta Chat Completions, Responses y Batch, y no soporta fine-tuning, Realtime, Assistants, embeddings, generación de imágenes, audio, moderación ni el endpoint legacy de Completions. Esto importa junto a otro cambio de OpenAI: la creación de nuevos trabajos de fine-tuning autoservicio cierra el 6 de enero de 2027, así que cualquier producto que dependa de un modelo afinado necesita un plan que no pase por Astra.

¿Debo migrar mi chatbot de gpt-3.5-turbo a GPT-6 Astra antes del 23 de octubre de 2026?

Casi seguro que no. gpt-3.5-turbo se apaga el 23 de octubre de 2026 junto con gpt-4, gpt-4-turbo, o1, o1-pro, o3-mini y o4-mini, así que sí tienes que moverte. Pero gpt-3.5-turbo cerró con un precio publicado de alrededor de 0.50 dólares por millón de entrada y 1.50 por millón de salida, contra los 10 y 50 de Astra: unas 20 veces el costo de entrada y 33 veces el de salida. Las cargas de alto volumen y contexto corto, como chatbots y clasificadores, pertenecen al nivel small o mini actual, que es a la vez más barato que gpt-3.5-turbo y bastante más capaz.

¿Qué son los niveles de razonamiento xhigh y max?

Astra agrega dos niveles arriba de high, para un total de cinco: low, medium, high, xhigh y max. Cualquier código que valide reasoning_effort contra una lista quemada —una unión de TypeScript, un esquema de Zod o Pydantic, un enum de JSON Schema, una restricción de base de datos— va a rechazar los valores nuevos hasta que se actualice, y el error resultante parece venir de tu propio código. Los tokens de razonamiento se facturan como tokens de salida, así que max sobre una petición de contexto largo es la combinación más cara que ofrece la API hoy.

¿Qué son las notas de contexto y en qué se diferencian de la compactación?

La compactación resume una conversación completa en una más corta cuando se llena la ventana de contexto, lo que pierde de forma irreversible detalles como mensajes de error exactos o enfoques que se probaron y se abandonaron. Astra en cambio mantiene notas persistentes entre ventanas de contexto y deja consultables las ventanas anteriores, así que puede recuperar un requisito o el resultado de una prueba de una ventana previa incluso cuando la nota no lo capturó. En Codex CLI v0.153.1 o posterior esto se configura subiendo auto_compact_token_limit para que las notas de Astra se encarguen de la continuidad en vez de que el harness compacte antes de tiempo.

Kubernetes 1.37: qué se rompe el día que actualizas (y por qué es tu plano de control)

Marco Orta — Sat, 05 Sep 2026 00:00:00 GMT

Kubernetes v1.37 “Garhwal” salió el 26 de agosto de 2026, y su cambio con ruptura principal se está contando mal en casi todos lados. La 1.37 no introduce la regla de que los pods estáticos no pueden referenciar objetos de la API — eso aterrizó en la 1.34. Lo que la 1.37 quita es la salida de emergencia. El feature gate PreventStaticPodAPIReferences desapareció y, según la nota de versión oficial, “ya no se puede desactivar”.

Eso invierte quién está en riesgo. Si nunca te topaste con esto, estás bien. Los clústeres que se rompen el día de la actualización son justo los que ya se toparon en la 1.34, la 1.35 o la 1.36, apagaron el gate para poder avanzar y archivaron el arreglo de verdad para después. Después es ahora, y lo que no arranca es el plano de control.

Los tres bloqueadores, por orden

#	Cambio	Cómo falla	Urgencia
1	Se elimina el gate `PreventStaticPodAPIReferences`	El kubelet rechaza la admisión de los pods estáticos que referencian objetos de la API — incluidos los manifiestos de etcd y kube-apiserver	Bloquea la actualización
2	Se hace cumplir el rechazo de cgroup v1	El kubelet sale al arrancar salvo que pongas `failCgroupV1: false`	Bloquea la actualización
3	Se deprecia el modo `ipvs` de kube-proxy	Solo advertencia al arrancar. Desactivado por defecto en la 1.40, eliminado en la 1.43	Planéalo, no corras

Todo lo demás de esta versión —kube-dns depreciado en favor de CoreDNS, kubectl run --filename/-f depreciado, dieciséis funciones que pasan a estable— es limpieza. Los dos que impiden que un nodo vuelva son los dos primeros.

1. Los pods estáticos ya no pueden referenciar objetos de la API

Cuál es la regla de verdad

La formulación limpia no es “nada de Secrets ni ConfigMaps”. Es la del pull request que lo implementó: los pods estáticos solo pueden usar volúmenes hostPath y emptyDir, y no pueden referenciar objetos de la API en absoluto.

La nota de versión oficial del PR #131837, que lleva un ACTION REQUIRED explícito, nombra la superficie completa:

Antes de actualizar, asegúrate de que los pods estáticos no estén referenciando objetos de la API como ServiceAccounts, ConfigMaps, Secrets, ResourceClaims, CSIDrivers, PersistentVolumeClaims o ClusterTrustBundles.

Fíjate en ServiceAccounts dentro de esa lista. Casi toda la cobertura secundaria de esta versión menciona solo configMapRef y secretRef, y eso se queda corto: un pod estático con un serviceAccountName, una entrada de imagePullSecrets o un volumen respaldado por un PVC queda rechazado igual. En la práctica, los campos que hay que cazar son:

env.valueFrom.configMapKeyRef y env.valueFrom.secretKeyRef
envFrom.configMapRef y envFrom.secretRef
volumes[].configMap, volumes[].secret, volumes[].persistentVolumeClaim, volumes[].projected
serviceAccountName, imagePullSecrets, resourceClaims

Por qué es un problema del plano de control y no de tus cargas

Los pods estáticos son los que el kubelet corre directo del disco desde /etc/kubernetes/manifests/, sin que intervenga el API server. En un clúster de kubeadm ese directorio contiene etcd, kube-apiserver, kube-controller-manager y kube-scheduler.

Así que la forma de fallar no es “uno de mis pods no se programó”. Es: actualizas un nodo del plano de control, el kubelet rechaza la admisión del manifiesto de etcd, y el API server nunca levanta para decirte por qué. Estás depurando desde journalctl -u kubelet en el nodo, no desde kubectl.

El comportamiento viejo era silencioso, y por eso existe esto

Antes de la 1.34 esto no daba error. El pod estático corría, y lo único que fallaba en reconciliar era el pod espejo — la representación de solo lectura que el kubelet crea en la API para que el pod aparezca en kubectl get pods. El contenedor estaba vivo en el nodo y era efectivamente invisible para la API. El PR #131837 cerró eso rechazando la admisión de plano, para que el contenedor nunca se cree en lugar de correr sin que nadie lo vea.

Esa historia es la razón de que el gate existiera: los revisores pidieron que la validación saliera activada por defecto pero desactivable “durante unas cuantas versiones”. Tres ciclos de versión después, el PR #140226 lo eliminó, con milestone v1.37.

La auditoría, antes de tocar un solo nodo

Corre esto en todos los nodos, de plano de control y de trabajo, no en uno:

grep -rlE 'configMapRef|secretRef|configMapKeyRef|secretKeyRef|serviceAccountName|imagePullSecrets|persistentVolumeClaim' \
  /etc/kubernetes/manifests/

Cada archivo que imprima es un manifiesto que tienes que rehacer antes de actualizar ese nodo. El arreglo siempre tiene la misma forma: dejar de sacar el valor de la API y ponerlo en disco, como montaje hostPath o como literal dentro del manifiesto, ya que hostPath y emptyDir son los únicos tipos de volumen que siguen permitidos.

Si tus manifiestos son generados —kubeadm, Cluster API, un chart de Helm que plantilla la config del nodo, un rol de Ansible— audita la plantilla, no solo la salida renderizada, o el siguiente nodo que aprovisiones vuelve a meter el problema.

Antes de dar por bueno un manifiesto rehecho, comprueba que sigue siendo YAML válido y que no rompiste la indentación al arrancar un bloque de volúmenes:

2. cgroup v1: el kubelet simplemente sale

Este es corto y absoluto. El kubelet se niega a correr en un host que usa cgroup v1. No advierte y degrada: sale al arrancar con

kubelet is configured to not run on a host using cgroup v1

El valor por defecto pasó a fallar en la 1.35, y la 1.37 lo mantiene. La única anulación va en KubeletConfiguration:

failCgroupV1: false

Dónde lo pones depende de tu distribución, y el momento importa:

kubeadm: edita el ConfigMap kube-system/kubelet-config y añade el campo antes de actualizar. Ponerlo después de que el kubelet ya se negó a arrancar significa editar configuración en un nodo cuyo plano de control quizá esté caído.
RKE2 / K3s: pasa el argumento del kubelet fail-cgroupv1=false en /etc/rancher/rke2/config.yaml o /etc/rancher/k3s/config.yaml.

Trátalo como un puente, no como un arreglo. Es exactamente la misma categoría de decisión que el gate de los pods estáticos por el que estás leyendo este post: un interruptor de apagado que upstream está retirando.

Comprueba en qué versión de cgroup está cada nodo antes de actualizarlo:

stat -fc %T /sys/fs/cgroup
# cgroup2fs -> v2, vas bien
# tmpfs     -> v1, no vas bien

ls /sys/fs/cgroup/cgroup.controllers   # solo existe en v2

Los nodos que tropiezan con esto son los viejos: hosts de CentOS 7 y Ubuntu 18.04 de larga vida, y cualquier cosa aprovisionada desde una AMI o imagen construida hace años y nunca reconstruida. Si corres un servicio gestionado (EKS, GKE, AKS) con imágenes de nodo actuales, casi seguro ya estás en v2 — pero “casi seguro” está a un stat de ser seguro.

3. IPVS de kube-proxy: depreciado, no eliminado

El mode: ipvs en KubeProxyConfiguration queda depreciado a partir de la 1.37 (KEP-5495). Hoy no se rompe nada: te salen advertencias en los logs de arranque de kube-proxy. La línea de tiempo:

Versión	Estado
v1.35	Empiezan los logs de advertencia
v1.37	Depreciado formalmente, siguen las advertencias
v1.40	Desactivado por defecto, se reactiva solo con feature gate
v1.43	Código eliminado por completo

Vale la pena conocer el motivo porque tumba la objeción habitual: el modo IPVS nunca fue un reemplazo completo de iptables — sigue necesitando iptables por debajo y no puede implementar los Services de Kubernetes por sí solo. El sucesor es nftables, no una vuelta a iptables.

Comprueba qué estás corriendo:

kubectl -n kube-system get cm kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep mode:

Si dice ipvs, tienes de ahora hasta la 1.40 para pasarte a mode: nftables. Eso es más o menos un año de versiones — suficiente para hacerlo a tu ritmo, que es justo la razón para meterlo en el calendario ahora en vez de encontrártelo como la gente se está encontrando el gate de los pods estáticos este mes.

La lista previa a actualizar

Corre todo esto antes del primer nodo, en cada nodo:

# 1. Referencias a la API en pods estáticos — el bloqueador
grep -rlE 'configMapRef|secretRef|configMapKeyRef|secretKeyRef|serviceAccountName|imagePullSecrets|persistentVolumeClaim' \
  /etc/kubernetes/manifests/

# 2. Versión de cgroup — el otro bloqueador
stat -fc %T /sys/fs/cgroup

# 3. Modo de kube-proxy — planear, no bloquear
kubectl -n kube-system get cm kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep mode:

# 4. ¿Sigues en kube-dns en vez de CoreDNS?
kubectl -n kube-system get deploy | grep -E 'kube-dns|coredns'

Salida vacía en el 1, cgroup2fs en el 2 y nftables o iptables en el 3 significa que la actualización va a ser aburrida. Ese es el objetivo.

Quién tiene que actuar de verdad

Desactivaste PreventStaticPodAPIReferences en algún momento desde la 1.34: eres el destinatario de todo este post. Ese gate ya no existe, así que lo que te llevó a desactivarlo ahora bloquea la actualización. Arregla los manifiestos primero, actualiza después.

Corres planos de control de kubeadm que has editado a mano: corre el grep específicamente en los nodos del plano de control. Los archivos editados a mano en /etc/kubernetes/manifests/ son justo donde alguien añade un secretRef o un serviceAccountName resolviendo un problema a las 2 de la mañana.

Tienes nodos de más de unos tres años: comprueba cgroups antes que nada. Un kubelet que sale al arrancar se ve idéntico a una actualización rota, y vas a perder una hora encontrando una respuesta de una línea.

Estás en Kubernetes gestionado con imágenes de nodo actuales: probablemente estás limpio en el 1 y el 2. Revisa el 3 y mete la migración de IPVS en un trimestre, no en un sprint.

Corres mode: ipvs: hoy no se rompe nada. Agenda el paso a nftables antes de la 1.40.

Para seguir leyendo:

Node 26: qué se rompe al actualizar — el mismo formato para el runtime, y el mismo patrón de fallos que no dan error.
Vite 8: qué se rompe al actualizar — la versión que heredaste sin elegirla, que es la otra forma en que muerden estas actualizaciones.
GPT-6 Astra para desarrolladores — si corres agentes con acceso a shell contra un clúster, la sección de seguridad y política de aprobación te aplica directo.

Preguntas frecuentes

¿Qué se rompe al actualizar a Kubernetes 1.37?

Dos cambios pueden bloquear la actualización de plano. El primero: se eliminó el feature gate PreventStaticPodAPIReferences, así que los pods estáticos que referencian objetos de la API reciben rechazo de admisión del kubelet sin forma de optar por salirse, y en clústeres de kubeadm esos pods estáticos incluyen etcd y kube-apiserver. El segundo: el kubelet se niega a arrancar en hosts que usan cgroup v1 salvo que failCgroupV1 esté puesto explícitamente en false. Un tercer cambio, la depreciación del modo IPVS de kube-proxy, solo produce advertencias en la 1.37 y todavía no rompe nada.

¿Por qué fallan los pods estáticos después de actualizar a Kubernetes 1.37?

Porque se quitó la salida de emergencia, no porque la regla sea nueva. La restricción sobre pods estáticos que referencian objetos de la API salió en la 1.34 detrás del feature gate PreventStaticPodAPIReferences, que venía activado por defecto pero se podía desactivar. Kubernetes 1.37 eliminó ese gate por completo, y la nota de versión oficial dice que ya no se puede desactivar. Los clústeres que apagaron el gate para posponer el arreglo son exactamente los que se rompen al actualizar.

¿Qué objetos de la API no puede referenciar un pod estático en Kubernetes 1.37?

La nota de versión oficial lista ServiceAccounts, ConfigMaps, Secrets, ResourceClaims, CSIDrivers, PersistentVolumeClaims y ClusterTrustBundles. La forma más simple de retener la regla es la del pull request que lo implementó: los pods estáticos solo pueden usar volúmenes hostPath y emptyDir. Eso significa que serviceAccountName, imagePullSecrets, envFrom.configMapRef, envFrom.secretRef, env.valueFrom.secretKeyRef, los volúmenes projected y los respaldados por PVC quedan rechazados todos, no solo las referencias a ConfigMap y Secret que mencionan la mayoría de los resúmenes.

¿Cómo compruebo si mi clúster está afectado antes de actualizar?

En cada nodo de plano de control y de trabajo, corre: grep -rlE 'configMapRef|secretRef|configMapKeyRef|secretKeyRef|serviceAccountName|imagePullSecrets|persistentVolumeClaim' /etc/kubernetes/manifests/ — cualquier archivo que imprima hay que rehacerlo antes de actualizar ese nodo. Aparte, corre stat -fc %T /sys/fs/cgroup en cada nodo: cgroup2fs es seguro y tmpfs significa cgroup v1, que impide que el kubelet arranque. Si tus manifiestos los generan kubeadm, Cluster API, Ansible o Helm, audita también la plantilla o los nodos nuevos volverán a meter el problema.

¿Se elimina el modo IPVS de kube-proxy en Kubernetes 1.37?

No. Queda depreciado en la 1.37 bajo el KEP-5495 y solo registra advertencias al arrancar. Se espera que quede desactivado por defecto en la 1.40, donde todavía se puede reactivar mediante feature gate, y eliminado por completo en la 1.43. El reemplazo es el modo nftables, no iptables. El razonamiento es que el modo IPVS siempre necesitó iptables por debajo y nunca pudo implementar los Services de Kubernetes por sí solo.

¿Qué pasaba con los pods estáticos que referenciaban Secrets antes de Kubernetes 1.34?

Fallaba en silencio, y por eso existe la restricción. El pod estático corría en el nodo, pero el pod espejo —la representación de solo lectura en la API que hace visible el pod para kubectl— no lograba reconciliar. El contenedor estaba vivo y era efectivamente invisible para el API server. El PR #131837 cambió esto para rechazar la admisión de plano, de modo que el contenedor nunca se crea en lugar de correr sin que nadie lo observe.

¿Cuándo salió Kubernetes 1.37 y cómo se llama?

Kubernetes v1.37, con nombre en clave "Garhwal", llegó a disponibilidad general el 26 de agosto de 2026. Junto con las depreciaciones graduó dieciséis funciones a estable, entre ellas el estado de dispositivo de ResourceClaim (KEP-4817), los taints y tolerations de dispositivo (KEP-5055), el estado de salud de recursos para pods (KEP-4680) y SELinuxMount con SELinuxChangePolicy (KEP-1710). También deprecó el subproyecto kube-dns en favor de CoreDNS y el flag --filename de kubectl run.

ESLint 10: qué se rompe al actualizar (y por qué ESLint 9 ya es inseguro)

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

ESLint 9 llegó a su fin de vida el 6 de agosto de 2026. Si tu CI todavía corre eslint@9, lleva cuatro semanas funcionando sin parches de seguridad, y nadie te lo va a avisar. ESLint 10 salió en general availability el 6 de febrero de 2026, lo que significa que la ventana de seis meses de traslape que el proyecto siempre da ya se agotó. El cambio central no es una regla nueva ni un parser más rápido: es que el sistema de configuración eslintrc, el que se arma alrededor de .eslintrc.json y .eslintrc.js, se eliminó del código. No se deprecó. No quedó detrás de un flag. Se eliminó. Hay exactamente una forma de configurar ESLint 10: eslint.config.js.

Esto pesa más que la mayoría de saltos de versión mayor porque ESLint viene anunciando esta eliminación exacta desde que flat config se volvió el default en la v9, allá por abril de 2024. Los equipos tuvieron dos años de aviso. Muchos usaron ese tiempo para no hacer nada, porque la config vieja seguía funcionando. Ahora deja de funcionar.

¿De dónde vienes?

El costo de la migración se divide fuerte según tres puntos de partida.

Desde ESLint 9 con flat config ya instalado. Estás en la mejor posición. Tu eslint.config.js ya existe y ya funciona como ESLint 10 lo espera. Lo que sí te puede tocar: el piso de versión de Node.js se movió, el set de reglas por default ganó tres reglas que no habías visto, y —si trabajas en un monorepo— el algoritmo de búsqueda del archivo de configuración cambió de una forma que puede alterar en silencio qué reglas aplican a qué archivos.

Desde ESLint 9 apoyado todavía en el shim FlatCompat de @eslint/eslintrc. Este fue el camino intermedio pragmático que tomaron muchos equipos en 2024-2025: escribir un eslint.config.js, pero usar FlatCompat.extends() adentro para seguir jalando una config compartida de estilo viejo (airbnb-base, un paquete interno eslint-config-company) que nunca sacó release de flat config. La buena noticia, y no es obvia, es que este camino sigue funcionando en ESLint 10 —FlatCompat no murió con eslintrc, es un paquete aparte y sigue mantenido. Sí necesitas asegurarte de que @eslint/eslintrc esté en una versión actual, porque las copias viejas son anteriores a los internos de ESLint 10.

Desde ESLint 8, o desde ESLint 9 sin ningún eslint.config.js (es decir, dependías del fallback automático de ESLint 9 al formato legado cuando no encontraba flat config). Este es el grupo que se rompe más duro, porque ese fallback es justo lo que se eliminó. Apunta ESLint 10 a un proyecto que solo tiene .eslintrc.json y ningún eslint.config.js, y no va a usar el archivo viejo calladito —va a fallar en encontrar cualquier configuración.

Las rupturas, ordenadas por lo que te van a costar

1. `eslintrc` desapareció. No hay flag para traerlo de vuelta.

Esta es la que todo mundo medio espera y aun así lo agarra, porque la eliminación real es más amplia que “el formato de archivo viejo deja de leerse”. Cuatro cosas se van juntas:

.eslintrc.js, .eslintrc.json, .eslintrc.yml y .eslintignore ya no se leen, punto.
La variable de entorno ESLINT_USE_FLAT_CONFIG, que antes te dejaba forzar a ESLint 9 de vuelta al sistema legado, ya no se respeta. Configurarla no hace nada —no truena, simplemente se ignora.
Los flags del CLI que solo tenían sentido para eslintrc desaparecieron: --no-eslintrc, --env, --resolve-plugins-relative-to, --rulesdir, --ignore-path. Los scripts que los pasan ahora fallan al arrancar.
La opción del constructor configType de Linter solo acepta "flat". Pásale "eslintrc" y truena.

La migración en sí, de .eslintrc.json a eslint.config.js, es mecánica una vez que la haces. Aquí va una real, antes y después:

Antes — .eslintrc.json:

{
  "root": true,
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "plugins": ["@typescript-eslint"],
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": ["warn", { "argsIgnorePattern": "^_" }]
  },
  "ignorePatterns": ["dist", "node_modules"]
}

Después — eslint.config.js:

import js from '@eslint/js';
import globals from 'globals';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  {
    ignores: ['dist/**', 'node_modules/**'],
  },
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    languageOptions: {
      globals: {
        ...globals.browser,
        ...globals.node,
      },
    },
    rules: {
      '@typescript-eslint/no-unused-vars': ['warn', { argsIgnorePattern: '^_' }],
    },
  },
);

Tres cosas cambiaron de forma, no solo de sintaxis: env se volvió languageOptions.globals jalado del paquete globals, extends se volvió un arreglo que esparces directo (tseslint.configs.recommended ya es un arreglo de objetos de configuración), y no-unused-vars: off desapareció —@typescript-eslint/no-unused-vars ya no necesita que silencies a mano la regla base porque tseslint.configs.recommended ya la delimita bien por archivo.

Si tu único bloqueo restante es una config compartida sin release de flat config, para eso es FlatCompat:

import { FlatCompat } from '@eslint/eslintrc';
import path from 'node:path';
import { fileURLToPath } from 'node:url';

const compat = new FlatCompat({
  baseDirectory: path.dirname(fileURLToPath(import.meta.url)),
});

export default [
  ...compat.extends('airbnb-base'),
  // el resto de tu flat config
];

Eso sigue siendo un eslint.config.js de verdad —FlatCompat nada más deja que una config compartida de formato viejo viva adentro. Es un puente, no el regreso de eslintrc.

2. El algoritmo de búsqueda de config cambió —silencioso en monorepos

Esta es silenciosa por diseño, y es el cambio con más probabilidad de morder a quien hizo todo “bien”. ESLint 10 dejó de resolver eslint.config.* desde el directorio de trabajo actual. En vez de eso, arranca la búsqueda desde el directorio de cada archivo que se está analizando y sube desde ahí. El objetivo declarado es que un monorepo pueda tener un eslint.config.js distinto por paquete sin cableado extra —lo cual es genuinamente útil. El costo es que un archivo ahora puede recoger en silencio una config distinta a la que tenía en ESLint 9, sin aviso ni error: el lint simplemente pasa o falla distinto a antes, y la razón es un archivo de configuración dos directorios más allá que se te olvidó que existía. Si corres un monorepo, analiza cada workspace por separado justo después de actualizar y compara la salida contra ESLint 9 antes de confiar en ella.

3. Tres reglas se acaban de activar en `eslint:recommended` —también en silencio

Si tu config incluye js.configs.recommended (antes eslint:recommended), actualizar agrega no-unassigned-vars, no-useless-assignment y preserve-caught-error a lo que estás exigiendo —sin que toques una sola línea de tu propia config. Esta es la ruptura silenciosa clásica: corres el mismo comando de siempre, y ahora falla o advierte sobre código que no cambió. Si tu CI trata los warnings como fallas, eso es un build en rojo la mañana después del bump, con un diff que no muestra nada que hayas hecho mal.

no-useless-assignment atrapa el valor que se sobreescribe antes de leerse:

function total(items) {
  let sum = 0; // esta asignación...
  sum = items.reduce((a, b) => a + b, 0); // ...se reemplaza de inmediato, nunca se lee
  return sum;
}

preserve-caught-error marca un error capturado que descartas en vez de encadenar:

// antes — el error original y su stack se pierden
try {
  parseConfig(raw);
} catch (err) {
  throw new Error('Config parsing failed');
}

// después — la causa original sobrevive para quien depure esto después
try {
  parseConfig(raw);
} catch (err) {
  throw new Error('Config parsing failed', { cause: err });
}

Nada de esto está mal de exigir —es buen consejo. El problema es enterarte por un deploy fallido en vez de por un changelog.

4. Los comentarios `/* eslint-env */` pasan de inertes en silencio a error explícito

Esta tiene una historia de dos pasos que vale la pena conocer. Flat config nunca soportó comentarios tipo /* eslint-env browser */ —llevan sin hacer nada en silencio desde que te moviste a flat config en ESLint 9, te hayas dado cuenta o no. ESLint 10 cierra ese silencio: el mismo comentario ahora se reporta como error de lint en vez de ignorarse calladito. Si nunca migraste esos comentarios a languageOptions.globals, vas a ver errores nuevecitos apuntando a código que “funcionaba” desde hace año y medio, porque los globals que necesitaba nunca se estaban declarando de verdad —el comentario simplemente no hacía nada.

/* eslint-env browser, node */
window.dispatchEvent(new Event('ready'));

Mueve la intención a la config, igual que el ejemplo de .eslintrc de arriba hizo con env:

{
  languageOptions: {
    globals: { ...globals.browser, ...globals.node },
  },
}

5. El piso de Node.js se movió, y no es solo un bump de número de versión

ESLint 10 requiere Node.js ^20.19.0 || ^22.13.0 || >=24. Node 21.x y 23.x —los lanzamientos impares que no son LTS— quedan sin soporte de plano, y cualquier cosa debajo de 20.19.0 o 22.13.0 no tiene soporte aunque el mayor sea el correcto. En package.json:

// antes
"engines": { "node": ">=18" }

// después
"engines": { "node": "^20.19.0 || ^22.13.0 || >=24" }

Si tu imagen de CI fija un patch viejo dentro de 20.x o 22.x, npm install puede seguir teniendo éxito mientras el linter mismo falla al arrancar con un error que no parece tener nada que ver con Node —instalas ESLint y ya está roto antes de leer un solo archivo.

6. Métodos eliminados de `context` y `SourceCode` rompen reglas propias y plugins viejos

Si escribes reglas propias, o dependes de un plugin interno que nadie toca desde 2023, aquí es donde muerde: context.getCwd(), context.getFilename(), context.getPhysicalFilename(), context.getSourceCode(), context.parserOptions y context.parserPath desaparecieron todos, junto con SourceCode#getTokenOrCommentBefore(), getTokenOrCommentAfter(), isSpaceBetweenTokens() y getJSDocComment(). La clase Linter en sí perdió defineParser(), defineRule(), defineRules() y getRules(). Existen reemplazos para los que importan (context.cwd, context.filename, context.sourceCode, isSpaceBetween()), pero una regla que solo llama a la API eliminada en una ruta de código rara no truena hasta que esa ruta corre —lo que puede significar que pasa el CI durante semanas y luego falla en un archivo específico.

7. `eslint.config.ts` necesita un `jiti` actual

ESLint 10 deja de soportar versiones de jiti anteriores a 2.2.0, lo cual importa solo si escribes tu config en TypeScript (eslint.config.ts) y dejas que jiti la transpile al vuelo. Debajo de 2.2.0, la falla no dice “actualiza jiti” —sale como un error de resolución de módulos sin relación aparente, que manda a la mayoría por el camino de depuración equivocado primero.

Lo que no se rompe

Vale la pena decirlo claro, porque el marco de “todo se rompe” tampoco es exacto. typescript-eslint ya soporta ESLint 10 (su rango de peer declarado es ^8.57.0 || ^9.0.0 || ^10.0.0), así que un proyecto en una versión moderna de typescript-eslint no necesita tocarlo para esta actualización. Y FlatCompat —la válvula de escape real, ya cubierta arriba— sigue viva y con releases.

El único lugar donde este stack te obliga la mano es Astro. El release actual de eslint-plugin-astro exige ESLint 10 de plano, así que un proyecto de Astro que actualiza el plugin de Astro por cualquier otra razón arrastra a ESLint con él, haya sido planeado el bump de ESLint o no. Revisa los dos juntos antes de tocar cualquiera.

¿Cuándo actualizar?

Ahora mismo, si sigues en ESLint 9 o antes. El fin de vida ya pasó hace un mes al momento de escribir esto; ya no queda versión de “espera a que se asiente el polvo” de ese argumento.

Esta semana, si estás en ESLint 9 con flat config ya migrado. Tu superficie de riesgo es el cambio de búsqueda en monorepo y las tres reglas nuevas por default —las dos están a una corrida de lint de hacerse visibles, no a una reescritura.

Después de una auditoría, si mantienes reglas propias o un plugin interno. Haz grep de tus implementaciones de reglas buscando getCwd, getFilename, getSourceCode y parserOptions antes de subir la versión, no después de que el CI te avise.

En una rama dedicada primero, si corres un monorepo. Analiza cada workspace de forma aislada, compara los resultados contra ESLint 9, y solo entonces haz merge —el cambio de búsqueda de config es exactamente el tipo de cosa que se ve bien en local y se porta mal en el paquete que no probaste tú mismo.

Con FlatCompat como puente, si dependes de una config compartida que nunca sacó soporte flat. Eso no es razón para quedarte en un mayor sin soporte —es la herramienta que te deja actualizar hoy y terminar la migración real después.

Para seguir:

Preguntas frecuentes

¿Cuándo llegó ESLint 9 a su fin de vida?

El 6 de agosto de 2026. Son seis meses después de que ESLint 10 salió en general availability, que es la ventana de soporte estándar que el proyecto ESLint le da al mayor anterior. Después de esa fecha, ESLint 9.x ya no recibe parches de seguridad ni corrección de bugs.

¿Cuándo se lanzó ESLint 10?

ESLint 10.0.0 llegó a general availability el 6 de febrero de 2026, después de una alpha en noviembre de 2025. Al momento de escribir esto, la línea de patches actual está en el rango 10.4.x.

¿Puedo seguir usando .eslintrc.json con ESLint 10?

No. ESLint 10 no lee .eslintrc.js, .eslintrc.json, .eslintrc.yml ni .eslintignore bajo ninguna configuración o variable de entorno. La variable ESLINT_USE_FLAT_CONFIG, que antes forzaba el comportamiento viejo en ESLint 9, ya no se respeta. El único archivo de configuración soportado es eslint.config.js (o .mjs/.ts/.cjs).

¿FlatCompat sigue funcionando en ESLint 10?

Sí. FlatCompat viene del paquete separado @eslint/eslintrc y sigue funcionando en ESLint 10, dejándote jalar una config compartida de formato viejo dentro de un eslint.config.js real con compat.extends(). Asegúrate de que @eslint/eslintrc esté en una versión actual, porque las copias viejas son anteriores a ESLint 10.

¿Cuál es la versión mínima de Node.js para ESLint 10?

Node.js ^20.19.0, ^22.13.0, o 24 en adelante. Node 21.x y 23.x no tienen soporte, y tampoco lo tiene ninguna versión de patch debajo de 20.19.0 o 22.13.0 dentro de un mayor por lo demás soportado.

¿typescript-eslint soporta ESLint 10?

Sí. El release actual de typescript-eslint declara un rango de peer dependency de ^8.57.0 || ^9.0.0 || ^10.0.0, así que un proyecto que ya está en una versión reciente de typescript-eslint no necesita ningún cambio ahí para pasar a ESLint 10.

Pest 5 y PHPUnit 13: qué se rompe al actualizar (y qué falla en silencio)

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

Pest 5 salió a finales de julio de 2026, corre directamente sobre PHPUnit 13 y exige PHP 8.4 como mínimo sin excepciones. Pest en sí mismo no trae rupturas a nivel de API — todo el dolor viene heredado de las reglas de mocking más estrictas de PHPUnit 13. Y lo que de verdad le pega a los equipos no es un error fatal: es que PHPUnit 13 convierte varios patrones de mocking comunes en avisos de deprecación en vez de fallas, así que tu suite puede quedar completamente en verde mientras deja de verificar, en silencio, justo lo que creías que verificaba. Si estás en Laravel 12, hay un segundo problema más contundente: el plugin oficial de Pest para Laravel en su versión 5 pide Laravel 13.23 o superior, así que el plugin ni siquiera se instala.

¿De dónde vienes?

El esfuerzo del salto no es parejo. Depende de cuántas versiones mayores de PHPUnit te estés saltando de un solo golpe.

Pest 4 (PHPUnit 12) → Pest 5 (PHPUnit 13). Es el salto pensado, el más pequeño. Pest 4 ya pedía PHP 8.3, así que el único piso que subes es de 8.3 a 8.4. Absorbes una sola tanda de cambios de PHPUnit (12 → 13).
Pest 3 o anterior (PHPUnit 11 o más viejo) → Pest 5. Aquí absorbes dos tandas apiladas: PHPUnit 11 → 12 ya había eliminado los metadatos por docblock (necesitas atributos nativos de PHP: #[Test], #[DataProvider], etc.) y los mocks de clases abstractas o traits, encima de todo lo que cambia PHPUnit 13 más abajo. Saltar de 3 a 5 en un solo composer update es como una actualización de 20 minutos se convierte en una de dos días — pasa primero por 4, o al menos prueba el salto a 12 de forma aislada.
PHPUnit puro, sin Pest, en PHPUnit 12.5. La propia regla de actualización de PHPUnit es explícita: no muevas a 13 si tu suite todavía no corre limpia en 12.5. Si phpunit --display-deprecations muestra algo, arréglalo primero, en su lugar, antes de tocar la restricción de versión de Pest o PHPUnit.

El piso que no se negocia: PHP 8.4

Pest 5 exige PHP 8.4.0 o superior, punto. No hay un “en la práctica funciona en 8.3” como sí existe en algunos saltos de versión de Laravel. Si tu equipo sigue en PHP 8.1, 8.2 u 8.3, eso es trabajo de infraestructura que pasa antes de tocar el composer.json de Pest — no en paralelo.

php -v          # necesitas 8.4.0 o superior

Haz el salto de PHP como su propio despliegue, verificado en verde con el stack de pruebas viejo, antes de cambiar también el stack de pruebas. De lo contrario, un CI en rojo después de la actualización no te dice cuál de los dos cambios fue el culpable.

Rupturas, ordenadas por lo que de verdad duele

1. Laravel 12 no puede usar el plugin de Pest 5 para Laravel (bloqueante, no silencioso)

Esta es la que nadie menciona cuando venden la actualización como “solo una línea”, y es lo primero que detiene en seco a un equipo de Laravel. pestphp/pest-plugin-laravel en su versión 5.0.1 declara:

{
  "require": {
    "php": "^8.4",
    "laravel/framework": "^13.23.0",
    "pestphp/pest": "^5.0.1"
  }
}

Si tu app está en Laravel 12, composer update se va a negar a resolver pest-plugin-laravel ^5.0 — Composer reporta un conflicto, no una falla de prueba misteriosa. La solución no es un problema de Pest: necesitas Laravel 13.23+ antes de que el plugin de Laravel para Pest 5 sea siquiera instalable. Si estás actualizando ambos frentes a la vez, ordénalo — primero Laravel, después Pest — o te vas a pasar una tarde depurando un árbol de dependencias que nunca iba a resolver.

2. `any()` y `with*()` sin `expects()` — la suite que pasa pero deja de verificar (silencioso)

Este es el cambio que más importa, porque nada en tu salida de CI te avisa que ocurrió. PHPUnit 13 deprecra de forma dura dos patrones que antes eran la forma cómoda y por defecto de configurar un mock:

// Antes: funciona, y significa en silencio "cualquier número de llamadas, sin verificar orden"
$mock->method('handle')->with($this->equalTo($payload));

// PHPUnit 13: emite una deprecación, pero igual corre y sigue "pasando"

Las deprecaciones en PHPUnit son avisos, no fallas, a menos que configures explícitamente failOnDeprecation (o failOnPhpunitDeprecation, la propia de PHPUnit) en tu suite. Lo que significa que el escenario realista no es “la actualización rompe el CI el día uno” — es “el CI se queda en verde durante semanas mientras acumula decenas de avisos de deprecación que nadie lee, y después alguien activa el fallo estricto por deprecación, o PHPUnit 14 elimina el patrón de golpe y la suite se pone roja toda junta, en una fecha que tú no controlas”.

La corrección es hacer explícita la intención en vez de depender del comportamiento implícito por defecto:

// Si de verdad quieres verificar que la llamada ocurre:
$mock->expects($this->once())->method('handle')->with($this->equalTo($payload));

// Si no te importa si se llama o no — usa un stub, no un mock:
$stub = $this->createStub(HandlerInterface::class);
$stub->method('handle')->willReturn($result);

El propio matcher any() de conteo de invocaciones queda deprecado de forma dura por la misma razón: combinar expects($this->any()) con un mock es una contradicción — los mocks existen para verificar interacciones, y any() significa “no me importa si esto pasa”. Los propios mantenedores de PHPUnit lo dicen sin rodeos: si no quieres verificar nada, lo que querías era un stub.

3. `createPartialMock()` de Laravel choca con la regla #2 (silencioso, específico de Laravel)

Es la misma deprecación de arriba, pero vale la pena señalarla aparte porque golpea a un helper que la mayoría de las suites de Laravel usan sin pensarlo dos veces. El trait de testing de Laravel envuelve el createPartialMock() de PHPUnit, y la implementación interna de ese envoltorio dispara la deprecación de “with*() sin expects()” en PHPUnit 13 aunque tu código de prueba se vea perfectamente sano:

// Dispara la deprecación en PHPUnit 13, aunque se vea inocente
$class = $this->createPartialMock(NightlyCommand::class, ['runSequenceOfCommands']);

// Corregido: te saltas el envoltorio y usas el builder de PHPUnit directamente
$class = $this->getMockBuilder(NightlyCommand::class)
    ->onlyMethods(['runSequenceOfCommands'])
    ->getMock();

Búscalo con grep antes de actualizar, porque el número de deprecaciones puede ser grande si el patrón es común en tu suite:

grep -rln "createPartialMock" tests/

4. Eliminaciones reales — estas sí fallan, de inmediato, sin ambigüedad

A diferencia de las dos anteriores, estas ya venían deprecadas de forma dura desde PHPUnit 12 y en 13 simplemente ya no existen. Lanzan un Error fatal, no un aviso, así que salen a la luz desde la primera corrida — que en realidad es la categoría fácil de resolver:

// Eliminado en PHPUnit 13 — error fatal, no una deprecación
$this->assertThat($value, $this->isType('string'));
$this->assertContainsOnly('string', $collection);
$this->assertNotContainsOnly('int', $collection);

// Sus reemplazos especializados, disponibles desde PHPUnit 11.5
$this->assertThat($value, $this->isString());  // o directamente assertIsString($value)
$this->assertContainsOnlyString($collection);
$this->assertContainsNotOnlyInt($collection);

// Para colecciones de objetos sigue existiendo la de siempre
$this->assertContainsOnlyInstancesOf(User::class, $collection);

También se eliminó el flag de CLI --dont-report-useless-tests, Configuration::includeTestSuite() / excludeTestSuite(), el atributo #[CoversNothing] en métodos individuales (ahora solo a nivel de clase), el atributo #[RunClassInSeparateProcess], y el soporte para cadenas de restricción de versión sin un operador de comparación explícito. Ninguno de estos es común en una suite típica de Laravel, pero si mantienes un paquete con extensiones propias de PHPUnit o herramientas de CI que invocan phpunit directamente, revisa tus flags.

Si vienes de withConsecutive() específicamente: eso ya es viejo — se eliminó desde PHPUnit 10 — pero PHPUnit 13 por fin trae reemplazos decentes en vez de dejarte escribiendo workarounds incómodos de conteo de llamadas:

// Nuevo en PHPUnit 13
$mock->expects($this->once())
    ->method('handle')
    ->withParameterSetsInOrder(['first'], ['second']);

$mock->expects($this->exactly(2))
    ->method('handle')
    ->withParameterSetsInAnyOrder(['first'], ['second']);

5. El Test Impact Analysis necesita un driver de cobertura, o simplemente no corre (silencioso)

La función estrella de Pest 5 — el Tia Engine, que promete reducir una suite de Laravel de 10 minutos a unos 4 segundos en corridas posteriores al solo volver a correr las pruebas afectadas por tu diff — necesita PCOV o Xdebug instalado para grabar su grafo de dependencias inicial. Sin uno de los dos, Pest no lanza error ni avisa fuerte; TIA simplemente nunca se activa, y tu suite sigue corriendo completa cada vez, en silencio. Si activaste TIA esperando la mejora de velocidad y no pasó nada, revisa si tienes un driver de cobertura antes de asumir que la función está rota:

php -m | grep -iE "pcov|xdebug"

Para una configuración de equipo, el patrón sensato es que el CI grabe el grafo base una vez por cada merge a main (donde activar un driver de cobertura sale barato) y que las máquinas locales consuman ese grafo en caché, en vez de que cada desarrollador corra una línea base instrumentada con cobertura en su propia máquina.

6. Sin cambios de configuración — de verdad no hay nada que hacer aquí

Vale la pena decirlo de forma explícita porque la gente lo espera: la guía de actualización de Pest 5 documenta ningún cambio en phpunit.xml ni en ningún archivo de configuración de Pest. Si tu suite corre limpia bajo las reglas de PHPUnit 13, el bump de versión en composer.json es toda la migración. Eso es lo bastante raro en este ecosistema como para no darle más vueltas de las necesarias.

¿Cuándo actualizar?

Estás en Pest 4 / PHPUnit 12, PHP 8.4 ya es tu piso, y phpunit --display-deprecations sale limpio. Actualiza ahora. Esto se acerca a los “2 minutos” que promete la documentación, y solo TIA ya vale la pena si tu suite pasó de un par de miles de pruebas.
Estás en Pest 4 pero todavía en PHP 8.3. Sube PHP primero, verifica que la suite actual siga en verde y sin deprecaciones en 8.4, y luego sube Pest como un paso aparte.
Estás en Pest 3 o en PHPUnit 11 o anterior, sin Pest. No te saltes directo a 5. Pasa primero por la tanda de PHPUnit 12 (atributos en vez de docblocks, sin mocks de abstractas ni traits), confirma que la suite está limpia, y toma el salto de 12 a 13 aparte.
Eres un equipo de Laravel todavía en Laravel 12. El plugin de Laravel para Pest 5 está fuera de tu alcance hasta que estés en Laravel 13.23+. O actualizas Laravel primero, o te quedas en pest-plugin-laravel ^4.0 con Pest 4 hasta que lo hagas — no dejes que el resolvedor de dependencias de Composer tome esa decisión por ti a medio camino.
Cualquiera con uso pesado de mocks en la suite, sin importar la versión. Corre el grep de deprecaciones antes de tocar siquiera el composer.json. El costo real de esta actualización no es el bump de versión — es descubrir cuántos de tus mocks solo “pasaban” porque en realidad no estaban verificando nada.

Para seguir leyendo:

Preguntas frecuentes

¿Pest 5 exige PHP 8.4?

Sí. Pest 5 requiere PHP 8.4.0 o superior como mínimo absoluto, sin excepciones para PHP 8.1, 8.2 u 8.3. Esto viene de que Pest 5 corre sobre PHPUnit 13, que a su vez exige PHP 8.4 o posterior.

¿Puedo usar Pest 5 con Laravel 12?

No con el plugin oficial. Desde la versión 5.0.1 de pest-plugin-laravel, el paquete exige laravel/framework ^13.23.0, así que Composer se niega a instalarlo en una aplicación con Laravel 12. Necesitas actualizar a Laravel 13.23 o superior primero, o quedarte en Pest 4 con pest-plugin-laravel ^4.0 mientras tanto.

¿Qué pasa si mi suite de pruebas ya tiene avisos de deprecación de PHPUnit antes de actualizar?

Los avisos de deprecación de PHPUnit no hacen fallar un build por defecto, así que una suite puede aparentar que pasa mientras usa patrones que PHPUnit 13 marca, como el matcher de invocaciones any() o las llamadas con*() sin un expects() explícito. PHPUnit recomienda oficialmente no actualizar a 13 a menos que tu suite ya corra limpia, sin avisos de deprecación, en PHPUnit 12.5, porque esos avisos se convierten en eliminaciones definitivas en una futura versión mayor sin más aviso.

¿Se eliminó el matcher any() en PHPUnit 13?

No, todavía no. El matcher de conteo de invocaciones any() está deprecado de forma dura en PHPUnit 13, lo que significa que todavía funciona pero dispara un aviso de deprecación, y está programado para eliminarse en PHPUnit 14. La corrección recomendada es usar una expectativa explícita como expects($this->once()) si quieres verificar que una llamada ocurre, o cambiar a createStub() si no necesitas verificación en absoluto.

¿Necesito Xdebug o PCOV para usar el Test Impact Analysis de Pest 5?

Sí. El Tia Engine necesita un driver de cobertura de código, ya sea PCOV o Xdebug, para grabar el grafo de dependencias en su primera corrida. Sin uno instalado y activado, el Test Impact Analysis no lanza ningún error; simplemente no se activa, y tu suite sigue corriendo todas las pruebas en cada corrida.

¿Cuánto tarda de verdad la actualización a Pest 5?

La documentación oficial estima unos 2 minutos para el bump de versión en composer.json, y esa estimación es precisa para la parte específica de Pest. El costo real de tiempo está en auditar tu suite contra las reglas de PHPUnit 13 antes de actualizar, sobre todo los patrones de uso de mocks y, para las apps de Laravel, confirmar que ya estás en Laravel 13.23 o superior.

PHP 8.6: qué se rompe de verdad al actualizar

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

PHP 8.6 sale el 19 de noviembre de 2026, y lo que más probablemente te va a tumbar producción no es ninguna función eliminada — es que cambian los defaults de tres directivas de sesión. session.use_strict_mode, session.cookie_httponly y session.cookie_samesite cambian de valor, y el modo de falla es silencioso: nada lanza excepción, tus usuarios simplemente dejan de mantener la sesión iniciada en peticiones cross-site.

Todo lo demás son deprecaciones, es decir, avisos y no errores fatales. Pero hay cuatro cambios de comportamiento genuinos escondidos entre ellas, y dos de esos cambian el resultado sin decir una palabra.

Esta es la lista de rupturas. Si buscas las novedades — Partial Function Application, clamp(), el enum SortDirection — están en todas las novedades de PHP 8.6.

Qué tan cerrada está esta lista

Vale la pena aclararlo, porque los artículos de “qué rompe PHP 8.6” empezaron a publicarse antes de que hubiera algo que reportar.

El calendario es público: la alpha 1 salió el 2 de julio, la beta 1 con el soft feature freeze llegó el 13 de agosto, el hard feature freeze es el 22 de septiembre, la RC1 llega el 24 de septiembre y la RC4 el 5 de noviembre, y la disponibilidad general es el 19 de noviembre de 2026.

Lo que eso significa para este artículo:

Las deprecaciones ya están cerradas. Vienen de RFCs que ya se votaron, y una RFC votada no se desvota.
La lista todavía puede crecer. Entre hoy y el hard freeze pueden entrar cambios aprobados por los release managers, y algunos bugfixes posteriores añaden notas de actualización.
Todavía no hay página oficial de migración. php.net/manual/es/migration86.php no existe al momento de escribir esto — la fuente de verdad hoy es el archivo UPGRADING en la rama master de php-src, de donde sale todo lo de abajo.

Voy a actualizar este artículo después del hard freeze y la RC1 del 24 de septiembre, cuando la lista quede prácticamente cerrada.

La que sí va a tumbar producción

Los defaults de seguridad de sesión cambian

Tres valores de php.ini cambian:

Directiva	Antes	En PHP 8.6
`session.use_strict_mode`	`0`	`1`
`session.cookie_httponly`	`0`	`1`
`session.cookie_samesite`	`""`	`"Lax"`

Cada uno por separado es el default correcto. Juntos son el cambio más disruptivo de la versión, porque ninguno de los tres lanza un error. Tu aplicación sigue corriendo y algunos usuarios simplemente dejan de estar logueados.

cookie_samesite = "Lax" es el que muerde. Una cookie Lax no viaja en peticiones POST cross-site. Si algo le hace POST a tu aplicación desde otro origen — una pasarela de pago que regresa al usuario por POST, el callback de un proveedor de identidad, un formulario embebido, un webhook que depende de la sesión — esa petición ahora llega sin sesión. El usuario aparece en la pantalla de login sin ninguna razón visible.

cookie_httponly = 1 significa que JavaScript ya no puede leer la cookie de sesión con document.cookie. Es lo correcto, y rompe cualquier código de front-end que leyera el ID de sesión directamente — algunos snippets viejos de analítica y auth por AJAX hecho a mano hacen justo eso.

use_strict_mode = 1 hace que PHP rechace IDs de sesión que él mismo no generó, que es la corrección real contra la fijación de sesión (session fixation). Rompe flujos que meten un ID de sesión desde afuera.

Si necesitas el comportamiento anterior de forma temporal, fíjalo explícitamente en vez de depender del default previo:

; solo como parche mientras arreglas la causa real
session.cookie_samesite = "None"
session.cookie_secure = 1   ; obligatorio siempre que uses SameSite=None

Ojo: los navegadores rechazan SameSite=None sin Secure, así que esto no es un revert de una línea.

El consejo honesto: no lo reviertas. Fija estas tres directivas explícitamente en tu php.ini hoy mismo, en PHP 8.5, y averigua qué se rompe mientras todavía controlas cuándo. Eso convierte una sorpresa del día del lanzamiento en una tarde de martes cualquiera.

Los cambios de comportamiento que no hacen ruido

`trim()` ahora elimina el form feed

trim(), ltrim() y rtrim() agregan \f (form feed, 0x0C) a su lista de caracteres por defecto. Era el único carácter de espacio en blanco ASCII que no eliminaban.

trim("hola\f");
// PHP 8.5 → "hola\f"
// PHP 8.6 → "hola"

Casi siempre es lo que querías. Lo listo aquí porque cambia la salida en silencio, y si tienes pruebas que comparan cadenas exactas al parsear archivos de ancho fijo, streams de impresión viejos o cualquier cosa que arrastre form feeds, van a empezar a fallar sin causa obvia.

Los NUL bytes ahora lanzan en vez de tolerarse

Un grupo grande de funciones ahora lanza ValueError cuando reciben una cadena con un byte NUL, en vez de truncar o comportarse de forma impredecible. La lista incluye getenv(), putenv(), parse_str(), setlocale(), dl(), openlog(), proc_open() (el argumento $cwd), y cerca de veinte funciones de sistema de archivos — file_exists(), is_file(), filesize(), stat() y sus parientes.

Es un endurecimiento de seguridad: los NUL bytes en esos argumentos han sido históricamente un vector de path traversal. El impacto práctico es que el código que pasa entrada de usuario sin sanear a validaciones de archivos ahora recibe una excepción ruidosa en vez de un silencio sin sentido:

// PHP 8.5: devuelve false, sin ninguna señal
// PHP 8.6: lanza ValueError
file_exists($_GET['path']);   // cuando $_GET['path'] contiene "\0"

Si tu aplicación hace esto, la excepción te está avisando de un bug que ya existía.

`unpack()` reinterpreta `<` y `>`

unpack() ahora trata < y > después de un código de formato como modificadores de endianness, no como parte del nombre. Esto cambia cómo se parsean cadenas de formato que ya tenías:

unpack("s<valor", $data);
// PHP 8.5 → clave "<valor"
// PHP 8.6 → short little-endian, clave "valor"

unpack("C>nombre", $data);
// PHP 8.6 → lanza excepción (C no tiene endianness)

Es un caso puntual, pero si parseas formatos binarios es una ruptura dura, no una deprecación. Busca unpack( en tu código y revisa si algún formato tiene < o > dentro de un nombre.

`SessionHandlerInterface` pide dos métodos más

Los manejadores de sesión personalizados que no implementan create_sid() ni validateId() ahora emiten deprecaciones. Si escribiste a mano un manejador de sesiones en base de datos o Redis, lo más probable es que implemente los seis métodos originales y no estos dos — y validateId() es justo lo que hace funcionar de verdad a use_strict_mode, así que este punto se conecta directo con el cambio de arriba.

Las deprecaciones

Ninguna de estas es fatal en 8.6. Emiten E_DEPRECATED, y son la lista de eliminación para PHP 9.

return dentro de finally. Regresar un valor desde un bloque finally descarta cualquier valor de retorno o excepción del try, que casi siempre está tapando un bug. Ahora está deprecado.

function f() {
    try { return 1; }
    finally { return 2; }   // deprecado — gana en silencio, regresa 2
}

Regresar un valor desde un constructor. Ya está cubierto con detalle en el post de novedades, pero la versión corta: es deprecación en tiempo de compilación, la ves aunque el código nunca se ejecute, y pasó la votación 39 a 0.

array_filter() lanza excepción con un $mode inválido. Antes ignoraba en silencio un modo incorrecto; ahora lanza ValueError. Es una mejora estricta, pero puede tumbar código que llevaba años pasando una constante equivocada sin que nadie se diera cuenta.

php://filter limita los filtros encadenados. Endurecimiento contra una técnica conocida de explotación por cadenas de filtros. Solo te toca si construyes cadenas de filtros a propósito.

Todo mbregex. Cada función mb_ereg* queda deprecada, porque Oniguruma, la librería detrás de ellas, dejó de tener mantenimiento. Es la deprecación más grande de la versión en superficie de código. La migración es a PCRE — preg_match() y compañía, con el modificador u para Unicode. El post de novedades trae el detalle completo de las 14 funciones y el checklist de migración; aquí basta con saber que no es opcional para siempre: se elimina en PHP 9.

Alias de verificación y conversión de tipos. is_double(), is_long(), is_integer() y doubleval() quedan deprecadas a favor de is_float(), is_int() y floatval(). También se deprecan metaphone(), strcoll(), spl_object_hash(), spl_classes() y la bandera de ordenamiento SORT_LOCALE_STRING.

spl_object_hash() es la que vale la pena marcar: reemplázala por spl_object_id(), que casi seguro es lo que en realidad querías.

Métodos de CSV en SPL y de ArrayIterator. SplFileObject::fgetcsv(), fputcsv(), setCsvControl() y getCsvControl() quedan deprecados, junto con diez métodos de ArrayIterator: getFlags(), setFlags(), asort(), ksort(), uasort(), uksort(), natsort(), natcasesort(), serialize() y unserialize().

Argumentos de objeto donde nunca tuvieron sentido. array_walk(), mb_convert_variables() y los filtros de stream de zlib y bz2 ahora deprecan argumentos tipo objeto.

Cabos sueltos de mysqli. mysqli_get_charset() y mysqli_stmt_init() quedan deprecadas. La opción classmap de SOAP ahora rechaza claves enteras.

Qué hacer en realidad, en orden

Fija las tres directivas de sesión explícitamente en PHP 8.5, hoy. Es todo el riesgo de la versión concentrado en un solo cambio, y es el único que puedes probar antes de que 8.6 exista siquiera. Revisa cada POST cross-site que le llegue a tu aplicación.
Activa el reporte de deprecaciones y corre tu suite de tests. error_reporting(E_ALL) con un log que de verdad revises. La mayor parte de esta versión aparece ahí.
Busca los nombres específicos. mb_ereg, is_double, is_long, is_integer, doubleval, spl_object_hash, metaphone, strcoll, unpack(. Es una pasada de veinte minutos y cubre casi toda la lista de deprecaciones.
Revisa tus manejadores de sesión personalizados en busca de create_sid() y validateId().
No toques trim() a menos que falle alguna prueba. Si falla una, aprendiste algo sobre tus datos de entrada.

Lo que NO se rompe

Vale la pena decirlo, porque la ansiedad de actualizar rellena huecos que no existen. PHP 8.6 no elimina nada que estuviera deprecado en 8.x — las eliminaciones llegan hasta PHP 9. Tus propiedades tipadas, enums, clases readonly, fibers y atributos siguen intactos. Si tu aplicación corre limpia en 8.5 con las deprecaciones silenciadas, el peor caso realista para 8.6 es un log ruidoso más el cambio de sesión.

Ese cambio de sesión, eso sí, no es un detalle menor. Es la razón por la que existe este artículo.

Preguntas frecuentes

¿Cuándo se libera la versión estable de PHP 8.6? El 19 de noviembre de 2026. El hard feature freeze es el 22 de septiembre y las release candidates corren del 24 de septiembre al 5 de noviembre.

¿Cuál es el cambio más peligroso de PHP 8.6? Los defaults de sesión: session.use_strict_mode y session.cookie_httponly pasan a 1, y session.cookie_samesite pasa a "Lax". Fallan en silencio — los usuarios dejan de mantener sesión en POSTs cross-site en vez de recibir un error.

¿PHP 8.6 elimina funciones existentes? No. Deprecia muchísimo — todo mbregex, varios alias de verificación de tipos, métodos CSV de SPL — pero las eliminaciones están programadas para PHP 9. Las deprecaciones emiten avisos, no errores fatales.

¿De verdad va a desaparecer mb_ereg? Está deprecada en 8.6 porque Oniguruma, la librería detrás de ella, dejó de tener mantenimiento, pero todavía funciona. Migra a PCRE (preg_match y compañía con el modificador u). Los patrones no siempre se traducen uno a uno, así que conviene probar en vez de hacer un find-and-replace.

Para seguir

Todas las novedades de PHP 8.6 — el lado de las funciones nuevas: Partial Function Application, clamp(), el enum SortDirection.
Qué se rompe al actualizar a Laravel 13 — Laravel 13 pide PHP 8.3 o superior, así que estas dos actualizaciones suelen caer en el mismo sprint.

Symfony 8: qué se rompe al actualizar desde 7.4 y cómo decidir entre LTS y la rama normal

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

Si estás en Symfony 8.0, llevas corriendo código sin soporte desde el 30 de julio de 2026 — 8.0 tuvo exactamente ocho meses de vida y ya se acabaron. Si estás en 7.4, tienes años por delante, pero igual te toca decidir si te quedas en el LTS o brincas a 8.1, publicado el 29 de mayo de 2026. Ninguno de los dos caminos es una reescritura. Los dos tienen cambios que no lanzan error — simplemente cambian en silencio qué hace tu aplicación.

Symfony 7.4 y 8.0 salieron el mismo día, el 27 de noviembre de 2025, con funcionalidades idénticas. La única diferencia es que 7.4 conservó las capas de deprecación acumuladas desde 7.0, y 8.0 las borró todas. Esa es toda la historia de “Symfony 8”: es 7.4 sin la red de seguridad. 8.1, que salió medio año después, sí agrega funcionalidad nueva encima y es la versión a la que llegas si sigues la rama normal (no LTS).

¿De dónde vienes?

Estás en	Estado hoy (sep 2026)	Qué hacer
Symfony 8.0	Sin mantenimiento desde el 30 jul 2026 — ni fixes ni parches de seguridad	Sube a 8.1 ya. Es el mismo código sin deprecaciones, sin cambios obligatorios bajo la promesa de BC
Symfony 7.4 (LTS)	Bug fixes hasta nov 2028, seguridad hasta nov 2029	Quédate, o brinca a 8.1 por las funciones nuevas. No hay urgencia de ningún lado
Symfony 6.4 (LTS) o anterior	6.4: bug fixes hasta nov 2026 y seguridad hasta nov 2027. De las anteriores solo 5.4 LTS recibe parches, y solo de seguridad (hasta feb 2029)	Pasa por 7.4 primero, sin esperar a que se acabe la ventana de 6.4. Corrige cada deprecación ahí con `phpunit --display-deprecations`, y luego decide entre 7.4-LTS y 8.x

La tabla de referencia, tal cual sale de symfony.com/releases:

Versión	Tipo	Lanzamiento	PHP mínimo	Bug fixes hasta	Seguridad hasta
7.4	LTS	27 nov 2025	8.2.0	nov 2028	nov 2029
8.0	Normal	27 nov 2025	8.4.0	jul 2026	jul 2026
8.1	Normal	29 may 2026	8.4.0	ene 2027	ene 2027

Hay dos cosas que vale la pena leer dos veces: toda la ventana de soporte de 8.0 fue de ocho meses, bug fixes y seguridad juntos — y esa es la política estándar para un minor no-LTS, no una recortada a propósito. Y 8.1 exige PHP 8.4, dos versiones completas por delante de lo que pide 7.4. Si sigues en PHP 8.2 u 8.3, subir la versión de PHP es trabajo de infraestructura real, aparte de todo lo que sigue en esta lista — hazlo primero, verifícalo, y hasta entonces toca composer.json.

Impacto alto

1. La configuración en XML desapareció — y rompió en silencio primero

Esta es la que agarra a la gente desprevenida, porque no falla el día que debería. Symfony 7.4 deprecó la configuración en XML; Symfony 8.0 la eliminó por completo. Si tus bundles, rutas o servicios están configurados en XML y nadie estaba revisando el log de deprecaciones durante la ventana de 7.4, el salto a 8.0 u 8.1 es un alto total: el loader ya no existe, no es que esté desaconsejado.

// Eliminado sin alternativa en Symfony 8.0
ExtensionInterface::getXsdValidationBasePath()
ExtensionInterface::getNamespace()

Routing, FrameworkBundle y WebProfilerBundle ya no cargan rutas en XML, punto. YAML sigue siendo el formato por default y sigue totalmente soportado. PHP es la alternativa recomendada para configuración basada en código, y también cambió de forma (ver el punto 4). Existe un convertidor automático para mantenedores de bundles — symfony-config-xml-to-php —, pero la configuración XML a nivel de aplicación la vas a reescribir a mano.

La razón por la que esto califica como “rompe en silencio”: el aviso de deprecación en 7.4 es nada más una línea de log. Nadie hace grep de logs de deprecación con regularidad. La falla aparece meses después, en el upgrade a 8.x, como un error fatal que parece no tener nada que ver con lo que tocaste esa semana.

2. Security: credenciales borradas, listeners del firewall, exposición de errores

Tres cambios caen en el mismo componente y se acumulan:

UserInterface::eraseCredentials() y TokenInterface::eraseCredentials() se eliminaron. Usa __serialize() para controlar qué sobrevive en el token en su lugar.
Los listeners del firewall tienen que extender AbstractListener o implementar FirewallListenerInterface. Registrar un callable simple como listener ya no funciona.
hide_user_not_found desapareció; usa expose_security_errors.

# Symfony <= 7.x
security:
    hide_user_not_found: false

# Symfony >= 8.0
security:
    expose_security_errors: account_status  # none | account_status | all

expose_security_errors es más preciso que el booleano al que reemplaza — account_status muestra excepciones solo a usuarios que ya dieron la contraseña correcta, all no oculta nada, none es el default seguro. Si tu security.yaml todavía trae hide_user_not_found, el contenedor no compila en 8.x. Ese es ruidoso. Lo que no es ruidoso: las cookies de remember-me. RememberMeDetails ya no incluye el nombre completo de la clase del usuario dentro del payload de la cookie. Las cookies viejas, emitidas antes del upgrade, dejan de autenticar en silencio — al usuario no le sale ningún error, simplemente se le cierra la sesión y tiene que volver a iniciarla. Si manejas una app con tráfico alto, espera un pico de tickets de soporte la semana que despliegues, no una alerta de incidente.

3. Comandos de consola: se eliminaron los métodos estáticos de metadata

// Symfony <= 7.x
class SyncCommand extends Command
{
    protected static function getDefaultName(): string
    {
        return 'app:sync';
    }
}

// Symfony >= 8.0
#[AsCommand(name: 'app:sync')]
class SyncCommand extends Command
{
}

Command::getDefaultName() y getDefaultDescription() se eliminaron — usa el atributo #[AsCommand]. Application::add() se reemplaza por Application::addCommand(). Si registras comandos de forma dinámica instanciando subclases de Command y metiéndolas a la aplicación, esto es un cambio mecánico pero obligatorio.

Impacto medio

4. La config PHP fluida desapareció; hay un formato nuevo de array-shape

Symfony 5.3 introdujo un formato de configuración PHP fluido, tipo builder (SecurityConfig, FrameworkConfig y compañía). Se eliminó en 8.0. Lo que lo reemplaza no es un regreso a los arrays de siempre — es un formato PHP nuevo de array-shape con metadata tipada que los IDEs y los analizadores estáticos sí pueden entender.

// Eliminado: configuración PHP fluida
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $security->firewall('main')->pattern('^/*')->lazy(true);
};

// Nuevo: configuración PHP array-shape
namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return App::config([
    'security' => [
        'firewalls' => [
            'main' => ['pattern' => '^/*', 'lazy' => true],
        ],
    ],
]);

La razón declarada es que los builders fluidos no podían representar cualquier forma semántica del árbol de configuración, lo que hacía innecesariamente difícil mantener actualizadas las recipes de Symfony de forma automática. YAML sigue siendo el default recomendado; este formato es para equipos que específicamente quieren PHP.

5. Doctrine: ya no auto-mapea entidades en los argumentos del controller

El auto-mapeo estilo ParamConverter, el que resolvía parámetros de ruta directo en argumentos de entidades Doctrine, se eliminó. Si una acción de un controller tipaba una entidad Doctrine y confiaba en que el bundle la resolviera implícitamente desde la ruta, esa resolución ya no existe — ahora lo cableas explícitamente con #[MapEntity] o la obtienes tú mismo dentro del cuerpo de la acción. DoctrineExtractor::getTypes() también desapareció; usa getType().

6. HttpFoundation: `Request::get()` eliminado, el method override se acotó

// Eliminado
$request->get('id');

// Usa el bag específico
$request->attributes->get('id');
$request->query->get('id');
$request->request->get('id');

Request::get() buscaba primero en attributes, luego en query, luego en el body de la petición, en ese orden — cómodo, y una fuente frecuente de bugs cuando dos bags tenían la misma llave. Ya no existe; hay que ser explícito sobre qué bag quieres. Aparte, el method override por HTTP (X-HTTP-METHOD-OVERRIDE / _method) ya no aplica a GET, HEAD, CONNECT ni TRACE — esos métodos están pensados para ser seguros e idempotentes, y ahora Symfony lo hace cumplir en la capa de request en vez de confiar en el header de override.

7. Form: `UrlType` deja de adivinar un protocolo

// Symfony <= 7.4: default_protocol usa 'http' por default
// escribir "example.com" en el campo guarda "http://example.com"

// Symfony >= 8.0: default_protocol usa null por default
// escribir "example.com" guarda "example.com" — sin protocolo agregado

Es de las pocas rupturas de 8.0 que no truenan. Desde 7.1, no configurar default_protocol emitía una deprecación; si nadie la leyó, en 8.0 el valor por default cambia sin avisar. Si tus formularios usan UrlType y después muestras o enlazas ese valor asumiendo que siempre trae un esquema, ahora ya no lo trae a menos que el usuario lo haya escrito. Nada lanza error; te queda un string con pinta de ruta relativa que se comporta como un link roto la primera vez que alguien le da clic. Para conservar el comportamiento anterior, declara 'default_protocol' => 'http' en el campo.

Novedades de 8.1 que cambian el comportamiento sin lanzar error

Esta sección vale la pena leerla con calma si ya pasaste 8.0 y estás evaluando 8.1, porque ninguno de estos cambios lanza excepción — simplemente hacen algo distinto.

8. Messenger ya no lanza excepción al fallar el decode

Los serializers ahora regresan un Envelope que envuelve una MessageDecodingFailedException en vez de lanzarla. Si tu transporte o middleware capturaba MessageDecodingFailedException alrededor del decode, ese bloque catch deja de dispararse. La falla ya no se expone como excepción — es un dato dentro del envelope que tienes que revisar tú. El código que no se actualice para esto va a procesar (o descartar) en silencio un fallo de decode que antes era imposible de pasar por alto.

9. `ParameterBag::getInt()` / `getBoolean()` empiezan a lanzar excepción

En dirección contraria al punto anterior: estos métodos antes forzaban en silencio un valor no convertible a 0 o false. En 8.1 lanzan UnexpectedValueException en su lugar. Este es un caso donde 8.1 convierte una falla anterior que era silenciosa en una ruidosa — bueno para detectar input malo, pero significa que el código que dependía del fallback viejo ahora necesita un try/catch o validación previa.

10. El `ChoiceType` colapsado y requerido renderiza su placeholder como `hidden`

Un campo ChoiceType requerido y no expandido ahora marca su <option> de placeholder con el atributo hidden en vez de ser nada más una opción de valor vacío. Es puramente visual, pero si tienes JavaScript o CSS que selecciona sobre la opción de placeholder, o pruebas de UI automatizadas que hacen assert sobre ese markup, es un cambio silencioso en el DOM. Puedes restaurar el comportamiento anterior con placeholder_attr: [] si lo necesitas.

Lo que NO se rompe

Symfony 8.0 y 8.1 no son “el siguiente 7.x”. Eliminaron deprecaciones; no agregaron una ola de comportamiento incompatible nuevo más allá de esa eliminación. La mayor parte de lo que rompe en el salto 7.4→8.0 es algo que ya estaba deprecado y registrado en 7.x — si limpiaste deprecaciones en 7.4, el upgrade a 8.0 es casi un no-evento.
YAML como configuración no va a ningún lado. Es explícitamente el formato que las recipes de Symfony siguen apuntando.
El upgrade de 8.0 a 8.1 no exige cambios de código bajo la promesa de retrocompatibilidad — 8.1 es un minor sobre 8.0, no un major.

El flujo real de migración

Aterriza en 7.4 primero si no estás ahí. Aunque tu destino sea 8.x, subir al LTS te da la capa de deprecación contra la cual trabajar.
Corre el reporte de deprecaciones y arregla lo que es tuyo:

php bin/phpunit --display-deprecations

Para que la suite falle solo por las deprecaciones de tu propio código, y no por las de paquetes de terceros que todavía no controlas, no busques el viejo SYMFONY_DEPRECATIONS_HELPER=weak_vendors: ese modo se eliminó en symfony/phpunit-bridge 5.0, y en PHPUnit 10 o superior el bridge ni siquiera registra su manejador de deprecaciones. Lo vigente es configurarlo en phpunit.dist.xml, como lo trae la recipe de Flex:

<phpunit failOnDeprecation="true">
    <source ignoreSuppressionOfDeprecations="true" ignoreIndirectDeprecations="true">
        <include>
            <directory>src</directory>
        </include>
        <deprecationTrigger>
            <function>trigger_deprecation</function>
        </deprecationTrigger>
    </source>
</phpunit>

ignoreIndirectDeprecations descarta las deprecaciones que dispara código de terceros — útil para priorizar qué es de verdad accionable este sprint. Si tu suite sigue en PHPUnit 9 con simple-phpunit, el equivalente es SYMFONY_DEPRECATIONS_HELPER='max[self]=0'.

Automatiza los renombres mecánicos con Rector. rector/rector-symfony trae sets de upgrade que cubren buena parte de esta lista — getDefaultName() a atributo, llamadas a métodos deprecados y similares — sin editar archivo por archivo a mano.
Actualiza dependencias y deja que Flex aplique las recipes nuevas:

composer require symfony/symfony:^8.1 --with-all-dependencies

Haz grep de lo específico de tu app antes de asumir que la automatización ya lo cubrió:

grep -rln '<?xml' config/
grep -rn "hide_user_not_found\|->get(" config/ src/
grep -rn "getDefaultName\|getDefaultDescription" src/

Compara tu árbol de config/ contra un symfony/skeleton fresco en la rama destino. La mayor parte de lo que está en esta lista vive en archivos de configuración, no en código del framework, y composer update no te toca la configuración.

¿Cuándo deberías actualizar?

Si ya estás en 8.0: muévete a 8.1 de inmediato. No hay costo de cambio de código bajo la promesa de BC, y cada día después del 30 de julio de 2026 es un día sin parches de seguridad.
Si estás en 7.4, estable, sin presión por funciones nuevas: quédate. Tienes hasta noviembre de 2028 para bug fixes y noviembre de 2029 para seguridad. No hay reloj empujándote a moverte.
Si estás en 7.4 y quieres lo más nuevo o planeas seguir el ritmo de la rama normal: ve a 8.1 ya, y luego sigue los minors semestrales (8.2 llega en noviembre de 2026). Arregla las deprecaciones de config en XML, config PHP fluida y hide_user_not_found antes del salto, no durante.
Si estás en 6.4 o anterior: 6.4 LTS deja de recibir bug fixes en noviembre de 2026 y parches de seguridad en noviembre de 2027; las anteriores ya no reciben nada, salvo 5.4 LTS, que conserva solo los de seguridad hasta febrero de 2029. Pasa por 7.4, limpia cada deprecación con PHPUnit, y luego elige entre LTS y rama normal según qué tanto quieras lo más nuevo contra una ventana de soporte larga y tranquila.

Para seguir leyendo:

Preguntas frecuentes

¿Symfony 8.0 todavía tiene soporte?

No. Symfony 8.0 fue una versión normal (no LTS) con una ventana de soporte de ocho meses que cubría tanto bug fixes como parches de seguridad. Se lanzó el 27 de noviembre de 2025 y su soporte terminó el 30 de julio de 2026. Quien siga corriéndolo está en código sin mantenimiento y debería actualizar a 8.1.

¿Cuál es la diferencia entre Symfony 7.4 y Symfony 8.0?

Salieron el mismo día, el 27 de noviembre de 2025, con funcionalidades idénticas. Symfony 7.4 es la versión LTS y conserva las capas de deprecación acumuladas desde 7.0, así que el código que usa APIs deprecadas sigue funcionando. Symfony 8.0 eliminó todas esas APIs deprecadas. Symfony 7.4 requiere PHP 8.2; Symfony 8.0 requiere PHP 8.4.

¿Qué cambio incompatible causa más fallas silenciosas en Symfony 8?

La configuración en XML. Se deprecó en Symfony 7.4 como una línea de log que nadie suele monitorear, y luego se eliminó por completo en Symfony 8.0. Los equipos que actualizan sin limpiar primero las deprecaciones de 7.4 se topan con una falla dura en 8.0 que parece no tener relación con nada que hayan cambiado. Las cookies de autenticación remember-me son un segundo caso silencioso: su formato cambió y las cookies viejas dejan de autenticar sin ningún error, solo forzando un nuevo inicio de sesión.

¿Actualizar de Symfony 8.0 a 8.1 exige cambios de código?

No. Symfony 8.1 es un minor sobre 8.0 y cae bajo la promesa de retrocompatibilidad. Las consideraciones principales son de comportamiento: Messenger ya no lanza excepción al fallar el decode de un mensaje, ParameterBag::getInt/getBoolean ahora lanzan excepción con input malo en vez de forzarlo en silencio, y el placeholder de un ChoiceType requerido se renderiza como hidden. El cambio de UrlType, que deja de agregar http:// a las URLs sin esquema, no es de 8.1: llegó con 8.0, así que si ya estás en 8.0 ya lo tienes.

¿Qué versión de PHP necesita Symfony 8?

Symfony 8.0 y 8.1 requieren ambos PHP 8.4.0 o superior. Symfony 7.4 LTS solo requiere PHP 8.2.0 o superior, que es una de las razones por las que los equipos que todavía no pueden subir de versión de PHP eligen quedarse en 7.4 en vez de saltar a 8.x.

¿Debería actualizar a Symfony 8.1 o quedarme en 7.4 LTS?

Si necesitas las funciones de PHP 8.4 o lo más nuevo de Symfony y puedes seguir el ritmo semestral de lanzamientos, ve a 8.1. Si quieres una ventana de soporte larga y tranquila sin perseguir cada minor, quédate en 7.4: recibe bug fixes hasta noviembre de 2028 y parches de seguridad hasta noviembre de 2029, sin fecha límite que te empuje.

Vite 8: qué se rompe al actualizar (y por qué ya lo trae Astro 7)

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

Vite 8 llegó a estable el 12 de marzo de 2026 y reemplaza a Rollup y esbuild por un solo bundler en Rust: Rolldown. Casi todo lo que se rompe lo hace en silencio — sin error rojo, nada más un output distinto. Y aquí está la parte que agarra a la gente en curva: si actualizaste a Astro 7 en cualquier momento después de su lanzamiento de junio de 2026, te llevaste Vite 8 de fábrica, lo hayas pedido o no. Este sitio corre Astro 7.2.2, y su node_modules/astro/package.json fija "vite": "^8.0.13". Si seguiste la migración a Astro 7, este post es la parte que nadie te contó.

¿De dónde vienes?

La lista de abajo aplica distinto según de dónde vengas:

Corres Vite directo y ya estás en Vite 7. El caso sencillo. Lee los renombres de config y la sección de interop CJS, corre un build, listo.
Estás en Vite 6 o antes. Estás saltando dos majors de cambios de un jalón — la migración a Vite 7 (Node 20.19+, salida ESM) más todo lo de abajo. Hazlo en dos pasos: aterriza primero en 7, verifica, y luego brinca a 8.
No tocaste Vite. Actualizaste Astro, Nuxt, SvelteKit u otro meta-framework, y Vite 8 se vino de arrastre. Este es el grupo para el que en realidad es este post. Nadie puso “nuevo bundler” en tu changelog; nada más apareció como una línea de vite en tu package-lock.json. Todo lo de aquí en adelante te aplica igual — nada más no elegiste cuándo.

Qué cambió de verdad, en una sola tabla

Área	Vite 7	Vite 8
Bundler de producción	Rollup	Rolldown (Rust)
Pre-bundling de dependencias en dev	esbuild	Rolldown
Transform / minify de JS	esbuild	Oxc
Minify de CSS	esbuild	Lightning CSS
`build.rollupOptions`	válido	deprecado, renombrado a `build.rolldownOptions`
Distribución	ESM	Solo ESM (sin cambio, nada más más estricto)
Mínimo de Node.js	20.19+ / 22.12+	igual
Tamaño de instalación	base	+~15 MB (binarios nativos)
`build.target` por defecto	Chrome 107, Safari 16.0	Chrome 111, Safari 16.4

El número que se roba el titular es real: el propio anuncio de Vite cita el build de producción de Linear bajando de 46s a 6s, Ramp 57% más rápido, Beehiiv 64%, Mercedes-Benz.io 38%. Eso es lo bueno. El resto de este post es la parte que no sale en el titular del release.

Rupturas, ordenadas por impacto

1. Los imports `default` de CommonJS resuelven distinto — en silencio

Esta es la que vale la pena leer dos veces, porque no produce ningún error de build. La guía de migración de Vite 8 lo dice claro: el import default de un módulo CJS solía resolver distinto entre dev y build; ahora es consistente, pero la regla cambió. El import default es el valor completo de module.exports solo si se cumple una de estas — el que importa es .mjs/.mts, el package.json más cercano al que importa tiene "type": "module", o la bandera __esModule del módulo CJS no es true. Si no, te toca module.exports.default.

En la práctica, esto significa que un import que ya funcionaba puede empezar a devolver un objeto envoltorio en vez de la función que esperas:

// cjs-pkg exporta: module.exports = { __esModule: true, default: function greet() {} }

import greet from 'cjs-pkg';
greet(); // Vite 7, en dev: funcionaba
          // Vite 8, .js normal sin "type": "module": TypeError: greet is not a function

La válvula de escape es una línea, y te compra tiempo para arreglar imports uno por uno en vez de todos de golpe:

// vite.config.js
export default defineConfig({
  legacy: { inconsistentCjsInterop: true }, // restaura el comportamiento viejo e inconsistente
});

Está marcada como deprecada a propósito — trátala como puente, no como destino final. Si es un paquete de terceros el que dispara esto, la documentación pide reportarlo al autor del paquete con un link a la explicación de interop CJS de Rolldown, no solo parcharlo por siempre.

2. `build.rollupOptions` ahora es `build.rolldownOptions`

Esta al menos falla lo bastante fuerte como para notarla — una advertencia de deprecación en cada build, todavía no un crash, porque un shim de compatibilidad mantiene viva la llave vieja:

// Antes (Vite 7)
export default defineConfig({
  build: {
    rollupOptions: {
      input: { main: './src/main.ts' },
    },
  },
});

// Después (Vite 8)
export default defineConfig({
  build: {
    rolldownOptions: {
      input: { main: './src/main.ts' },
    },
  },
});

worker.rollupOptions recibe el mismo trato (worker.rolldownOptions). Si tienes ambas en una config de monorepo compartida entre paquetes, un grep -rn "rollupOptions" . antes de empezar te encuentra todos los lugares de un jalón.

3. `manualChunks` como objeto no está deprecado — está eliminado

Escondido dentro del renombre de arriba hay un filo más cortante: la forma de objeto de output.manualChunks ya no está soportada, punto. Solo la forma de función sigue funcionando, y también está marcada como deprecada, a favor de la opción propia de Rolldown, codeSplitting.

// Vite 7 — este patrón aparece seguido en configs reales
build: {
  rollupOptions: {
    output: {
      manualChunks: {
        vendor: ['react', 'react-dom'], // forma de objeto
      },
    },
  },
},

// Vite 8 — la forma de objeto truena en build; convertir a función es el arreglo mínimo
build: {
  rolldownOptions: {
    output: {
      manualChunks(id) {
        if (id.includes('node_modules/react')) return 'vendor';
      },
    },
  },
},

Esta es la que más probablemente rompa tu build de verdad (no nada más avise), porque un montón de configs de Vite copiadas y pegadas usan la forma de objeto para separar vendors.

4. `build.commonjsOptions` ahora es un no-op

Sin advertencia, sin error — nada más se ignora. Si tu config trae build.commonjsOptions.include, .exclude, o .requireReturnsDefault para rodear algún paquete CJS específico, ese parche deja de aplicar en silencio después del upgrade. El síntoma aparece río abajo, en lo que sea que la opción arreglaba, no en la línea de la config — lo que hace fácil culpar a lo que no es.

5. Node.js 20.19+ / 22.12+ es un piso duro, y es por `require(esm)`

Es el mismo requisito de Vite 7, así que si vienes de ahí esto no cambia nada. Pero si brincas desde Vite 6, esto es nuevo: Vite se distribuye solo en ESM, y esas versiones de patch específicas son justo las que soportan require(esm) sin flag — el mecanismo que deja a un toolchain de la era CJS seguir cargando un paquete que solo existe en ESM. Cualquier versión más vieja ni siquiera instala bien, no nada más corre raro.

6. Yarn PnP: sin veredicto oficial, pero tampoco está sólido

La documentación de Vite no trae una línea de “Yarn PnP: no soportado”, pero el issue tracker de rolldown-vite tiene varios reportes abiertos de resolución de dependencias fallando específicamente bajo el modo Plug’n’Play de Yarn — paquetes que resuelven bien con node_modules y truenan con Failed to resolve import bajo PnP. Si tu equipo corre Yarn Berry con nodeLinker: pnp, trata a Vite 8 como “prueba en una rama antes de tocar CI”, no como un reemplazo seguro todavía.

7. El tamaño de instalación crece unos 15 MB

Confirmado en el anuncio de la release: cerca de 10 MB de Lightning CSS (ahora el minificador de CSS por defecto, ya no opcional) y cerca de 5 MB del binario nativo de Rolldown. Nada se rompe funcionalmente, pero si construyes imágenes Docker con presupuesto de capas apretado o metes node_modules completo en un bundle de Lambda, es una línea real que vale la pena revisar — y aplica aunque nunca toques Vite directamente, porque viaja de polizón como dependencia de Astro (o Nuxt, o SvelteKit).

8. Los targets de navegador por defecto subieron — y los navegadores viejos fallan sin avisar en el build

Los valores por defecto de build.target subieron: Chrome 107→111, Edge 107→111, Firefox 104→114, Safari 16.0→16.4, alineados a Baseline Widely Available de enero de 2026. Vite compila sin quejarse de cualquier forma — la falla, si la tienes, aparece como JavaScript roto en un Safari viejo dentro del analytics de producción de alguien, semanas después, sin nada en tu log de build que señale la causa. Si tienes una matriz de soporte de navegadores documentada que incluya algo más viejo que Safari 16.4, fija build.target a mano en vez de confiar en el default.

9. Los plugins en general nada más funcionan — con dos excepciones reales

Rolldown implementa la misma API de plugins que Rollup, y los plugins de framework que importan ya están al día: @vitejs/plugin-react v6 usa Oxc en vez de Babel para el transform de Refresh (la v5 sigue corriendo bien en Vite 8 si todavía no la actualizas), y @vitejs/plugin-vue no necesita cambios. Donde sí se rompe de verdad:

Plugins que dependen del hook moduleParsed: está documentado que no se llama en dev en absoluto, para evitar un parse completo de AST en cada archivo.
Plugins construidos contra el formato propio de esbuild (onLoad/onResolve, no el de Rollup) — esa es una API completamente distinta y Rolldown no la habla. Si el README de un plugin menciona “esbuild plugin”, busca un reemplazo nativo de Rolldown antes de asumir que se actualiza gratis.

¿Cuándo conviene actualizar?

Corres Vite directo, ya en 7, sin dependencias CJS exóticas: actualiza ya. La ganancia en tiempo de build es real y la superficie de ruptura es chica si no dependes de manualChunks como objeto.

Estás en Vite 6: pasa por 7 primero. Vite mantiene un paquete rolldown-vite que es “Vite 7 con Rolldown, nada más” pensado como paso intermedio — úsalo para aislar el cambio de bundler del salto de versión.

Llegaste aquí vía Astro 7 (o Nuxt, SvelteKit, similar): ya lo estás corriendo. La movida no es “¿le entro?” — es auditar tu vite.config existente en busca de rollupOptions.output.manualChunks como objeto y cualquier override de commonjsOptions, porque esas son las dos que fallan o se apagan en silencio sin que hayas tocado la versión del framework para nada.

Tu equipo corre Yarn PnP: espera, o fija rolldown-vite@7.x y vigila los issues abiertos antes de moverte a Vite 8 de verdad.

Mantienes un plugin de Rollup con uso pesado de moduleParsed o de hooks de output: presupuesta tiempo real, no un ajuste de config — es un problema de forma de API, no un renombre.

Para seguir:

Actualizar a Astro 7 — el upgrade de framework que trae Vite 8 de arrastre, con su propio set de trampas aparte.
Node 26: qué se rompe al actualizar — el lado del runtime del mismo problema de “se rompe en silencio”, para la versión sobre la que corren la mayoría de instalaciones de Vite 8.
TypeScript 7: qué se rompe al actualizar — mismo formato, mismo instinto: ordenar por impacto, marcar lo que falla sin avisar.

Preguntas frecuentes

¿Astro 7 usa Vite 8?

Sí. Astro 7.0.0 ya fija "vite": "^8.0.13" en su package.json, y cada release 7.x desde entonces lo hereda. Si actualizaste de Astro 6 a Astro 7, te llevaste Vite 8 y su bundler Rolldown automáticamente, sin un paso de actualización de Vite aparte.

¿Qué se rompe en silencio al actualizar a Vite 8?

Dos cosas no producen ningún error de build: la resolución de imports default de CommonJS cambió de regla (un import x from 'paquete-cjs' que ya funcionaba puede empezar a devolver un objeto envoltorio en vez del valor que esperas), y build.commonjsOptions se volvió un no-op, así que cualquier parche de include/exclude/requireReturnsDefault en tu config deja de aplicar en silencio. Las dos fallan río abajo, no en la línea de la config, lo que las hace fáciles de diagnosticar mal.

¿Por qué build.rollupOptions dejó de funcionar en mi vite.config.js?

Se renombró a build.rolldownOptions porque Vite 8 reemplazó Rollup por Rolldown como su bundler. La llave vieja todavía funciona a través de un shim de deprecación y muestra una advertencia en cada build, pero eventualmente se va a eliminar. worker.rollupOptions sigue el mismo renombre, a worker.rolldownOptions.

¿Todavía puedo usar manualChunks como objeto en Vite 8?

No. La forma de objeto de output.manualChunks se eliminó por completo, no nada más se deprecó, y usarla truena en tiempo de build. Solo la forma de función sigue funcionando, y esa también está marcada como deprecada a favor de la opción codeSplitting de Rolldown. Las configs de separación de vendors copiadas de tutoriales viejos son el lugar más común donde esto aparece.

¿Vite 8 es compatible con Yarn PnP?

No hay una postura oficial en ningún sentido en la documentación de Vite, pero el issue tracker de rolldown-vite tiene varios reportes abiertos de resolución de dependencias fallando bajo el modo Plug'n'Play de Yarn al momento de escribir esto. Los equipos con Yarn Berry y nodeLinker: pnp deberían probar en una rama antes de meter Vite 8 a CI, o quedarse en el paquete intermedio rolldown-vite@7.x.

¿Necesito actualizar @vitejs/plugin-react o @vitejs/plugin-vue para Vite 8?

No estrictamente. @vitejs/plugin-vue funciona sin modificar, y la v5 de @vitejs/plugin-react sigue corriendo en Vite 8. La v6 de plugin-react es la actualización recomendada porque pasó de Babel a Oxc para el transform de Fast Refresh, lo que es más ligero de instalar y empata con el resto del toolchain de Vite 8, pero no es un requisito duro.

¿Cuánto cuesta una página web en México en 2026? (y cuándo no deberías pagar por una)

Marco Orta — Sat, 22 Aug 2026 00:00:00 GMT

Una página web profesional en México cuesta en 2026 entre $8,000 y $25,000 MXN si es una landing o un sitio informativo, entre $25,000 y $80,000 MXN si es un sitio corporativo a medida, y de $50,000 MXN en adelante si hablamos de e-commerce o una aplicación web. A eso hay que sumarle lo que casi ninguna cotización desglosa: dominio ($200–800 al año), hosting ($40–300 al mes) y mantenimiento ($1,500–4,000 al mes si lo delegas). Y hay un cuarto rango del que las agencias no te hablan: $0 de desarrollo, porque hay negocios a los que hoy les conviene más un builder o un perfil de Google que pagar por un sitio.

Yo desarrollo sitios y sistemas web — es decir, tengo el incentivo de venderte uno. Por eso esta guía va al revés de las de agencia: primero los números del mercado con sus fuentes, luego qué los mueve de verdad, y al final los casos en los que no te conviene contratarme ni a mí ni a nadie.

Si solo vienes por tu número: mi cotizador te da un rango al instante, eligiendo tipo de proyecto, complejidad y funciones. Sin dejar tu correo.

Los rangos del mercado en 2026

Crucé lo que publican los estudios de precios de este año — Simplixy, GEDX y New Emage entre otros — con lo que yo mismo cotizo. Coinciden más de lo que esperarías:

Tipo de sitio	Rango 2026 (MXN)	Qué incluye normalmente
Hazlo tú mismo (builder)	$0 – $4,000 / año	Plantilla, editor visual, hosting incluido
Landing page	$8,000 – $25,000	1 página enfocada a captar clientes o validar una idea
Sitio informativo / profesional	$14,000 – $30,000	5–8 páginas, diseño personalizado, SEO básico
Sitio corporativo a medida	$25,000 – $80,000	Diseño propio, contenido optimizado, integraciones
E-commerce	$27,000 – $126,000	Catálogo, pagos, envíos, facturación
Aplicación web	$36,000 – $250,000+	Lógica de negocio propia, usuarios, paneles

Dos advertencias sobre esta tabla, porque las tablas mienten con facilidad:

El rango dentro de cada fila es más ancho que el rango entre filas. Una landing compleja puede costar más que un sitio corporativo simple. El tipo de sitio es el punto de partida, no el precio.
Freelancer vs agencia mueve el número tanto como el proyecto. El mismo sitio informativo va de $5,000–25,000 MXN con un freelancer a $15,900 MXN en adelante con agencia. No es que uno esté bien y otro mal: pagas cosas distintas — con la agencia, gestión y continuidad; con el freelancer, trato directo y menos capas.

Lo que la cotización no suele desglosar

El precio del desarrollo es el número grande, pero es el único que pagas una vez. Estos son los que pagas para siempre:

Dominio: $200–800 MXN al año. Se renueva cada año y debe estar a tu nombre — si tu proveedor lo registra a nombre suyo, el día que quieras cambiarte descubrirás que tu dominio no es tuyo. Es la letra chiquita más cara de esta industria.
Hosting: $40–300 MXN al mes en planes básicos; más si el sitio crece. Aplica lo mismo: acceso propio, siempre.
Mantenimiento: $1,500–4,000 MXN al mes si lo contratas. Aquí sí hay decisión real: un sitio informativo estático puede vivir años sin mantenimiento; un WordPress con plugins, no — sin actualizaciones es cosa de tiempo que lo hackeen.
Renovaciones invisibles: certificado SSL (hoy debería ser gratis con Let’s Encrypt — sospecha de quien lo cobre aparte), licencias de plugins o plantillas, y el correo corporativo.

La pregunta que le haría yo a cualquier cotización: «¿qué de esto pago una vez y qué pago cada mes, y a nombre de quién queda cada cosa?». La respuesta te dice más del proveedor que su portafolio.

Las tres cosas que de verdad encarecen un proyecto

Después de cotizar muchos proyectos, los factores que mueven el precio casi siempre son los mismos tres — y ninguno es “el diseño”:

Funcionalidad, no páginas. Duplicar el número de páginas apenas mueve el precio; añadir pagos en línea, un área de clientes con sesión, facturación CFDI o una integración con tu sistema interno lo puede duplicar. Cada función de esas es software que hay que construir y probar.
La complejidad del contenido y las decisiones. Un proyecto donde el cliente trae textos, fotos y estructura clara cuesta horas; uno donde todo se decide en juntas cuesta semanas. Se cobra el tiempo, y el tiempo se va en decidir.
La urgencia. «Lo necesito en dos semanas» es un multiplicador, no un detalle. Comprimir un proyecto obliga a apartar otros, y eso se cobra.

Por eso desconfío de los precios cerrados por catálogo («sitio web: $9,999») tanto como de los presupuestos sin desglose: los dos esconden en qué fila de la tabla vas a caer después de firmar.

Cuándo NO deberías pagar por una página web

Esta sección no aparece en las guías de agencias, por razones obvias:

Si tu negocio vive de un radio de 5 cuadras — una fonda, una estética, un taller — tu inversión digital con mejor retorno es un perfil de Google Business bien trabajado (gratis) y WhatsApp Business (gratis). Una web de $15,000 MXN no te traerá más clientes que eso.
Si todavía estás validando la idea, un builder tipo Wix o un sitio de una página hecho con plantilla ($0–4,000 MXN/año) es suficiente para probar. Pagar desarrollo a medida antes de saber si el negocio funciona es construir la casa antes que los cimientos.
Si vendes por marketplace y te va bien ahí, la web propia es diversificación, no urgencia. Llega, pero no tiene que ser hoy.

¿Cuándo sí? Cuando el sitio tiene un trabajo concreto que hacer — captar leads, vender, automatizar algo que hoy haces a mano — y puedes ponerle número a ese trabajo. En ese momento el sitio deja de ser un gasto de imagen y se vuelve una inversión con retorno medible. De medirlo escribí en la guía de GEO y AEO: de nada sirve un sitio de $80,000 que ni Google ni ChatGPT pueden leer.

Cómo cotizo yo (para que compares con lo que te ofrezcan)

Mi cotizador es público y funciona sin registro: eliges tipo de proyecto (landing, corporativo, e-commerce, aplicación web, API, app móvil), nivel de complejidad y funciones concretas, y te da el rango en pesos o dólares al momento. Los rangos que arroja para los proyectos típicos van de $3,600 MXN (una landing mínima) hasta los cientos de miles de una aplicación completa — los mismos órdenes de magnitud de la tabla de arriba, porque el mercado mexicano de desarrollo serio converge en esos números.

Lo que sí varía entre proveedores — y donde de verdad se compite — es lo de siempre: el desglose claro, a nombre de quién quedan dominio y hosting, y si el que te cotiza va a estar ahí en un año. Pregunta esas tres cosas antes que el precio.

Si prefieres platicar el proyecto directamente, en servicio de desarrollo web está el detalle de cómo trabajo.

Preguntas frecuentes

¿Cuánto cuesta una página web profesional en México en 2026?

Los rangos de mercado en 2026: una landing page entre $8,000 y $25,000 MXN; un sitio informativo profesional de 5 a 8 páginas entre $14,000 y $30,000 MXN; un sitio corporativo a medida entre $25,000 y $80,000 MXN; y un e-commerce desde unos $27,000 MXN. A eso se suman los costos recurrentes: dominio ($200–800 al año), hosting ($40–300 al mes) y mantenimiento ($1,500–4,000 al mes si se contrata).

¿Qué es más barato: freelancer o agencia?

El freelancer casi siempre cotiza más bajo: un sitio informativo va de $5,000 a $25,000 MXN con freelancer, mientras una agencia parte de unos $15,900 MXN por proyectos similares. Pero pagan cosas distintas: la agencia cobra gestión, equipo y continuidad; el freelancer ofrece trato directo y menos capas. El criterio útil no es el precio sino el desglose, la propiedad del dominio y quién dará mantenimiento en un año.

¿Cuánto cuesta mantener una página web al mes en México?

Los costos recurrentes mínimos son el hosting ($40–300 MXN al mes en planes básicos) y el dominio (unos $200–800 MXN al año). Si se contrata mantenimiento —actualizaciones, seguridad, cambios menores— el mercado ronda entre $1,500 y $4,000 MXN mensuales. Un sitio estático bien hecho puede vivir con el mínimo; un WordPress con plugins necesita mantenimiento activo o termina hackeado.

¿Cuándo conviene NO pagar por una página web?

Cuando el negocio es puramente local y de radio corto (una fonda, una estética), donde un perfil de Google Business y WhatsApp Business gratuitos rinden más; cuando la idea de negocio aún no está validada, donde basta un builder de $0 a $4,000 MXN al año; y cuando las ventas ya funcionan por marketplace y la web propia es diversificación, no urgencia. El sitio a medida conviene cuando tiene un trabajo medible: captar clientes, vender o automatizar.

¿Qué encarece más una página web: el diseño o las funciones?

Las funciones. Duplicar el número de páginas apenas mueve el precio, pero añadir pagos en línea, área de clientes, facturación CFDI o integraciones con sistemas internos puede duplicarlo, porque cada función es software que hay que construir y probar. Los otros dos factores que más pesan son la claridad del contenido que aporta el cliente y la urgencia del plazo.

¿El dominio y el hosting deben quedar a mi nombre?

Siempre. Si el proveedor registra el dominio a su nombre, el negocio no es dueño de su propia dirección en internet, y cambiar de proveedor se convierte en una negociación. Antes de firmar, hay que confirmar que el dominio queda a nombre del cliente y que se entregan los accesos del hosting. Es la pregunta que más problemas evita en toda la contratación.

Los mejores servidores MCP para SEO y GEO en 2026: cuál conectar según tu caso

Marco Orta — Sat, 22 Aug 2026 00:00:00 GMT

No existe «el mejor servidor MCP para SEO»: existe el mejor para cada tipo de dato. Si lo que quieres es leer el rendimiento real de tu sitio, el MCP de Google Search Console es gratis y nadie tiene datos más exactos. Si necesitas datos de terceros —keywords, competidores, SERPs— la decisión está entre DataForSEO (pago por consulta) y Ahrefs o Semrush (suscripción). Y si tu pregunta es de GEO — ¿puede ChatGPT leer y citar mi web? — esa capa la cubren herramientas de auditoría como mi seo-geo-mcp, que es open source y no pide ni API key.

A mediados de 2026, prácticamente toda plataforma SEO grande tiene un servidor MCP oficial o está corriendo para publicarlo. Eso es bueno y malo a la vez: hay dónde elegir, pero los listados de «los 12 mejores» mezclan cosas que no compiten entre sí. Esta guía los ordena por la única pregunta que de verdad decide: ¿de quién son los datos que tu agente necesita?

Si todavía no tienes claro qué es MCP o cómo un agente usa estas conexiones, empieza por la guía de IA agéntica, agentes y MCP y vuelve: esta pieza asume esa base.

La tabla completa

Servidor	Datos que expone	Precio	Tipo
Google Search Console	Clicks, impresiones, CTR, posiciones de tu sitio	Gratis	Solo de la comunidad: Google no tiene uno oficial
Google Analytics 4	Eventos, conversiones, embudos de tu sitio	Gratis	Oficial (experimental)
DataForSEO	SERPs, keywords, backlinks, on-page (Google, Bing, Baidu)	Pago por consulta	Oficial
Ahrefs	20 grupos de tools: Site Explorer, Keywords, Site Audit, Rank Tracker, Brand Radar	Por unidades, según plan	Oficial
Semrush	Keywords (más de 28.000 M, 142 bases regionales), competencia	Ligado a suscripción	Oficial
SE Ranking	180+ tools: keywords, auditorías, backlinks, visibilidad en IA	Ligado a suscripción o API de pago por uso	Oficial
Nightwatch	Rankings (Google/Bing/YouTube) + visibilidad en IA	Desde plan de pago	Oficial
Advanced Web Ranking	48 tools de rank tracking histórico y comparativas	Plan Agency o superior	Oficial
Screaming Frog	Orquestar rastreos y auditorías técnicas desde el agente	Con la licencia (v24+)	Oficial, local
Peec AI	Citaciones y visibilidad en 8 motores de IA (ChatGPT, Perplexity, Gemini, Claude, Copilot…)	Planes de pago	Oficial
seo-geo-mcp	17 tools de auditoría on-page + GEO: robots, crawlers de IA, schema, hreflang	Gratis, sin API keys	Open source (npm), local o auto-hospedado

Los datos de tools y precios salen de la documentación de cada plataforma y de los análisis comparativos de Nightwatch y MCP.Directory; las cifras concretas de tu factura dependen de tu plan.

Cómo se conecta cada uno y cuánto cuesta entrar

Verificado el 13 de septiembre de 2026 en la documentación y la página de precios de cada plataforma (enlazadas). «Remoto» es un servidor que aloja la plataforma y al que te conectas por HTTP; «local» es un proceso que corre en tu máquina, normalmente por stdio. Precios de lista en dólares o euros, sin impuestos y con pago mensual salvo que se indique.

Servidor	Transporte	Autenticación	Precio de entrada
Google Search Console	Local (stdio), implementaciones de la comunidad	Credenciales de Google Cloud (OAuth o service account)	0 USD
Google Analytics 4	Local (stdio, `pipx run analytics-mcp`)	Credenciales de Google Cloud, alcance de solo lectura	0 USD
DataForSEO	Remoto (`mcp.dataforseo.com/v3/mcp`), HTTP local o stdio	OAuth por HTTP; login y contraseña de la API por stdio	1 USD de saldo de prueba al registrarte; recarga mínima de 50 USD
Ahrefs	Remoto (`api.ahrefs.com/mcp/mcp`)	OAuth o clave MCP	Plan Lite, 129 USD/mes; consume las unidades de API del plan
Semrush	Remoto (`mcp.semrush.com/v2/mcp`)	OAuth o API key	Semrush One Starter, 199 USD/mes, u otro plan de su lista; incluyen 50.000 unidades de API
SE Ranking	Remoto	Autorizas la conexión con tu cuenta	Prueba con 100.000 créditos sin tarjeta; API de pago por uso desde 50 USD por 250.000 créditos
Nightwatch	Remoto (`mcp.nightwatch.io`, SSE)	Token Bearer	Starter, 79 €/mes con pago anual (948 €/año); el MCP va en todos los planes
Advanced Web Ranking	Remoto (`api.advancedwebranking.com/mcp`)	OAuth o API key	Plan Agency, 279 USD/mes
Screaming Frog	Local, junto a SEO Spider v24+ (stdio o Streamable HTTP)	La licencia del programa	Licencia de 279 USD/año; el MCP no funciona en la versión gratuita
Peec AI	Remoto (`api.peec.ai/mcp`)	OAuth o token personal	Starter, 95 USD/mes
seo-geo-mcp	Local (stdio, `npx -y seo-geo-mcp-server`) o HTTP auto-hospedado	Ninguna (token Bearer opcional en HTTP)	0 USD

Dos avisos que no caben en la tabla. El repositorio local de Ahrefs (ahrefs/ahrefs-mcp-server) está archivado y su propio README pide no usarlo: el oficial es el remoto. Y ni Google ni Microsoft publican un MCP para sus consolas: la lista oficial de servidores MCP de Google incluye Analytics pero no Search Console, y la petición de uno oficial sigue abierta; para Bing Webmaster Tools tampoco encontré uno de Microsoft, solo implementaciones de la comunidad.

Caso 1: quieres leer los datos de TU sitio

Empieza aquí, porque es gratis y es el dato más exacto que existe. El MCP de Google Search Console le da a tu agente acceso directo a clicks, impresiones, CTR y posición por consulta y por página — el mismo dato de primera mano que ves en la consola, sin muestreos de terceros. Ojo con el nombre: Google no publica un MCP de Search Console. Todas las implementaciones son open source y de la comunidad, y todas piden credenciales de Google Cloud (OAuth o service account), que es el único peaje de instalación.

Su límite es estructural, no del MCP: Search Console solo retiene 16 meses de historia. Si quieres series más largas, tu agente tiene que ir guardando snapshots — el problema deja de ser de conexión y pasa a ser de almacenamiento.

El MCP de Google Analytics 4 (oficial, todavía experimental) es su pareja natural: GSC te dice cómo llegan, GA4 qué hacen después. Juntos cubren el embudo completo sin gastar un centavo.

Caso 2: necesitas datos de terceros — keywords, SERPs, competidores

Aquí es donde está la decisión con dinero de por medio, y el criterio es el patrón de uso:

DataForSEO cobra por consulta, sin suscripción: 1 USD de prueba al registrarte y recargas desde 50 USD. Para flujos de agente — que hacen ráfagas de consultas puntuales, no monitoreo continuo — suele salir mucho más barato que una suscripción completa. Su contra: no hay interfaz; es una capa de datos pura y la calidad del resultado depende por completo de cómo pregunte tu agente.
Ahrefs reparte sus herramientas en 20 grupos (Site Explorer, Keywords Explorer, Site Audit, Rank Tracker, Brand Radar…) sobre su índice de enlaces, con un sistema de unidades por plan desde Lite. Son tantas que su propia documentación admite que superan el límite de algunos clientes MCP, y por eso acepta ?tools=essentials o una lista de grupos en la URL. El riesgo práctico es nuevo y muy de 2026: un agente en bucle puede quemar tus unidades del mes en una tarde. Si lo conectas, ponle presupuesto por sesión (Ahrefs deja fijar un tope mensual de unidades por clave).
Semrush juega la carta de la cobertura (más de 28.000 millones de keywords en 142 bases regionales). Su MCP funciona en ChatGPT, Claude, Cursor, VS Code y Perplexity, y de su API de proyectos solo expone los métodos de lectura.
SE Ranking es el de mayor superficie (180+ tools) — tanta, que conviene podar las que expones por sesión: a los agentes les cuesta elegir entre 180 opciones.

Mi lectura práctica: para automatizaciones puntuales y agentes, DataForSEO; si ya pagas Ahrefs o Semrush por otra razón, su MCP es un añadido obvio y no una razón para suscribirse.

Caso 3: rank tracking y auditoría técnica

Nightwatch y Advanced Web Ranking son rank trackers con MCP: posiciones históricas, ganadores/perdedores, comparativas multi-proyecto. AWR pide plan Agency, así que solo tiene sentido en agencias.
Screaming Frog (desde la v24) trae MCP oficial: tu agente puede orquestar rastreos — «rastrea el sitio y dime qué páginas tienen títulos duplicados» — sobre la herramienta que ya usabas. Corre local, atado a tu licencia y a tu máquina: en la versión gratuita del programa el MCP no funciona.

Caso 4: GEO — ¿pueden los motores de IA leerte y citarte?

Esta es la capa nueva, y la que más se confunde con el SEO clásico. La pregunta ya no es «¿posiciono?» sino «¿puede GPTBot rastrearme, entiende mi schema, y estoy bloqueando sin querer al bot que me citaría?». Dos herramientas la atacan desde ángulos opuestos:

Peec AI mide el resultado: qué motores de IA te citan, cuánto, y contra quién compites en cada respuesta.
seo-geo-mcp — mi servidor, open source — audita la causa: 17 herramientas de solo lectura que revisan si tu página es rastreable y citable. Separa el bloqueo de entrenamiento del de citación (bloquear GPTBot impide entrenar; bloquear OAI-SearchBot te borra de las respuestas de ChatGPT — mucha gente hizo lo segundo queriendo lo primero), detecta páginas que renderizan solo en cliente (Googlebot ejecuta JavaScript; GPTBot, ClaudeBot y PerplexityBot en general no), y valida schema, hreflang, sitemaps y redirecciones. Sin API keys: todo se resuelve con HTTP, DNS y robots.txt públicos.

Lo que seo-geo-mcp no hace, para que no lo conectes esperando otra cosa: no tiene datos de keywords, ni de backlinks, ni de posiciones. Es el auditor, no la base de datos. La combinación que uso yo: GSC para el rendimiento, seo-geo-mcp para el diagnóstico, y esta pareja cubre el 90 % del trabajo de un sitio propio sin pagar nada.

El porqué de invertir en esta capa tiene números detrás: el estudio de GEO de Princeton (KDD 2024) midió que optimizar el contenido para motores generativos —citas, estadísticas, fuentes— puede subir la visibilidad en sus respuestas hasta un 40 %. Cómo aplicarlo lo tienes en la guía de GEO y AEO: aparecer en ChatGPT.

Conectar uno, en 60 segundos

Con Claude Code, un MCP remoto se añade con un comando (la URL exacta la da la documentación de cada plataforma):

claude mcp add --transport http ahrefs https://api.ahrefs.com/mcp/mcp

Y uno local (como seo-geo-mcp), que Claude Code arranca como proceso y le habla por stdio. Como está publicado en npm, no hace falta clonar nada:

claude mcp add seo-geo -- npx -y seo-geo-mcp-server

Dos consejos que ahorran disgustos: conecta solo los que uses en esa sesión — cada servidor suma herramientas al contexto del agente y demasiadas opciones lo vuelven torpe — y en los de pago, revisa el consumo tras las primeras sesiones: el patrón de consulta de un agente no se parece al de un humano.

El resumen honesto

Sitio propio, presupuesto cero: Search Console MCP + seo-geo-mcp. Gratis los dos, cubren rendimiento y diagnóstico.
Investigación de keywords y competidores: DataForSEO si pagas por uso; Ahrefs/Semrush si ya tienes la suscripción.
Agencia con reporting: SE Ranking o Nightwatch, que traen el rank tracking integrado.
Auditoría técnica profunda: Screaming Frog v24+ con su MCP local.
Medir citaciones en IA: Peec AI, cuando ya hiciste los deberes de las capas anteriores.

Preguntas frecuentes

¿Qué es un servidor MCP de SEO?

Es un servidor del Model Context Protocol que expone datos o herramientas SEO —posiciones, keywords, backlinks, auditorías— a un agente de IA como Claude o ChatGPT. En vez de copiar y pegar informes, el agente consulta la fuente directamente: pide las posiciones a Search Console, lanza un rastreo a Screaming Frog o audita el robots.txt de una página, y razona sobre el resultado.

¿Cuál es el mejor servidor MCP para SEO en 2026?

Depende del dato que necesites. Para el rendimiento de tu propio sitio, el MCP de Google Search Console (gratis y con el dato más exacto posible). Para datos de terceros como keywords y SERPs, DataForSEO si prefieres pagar por consulta, o Ahrefs/Semrush si ya tienes su suscripción. Para auditoría GEO —si los motores de IA pueden leer y citar tu web— seo-geo-mcp, que es open source y no requiere API keys.

¿Hay servidores MCP de SEO gratuitos?

Sí. Los MCP de Google Search Console (todos de la comunidad: Google no publica uno oficial) y el de Google Analytics 4 son gratuitos (solo piden credenciales de Google Cloud), y seo-geo-mcp es open source y funciona sin ninguna API key porque todo lo resuelve con HTTP, DNS y robots.txt públicos. Con esos tres se cubre el rendimiento y el diagnóstico de un sitio propio sin coste.

¿Qué diferencia hay entre un MCP de SEO y uno de GEO?

El de SEO responde preguntas del buscador clásico: posiciones, keywords, backlinks. El de GEO responde si los motores generativos —ChatGPT, Perplexity, Gemini— pueden rastrear, leer y citar tu página: si robots.txt bloquea al bot equivocado, si la página depende de JavaScript que esos crawlers no ejecutan, o si el schema está bien formado. Son capas complementarias: puedes posicionar bien en Google y ser invisible para los asistentes de IA.

¿Un agente de IA puede gastar mucho dinero usando un MCP de pago?

Sí, y es el riesgo práctico más nuevo de esta categoría: un agente en bucle hace ráfagas de consultas que no se parecen al uso humano, y en servidores con sistema de unidades como Ahrefs puede consumir la cuota mensual en una sesión larga. La defensa es ponerle presupuesto por sesión, conectar solo los servidores necesarios y revisar el consumo tras las primeras sesiones de uso.

Marco Orta — Blog

Laravel Octane + FrankenPHP: qué se rompe de verdad (reproduje cada fuga)

El laboratorio

Antes de arrancar: pcntl, zip y el binario musl

1. Singletons: la fuga que todos describen no es la que muerde

2. El estado estático crece hasta que el worker se reinicia

3. --max-requests=0 no significa «sin límite» en FrankenPHP

4. La configuración inyectada en un singleton se queda vieja, y puede envenenar el worker

5. Lo que añade FrankenPHP: hilos, $_ENV y exit()

6. Las funciones exclusivas de Swoole fallan en silencio

7. Paquetes: casi todos bien en 2026

¿Vale la pena? Los números

La revisión antes de cambiar

Preguntas frecuentes

¿Un singleton que recibe la petición se filtra entre peticiones en Laravel Octane?

¿Qué hace --max-requests=0 con Octane y FrankenPHP?

¿Qué funciones de Octane no sirven con FrankenPHP?

¿Por qué Laravel Octane falla con «Undefined constant SIGINT» en FrankenPHP?

¿$_ENV se reinicia entre peticiones en el modo worker de FrankenPHP?

¿Cuánto más rápido es Laravel con Octane y FrankenPHP?

Meta prohibió los chatbots de IA genéricos en WhatsApp: qué cambia para tu negocio en México (y qué no)

Qué dice la regla, palabra por palabra

Quién se fue de WhatsApp (y quién volvió)

Por qué en Europa y Brasil sí hay ChatGPT

Lo que tu negocio sí puede hacer con IA en WhatsApp

Lo que sí cambia para ti (y no tiene que ver con la prohibición)

1. Desde el 1 de octubre, las respuestas de atención se cobran

2. Meta ya vende su propio agente de IA

3. Los términos se reorganizan el 23 de septiembre

¿El agente de Meta o uno conectado a tu negocio?

Cinco preguntas para tu proveedor de bot

Preguntas frecuentes

¿Meta prohibió los chatbots de IA en WhatsApp?

¿Puedo usar un bot de IA en el WhatsApp de mi negocio en 2026?

¿Por qué ChatGPT sí funciona en WhatsApp en España y no en México?

¿Me pueden suspender el número por usar IA en WhatsApp?

¿Cuánto cuesta el agente de IA de Meta para negocios?

¿Las respuestas de un bot de IA en WhatsApp se cobran?

OpenAI apaga GPT-4, o1 y o3-mini el 23 de octubre: qué se rompe en tu código (y no es solo el nombre del modelo)

Qué se apaga y qué dice OpenAI que uses

Cómo se ve el fallo

1. El modelo que nunca escribiste: los defaults de las librerías

2. Las tools en Chat Completions ahora piden el razonamiento apagado

3. max_tokens: cambia de nombre y ahora paga el razonamiento

4. Los fine-tunes no tienen sucesor

5. o1-pro y gpt-image-1: cambian los parámetros, no solo el nombre

6. La factura

La auditoría: tres greps y una petición real

El resto del calendario de OpenAI este año

Preguntas frecuentes

¿Qué modelos de OpenAI se apagan el 23 de octubre de 2026?

¿Por qué modelo cambio gpt-4 y gpt-3.5-turbo?

¿Qué error devuelve la API de OpenAI con un modelo retirado?

¿LangChain sigue usando gpt-3.5-turbo por defecto?

¿Por qué gpt-5.6 falla con «Function tools with reasoning_effort are not supported»?

¿Sale más caro migrar a gpt-5.6?

¿Qué pasa con mi modelo gpt-3.5-turbo con fine-tuning?

Por qué tu tienda en línea se cae en el Buen Fin (y cómo evitarlo): la guía técnica de 2026

Lo que pasa en esos cinco días

1. Tu hosting compartido tiene un techo, y está escrito

2. La caché: qué se puede guardar y qué no

3. Tu pasarela de pagos también tiene límite

4. El problema que nadie te cuenta: el pago en OXXO aparta tu inventario

5. Sobreventa: dos personas compran la última pieza

6. Lo que trabaja en segundo plano

7. Pruébalo antes con tráfico falso

Si tu tienda está en Shopify o Tiendanube

La lista para dos semanas antes

Preguntas frecuentes

¿Cuándo es el Buen Fin 2026?

¿Por qué se cae una tienda en línea en el Buen Fin?

¿Cloudflare gratis protege mi tienda del tráfico del Buen Fin?

¿Un pago en OXXO pendiente aparta mi inventario?

¿Cómo hago una prueba de carga de mi tienda en línea?

¿Qué pasa si se cae el banco de mi cliente durante el Buen Fin?

Chrome quita XSLT: qué se rompe en sitemaps, feeds y visores de CFDI

Las fechas

Qué se rompe, qué ves y cómo se arregla

Sitemaps y feeds: se rompe el adorno, no el archivo

¿Y Google?

3. `--max-requests=0` no significa «sin límite» en FrankenPHP

5. Lo que añade FrankenPHP: hilos, `$_ENV` y `exit()`

3. `max_tokens`: cambia de nombre y ahora paga el razonamiento

5. `o1-pro` y `gpt-image-1`: cambian los parámetros, no solo el nombre

Dockge: si solo quieres editar tus `compose.yaml` desde el navegador

`pricing.type`: el que decide