Claude Fable 5.2 vs Opus 5.5: código y tareas de agente

En estas cuatro tareas pequeñas de código y herramientas, el sobreprecio de Fable 5.2 no compensa: Claude Fable 5.2 y Claude Opus 5.5 pasaron las 29 comprobaciones de código, y la estimación a tarifa estándar de Opus fue de $0,031 para el conjunto frente a $0,146 de Fable. Plantéate Fable para razonamiento más difícil o ejecuciones largas de agente cuando Opus con más effort se quede corto.

Fable 5.2 y Opus 5.5 de un vistazo

Fable 5.2 es más nuevo, pero los dos modelos comparten la misma ventana de contexto de 1M tokens y la misma salida de 128K tokens. La diferencia práctica en esta prueba fue el uso de tokens, no la corrección del código.

Las páginas de modelo de Anthropic de Fable 5.2 y Opus 5.5 listan ambos como activos, con entrada de texto e imagen. Fable se publicó el 9 de noviembre de 2026; Opus, el 22 de septiembre de 2026. Sus niveles de effort por defecto son distintos, así que pon medium en los dos cuando los compares.

El resumen de modelos de Anthropic recomienda Opus 5.5 para la mayoría de las tareas. Sitúa Fable 5.2 para razonamiento exigente y trabajo de agente de largo alcance, o para casos en los que las evaluaciones de Opus 5.5 con más effort sigan quedándose cortas. Eso es el posicionamiento del fabricante; esta prueba cubre cuatro tareas pequeñas.

Para ver los cambios de la versión, lee qué cambió en Fable 5.2. Para un análisis de un solo modelo, está la reseña de Opus 5.5.

Cuánto cuestan las cuatro tareas

La página de precios oficial de Anthropic lista $8 de entrada y $40 de salida por millón de tokens para Fable 5.2, frente a $4 y $20 para Opus 5.5 (consultada el 12 nov 2026). Batch reduce a la mitad los dos pares de precios; el modo fast los duplica.

En las cuatro tareas puntuadas, Fable usó 3.439 tokens de entrada y 2.954 de salida. Opus usó 2.421 y 1.065. A tarifa estándar, sale así:

• Fable: (3.439 × $8 + 2.954 × $40) ÷ 1.000.000 = $0,1457
• Opus: (2.421 × $4 + 1.065 × $20) ÷ 1.000.000 = $0,0310

Son estimaciones a tarifa estándar a partir de los tokens observados, no facturas ni cargos de OmniaKey. La respuesta de Opus informó velocidad fast, y la de Fable, standard; Anthropic lista la entrada y la salida de fast al doble de la tarifa estándar. Aquí normalizamos ambos a tarifa estándar, así que las cifras no son una comparación de tiempos ni de facturación controlada.

Estimaciones a tarifa estándar en dólares:

En promedio sobre las cuatro tareas probadas, Fable costó $0,0364 y Opus $0,0077; la estimación a tarifa estándar de Fable fue $0,1147 más alta en el conjunto. La regla práctica es el coste por tarea utilizable: gasto de API más tiempo de reintento y revisión. Sube de modelo cuando los casos reales fallidos justifiquen ese gasto extra; estas cuatro tareas pequeñas no lo hacen.

Los totales de tiempo real fueron 27,8 s para Fable y 43,6 s para Opus. Las respuestas de Fable informaron velocidad standard y las de Opus, fast, y no fijamos ninguna; léelos como observaciones, no como una clasificación de velocidad.

Dos arreglos de Python: 22/22 comprobaciones en ambos

Los dos arreglos son cortos y ambos modelos devolvieron funciones que funcionan. Los fallos merecen reutilizarse porque prueban el manejo de revisiones y los casos límite de paginación, no el conocimiento de una biblioteca.

Totales de uso: un fallo nuevo debe borrar un éxito viejo

La función antigua sumaba todos los eventos complete. Ignoraba revision y status, así que un reintento contaba los tokens dos veces y una revisión failed nueva no podía anular una complete anterior.

La regla central del prompt:

Keep only the highest revision for each event_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing.

La reproducción mínima es el evento x en la revisión 1, complete, 10 tokens, seguido de x en la revisión 2, failed, 10 tokens. El total correcto es cero; la función antigua devuelve 10.

Ambos modelos conservaron la revisión más alta, usaron el orden de entrada para revisiones iguales, saltaron los ganadores failed, mantuvieron a los usuarios con cero tokens y dejaron la entrada sin cambios. Resultado: 8/8 comprobaciones cada uno, con funciones equivalentes.

