Fable 5 High vs Opus 4.8 High vs Sonnet 5 High: una guía práctica de modelos Claude

En resumen

• En CursorBench 3.2, la comparación actual más clara con el mismo nivel de esfuerzo, Fable 5 High obtiene 66.5%, Opus 4.8 High obtiene 58.0% y Sonnet 5 High obtiene 56.9%.
• Fable 5 High es la opción por capacidad. Supera a Opus por 8.5 puntos en tareas de ingeniería amplias, representativas del uso de Cursor, pero Cursor reporta un costo promedio por tarea de $8.77 frente a$3.15 para Opus.
• Opus 4.8 High es mi opción predeterminada en la práctica. Su ventaja de 1.1 puntos sobre Sonnet podría no ser estadísticamente significativa, pero usó 33 pasos y 33,548 tokens por tarea frente a los 57 pasos y 39,483 tokens de Sonnet.
• Sonnet 5 High es la opción de valor para pago por uso, especialmente durante el precio introductorio de Anthropic de $2/$10 por millón de tokens de entrada/salida hasta August 31, 2026. No supongas que una tarifa menor por token garantiza un costo menor por tarea completada.
• Ultracode no es otro modelo. Es una configuración de sesión que envía el nivel de esfuerzo xhigh al modelo seleccionado y agrega orquestación mediante Dynamic Workflows para tareas sustanciales.
• Para Ultracode, mi opción predeterminada es Opus 4.8 como coordinador. Usa Fable 5 para trabajo de valor excepcional, ambiguo y de larga duración. Usa Sonnet 5 para trabajo que se pueda descomponer y en el que el costo importe más que la eficiencia de la orquestación.
• Un experimento prometedor es usar Fable u Opus como modelo principal con agentes de workflow basados en Sonnet. Claude Code permite configurar esa sustitución. Por separado, Cognition descubrió que un asistente más económico cuyo modelo no se especificó invirtió el orden esperado de costos entre Fable y Opus en su harness Fusion; ese resultado no evaluó Sonnet ni Ultracode.

Qué aprenderás aquí

• Cómo se comparan Fable 5, Opus 4.8 y Sonnet 5 con el mismo nivel de esfuerzo high
• Qué resultados de benchmarks son realmente comparables y cuáles usan distintos harnesses o niveles de esfuerzo
• Por qué el precio por token puede no coincidir con el costo por tarea de programación completada
• En qué se diferencian high, xhigh, max y ultracode
• Qué modelo elegiría para programación diaria, refactors difíciles, migraciones y workflows paralelos
• Cómo implementar una pequeña política de asignación de modelos para Claude Code y evaluarla en tu propio repositorio

La pregunta depende del nivel de esfuerzo

Anthropic lanzó:

• Claude Opus 4.8 el May 28, 2026
• Claude Fable 5 el June 9, 2026
• Claude Sonnet 5 el June 30, 2026

Los tres admiten una ventana de contexto de 1 millón de tokens, hasta 128,000 tokens de salida, razonamiento adaptativo y la escala de esfuerzo desde low hasta max. Su nivel de esfuerzo predeterminado es high.

Antes de compararlos, hay una salvedad importante:

Anthropic calibra el esfuerzo por separado para cada modelo. La misma etiqueta no garantiza la misma asignación interna de tokens de razonamiento.

high sigue siendo la comparación operativa más útil porque es el valor predeterminado en los tres modelos. Eso no significa que Anthropic haya asignado cómputo idéntico a cada ejecución.

Salvo que se indique lo contrario, los resultados de benchmarks que siguen provienen del harness de agentes de Cursor, mientras que las recomendaciones de asignación están dirigidas a Claude Code. La puntuación de un modelo no se traslada automáticamente entre esos harnesses.

La comparación más clara con esfuerzo High

CursorBench 3.2 es la fuente actual más útil para esta pregunta específica porque reporta los tres modelos en high dentro del mismo harness de agentes de producción.

Cursor describe el benchmark como un conjunto de tareas derivadas de sesiones reales de programación, incluidas solicitudes ambiguas, ediciones en varios archivos, comprensión de repositorios, detección de bugs, planificación, revisión de código, seguimiento de instrucciones y uso avanzado de herramientas. La versión 3.2 se presentó el July 8, 2026.

Las conclusiones útiles van más allá de «primero, segundo, tercero».

