GPT-6.1 Sol vs GPT-6 Sol: Lo que una semana de trabajo adicional logró, y lo que no

Si tienes GPT-6 Sol en producción hoy y estás intentando decidir si GPT-6.1 Sol merece una migración, la respuesta depende enteramente de cuál de tus costos es mayor — y los dos modelos están construidos de modo que la respuesta casi nunca es «ambos». GPT-6 Sol se lanzó el 22 de septiembre de 2026 a $2.00 por millón de tokens de entrada, $0.20 en caché y $10.00 de salida. GPT-6.1 Sol se lanzó el 29 de septiembre de 2026 a $2.00 de entrada, $0.10 en caché y $10.00 de salida, con una mejora de 6.4 puntos porcentuales reportada por el proveedor en tareas complejas de ingeniería de software con un esfuerzo de razonamiento menor. Los precios de entrada y salida no se movieron. La tarifa de caché se redujo a la mitad. Esa única línea modificada constituye todo el caso financiero, y todo lo demás es un argumento de capacidad que, en este punto de la vida del lanzamiento, proviene de exactamente una fuente.

Tres cosas cambiaron. Una de ellas es una factura.

Si dejas a un lado el marketing, la diferencia entre estos dos despliegues es lo suficientemente breve como para retenerla en la cabeza.

• Entrada en caché — 0,10 $ por millón de tokens en GPT-6.1 Sol frente a 0,20 $ en GPT-6 Sol. Medido, no prometido, y el único cambio que se refleja como aritmética.
• Capacidad, según el proveedor — OpenAI informa de una ventaja de 6,4 puntos en DeepSWE v1.1 con un esfuerzo de razonamiento y un coste menores, más del doble de puntuación en Terminal-Bench Science 0.1 con esfuerzo máximo, siete puntos en el conjunto offline de OSWorld 2.0 con esfuerzo máximo, 4,8 puntos en AutomationBench con esfuerzo medio, y una tasa de errores factuales que baja del 11,4 % al 7,7 % en un conjunto de prompts diseñado deliberadamente para inducir errores. Nada de ello reproducido.
• Escalera de razonamiento — GPT-6.1 Sol admite low, medium, high, xhigh y max, y no admite none; GPT-6 Sol admite las seis. Este es el delta que rompe el código, y es el que nadie incluye en una publicación de lanzamiento.

Todo lo demás es idéntico o casi: la misma {{1}}ventana de contexto de 1.050.000 tokens{{/1}}, el mismo {{2}}límite de salida de 128.000 tokens{{/2}}, la misma tarifa de escritura en caché de $2,50, el mismo umbral de reajuste de precios de 272K tokens por encima del cual una solicitud completa se factura a 2× la entrada y la caché y a 1,5× la salida, el mismo requisito de Responses-API para la llamada a herramientas y la misma ausencia de soporte para ajuste fino. La fecha de corte de conocimiento pasó del 20 de abril al 30 de abril de 2026 —diez días, el tipo de cifra que te dice hasta qué punto esto fue una adaptación más que una reconstrucción.

Por qué la línea de caché vale más de lo que parece

Una lectura de caché reducida a la mitad es algo extraño con lo que encabezar una renovación de producto, hasta que observas cómo es realmente el tráfico de agentes. Un bucle de agente reenvía un prefijo estable —prompt del sistema, esquemas de herramientas, contexto recuperado, historial de conversación— en cada turno, y en una sesión larga el mismo prefijo se factura decenas o cientos de veces. Ese es el tráfico donde una tasa de caché deja de ser un error de redondeo y se convierte en la línea dominante de la factura.

Echemos números a una única sesión larga de agente. Supongamos un prefijo de 120.000 tokens reutilizado a lo largo de 40 turnos, es decir, 4,8 millones de tokens de entrada en caché por sesión, más unos modestos 150.000 tokens de salida nuevos. En GPT-6 Sol, las lecturas en caché cuestan $0,96 y la salida $1,50 — aproximadamente $2,46 por sesión. En GPT-6.1 Sol, la misma sesión cuesta $0,48 por lecturas en caché y los mismos $1,50 por salida: unos $1,98. Por sesión, la diferencia es de 48 centavos, lo que no es una decisión. Multiplícala por cien mil sesiones al mes y son $48.000 — lo que sí lo es.

Dos salvedades mantienen eso honesto. Las lecturas en caché solo se facturan a la tarifa de caché cuando el prefijo realmente acierta, así que tu ahorro real es tu tasa de aciertos multiplicada por la diferencia, no la diferencia en sí. Y el prefijo tiene que estar por debajo de 272.000 tokens para que las tarifas estándar se apliquen siquiera: cruza esa línea y la solicitud entera se vuelve a tarifar a 2× en entrada y caché, y 1,5× en salida, lo que puede arrasar con un ahorro de 10 centavos en el prefijo. Las sesiones de contexto largo son justamente aquellas en las que es menos probable que las cuentas de la caché se parezcan a lo que promete el folleto.

La brecha en los benchmarks es real, y proviene de un solo lugar

El anuncio de lanzamiento de OpenAI es inusualmente específico sobre sus evaluaciones, lo cual es un punto a su favor, y cada uno de esos números proviene del propio proveedor evaluando su propio modelo, lo cual es el punto en contra. El patrón entre todos ellos es consistente: la comparación que trasciende es siempre contra GPT-6 Astra, y la comparación con Astra es siempre una comparación de costos. En DeepSWE v1.1, la afirmación es que iguala a Astra a aproximadamente una quinta parte del costo. En GDP.pdf, que se acerca al estado del arte de Astra a aproximadamente una quinta parte del costo por tarea. En OSWorld 2.0, a 2,1 puntos de Astra a aproximadamente una séptima parte del costo por tarea. En factualidad, a 1,9 puntos de Astra a menos de una quinta parte del costo por tarea. Eso no es una casualidad de redacción; es la tesis del producto, y es una tesis sobre el precio, no sobre el liderazgo en capacidades.

