OpenAI anunció GPT-6.1 Sol el 29 de septiembre, durante su DevDay 2026, y lo que más llamó la atención no fue un benchmark: fue el precio. El modelo nuevo cuesta una quinta parte de lo que cobra GPT-6 Astra —su hermano mayor, lanzado apenas unas semanas antes— y llega casi al mismo nivel en coding agéntico, uso de computadora y trabajo profesional.
Por qué OpenAI lanzó un modelo "casi tan bueno" en vez de uno mejor
La jugada tiene sentido si la miras desde el lado del negocio. GPT-6 Astra ya era el modelo más caro del catálogo de OpenAI, y para la mayoría de tareas de desarrollo diario —generar un endpoint, revisar un pull request, escribir tests, limpiar un módulo viejo— no hace falta el modelo tope de gama. Sol cuesta 2 USD por millón de tokens de entrada y 10 USD por millón de salida en la API, frente a precios bastante más altos de Astra. Para un equipo que corre miles de llamadas diarias en Codex, esa diferencia se nota directo en la factura a fin de mes.
Lo que trae GPT-6.1 Sol
- ▸Disponible desde el día uno en ChatGPT Work y Codex, empezando por cuentas Pro y expandiéndose a Plus, Business, Enterprise y Edu.
- ▸Rendimiento comparable a GPT-6 Astra en coding agéntico, uso de computadora (computer use) y tareas de trabajo profesional, según las evaluaciones que publicó OpenAI.
- ▸Mejoras de robustez frente a jailbreaks y ataques de ciberseguridad respecto a la generación anterior.
- ▸Acceso directo vía API como gpt-6.1-sol para quien construye sus propios agentes, sin esperar integraciones de terceros.
Qué cambia si ya usas Codex todos los días
Si tu equipo ya automatiza parte del código con Codex, probablemente no vas a notar un salto dramático en la calidad de las respuestas. Lo que sí vas a notar es que puedes correr más tareas en paralelo sin que el costo se dispare. Eso cambia cómo diseñas tu flujo de trabajo: tareas largas y agénticas —refactors completos, migraciones de librería, debugging exploratorio— que antes reservabas para casos puntuales por el precio, ahora entran en el presupuesto normal. En el curso de Codex de DataPath enseñamos justo ese tipo de flujo: cómo delegarle tareas completas a un agente de código y revisar su trabajo sin perder el control del repo.
Y si trabajas con datos propios en vez de código
GPT-6.1 Sol también llega a ChatGPT Work, que es la superficie que más usan los equipos de atención al cliente y operaciones para automatizar respuestas sobre su propia información. Si tu caso de uso es entrenar un chatbot con tus datos —políticas internas, catálogo de productos, históricos de soporte— vale la pena revisar si tu stack actual ya soporta el modelo nuevo. El ahorro en costo por token hace viable correr volúmenes de consultas que antes no cerraban en el presupuesto. Esto lo trabajamos a fondo en el curso de chatbots con datos propios de DataPath.
Dónde queda esto frente a Claude y Gemini
La comparación obligada: Anthropic lanzó Claude Opus 5.5 y Sonnet 5.5 en septiembre, y Google ya tiene a Gemini 3.8 Flash como su opción de bajo costo para agentes de larga duración. El patrón es el mismo en los tres laboratorios: el modelo más caro marca el techo de capacidad, y la pelea real de 2026 es por el modelo "suficientemente bueno y barato" que puedas correr en producción sin pensarlo dos veces. Sol es la respuesta de OpenAI a esa pelea, no un intento de superar a Astra.
Lo que casi nadie menciona cuando sale un modelo "casi tan bueno pero más barato" es que termina reemplazando al modelo caro en producción para el 80% de los casos, y el modelo tope de gama se vuelve el que usas solo cuando de verdad lo necesitas.
Un ejemplo concreto de cuándo usar cada uno
Piensa en un pipeline típico de Codex corriendo en CI: revisar cada pull request, sugerir tests faltantes, y una vez a la semana hacer un refactor grande de un módulo completo. Las primeras dos tareas son de volumen alto y complejidad media, ahí Sol rinde prácticamente igual que Astra a un quinto del costo, y correrlas con el modelo caro sería tirar presupuesto. El refactor grande, en cambio, sí se beneficia del modelo tope de gama: son pocas corridas al mes, pero cada una toca más archivos y más contexto, y un error ahí cuesta más tiempo de revisión humana que lo que ahorras en tokens. La regla práctica que les doy a los equipos que capacitamos es simple: si la tarea es repetible y acotada, empieza con el modelo barato; si es exploratoria o de alto riesgo, usa el caro y no discutas el costo.
El riesgo de no tener un criterio de selección de modelo
Un error común en equipos que recién arrancan con Codex o con cualquier asistente agéntico es dejar el modelo por defecto que trae la herramienta y nunca revisarlo. Eso funciona cuando hay poco volumen, pero se vuelve un problema real apenas escalas: he visto equipos sorprendidos con facturas de varios miles de dólares en un mes porque un agente quedó corriendo en loop con el modelo más caro disponible, sin límites de tokens ni alertas. Antes de automatizar cualquier flujo con GPT-6.1 Sol o con el modelo que sea, define un presupuesto de tokens por tarea y una alerta cuando se exceda. Es una hora de trabajo que te ahorra un dolor de cabeza mucho más grande.
Preguntas que me hacen seguido sobre este tipo de releases
¿Tengo que migrar mi código si ya uso Astra? No necesariamente. GPT-6.1 Sol se accede con un nombre de modelo distinto (gpt-6.1-sol), así que es un cambio de una línea en tu configuración, no una migración de API completa como la que obligó el cierre de Assistants API en agosto. ¿Vale la pena probarlo si recién estoy empezando con Codex? Sí, es buen punto de entrada porque el costo bajo te permite experimentar y romper cosas sin preocuparte tanto por la factura. ¿Astra queda obsoleto? No, sigue siendo la opción cuando la tarea es compleja de verdad y el margen de error es bajo. ¿Y si mi equipo usa Claude en vez de GPT? El mismo criterio aplica: la mayoría de proveedores ya tienen su propio par barato/caro, así que vale la pena revisar el equivalente en tu proveedor actual antes de asumir que necesitas cambiar de plataforma.
Cómo prepararte para lo que viene
La velocidad con la que OpenAI está sacando variantes —Astra en septiembre, Sol 6.1 dos semanas después— es parte de una tendencia más amplia: los modelos de frontera dejaron de ser el cuello de botella, y la habilidad que marca la diferencia ahora es diseñar sistemas de agentes que usen el modelo correcto para cada tarea, en vez de pegarle prompts a uno solo. Eso es justo lo que cubre la ruta AI Agentic Engineer de DataPath, donde trabajas con LangGraph y patrones reales de orquestación de agentes en producción.
Si quieres ver cómo otros developers están probando estos modelos nuevos en la práctica —qué funciona y qué no apenas sale cada release— cada semana hacemos un taller en vivo en la Comunidad AI Builders.
Si quieres meterle mano a esto directo: el curso de Codex para developers, el curso de chatbots con tus propios datos, o revisa toda la oferta de cursos de DataPath.