Fable 5 High lidera con más claridad en tareas de programación amplias

Fable supera a Opus por 8.5 puntos porcentuales, una diferencia mucho mayor que los 1.1 puntos que separan a Opus y Sonnet.

Esa ventaja cuesta considerablemente más:

Fable High average benchmark cost
    $8.77 / $3.15
    = 2.78x Opus High

Esto no es una razón para descartar Fable. Es una razón para asignarlo de forma deliberada.

El sobrecosto es más fácil de justificar cuando un primer intento fallido tiene consecuencias costosas:

• hay que reiniciar una migración
• una persona debe reconstruir un plan parcialmente ejecutado
• un diff grande necesita otro ciclo de revisión
• la tarea es difícil de descomponer antes de que el modelo comience
• el trabajo se ejecutará de forma asíncrona con poca supervisión humana

Opus 4.8 High es la opción predeterminada más sólida

Opus supera a Sonnet por solo 1.1 puntos, y Cursor advierte que las diferencias pequeñas de puntuación podrían no ser estadísticamente significativas.

Las señales de eficiencia son más interesantes:

• Opus usó alrededor de 15% menos tokens por tarea
• Opus usó 33 pasos por tarea frente a los 57 de Sonnet
• El costo por tarea publicado por Cursor fue ligeramente menor para Opus, a pesar de que su tarifa por token de API es más alta

Eso no demuestra que Opus siempre será más económico. Muestra por qué la selección de modelos debería basarse en el costo por resultado aceptado, y no solo en el precio de lista.

Para un ingeniero que busca una opción predeterminada y confiable de Claude Code, empezaría con Opus 4.8 High.

Sonnet 5 High sigue siendo la opción para alto volumen

El precio de la API de Sonnet es:

• $2 por millón de tokens de entrada y$10 por millón de tokens de salida hasta August 31, 2026
• $3 por millón de tokens de entrada y$15 por millón de tokens de salida después de esa fecha

Opus cuesta $5/$25 y Fable cuesta $10/$50.

Eso hace atractivo a Sonnet para:

• desarrollo de funcionalidades a gran escala
• correcciones de bugs acotadas
• generación de pruebas
• documentación
• agentes de trabajo con alcance limitado
• cargas de trabajo en las que una persona ya supervisa cada ciclo

Pero el resultado de CursorBench advierte contra las afirmaciones simplistas sobre costos. Sonnet necesitó más pasos y tokens que Opus en ese harness. Cuando termine el precio promocional, el modelo más económico por token podría no ser el más económico por tarea completada.

High responde qué modelo debería encargarse de una sesión ordinaria de programación. Ultracode plantea otra pregunta: qué modelo debería coordinar un workflow generado para una tarea sustancial. Vuelvo a esa distinción después de contrastar el resultado de High.

Cómo contrastar el resultado

Un solo benchmark no debería definir una política de asignación de modelos para producción. Los demás resultados públicos respaldan en general la jerarquía, pero es necesario identificar cuidadosamente sus configuraciones.

Terminal-Bench muestra una ventaja más estrecha de Fable

En la ficha técnica de Fable 5, Anthropic volvió a ejecutar Terminal-Bench 2.1 con el harness mini-SWE-agent en high:

Sonnet se incluye como contexto, no como una comparación equivalente en High.

La diferencia de 1.6 puntos entre Fable y Opus es mucho menor que la de 8.5 puntos en CursorBench. Mi interpretación es que el sobrecosto de Fable aporta más valor a medida que el trabajo se vuelve más amplio, más ambiguo y más dependiente del buen criterio sostenido sobre el repositorio. Una tarea de terminal acotada le da a Opus más oportunidades de mantenerse cerca.

Hay otra salvedad importante: 20.9% de las pruebas de Fable en Terminal-Bench activaron una negativa por seguridad y recurrieron a Opus 4.8 para el resto de la ejecución. Por lo tanto, el 84.3% reportado corresponde a una configuración de Fable desplegada, no a un resultado exclusivo de Fable.

SWE-bench muestra los resultados publicados por Anthropic con esfuerzo Max

Las fichas técnicas de Anthropic reportan los siguientes resultados de SWE-bench, generalmente con razonamiento adaptativo y esfuerzo max:

Estas cifras son útiles para entender el orden de capacidad máxima publicado por Anthropic. No son resultados con esfuerzo High y no deberían presentarse junto a CursorBench High sin esa aclaración. Los resultados de Fable en configuración de producción también pueden incluir salvaguardas y el uso de Opus como alternativa.

SWE-bench Verified también se acerca a la saturación entre los modelos de frontera. SWE-bench Pro y las tareas privadas de programación actuales ofrecen una mayor diferenciación, pero ningún benchmark predice perfectamente el rendimiento en tu repositorio.

FrontierCode nos recuerda que debemos mantener actualizadas las versiones de los benchmarks

La metodología original de FrontierCode de Cognition evalúa si un patch es correcto, disciplinado, probado y apto para integrarse, no solo si pasa una prueba visible.

El July 7, 2026, Cognition lanzó FrontierCode 1.1 y:

• refinó su política de uso justo de internet
• auditó más de 1,000 criterios de evaluación
• redujo la severidad de 75 criterios bloqueantes demasiado estrictos
• dejó de usar el subconjunto Diamond porque los resultados de sus tareas más difíciles tenían demasiado ruido

Esa es una lección útil para interpretar benchmarks: no sigas repitiendo una fila antigua de la clasificación después de que el autor del benchmark cambie la metodología.

En la comparación anterior de FrontierCode v1 Main con xhigh, Fable obtuvo 46.3% y Opus obtuvo 34.3%. La ficha técnica posterior de Sonnet reportó 38.8% con su configuración estándar Max, por lo que las tres filas no deberían tratarse como una clasificación con el mismo nivel de esfuerzo. La afirmación sustentable es más acotada: Fable lideró la ejecución v1 comparable entre Fable y Opus. Aplicar ese resultado a trabajo de producción de larga duración sigue siendo una inferencia.

Especificaciones y estructura de costos

Sonnet 5 también usa un nuevo tokenizer que, según Anthropic, puede producir aproximadamente entre 1.0 y 1.35 veces más tokens para la misma entrada que Sonnet 4.6, según el contenido. Eso no convierte a Sonnet 5 en una mala opción en términos de valor. Significa que las estimaciones de migración deberían usar los conteos de tokens observados en lugar de multiplicar el tráfico anterior por la nueva tarifa.

Para agentes de programación, usa este modelo de costos:

cost per accepted result =
  lead-model tokens
  + worker-model tokens
  + cache reads and writes
  + failed attempts
  + repair loops
  + human review time

El modelo con el precio más bajo para la primera solicitud puede terminar costando más si necesita más turnos, produce un diff más grande o requiere otro ciclo de revisión humana.

Mi recomendación de asignación de modelos

Esta es una política inicial, no una clasificación universal.

La razón más sólida para apartarte de ella son tus propios datos de aceptación.

Ultracode cambia la comparación

La documentación de configuración de modelos de Claude Code define Ultracode con precisión:

Ultracode es una configuración de sesión que envía el esfuerzo xhigh al modelo y, además, hace que Claude orqueste Dynamic Workflows para tareas sustanciales.

En resumen, CursorBench High usa el harness de agentes de Cursor con un modelo seleccionado en high. Ultracode es xhigh más planificación automática de workflows. Un workflow generado puede ejecutar pasos de forma secuencial o paralela; no necesariamente incluye etapas dedicadas de consolidación y verificación.

Llamar a Ultracode un nivel de esfuerzo es práctico en la CLI, pero técnicamente es una descripción incompleta. Agrega un comportamiento del harness que xhigh normal no tiene. Para conocer la arquitectura completa del workflow, sus límites y salvaguardas, consulta el plano de arquitectura de Ultracode.

Xhigh es la referencia más cercana en los benchmarks

CursorBench 3.2 reporta:

Cursor llama a esta fila Extra High; Claude Code expone la configuración correspondiente como xhigh. max es diferente: elimina la restricción de tokens de razonamiento y puede mejorar las tareas coherentes más difíciles para un solo agente, pero Anthropic advierte sobre rendimientos decrecientes y razonamiento excesivo. Ultracode usa xhigh, no max, porque agrega orquestación de workflows en lugar de razonamiento sin restricciones en cada llamada al modelo.

El cambio de High a Xhigh produjo:

Esos son costos de benchmark con un solo agente. Un Dynamic Workflow real puede lanzar varios agentes, por lo que el costo total de la sesión puede ser mucho mayor.