El único punto en el que OpenAI se abstiene de imponer su propio encuadre merece reconocimiento: en Terminal-Bench Science 0.1 afirma sin rodeos que GPT-6 Astra sigue ostentando la mejor puntuación entre los modelos evaluados, con un 68,1%, y que debería utilizarse para la investigación científica más exigente. Una publicación de lanzamiento que te dice cuándo comprar el hermano más caro es una publicación de lanzamiento con algo de disciplina.

Frente a GPT-6 Sol en concreto, el estado honesto de la comparación es este: no existe una puntuación independiente para ninguno de los dos modelos en esta configuración. Artificial Analysis cuenta con una evaluación completa de GPT-6 Sol con el máximo esfuerzo de razonamiento: un Índice de Inteligencia de 48, 1,06 $ por tarea de índice, 77 millones de tokens de salida generados frente a una mediana del tablero de 88 millones, y un Índice de Agente de Programación de 57 a 2,99 $ por tarea. No tiene ninguna entrada de GPT-6.1 Sol a fecha de 30 de septiembre; el slug del modelo devuelve un 404 y la cadena no aparece en la clasificación en vivo. Así que la única comparación medida y de terceros disponible hoy es entre GPT-6 Sol y los modelos de otros laboratorios, no entre GPT-6 Sol y su propio sucesor. Cualquiera que te muestre ahora mismo un gráfico de 6.1 frente a 6.0 te está mostrando la diapositiva de OpenAI.

La migración es un cambio de cadena, excepto cuando no lo es

Vale la pena leer la propia guía de migración de OpenAI para la familia GPT-6 antes de cambiar el identificador, porque dos puntos de esa guía rompen código que funciona. El primero es la escala de razonamiento: si alguna solicitud envía reasoning_effort: "none", GPT-6.1 Sol la rechaza, y el remedio documentado es empezar en low y comparar en tareas representativas en lugar de asumir que el ajuste más bajo es equivalente. Los flujos de trabajo que usaban none como línea base de latencia pierden esa línea base. El segundo es la llamada a herramientas: GPT-6.1 Sol admite Chat Completions, pero no la llamada a herramientas a través de ella; las herramientas requieren la API de Responses. Si tu stack llama a funciones en /v1/chat/completions, no estás cambiando una cadena, estás portando un endpoint. La propia instrucción del proveedor para los desarrolladores que ya usan GPT-6 Sol es revisar esa guía antes de cambiar, lo cual es una señal clara de que esta no es la actualización directa que sugiere el intervalo de una semana.

El resto de los parámetros se comportan igual: el esfuerzo de razonamiento, las salidas estructuradas, el streaming, el almacenamiento en caché de prompts y el conjunto de herramientas se conservan, y la misma regla de reajuste de precios de 272K se aplica a ambos modelos de forma idéntica. Establece model en gpt-6.1-sol, mantén tu configuración de esfuerzo donde se admitía y elimina temperature, top_p y top_logprobs siempre que el esfuerzo no sea none — esta última se aplica a ambos modelos y es una fuente común de errores 400 tras cualquier migración a un modelo de razonamiento.

Migrar sin apostar una ruta de producción a ello

La migración realista no es una conmutación total, sino una ejecución en sombra: envía una parte del tráfico de producción al nuevo identificador, mantén el antiguo como la ruta que responde y compara con tus propias tareas. Eso es un problema de enrutamiento, y es el único punto en el que la plataforma a través de la que llamas cambia la forma del trabajo. OrcaRouter sirve GPT-6 Sol hoy al precio de lista de OpenAI, sin margen de beneficio —la tarifa de $2.00 / $0.20 / $10.00, incluida la regla de reajuste de precios de 272K—, así que el brazo de referencia de la comparación está activo en la misma clave que todo lo demás, y el brazo 6.1 puede añadirse al conjunto de rutas tan pronto como sea invocable, sin un segundo contrato ni un segundo SDK. Hasta entonces, la postura honesta es que GPT-6 Sol es el modelo disponible para llamar, y vale la pena decirlo claramente en lugar de dar a entender lo contrario: openai/gpt-6.1-sol devuelve "model not found" en nuestro endpoint público de catálogo hoy. La conmutación automática por error es lo que hace que la ejecución en sombra sea segura cuando se materialice: si la nueva ruta da error, la solicitud se completa en la antigua y te enteras por los registros, no por tus usuarios.

Quién debería migrar ahora: los equipos cuyo costo está dominado por la entrada en caché en sesiones largas de agentes, y los equipos cuyos flujos de trabajo ya usan la API de Responses y nunca envían none. Para ellos, esto es casi una actualización gratuita: el proveedor reporta las mejoras de capacidad, la tasa de caché se reduce a la mitad y la migración es una sola cadena. Quién debería esperar: los equipos que tienen none en una ruta crítica de latencia, los equipos cuyo uso de herramientas pasa por Chat Completions, y cualquiera que necesite una cifra de fuera de OpenAI antes de comprometerse. Para ese último grupo, la espera no tiene fecha de finalización publicada, y lo sensato es aprovechar ese tiempo para construir el conjunto de evaluación que la comparación necesitará, porque cuando llegue la puntuación independiente, será para el tráfico de otra persona.