Paginación por cursor: los empates no deben repetir ni saltar

La versión antigua ordenaba solo por ts, cortaba la primera página antes de aplicar el cursor, aceptaba timestamps iguales con <=, nunca validaba limit y siempre devolvía un cursor siguiente. Con dos filas en ts=4, eso repite o salta un ID.

Las reglas centrales del prompt:

Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid.

Ambos lo corrigieron todo: orden por tupla, menor estricto, filtrado de la lista completa antes del corte, cursor siguiente solo cuando quedan filas y validación que rechaza True, False, 0, 101, 1.5, '2' y None. Resultado: 14/14 comprobaciones cada uno, incluido un recorrido de una fila sobre timestamps empatados.

El libro mayor asíncrono: mismas cifras, distinto JSON

Ambos modelos acertaron la conciliación: $0,93 netos reservados, t3 pendiente, t1 y t5 completadas y poll_existing para t3.

El fixture sintético que se entregó usa importes ilustrativos, no precios de OmniaKey. Sus líneas clave:

POST key=a => 201 task=t1 quote=0.40

POST key=a, identical body => 200 task=t1

GET t1 => SUCCEEDED

POST key=b => 201 task=t2 quote=0.40

GET t2 => FAILED

POST key=c => 201 task=t3 quote=0.13

Client stopped polling t3 after 120 seconds; last status PROCESSING

POST key=d => 201 task=t4 quote=0.13

GET t4 => CANCELED

POST key=e => 201 task=t5 quote=0.40

GET t5 => SUCCEEDED

La aritmética es 0,40 + 0,13 + 0,40 = 0,93. t2 y t4 se reembolsan; t1 y t5 consumen; t3 conserva su reserva porque el cliente dejó de consultar, no porque la tarea fallara.

Contando solo las tareas con último estado observado SUCCEEDED, ambos devolvieron los mismos valores. Fable devolvió JSON en bruto. Opus envolvió el JSON en un bloque de código JSON. El prompt decía "Return ONLY JSON", así que un json.loads estricto sobre la respuesta de Opus falla hasta que se quita el bloque. Es un fallo solo de formato: la petición pedía texto JSON plano, sin esquema JSON ni modo de salida estructurada. Resultado: los valores pasan en ambos; para automatizar, valida la respuesta en bruto con un analizador estricto o usa salida estructurada. Fue un fallo observado, no un patrón general.

La tarea de archivo en dos turnos: una lectura, un parche

El remaining_quota antiguo del fixture restaba las units de todos los eventos. Ignoraba el último estado de cada id y el recorte max(0, ...), así que las tareas failed o canceled seguían consumiendo cuota y los eventos repetidos cobraban dos veces.

La tarea:

Use read_file once to inspect quota.py, then return one Python code block containing only a corrected remaining_quota(limit, events) function.

Ambos modelos hicieron exactamente una llamada a read_file para quota.py. Cuando volvió el fixture, ambos devolvieron la misma lógica de parche: conservar el último evento por id, sumar units solo para reserved o succeeded y devolver max(0, limit - consumed). Resultado: 7/7 comprobaciones cada uno, incluidos los casos de failed y luego reserved y los de límite superado.

Son dos turnos y un fixture. Muestra que los modelos piden el archivo correcto y lo parchean; no cubre una ejecución larga de agente.

Cómo lo probamos

El 12 nov 2026 enviamos cuatro tareas a claude-fable-5-2 y claude-opus-5-5 a través del endpoint Messages de OmniaKey. Cada par modelo/tarea usó una conversación nueva y caché fría, con effort medium, max_tokens 4096 por petición, sin system prompt, sin temperature ni top_p, y un solo intento. Alternamos qué modelo iba primero según la tarea.

La tarea de agente usó una herramienta read_file estricta con tool_choice: auto; el resto fue un único mensaje de usuario. El evaluador filtró cada respuesta de Python con AST y luego la ejecutó en un proceso aislado con un tiempo límite de 3 segundos contra 8 casos de uso, 14 de cursor y 7 de agente: 29 casos de código por modelo. Cada petición se ejecutó una vez.

El primer prompt del libro mayor dejaba abierto si las tareas FAILED/CANCELED pertenecen a completed_task_ids. Sustituimos esa ronda ambigua por una repetición aclarada por modelo, contando solo las tareas con último estado SUCCEEDED; las salidas originales quedan fuera de los totales de las cuatro tareas puntuadas.