La tabla de Xhigh nos informa sobre la configuración de razonamiento. No demuestra por sí sola cuánto mejora la tasa de finalización gracias a la capa de workflows.

Fable 5 con Ultracode

Úsalo para:

• migraciones que abarcan todo el repositorio
• investigaciones amplias con varias líneas de trabajo inciertas
• tareas difíciles que deben mantenerse coherentes durante una ejecución prolongada
• trabajo asíncrono de alto valor con un criterio de prueba sólido

Por qué resulta atractivo:

• Fable tiene la mayor ventaja en los benchmarks de programación
• Anthropic lo posiciona específicamente para agentes de larga duración
• Cursor reporta que Fable lidera desde el esfuerzo Medium en adelante

Por qué es arriesgado:

• Fable Xhigh ya cuesta $11.73 por tarea de CursorBench antes de distribuir el workflow entre varios agentes
• Los agentes de Dynamic Workflows multiplican el contexto y el volumen de revisión
• El contexto de ciberseguridad, biología/química, destilación o desarrollo de LLM de frontera puede cambiar la sesión de Claude Code al modelo Opus configurado como alternativa
• Una definición débil de la tarea puede convertir una capacidad costosa en retrabajo costoso

Mi recomendación: reserva Fable Ultracode para tareas cuyos criterios de aceptación sean medibles y donde el valor esperado de evitar una ejecución fallida sea alto.

Opus 4.8 con Ultracode

Esta es mi configuración predeterminada de Ultracode.

Opus Xhigh está a 0.7 puntos de Sonnet Xhigh en CursorBench, pero usa 40 pasos en lugar de 67. Es mucho más económico que Fable y evita el cambio a un modelo alternativo de Fable basado en el contenido.

Úsalo para:

• refactors grandes pero acotados
• migraciones con límites claros entre paquetes o servicios
• auditorías de repositorios que necesitan verificación independiente
• trabajo que se beneficia de varias líneas de investigación paralelas

Opus es la recomendación menos llamativa, y precisamente por eso es útil: ofrece un coordinador sólido sin convertir cada workflow en un gasto propio de un modelo de frontera.

Sonnet 5 con Ultracode

Sonnet es una opción viable cuando el workflow es amplio, pero no muy ambiguo:

• un agente por paquete independiente
• correcciones repetitivas con pruebas deterministas
• generación de documentación o pruebas en muchos módulos
• investigaciones paralelas que producen evidencia en lugar de ediciones superpuestas

La preocupación es la eficiencia con un solo agente. En CursorBench Xhigh, Sonnet usó 67 pasos frente a los 40 de Opus. Todavía no se ha medido de forma independiente si Dynamic Workflows amplifica o reduce esa diferencia.

Mi recomendación: usa Sonnet Ultracode cuando las tareas ya sean fáciles de dividir y los resultados de los agentes sean económicos de verificar. No lo elijas solo porque su precio por token sea menor.

Un experimento con un modelo principal potente y agentes más económicos

La evidencia de esta sección es indirecta. Cognition probó su propio harness Fusion con el mismo asistente más económico, cuyo modelo no especificó, para ambos modelos principales. No probó agentes Sonnet ni Claude Code Ultracode.

Claude Code te permite sustituir el modelo que usan los subagentes, equipos de agentes y agentes de workflow con CLAUDE_CODE_SUBAGENT_MODEL.

Eso permite hacer un experimento útil:

CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-5 \
  claude --model claude-fable-5 --effort ultracode

En la API nativa de Anthropic, la división de roles prevista es:

Fable Xhigh main session
    -> interpret the request and generate the workflow

Sonnet workflow agents
    -> execute every agent role spawned by that workflow

La sustitución se aplica a todos los agentes del workflow, no solo a los agentes de implementación. Por lo tanto, puede asignar a Sonnet los roles de investigación, consolidación o verificación cuando el workflow generado los incluya. En proveedores externos, usa el ID completo del modelo Sonnet 5 del proveedor en lugar de suponer que el alias sonnet apunta a Sonnet 5.

Cognition reportó un resultado relacionado con su arquitectura Fusion en FrontierCode 1.1:

