GPT-5.6 Sol versus Claude Fable 5 por tarea

Resumen

Comparar modelos de IA como Sol y Fable 5 sin declarar la configuración es una trampa silenciosa: el precio y el rendimiento pueden variar hasta 68x dentro de un mismo modelo. Si trabajas con agentes de código, entender la curva de costo y los settings detrás de cada benchmark te ahorra decisiones caras y comparaciones injustas.

¿Por qué la configuración cambia todo al comparar modelos?

La curva de costo dentro de un mismo modelo abarca 68x. Desde la configuración más barata hasta la más cara de Sol, el precio se multiplica por ese factor. Entonces cuando alguien te dice Sol le gana a Fable o Fable es mejor que Sol, la pregunta inmediata es: ¿en qué configuración?

Comparar dos modelos sin declarar el setting es como comparar dos autos sin decir si uno iba en primera y el otro en sexta. La analogía suena tonta, pero es exactamente lo que pasa en la mayoría de los benchmarks que circulan.

¿Qué es un setting en modelos de IA? Es la combinación de parámetros como nivel de razonamiento, cantidad de subagentes en paralelo y verbosity que define cuánto piensa y cuánto cuesta correr una tarea en el modelo.

¿Qué esconden los benchmarks headline de Sol y Fable?

Los números de cabecera que ves en comunicaciones oficiales casi siempre vienen de la configuración más cara disponible [0:32]. Y ahí empieza el problema: colapsan una curva entera en un solo punto sin etiqueta.

Algunos datos concretos del reporte:

  • Terminal-Bench: Sol reportó 91.9% usando ultra mode con cuatro subagentes en paralelo. El score single-agent del mismo benchmark es 88.8. Tres puntos de diferencia que cuestan entre 2x y 12x más [0:36].
  • BrowseComp: 92.2 en ultra y 90.4 sin él [0:53].
  • Coding Agent Index: 80.0 con max reasoning, pero eso no se declaró en el marketing [1:00].

Si el resultado está en el tope absoluto del rango publicado y no te muestran el costo ni el setting, asume la configuración más cara. Es la explicación más parsimoniosa.

¿Por qué no comparar directamente los benchmarks de ambos?

Porque el instrumento de medición oscila más que la diferencia que pretende medir. Sol tiene unas 30 configuraciones posibles combinando effort, pro, ultra y verbosity. Fable 5 tiene un modo: thinking adaptativo, siempre activo. No puedes apagarlo [1:33].

Entonces max versus max suena simétrico pero no lo es mecánicamente. Además, Artificial Analysis corrió Fable con fallback automático a Opus 4.8 en aproximadamente 8% de las tareas. El score publicado es una mezcla de dos modelos [1:51].

¿Qué dicen los datos cuando hay intervalos de confianza?

DeepSWE v1.1 es el único benchmark que publica intervalos de confianza: Sol 73% ±3, y Fable 70% ±4. Esos rangos se solapan. Estadísticamente indistinguibles [2:03]. Sin embargo, Sol costó apenas el 39% de lo que costó Fable por tarea.

Y aquí viene lo interesante: por tipo de tarea, la historia cambia por completo.

¿Dónde gana Fable y dónde gana Sol?

En coding complejo de extremo a extremo, Fable gana con evidencia replicada. El test Senior Engineer de Every dio a Sol 56 de 100, y a Fable 90 de 100. Sol produjo unas 12,900 líneas de código innecesario [2:41].

Piensa en dos contratistas: Sol llega rápido y termina, pero deja paredes y cableado que no pediste. Fable construye exactamente lo solicitado.

En trabajo agéntico de terminal, Sol tiene ventaja. El AA Coding Agent Index da Sol 80 versus Fable 77.2. Sol usó 60,000 tokens de output por tarea; Fable usó 119,000. Sol corre consistentemente 5 veces más rápido [3:00].

En documentos y razonamiento general, un punto de diferencia que cae dentro del ruido metodológico. En frontend y diseño, Fable gana según múltiples testers independientes.

¿Cuánto cuesta realmente cada modelo por tarea?

La brecha documentada es 2.6x a favor de Sol. Dos mediciones independientes lo confirman. ¿Por qué más grande que la diferencia de precio por token? Porque Fable piensa mucho más: 119,000 tokens de output versus 60,000.

Es como dos taxis: Sol cobra más por kilómetro pero toma la ruta corta.

¿El modelo más caro por token siempre sale más caro por tarea? No. Un modelo que piensa el doble puede costarte más aunque su precio por token sea la mitad. Lo que importa es el costo por tarea completada.

Pero este ratio tiene supuestos frágiles:

  1. Con caching intensivo la brecha se encoge, pero nadie sabe cuánto [3:55].
  2. Fable en un setting más bajo costaría menos.
  3. Por encima de 272,000 tokens, Sol pasa de 5 a 10 dólares por millón de input. Fable cobra 10 planos sin cliff [4:11].

La ventaja de mitad de precio colapsa a casi paridad cuando cruzas ese umbral.

¿Qué preguntas debes hacerte antes de elegir modelo?

Haz este ejercicio mental con tu próximo workload:

  • ¿Tu contexto típico supera 272,000 tokens?
  • ¿Tu prefijo es estable y cacheable?
  • ¿Necesitas zero data retention? Fable no está disponible bajo esa política [4:34].

Esas tres preguntas mueven tu decisión más que cualquier benchmark. El setting que eliges mueve tu factura más que el modelo que eliges. Eso es lo verificable hoy.

En la próxima entrega vamos a tomar exactamente esta decisión y ejecutarla: migración de prompts agénticos entre ecosistemas. Porque elegir proveedor es solo la mitad del problema. Portar tu sistema sin perder calidad es la otra. ¿Qué configuración estás usando tú y cuánto te está costando por tarea? Cuéntamelo en los comentarios.