GPT-6.1 Sol vs GPT-6 Sol: mismas tarifas de entrada y salida, menor caché y nuevas reglas de migración
none y exige Responses para herramientas. Un agente que usaba herramientas en Chat Completions necesita algo más que cambiar el ID.GPT-6.1 Sol vs GPT-6 Sol: diferencias principales
| Variable de decisión | GPT-6 Sol | GPT-6.1 Sol | Qué cambia para un agente existente |
|---|---|---|---|
| ID oficial | gpt-6-sol | gpt-6.1-sol | Fijar la versión; no depender de un alias Sol genérico |
| Entrada / salida | Texto e imagen / texto | Texto e imagen / texto | No hay una modalidad nueva de salida que integrar |
| Contexto / salida máxima | 1,050,000 / 128,000 tokens | Mismos límites | La ventana no aumenta |
| Corte de conocimientos | 20 de abril de 2026 | 30 de abril de 2026 | Un corte más reciente no demuestra calidad en tus tareas |
| Esfuerzo de razonamiento | none, low, medium, high, xhigh, max | low, medium, high, xhigh, max; sin none ni minimal | Eliminar ajustes no admitidos de la configuración candidata |
| Funciones en Chat Completions | Solo con esfuerzo none | No admitidas | Llevar flujos con herramientas a una ruta Responses verificada |
| Herramientas en Responses | Admitidas | Admitidas | Verificar igualmente el bucle de herramientas y el gateway |
| Streaming / salida estructurada | Enumerados por OpenAI | Enumerados por OpenAI | Soporte del proveedor no prueba soporte de la ruta concreta |
medium por defecto. Los límites idénticos hacen que compatibilidad y coste por tarea aceptada sean variables más útiles que el tamaño de contexto.Qué dice la evidencia oficial de rendimiento
| Evaluación | Cambio declarado frente a GPT-6 Sol | Condiciones y límite de interpretación |
|---|---|---|
| DeepSWE v1.1 | +6.4 puntos porcentuales sobre el mejor resultado anterior | El candidato usó menor esfuerzo y coste; no es una comparación al mismo esfuerzo |
| AutomationBench 1.0.6 | +4.8 puntos porcentuales | Mismo ajuste medium; relevante para flujos de herramientas de varios pasos |
| OSWorld 2.0 | +7 puntos porcentuales, con menos de la mitad del coste por tarea | Esfuerzo máximo; recompensa parcial en el conjunto offline v2026.08.08 |
La evidencia justifica probar cambios complejos de código y flujos de negocio con herramientas. La recompensa parcial de OSWorld mide progreso hacia una tarea; no sustituye tu tasa binaria de aceptación. OpenAI también advierte que el entorno de investigación/API puede diferir de ChatGPT en producción. Al citar resultados, conserva el entorno de evaluación, el esfuerzo y el alcance de costes.
Para trabajos rutinarios que el modelo actual ya resuelve, hay menos motivos para reemplazarlo ampliamente. Usa las tareas emparejadas siguientes para comprobar qué mejoras se trasladan a tu carga. No deduzcas latencia, reintentos ni factura EvoLink de estos resultados.
Decide el endpoint antes de evaluar rendimiento
Hay tres migraciones sustancialmente distintas. Tratarlas como una sola prueba dificulta interpretar los fallos.
| Flujo existente | Ruta candidata | Primera comprobación de aceptación |
|---|---|---|
| Chat Completions sin herramientas y con razonamiento admitido | Probar el contrato documentado sin herramientas de 6.1 Sol | Parseo, forma de salida y uso realmente facturado |
Herramientas en Chat Completions con none | Cambiar a Responses y elegir un esfuerzo admitido | Solicitudes de herramientas, asociación de resultados, continuación y reintentos |
| Responses con herramientas | Conservar el flujo, fijar el ID nuevo y esfuerzo admitido | Bucle completo, resultados estructurados, streaming y cancelación si se usan |
none también puede cambiar latencia, consumo de salida y comportamiento aunque el endpoint no cambie.Para migrar un agente con herramientas, haz primero un inventario del endpoint, el esfuerzo, definiciones de herramientas, identificadores de resultados y gestión de continuaciones. Adapta después el bucle a Responses, incluida la asociación entre cada resultado y la llamada que lo pidió. Reproduce en un entorno aislado una acción exitosa, una fallida y una ejecución cancelada; inspecciona los registros resultantes y el texto final. Comprueba salida estructurada y streaming si el cliente los usa. Solo entonces empieza la comparación de calidad.
Separa incompatibilidades de tareas rechazadas. Verifica contrato y facturación de la ruta exacta antes de un piloto y conserva modelo, endpoint y parser anteriores juntos como configuración de reversión.
La rebaja de caché es menor que una rebaja del trabajo completo
| Categoría de tokens | GPT-6 Sol, hasta 272K de entrada | GPT-6.1 Sol, hasta 272K | GPT-6.1 Sol, más de 272K |
|---|---|---|---|
| Entrada sin caché | $2.00 | $2.00 | $4.00 |
| Lectura de entrada en caché | $0.20 | $0.10 | $0.20 |
| Escritura de caché | $2.50 | $2.50 | $5.00 |
| Salida | $10.00 | $10.00 | $15.00 |
El cambio directo frente a 6 Sol es una lectura de caché un 50% más barata. Frente a la entrada ordinaria del propio 6.1 Sol, una lectura cuesta un 95% menos. Ninguna afirmación significa que todo el trabajo sea un 50% o 95% más barato. Salida, entrada sin caché y escrituras no reciben esa misma reducción.
| Proporción en caché del millón de tokens de entrada | GPT-6 Sol: entrada + salida | GPT-6.1 Sol: entrada + salida | Ahorro directo |
|---|---|---|---|
| 40% | $1.20 sin caché + $0.08 caché + $1.00 salida = $2.28 | $1.20 + $0.04 + $1.00 = $2.24 | $0.04 |
| 90% | $0.20 sin caché + $0.18 caché + $1.00 salida = $1.38 | $0.20 + $0.09 + $1.00 = $1.29 | $0.09 |
Son proporciones supuestas, no tasas de acierto medidas ni una promesa de que reutilizar un prompt active la caché. Más salida de razonamiento o un reintento adicional pueden absorber el ahorro. Una tasa mayor de tareas aceptadas, en cambio, puede aportar mucho más valor que la diferencia de caché. Mide ambos efectos en lugar de declarar éxito con la tabla de precios.
Construye una evaluación emparejada con seis trabajos reales
Fija tareas recientes, versiones de repositorio y reglas de aceptación antes de ejecutar ambos modelos. Incluye casos donde el agente anterior falló o necesitó intervención humana junto a trabajos rutinarios. Mantén permisos y límites de reintentos iguales; declara cambios necesarios de endpoint o entorno de evaluación en vez de fingir un experimento perfectamente controlado.
| Trabajo | Entrada y resultado esperado | Señal de aceptación | Señal de coste o fallo | Prioridad de prueba |
|---|---|---|---|---|
| Reparación en varios archivos | Repositorio fijo e issue → parche | Pruebas requeridas pasan sin cambios ajenos | Reintentos, retrabajo e intervención del revisor | Empezar por fallos y cambios con mucha revisión |
| Revisión de PR | Diff fijo y convenciones → hallazgos | Defectos confirmados con falsos positivos tolerables | Tiempo comprobando falsas alarmas | Mantener referencia si los hallazgos añaden ruido |
| Agente con contexto repetido | Contexto guardado y herramientas permitidas → tarea completada | Restricciones conservadas; sin efectos duplicados | Lecturas/escrituras de caché y salida de razonamiento | Probar cuando el uso confirme muchas lecturas de caché |
| Preguntas documentales | Documentos y preguntas fijos → respuestas respaldadas | Campos correctos y evidencia rastreable | Conclusiones sin respaldo y tiempo de revisión | Probar tablas y evidencia contradictoria, no solo búsquedas fáciles |
| Flujo de negocio con herramientas | Objetivo y herramientas aisladas → registros finales previstos | Secuencia y estado correctos | Escrituras duplicadas o resultados mal asociados | Verificar el bucle antes de juzgar calidad |
| Escalado de tareas difíciles | Cola fija → resultados aceptados | Umbral de calidad en toda la cola | Costes combinados de candidato, escalado y respaldo | Probar primero una ruta separada de tareas difíciles |
Define criterios de rechazo antes de ejecutar. Un flujo de negocio puede rechazar cualquier escritura duplicada aunque el texto final parezca correcto. Un parche puede necesitar pruebas ocultas además de las visibles para el agente. JSON válido no demuestra campos extraídos correctos.
Registra por intento tarea, identidad del modelo, endpoint, esfuerzo, llamadas a herramientas, uso, reintentos, aceptación y revisión. Resume tamaño de muestra y desacuerdos emparejados: un conjunto pequeño puede detectar bloqueos, pero no probar mejoras fiables en toda la población. Inspecciona fallos individuales y promedios, especialmente si una tarea larga domina la factura.
Compara el coste por tarea aceptada y cambia por etapas
Usa esta definición contable:
Haz explícito el coste humano: asígnale una tarifa documentada o informa minutos de revisión junto al coste API. No lo omitas silenciosamente de un modelo. Si no se acepta ninguna tarea, el cociente es indefinido; registra una prueba fallida, no un resultado barato.
Ejemplo completo de contabilidad para 100 tareas
| Métrica | Base 6 Sol | 6.1: Caché | 6.1: Retrabajo ↓ | 6.1: Salida/retry |
|---|---|---|---|---|
| Entrada sin caché / lecturas, millones de tokens | 4 / 6 | 4 / 6 | 3.6 / 5.4 | 4.8 / 7.2 |
| Escrituras / salida, millones de tokens | 0.4 / 1 | 0.4 / 1 | 0.36 / 0.9 | 0.48 / 1.8 |
| Reintentos adicionales | 20 | 20 | 10 | 30 |
| Cargos de tokens | $20.20 | $19.60 | $17.64 | $29.52 |
| Cargos supuestos de herramientas | $3.00 | $3.00 | $2.70 | $3.60 |
| Minutos de revisión / coste | 240 / $120 | 240 / $120 | 180 / $90 | 300 / $150 |
| Coste total de la prueba | $143.20 | $142.60 | $110.34 | $183.12 |
| Tareas aceptadas de 100 | 80 | 80 | 90 | 75 |
| Coste por tarea aceptada | $1.79 | $1.78 | $1.23 | $2.44 |
4 × $2 + 6 × $0.20 + 0.4 × $2.50 + 1 × $10 = $20.20. Herramientas y revisión llevan a $143.20 ÷ 80 = $1.79 por tarea aceptada. El supuesto de menor retrabajo es $110.34 ÷ 90 ≈ $1.23.Sin cambios de comportamiento, la rebaja de caché ahorra solo $0.60 en toda la cola. Menos retrabajo puede aportar más; más salida, reintentos y revisión pueden anularlo. El ejemplo no predice el comportamiento de 6.1 Sol. Sustituye cada supuesto por registros emparejados de uso, aceptación y revisión y utiliza tarifas verificadas del gateway para decidir en EvoLink.
Define los criterios del piloto antes de ejecutar al candidato
Copia esta ficha y sustituye sus políticas de ejemplo por los requisitos de tu servicio. Son puntos de partida editoriales, no recomendaciones de OpenAI ni garantías estadísticas.
| Métrica | Qué registrar en ambos modelos | Criterio ilustrativo |
|---|---|---|
| Tareas aceptadas | Aceptadas/asignadas y desacuerdos emparejados | Candidato no inferior a referencia; revisar aparte regresiones críticas |
| Coste efectivo | Coste de todos los intentos / tareas aceptadas | No superar la referencia, salvo prima de calidad acordada antes |
| Latencia | p95 de principio a fin con herramientas y reintentos | Dentro del presupuesto ilustrativo de 75 segundos definido por el equipo |
| Corrección de herramientas | Acciones erróneas, escrituras duplicadas, estado final | Cero escrituras duplicadas o no autorizadas; cualquier caso bloquea el piloto |
| Contrato y facturación | Identidad devuelta, funciones, uso y cargo real | Verificados en la ruta candidata antes de tráfico de producción |
Estas decisiones continúan el ejemplo ficticio de 100 tareas; latencia y resultados de acciones son supuestos adicionales.
| Resultado | Evidencia ilustrativa | Siguiente acción |
|---|---|---|
| Iniciar piloto limitado | 90 aceptadas frente a 80; $1.23 frente a $1.79; p95 70s; sin escrituras erróneas; ruta/cargo verificados | Enviar una cohorte pequeña, por ejemplo 5%, y revisar los mismos criterios antes de ampliar |
| Seguir evaluando fuera de producción | Sin incumplir criterios duros, pero desacuerdos entre revisores dejan calidad sin resolver | Recalificar tareas discutidas y ampliar el conjunto emparejado; mantener referencia en producción |
| Rechazar o revertir | 75 aceptadas y $2.44, o cualquier escritura duplicada/no autorizada | Restaurar la configuración de referencia y diagnosticar la capa que falla |
La reversión restaura juntos modelo, endpoint, esfuerzo, esquema de herramientas y parser. Comprueba el estado de las acciones antes de reintentar con otro modelo para evitar duplicados. Un gateway unificado conserva opciones de modelos; los contratos de ruta y la semántica de reintentos aún requieren sus propias comprobaciones.
Cuándo conviene mantener GPT-6 Sol
Conserva la referencia mientras el cliente con herramientas no pueda usar una ruta Responses verificada, mientras funciones o factura nuevas sigan sin verificar, o mientras fallen los umbrales de calidad y latencia. Una carga con poca caché y mucha salida puede ahorrar poco directamente. Si el modelo actual resuelve trabajos rutinarios con escaso retrabajo, prioriza una prueba de tareas difíciles en vez de una migración amplia.
No declares obsoleto 6 Sol por existir 6.1 Sol. Las referencias los distinguen; este artículo no dispone de una instrucción confirmada de retirada. Mantén seleccionable el identificador anterior hasta que exista una razón documentada para cambiarlo.
FAQ
¿GPT-6.1 Sol es más barato que GPT-6 Sol?
En las tarifas Standard de OpenAI para entrada corta, entrada y salida ordinarias no cambian; la lectura de caché cuesta la mitad. El coste completo depende de uso de caché, salida, reintentos y resultados aceptados. Las tarifas EvoLink requieren verificación aparte.
¿Puedo actualizar cambiando solo el ID del modelo?
none requiere migrar endpoint y razonamiento.¿GPT-6.1 Sol admite razonamiento none?
low, medium, high, xhigh y max, con medium por defecto. No admite none ni minimal.¿El nuevo Sol tiene una ventana de contexto mayor?
No. Ambas referencias indican 1,050,000 tokens de contexto y 128,000 de salida máxima. No confundas el presupuesto combinado con entrada máxima.
¿GPT-6.1 Sol está disponible a través de EvoLink?
A 29 de septiembre, este artículo no ha verificado esa ruta, sus funciones ni tarifas de venta. Consulta catálogo y documentación actuales antes de usar una configuración específica del gateway.
¿Qué métrica resulta más útil al actualizar?
Coste por tarea aceptada junto a calidad, latencia y reglas de rechazo de acciones inseguras. Incluye fallos y coste de respaldo, y haz visible el tiempo del revisor. Una respuesta exitosa más barata no basta si incumple la tarea.
Fuentes
- Referencia de GPT-6.1 Sol — contrato y límites nuevos.
- Referencia de GPT-6 Sol — contrato de referencia.
- Precios API de OpenAI — tarifas Standard, caché y condiciones de entrada larga.
- Anuncio de GPT-6.1 Sol — lanzamiento y evaluaciones del proveedor; no reproducción de EvoLink.
Fuentes oficiales consultadas el 29 de septiembre de 2026. Los ejemplos de carga son cálculos ilustrativos y métodos de prueba, no uso medido ni garantías de ahorro.