Fable como modelo principal usó 11.5 turnos por ejecución con el asistente cuyo modelo no se especificó, mientras que Opus usó 26.5. Cognition concluyó que una mejor delegación y gestión del contexto compensó la tarifa más alta por token de Fable.

Esta es evidencia prometedora para la asignación asimétrica de modelos. No es evidencia específica sobre Sonnet, ni demuestra que Claude Code Ultracode reproducirá los costos de Fusion. El harness, el modelo de los agentes, los prompts, los niveles de esfuerzo y la política de orquestación son diferentes.

Trata el comando anterior como un experimento y mide la sesión completa.

Implementa una pequeña política de asignación de modelos

No necesitas un router de plataforma para probar esta división de modelos. Empieza con un wrapper pequeño:

#!/usr/bin/env bash
set -euo pipefail

task_class="${1:?usage: claude-route <routine|complex|migration>}"
shift

case "$task_class" in
  routine)
    exec claude --model claude-sonnet-5 --effort high "$@"
    ;;
  complex)
    exec claude --model claude-opus-4-8 --effort high "$@"
    ;;
  migration)
    export CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-5
    exec claude --model claude-fable-5 --effort ultracode "$@"
    ;;
  *)
    echo "unknown task class: $task_class" >&2
    exit 2
    ;;
esac

La política es intencionalmente conservadora:

routine
  -> cheapest capable daily loop

complex
  -> stronger single coordinator, no automatic fan-out

migration
  -> strongest lead, Xhigh reasoning, workflow orchestration,
     cheaper bounded workers

Iniciar Ultracode con --effort ultracode requiere Claude Code v2.1.203 o posterior. Ultracode solo se aplica a la sesión. Si Dynamic Workflows no está disponible o está deshabilitado, el comando recurre a Xhigh sin orquestación de workflows.

Evalúa la política en tu repositorio

Usa al menos 12 tareas representativas:

• cuatro ediciones rutinarias
• cuatro correcciones de bugs o refactors complejos
• cuatro migraciones amplias, auditorías o cambios que abarquen varios paquetes

Ejecuta cada modelo y modo aplicable con el mismo commit del repositorio, la misma política de herramientas, el mismo texto de tarea y las mismas pruebas de aceptación. Haz al menos cinco repeticiones por condición porque los agentes no son deterministas; después, compara las medianas y los rangos de resultados en lugar de seleccionar una ejecución favorable.

Esta evaluación es más acotada que las evaluaciones generales de modelos y Ultracode de los artículos relacionados. Combina deliberadamente:

• el mismo commit y la misma tarea en los tres modelos
• high, xhigh y Ultracode como modos separados
• ejecuciones de Fable con seguimiento explícito del modelo alternativo

Registra:

type ClaudeModelRun = {
  taskId: string;
  model: "fable-5" | "opus-4.8" | "sonnet-5";
  mode: "high" | "xhigh" | "ultracode";
  accepted: boolean;
  deterministicTestsPassed: boolean;
  inputTokens?: number;
  outputTokens?: number;
  totalCostUsd?: number;
  wallTimeMinutes: number;
  agentSteps?: number;
  workerCount: number;
  repairLoops: number;
  humanReviewMinutes: number;
  fallbackModel?: string;
};

Elige con estas métricas:

1. tasa de tareas aceptadas
2. costo por tarea aceptada
3. minutos de revisión humana por tarea aceptada
4. tiempo transcurrido
5. frecuencia de uso del modelo alternativo, reintentos y correcciones

No adoptes un modelo porque produjo más código o lanzó más agentes. Adóptalo cuando produzca más trabajo aceptado dentro de tu presupuesto de costos y revisión.

Salvedades sobre benchmarks y despliegue

Ten presentes estas limitaciones:

