El 15 de octubre de 2026, Anthropic anunció que el modo rápido de Claude Opus 5.5 salía de research preview, su fase de acceso experimental. Para los desarrolladores, el cambio permite empezar a utilizarlo sin solicitar acceso específico, dentro de los niveles admitidos. Sigue siendo una opción de pago con capacidad propia: conviene decidir dónde compensa antes de activarla para todas las peticiones.
Lo recogimos en el resumen del 15 de octubre. Aquí desarrollamos sus consecuencias de integración. El lanzamiento de Opus 5.5 fue otro hecho, anunciado en septiembre.
Qué cambia en el acceso
Según las notas de versión de Anthropic, Opus 5.5 ya no necesita la cabecera fast-mode-2026-02-01; las peticiones que todavía la incluyen continúan funcionando. Los niveles de uso Start, Build y Scale tienen un límite rápido predeterminado. Una organización en Evaluation necesita pasar a uno de esos niveles.
La salida de la fase experimental afecta a Opus 5.5. Opus 5 y Opus 4.8 mantienen fast en research preview y requieren la cabecera. Estas condiciones pertenecen a la plataforma de desarrollo y no describen las suscripciones del chat de Claude. Fast tampoco está disponible con Batch API ni con un compromiso Priority Tier.
Microsoft Foundry también incorpora fast para Opus 5.5 en despliegues alojados en Azure. La documentación excluye los despliegues de Foundry alojados en Anthropic. La página de precios tampoco lo ofrece en Claude Platform on AWS ni en otras plataformas operadas por socios: el nombre comercial del modelo no basta para confirmar disponibilidad.
Generar más deprisa tiene un precio distinto
La tarifa oficial de Opus 5.5 en la API es de 4 dólares por millón de tokens de entrada y 20 por millón de salida a velocidad estándar. En fast pasa a 8 y 40 dólares, respectivamente. Los ajustes de caché y residencia de datos pueden modificar el importe.
Ejemplo hipotético, no ejecutado contra la API: una petición con 10.000 tokens de entrada y 2.000 de salida costaría 0,08 dólares a velocidad estándar y 0,16 en fast. Mil peticiones iguales serían 80 y 160 dólares. El cálculo excluye caché, residencia, herramientas, impuestos y cualquier otro ajuste; no representa una factura ni una medición de Puntoes.
La guía técnica de fast describe los mismos pesos y capacidades con otra configuración de inferencia. Anthropic anuncia hasta 2,5 veces más tokens de salida por segundo. Ese máximo se refiere al ritmo de generación: no equivale a reducir en esa proporción la espera del primer token ni el tiempo total de una tarea con consultas y herramientas. Puntoes no ha medido esa mejora.
Capacidad separada y retorno explícito a estándar
La petición activa el modo con speed: "fast" y la respuesta permite comprobarlo en usage.speed. Fast tiene límites independientes de los estándar. Al agotarlos, la API devuelve un error 429 con retry-after; el SDK, la biblioteca de desarrollo, reintenta hasta dos veces por defecto según la documentación.
Esperar y volver a solicitar fast es distinto de reenviar a velocidad estándar. Ese retorno debe programarlo la aplicación. Además, ambas velocidades no comparten los prefijos de caché: cambiar puede provocar un fallo de caché y alterar el cálculo de coste.
Dónde probarlo primero
Nuestro criterio sería empezar por una tarea interactiva donde una persona espere una respuesta extensa. Compararíamos la misma carga a ambas velocidades, el coste por tarea correcta y los tiempos de extremo a extremo. Medir la mediana y el percentil 95 ayuda a separar la experiencia habitual de las esperas largas.
Antes de ampliar su uso, definiríamos cuánto esperar ante un 429 y cuándo aceptar la velocidad estándar. Las trazas de Claude y MLflow pueden ayudar a localizar las esperas, con sus propios requisitos. Si el cuello de botella está en una herramienta externa, acelerar la generación puede aportar poco. La decisión necesita datos de la aplicación, además del máximo anunciado por el proveedor.