Las 12 peticiones devolvieron HTTP 200 con el ID de modelo solicitado y terminaron en end_turn, o tool_use y luego end_turn, sin truncamiento. Ambos informaron service tier standard. Fable informó velocidad standard y recuentos separados de tokens de thinking; Opus informó velocidad fast y omitió el campo de tokens de thinking. Dejamos la velocidad sin fijar, y los tokens de salida ya incluyen el thinking facturado, así que el campo ausente de Opus no dice nada sobre un thinking nulo.

La misma cadena de effort es un ajuste, no un presupuesto de cómputo igualado. Esta ejecución mantiene el effort en medium; para tu propio trabajo, recorre los niveles de effort que pida tu tarea. Es una prueba con un fixture pequeño, no un benchmark de un repositorio completo ni de un agente de larga duración. No predice tasas de acierto en otras tareas. OmniaKey vende acceso a los dos modelos; los precios de arriba son los de lista oficiales de Anthropic.

Cuándo evaluar Fable

Empieza con Opus 5.5 para trabajo corto y bien especificado. Igualó a Fable en las 29 comprobaciones de código, y la estimación a tarifa estándar de Fable fue 4,7 veces la de Opus.

Trata Fable 5.2 como el siguiente candidato para razonamiento exigente o bucles largos de herramientas después de que Opus con más effort falle en tus casos reales. Ese es el posicionamiento de Anthropic; esta ejecución cubre solo las cuatro tareas pequeñas. Prueba con 10–20 fallos reales antes de cambiar.

El anuncio de Fable 5.2 de Anthropic añade un dato reportado por el fabricante: Fable 5.2 en High sacó 45,3 % en FrontierCode 2.0 frente a 45,5 % de Opus 5.5 en Max, con cerca de la mitad del coste por tarea. El anuncio dice también que Fable 5.2 en Xhigh llegó a 49,1 %, la puntuación más alta de cualquier modelo publicado probado. Eso empareja Fable High con Opus Max, una comparación distinta de nuestra prueba con el mismo medium.

Para un proyecto real, compara el gasto de API con el tiempo de reintento y revisión por tarea utilizable. En trabajo pequeño que ya pasa, Opus es la opción por defecto más barata.

Para usar cualquiera de los dos modelos en Claude Code, la guía de configuración de Claude Code tiene la base URL y los ajustes de clave. Páginas de modelo: Claude Fable 5.2 y Claude Opus 5.5.

Preguntas frecuentes

¿Vale la pena pagar más por Fable 5.2 frente a Opus 5.5?

Plantéate Fable después de que Opus con más effort falle en tus propios casos, y comprueba que Fable los mejora; esta ejecución no da un veredicto sobre tareas difíciles. En nuestras cuatro tareas pequeñas ambos pasaron 29/29 comprobaciones de código; la estimación a tarifa estándar de Fable fue $0,1457 frente a $0,0310 de Opus.

¿Pasaron Fable 5.2 y Opus 5.5 las mismas pruebas de código?

Sí. Ambos pasaron 8/8 casos de uso, 14/14 de cursor y 7/7 de parche de archivo. La respuesta del libro mayor también fue correcta en los dos, con una diferencia de formato: Opus añadió un bloque de código JSON.

¿Cuál es más barato para programar, Fable 5.2 u Opus 5.5?

Con los precios de lista estándar de Anthropic, Opus 5.5: $4 de entrada y $20 de salida por millón de tokens frente a $8 y $40. Nuestros tokens dejan la estimación a tarifa estándar de Fable en 4,7 veces la de Opus: $0,1457 frente a $0,0310 en cuatro tareas.

¿Es Fable 5.2 más rápido que Opus 5.5?

Nuestra ejecución lo deja abierto. Los totales observados fueron 27,8 s para Fable y 43,6 s para Opus, pero las respuestas de Fable informaron velocidad standard y las de Opus, fast, y dejamos la velocidad sin fijar. Vuelve a compararlos con el mismo ajuste de velocidad.

¿Puedo usar los dos modelos en Claude Code a través de OmniaKey?

Sí. En esta ejecución llamamos a los dos ID de modelo a través de OmniaKey, y la guía de configuración de Claude Code muestra la base URL y la clave. Comprueba el nombre del modelo en tu cliente después de conectar.

Fuentes consultadas

• Anthropic: Descripción del modelo Claude Fable 5.2
• Anthropic: Introducing Claude Fable 5.2 and Mythos 5.2
• Anthropic: Descripción del modelo Claude Opus 5.5
• Anthropic: Resumen de modelos
• Anthropic: Precios

Todas consultadas el 12 nov 2026.