1. CursorBench es relevante, pero no universal. Usa el harness de agentes de producción de Cursor y tareas representativas de su uso.
2. Las diferencias pequeñas pueden ser ruido. Cursor advierte explícitamente que las puntuaciones cercanas podrían no ser estadísticamente significativas.
3. Las tablas principales de las fichas técnicas de Anthropic suelen usar Max. No deben etiquetarse erróneamente como High.
4. La elección del harness puede cambiar considerablemente las puntuaciones. Los resultados de Terminal-Bench difieren entre mini-SWE-agent, Terminus-2, Claude Code y Codex CLI.
5. La contaminación de benchmarks es un problema vigente. Tanto Cursor como Cognition cambiaron sus prácticas de evaluación en 2026 para reducir la recuperación de soluciones existentes en lugar de su derivación.
6. Los resultados de Fable pueden incluir el uso de Opus como alternativa. Es un comportamiento realista del producto, pero dificulta atribuir los resultados exclusivamente a un modelo.
7. Ultracode necesita una evaluación separada. Las puntuaciones de Xhigh con un solo agente no miden la capa completa de Dynamic Workflows.
8. El paralelismo desplaza el cuello de botella. Más agentes pueden reducir el tiempo transcurrido mientras aumentan el uso de tokens, los conflictos de integración y la revisión humana.

Cuándo debería adoptar un equipo esta política

Una política de tres modelos solo vale la pena cuando el equipo puede mantenerla. Alguien debe encargarse de las listas de modelos permitidos, la facturación, la actualización de benchmarks, el comportamiento de los modelos alternativos y las excepciones. Los repositorios también necesitan pruebas deterministas o criterios de aceptación explícitos; de lo contrario, el modelo más potente solo produce un resultado más costoso que sigue siendo difícil de aprobar.

Si faltan esos controles, estandariza primero en Opus 4.8 High. Agrega Sonnet para líneas de trabajo de alto volumen que puedas medir y Fable solo después de que el equipo pueda identificar de forma consistente el trabajo en el que fallar resulta costoso.

Recomendación final

Si tuviera que estandarizar una política hoy:

Default coding:
    Opus 4.8 High

High-volume, bounded work:
    Sonnet 5 High

Hard, long, expensive-to-fail work:
    Fable 5 High

Large substantive workflow:
    Opus 4.8 Ultracode

Exceptional migration with strong acceptance tests:
    Experiment with Fable 5 Ultracode + Sonnet workflow agents

La distinción importante no es simplemente el tamaño del modelo.

Es la naturaleza de la tarea:

bounded and steerable
    -> optimize unit cost and latency

complex but still one coherent problem
    -> optimize coordinator efficiency

ambiguous, long-running, and expensive to restart
    -> pay for the stronger model and verify aggressively

Fable 5 es el ganador de los benchmarks. Opus 4.8 es la opción predeterminada para operar. Sonnet 5 es la herramienta para alto volumen.

Ultracode no elimina esos roles. Hace que la asignación de modelos y el costo total del workflow sean aún más importantes.

Lecturas relacionadas

• Plano de arquitectura de Claude Code Ultracode para Cursor y agentes personalizados
• Construye un workflow de programación similar a Ultracode con Agno y AgentOS
• Construye un workflow de programación similar a Ultracode con LangGraph
• Una estrategia de modelos por fases para GitHub Spec Kit en 2026
• Claude Sonnet 4.6 1M vs Composer 2.5 Fast
• Cuándo usar subagentes y cuándo usar el hilo principal del chat

Fuentes

• Anthropic, “Presentamos Claude Opus 4.8”, May 28, 2026.
• Anthropic, Ficha técnica de Claude Opus 4.8, May 28, 2026.
• Anthropic, “Claude Fable 5 y Claude Mythos 5”, June 9, 2026.
• Anthropic, Ficha técnica de Claude Fable 5 y Claude Mythos 5, June 9, 2026; corregida el June 11, 2026.
• Anthropic, “Presentamos Claude Sonnet 5”, June 30, 2026.
• Anthropic, Ficha técnica de Claude Sonnet 5, June 30, 2026.
• Documentación de Claude Platform, “Descripción general de los modelos”, consultado el July 15, 2026.
• Documentación de Claude Code, “Configuración de modelos”, consultado el July 15, 2026.
• Documentación de Claude Code, “Orquesta subagentes a escala con Dynamic Workflows”, consultado el July 15, 2026.
• Cursor, “CursorBench 3.2”, consultado el July 15, 2026.
• Cursor, “Cómo comparamos la calidad de los modelos en Cursor”, March 11, 2026.
• Cursor, “La explotación de recompensas está opacando los avances en inteligencia de los modelos”, June 25, 2026.
• Cognition, “Presentamos FrontierCode”, June 8, 2026.
• Cognition, “FrontierCode 1.1”, July 7, 2026.
• Cognition, “Cómo hacer que Fable sea más económico que Opus”, July 13, 2026.