OpenAI reemplazó en el segundo trimestre de 2026 el servicio en Python que atendía cada lectura de datos de ChatGPT por una reescritura en Rust, un proyecto que completaron dos ingenieros con Codex y GPT-5.5. El resultado gestiona hoy el 95% del tráfico de producción, es seis veces más eficiente en CPU y quince veces más eficiente en memoria que el servicio anterior, y la implementación en Python está siendo retirada por completo.
Claves del caso
- Habitat, la plataforma de almacenamiento en línea de OpenAI, atiende más de 70 millones de solicitudes por segundo sobre más de 500 petabytes de datos para productos que usan mil millones de personas cada semana.
- La reescritura de Python a Rust la ejecutaron dos ingenieros apoyados en Codex y GPT-5.5, con mejoras de 6 veces en CPU y 15 veces en memoria.
- Las lecciones más duras fueron operativas y no del lenguaje: retardos de planificación en asyncio, reutilización de conexiones en orden LIFO que concentraba la carga en los pods que ya iban ahogados, y efecto de estampida a través de Envoy e Istio.
Qué hace Habitat y por qué existe
Habitat se sitúa entre los productos de OpenAI y los sistemas de almacenamiento que están debajo: Azure Cosmos DB, almacenamiento de objetos, capas de caché y bases de datos internas. Cuando un producto necesita datos, Habitat resuelve el esquema, enruta la solicitud, comprueba la autorización, se encarga del cifrado y la serialización, da forma a la petición y administra el grupo de conexiones. Los ingenieros de producto tratan con una sola interfaz en lugar de aprender cada backend.
El origen fue mucho más modesto. Habitat nació a mediados de 2024 como una biblioteca cliente en Python, en esencia un paquete compartido que los servicios importaban para hablar con una base de datos. Ese diseño se construyó rápido y, durante un tiempo, también se mejoró rápido: añadir caché o compresión consistía en publicar una versión nueva y dejar que cada equipo la adoptara.
El problema de una biblioteca es que las actualizaciones quedan repartidas. OpenAI describe el intento de distribuir datos críticos entre varias cuentas de base de datos regionales para sobrevivir a la caída de una región, lo que exigía nueva lógica de enrutamiento dentro de cada servicio consumidor, desplegada uno por uno, validada en paralelo contra tráfico real y activada después detrás de un interruptor de funcionalidad. Coordinar decenas de servicios llevó días y al menos un equipo revirtió a una versión que arrastraba un error antiguo, provocando justo la caída que el trabajo pretendía evitar. Habitat se extrajo como servicio independiente a mediados de 2025: en los productos quedó un SDK cliente ligero y el enrutamiento, el despliegue, la monitorización y el control de acceso se concentraron en un solo lugar.
Los fallos que aparecieron a escala
Operar ese servicio en Python con el volumen de solicitudes de OpenAI sacó a la luz problemas que no aparecen en los benchmarks. El retardo de planificación de asyncio, provocado por trabajo de fondo intensivo en CPU, acabó dominando la latencia de cola incluso cuando las llamadas posteriores respondían rápido. En un caso, todos los pods analizaban como JSON una configuración de banderas de Statsig una vez por minuto, sin variación aleatoria y con ocho procesos por pod, de modo que todos los trabajadores se detenían en el mismo instante. La solución fue prosaica e instructiva: una configuración más pequeña y específica, un intervalo de refresco más largo y temporización aleatorizada.
El segundo fallo era más sutil. El grupo de conexiones de aiohttp en Python reutiliza conexiones en orden LIFO por defecto, lo que significa que un servidor más lento y sobrecargado devuelve su conexión más tarde y, por tanto, resulta elegido más a menudo: el tráfico se concentra en los pods menos capaces de absorberlo. Pasar a reutilización FIFO rompió ese bucle de retroalimentación y, como efecto colateral, redujo la varianza de las solicitudes en régimen estable. El efecto de estampida a través de Envoy e Istio completó la lista.
OpenAI tomó además una decisión de diseño que se lee como una limitación y funciona como barrera de seguridad: Habitat expone una API NoSQL deliberadamente reducida. Las consultas caras o impredecibles simplemente no se pueden expresar, lo que mantiene acotado el coste por solicitud a medida que crece el número de productos que la consumen.
Dos ingenieros, una reescritura
El detalle de la migración con más probabilidades de circular es el equipo. La reescritura de un servicio en la ruta crítica de mil millones de usuarios semanales, de un lenguaje interpretado a Rust, la hicieron dos ingenieros con las propias herramientas de programación de OpenAI. Es un dato concreto en un debate que hasta ahora se había sostenido con anécdotas: las migraciones de lenguaje se han rechazado históricamente no porque el lenguaje de destino fuera equivocado, sino porque el trabajo de portar no se podía justificar, y las herramientas de programación con agentes cambian esa aritmética.
Conviene leer las cifras de eficiencia con cuidado. Una mejora de 6 veces en CPU y 15 en memoria refleja la sobrecarga del intérprete de Python en una carga de enrutamiento de solicitudes dominada por serialización y coordinación de entrada y salida, que se acerca al mejor escenario posible para una reescritura en Rust. Los equipos cuyo cuello de botella sea una base de datos o una API externa no deberían esperar retornos similares.
La exposición de la propia cadena de suministro de Rust es una preocupación aparte para quien siga el camino de OpenAI, como dejó claro el incidente en que un crate envenenado estuvo disponible 86 minutos. El artículo técnico de ingeniería de OpenAI es el primero de dos, y la capa de almacenamiento se aborda en la continuación.
Preguntas frecuentes
¿Por qué OpenAI reescribió Habitat de Python a Rust?
La sobrecarga del intérprete dejó de ser aceptable al volumen de solicitudes del servicio, y los fallos operativos con los que topó el equipo, como el retardo de planificación de asyncio y la metaestabilidad del grupo de conexiones, eran síntomas de empujar un servicio en Python más allá de su rango cómodo. El reemplazo en Rust es seis veces más eficiente en CPU y quince en memoria, y atiende ya el 95% de las solicitudes de producción.
¿Significa esto que Python no sirve para servicios en producción?
No. Habitat funcionó en Python durante tres años de crecimiento superior a diez veces anual, y ahí está el punto: el lenguaje fue la decisión correcta mientras la forma del producto todavía se movía, y la deuda se pagó de forma deliberada cuando la escala lo justificó. El caso describe una decisión de secuencia, no un veredicto sobre Python.
¿Qué sistemas de almacenamiento hay detrás de Habitat?
Azure Cosmos DB es la capa principal de base de datos, junto con caché, almacenamiento de objetos y otros servicios internos de datos. Los productos no acceden a esos sistemas directamente: llaman a Habitat, que resuelve dónde vive el dato y cómo alcanzarlo.
