Fable 5.2 vs Opus 5.5: programación, casos y costes
Compare Fable 5.2 y Opus 5.5 con casos reales, vídeos comparativos, High frente a Max, costes de caché y selección por tarea.
EvoLink TeamEquipo de productoEn este artículo
Para quienes gestionan acceso y costes con EvoLink, la decisión es qué configuración debe encargarse de cada trabajo. Una modificación corriente de repositorio, una migración difícil y un agente de investigación pueden justificar elecciones distintas. El comparativo debe identificar dónde un mejor resultado cambia lo que el equipo puede entregar.
Las comparaciones públicas muestran resultados en tareas reales
Los ejemplos concretan la elección. Los tres primeros son ejecuciones individuales relatadas por sus autores; el cuarto es un experimento de Anthropic. Ninguno es una reproducción de EvoLink ni una estimación del rendimiento medio en el trabajo cotidiano.
Encontrar y corregir errores en un plugin existente
El desarrollador Octavio Aranda pidió a ambos modelos encontrar errores reales en un plugin, reproducirlos y proponer correcciones. Según él, utilizó las mismas instrucciones y el mismo esfuerzo. Ambos encontraron los mismos seis errores del plugin objetivo.
| Resultado comunicado por el autor | Opus 5.5 | Fable 5.2 |
|---|---|---|
| Tiempo | 2,9 minutos | 6,6 minutos |
| Coste a tarifas API | ≈ $0.76 | ≈ $2.78 |
| Correcciones con las pruebas del otro modelo | Todas superadas | Una prueba fallida |
Una piscina de cristal con una factura mayor
Mr Tactical publicó un vídeo que compara ambos modelos en una escena de piscina de cristal.
| Resultado comunicado por el autor | Opus 5.5 | Fable 5.2 |
|---|---|---|
| Tiempo | 68 minutos | 90 minutos |
| Coste | $14.39 | $57.87 |
En un prototipo visual, decida si el detalle adicional importa para el encargo. Puede compensar refinar una escena seleccionada, mientras unos borradores económicos bastan para explorar ideas.
Cathedral of Ice: menos espera a mayor precio
Tony, conocido como EnvolDev, afirma haber dado el mismo prompt Cathedral of Ice a los dos modelos.
| Resultado comunicado por el autor | Opus 5.5 | Fable 5.2 |
|---|---|---|
| Tiempo | 3 h 11 min 26 s | 1 h 56 min 52 s |
| Coste | $45.97 | $81.10 |
Una formalización grande con distinto grado de finalización
Es un caso concreto de trabajo exigente con diferente finalización. Su infraestructura especializada, materiales iniciales y verificación lo separan de una tarea corriente de programación.
Los casos respaldan decisiones diferentes. Una corrección verificada, detalles visuales preferidos, menor espera y terminar un proyecto atascado son objetivos distintos. Elija el que realmente necesita el trabajo y compare el coste de conseguirlo.
Las diferencias que afectan a la elección
Las especificaciones estándar de Claude API ofrecen un punto de partida bastante próximo.
| Especificación API estándar | Opus 5.5 | Fable 5.2 |
|---|---|---|
| ID del modelo | claude-opus-5-5 | claude-fable-5-2 |
| Ventana de contexto | 1M tokens | 1M tokens |
| Salida máxima en mensajes ordinarios | 128K tokens | 128K tokens |
| Entrada y salida | Texto e imágenes → texto | Texto e imágenes → texto |
| Esfuerzo API predeterminado | medium | high |
| Entrada nueva por millón de tokens (USD) | $4 | $8 |
| Salida por millón de tokens (USD) | $20 | $40 |
Fable no ofrece más contexto en este comparativo. Si la aplicación omite un archivo relevante o da requisitos contradictorios, cambiar el modelo no resuelve ese problema. Compruebe que ambos candidatos reciben la información necesaria.
Los valores predeterminados también importan: sin especificar effort, Opus usa Medium y Fable High. Describe las solicitudes por defecto, pero sustituir una configuración requiere además comparar el Opus realmente usado con ajustes Fable razonables.
Los benchmarks muestran una ventaja y una excepción relevante
Anthropic publica estos resultados de evaluación.
| Evaluación | Opus 5.5 | Fable 5.2 |
|---|---|---|
| FrontierCode 2.0 | 45.5% | 49.1% (Xhigh) |
| FrontierSWE v2 | 62.3% | 69.9% |
| AutomationBench | 42.5% | 51.4% |
| AA-Briefcase v1.1 puntuación de rúbrica | 61.2% | 66.1% |
| AA-Briefcase v1.1 Elo | 1800 | 1785 |
Justifican evaluar Fable en trabajos difíciles manteniendo visibles los criterios de aceptación. En código, compruebe comportamiento y pruebas; en análisis, hechos, cálculos y respuesta al encargo. Una puntuación agregada mayor no decide qué errores importan en su aplicación.
Compare Fable High con la configuración Opus que utiliza
Una tarifa por token mayor puede coexistir con menos coste total porque las configuraciones consumen distinto trabajo y tokens. El resultado corresponde a esa evaluación y no establece el mismo ahorro frente a Opus Medium en tareas habituales.
Si ya necesita Opus Max para problemas difíciles, Fable High merece una prueba. Si Opus Medium entrega resultados aceptados, determine primero qué mejoraría el cambio: finalización, revisión humana o tiempo hasta un resultado útil. Así un benchmark atractivo no se convierte automáticamente en más gasto.
Dónde encaja cada modelo en el desarrollo
| Trabajo necesario | Punto de partida | Qué justificaría cambiar |
|---|---|---|
| Cambio definido con pruebas fiables | Mantener la configuración Opus | Fable reduce suficiente tiempo total o correcciones para justificar su coste |
| Migración o refactorización bloqueada | Comparar Fable High con Opus actual | Conservar el comportamiento y superar las mismas pruebas |
| Decisión arquitectónica difícil | Comparar planes antes de implementar | Plan que resuelve restricciones y produce un cambio viable |
| Revisión de un cambio importante | Evaluar Fable como revisor adicional | Problemas comprobables sin falsos positivos excesivos |
Son puntos de partida de evaluación. La pregunta útil es si el cambio mejora el entregable de esa clase de trabajo.
Para una migración de servicio que rompe la compatibilidad, dé a cada candidato contrato de interfaz, implementación, pruebas relevantes y fallos conocidos. Pida explicar la causa, proponer un plan y realizar el cambio mínimo viable. La aceptación debe incluir compatibilidad y comportamiento fuera del test visible que falla.
En revisión de código, cada hallazgo debe tener ubicación, desencadenante concreto, fallo resultante y pruebas. Registre hallazgos confirmados, defectos omitidos y tiempo dedicado a falsos positivos. Una lista larga puede aumentar el trabajo de mantenimiento sin mejorar el cambio.
El doble por token no implica el doble por solicitud
Los siguientes ejemplos hipotéticos usan el mismo número de tokens facturados en cada modelo.
| Ejemplo de cálculo | Opus 5.5 | Fable 5.2 |
|---|---|---|
| 100K tokens de entrada nueva y 10K de salida facturada | $0.60 | $1.20 |
| 800K tokens leídos de caché existente + 100K de entrada nueva + 10K de salida | $0.76 | $1.36 |
La segunda fila presupone un prefijo ya en caché y excluye el coste previo de crearlo. Ambas filas excluyen herramientas, reintentos y otros cargos. Son cálculos de tarifas, no resultados de tareas medidas.
Para un trabajo completo, sume las solicitudes fallidas y los intentos necesarios para terminar. Compare todos los cargos del flujo divididos por el número de tareas aceptadas, registrando aparte la revisión humana. Gastar más puede reducir el coste por resultado aceptado si evita fallos repetidos. Explorar más sin mejorar la aceptación aporta poco.
Mantenga creación y reutilización de caché en el registro. Una solicitud con caché existente sirve para estudiar trabajo repetitivo, pero la primera también pertenece al coste del proyecto.
Fable en decisiones clave y Opus en la ejecución
En una aplicación propia, también puede usar un documento explícito: requisitos, plan, decisiones, preguntas pendientes y pruebas. El ejecutor debe informar cuando la realidad contradiga el plan. Añada revisión donde haga falta mayor criterio, en lugar de revisar automáticamente cada paso pequeño.
Compare la combinación con Opus solo y Fable solo. Cuente planificación y revisión junto a ejecución. Un mal plan puede conservar su error al pasar a un ejecutor barato; el traspaso debe permitir cuestionar las premisas.
El advisor nativo es una función Anthropic de Claude Code. Su disponibilidad en otros canales API debe verificarse aparte. Diseñar un traspaso explícito no presupone que la pasarela implemente ese instrumento.
Conservar el estado al cambiar una conversación de modelo
En flujos que alternan modelos, mantenga el estado en documentos ordinarios: requisitos aceptados, archivos modificados, comprobaciones y problemas abiertos. Pruebe el cambio en la aplicación real, incluido el tratamiento de historial y resúmenes.
Convertir el comparativo en una elección en EvoLink
Comience con una tarea corriente, otra donde Opus ya haya tenido dificultades y otra con una secuencia larga de herramientas. Fije entradas y aceptación. Compare su Opus actual con Fable High y ajuste el esfuerzo si el resultado lo justifica. Repita tareas variables y conserve el número de resultados aceptados.
Mantenga Opus donde siga entregando bien a un coste adecuado. Use mejoras medidas de Fable para definir reglas concretas de escalado por tipo de tarea o fallo recurrente. Así la política de modelos se puede explicar y mantener.
Preguntas frecuentes
¿Fable 5.2 programa mejor que Opus 5.5?
Puntúa más en los benchmarks de código publicados arriba. La mejora real depende de tarea, esfuerzo, herramientas y criterios de aceptación.
¿Fable siempre cuesta más?
Sus tarifas de entrada nueva y salida son mayores. El coste completo depende también de consumo, caché, reintentos y herramientas. El caso oficial Fable High frente a Opus Max muestra por qué importa la configuración completa.
¿Debo poner ambos en Max para comparar de forma justa?
Use los ajustes que podría desplegar, con presupuesto y calidad explícitos. Comparar límites de capacidad es útil, pero responde a una pregunta distinta a la mejor configuración de producción.
¿Fable tiene un contexto más grande?
Ambos anuncian 1M tokens. Compruebe si usan correctamente el contexto relevante; la capacidad no es una medida de calidad.
¿Puede Fable planificar y Opus escribir código?
Sí, es un flujo que puede evaluarse con un plan explícito y una salida verificable. Incluya los cargos de ambos y el coste de corregir un mal traspaso.
¿Cuándo debería mantener Opus?
Cuando la configuración actual cumpla los requisitos de calidad y tiempo y la alternativa no aporte una mejora valiosa. Un modelo nuevo no modifica la aceptación de una tarea que ya se resuelve bien.
