El coste por tarea de Claude Opus 5.5 es menor, pero los precios de los tokens explican solo la mitad
Anthropic redujo las tarifas de tokens de Claude Opus 5.5 en un 20%, pero el coste estimado por tarea de Claude Opus 5.5 puede caer aún más. Las lecturas de caché cuestan un 60% menos que en Opus 5, lo que cambia la economía de las sesiones largas de Claude Code.
Claude Devs destacó esta diferencia mediante un análisis de costes por tarea y una calculadora interactiva publicados el 22 de septiembre de 2026. El análisis pide a los desarrolladores medir el trabajo completado, en lugar de comparar tarifas de tokens aisladas.
Esa distinción configura la verdadera competencia entre Opus 5.5 y Opus 5. Un token más barato no garantiza una funcionalidad, migración o sesión de depuración más económica. Los turnos, el comportamiento de la caché, la salida de razonamiento, los reintentos y la configuración del modelo determinan el resultado final.
Qué cambió en el coste por tarea de Claude Opus 5.5
Anthropic redujo todas las principales categorías de tokens, pero las lecturas de caché recibieron la mayor rebaja.
Las tarifas de tokens de entrada y salida son, respectivamente, un 20% inferiores a sus equivalentes de Opus 5. Las lecturas de caché son un 60% más baratas, según el anuncio del modelo de Anthropic.
La diferencia importa porque Claude Code envía repetidamente al modelo el material de conversaciones anteriores. Ese material reutilizado suele incluir instrucciones, archivos de código fuente, resultados de herramientas y el trabajo completado hasta el momento.
El almacenamiento en caché de prompts permite al servicio reconocer contenido procesado previamente. Una lectura de caché recupera ese contexto reutilizable a una tarifa inferior a la de procesarlo como entrada nueva.
Anthropic afirma que las lecturas de caché representan la mayor parte del volumen de tokens en muchas cargas de trabajo de programación y agentes. Esta afirmación describe la composición de los tokens, no necesariamente el mayor cargo de cada factura.
La salida aún puede dominar el coste final, porque el razonamiento y el texto generado se facturan como tokens de salida. Una sesión con una entrada moderada pero razonamiento extenso puede beneficiarse menos de las lecturas de caché más económicas.
El análisis oficial de costes por tarea separa esos efectos. Primero compara ambos modelos utilizando recuentos de tokens idénticos, aislando el cambio de tarifa.
Su sesión ilustrativa contiene un contexto en caché considerable, algo de entrada nueva y una cantidad menor de salida. Bajo esos supuestos fijos, Opus 5.5 cuesta aproximadamente un 31% menos que Opus 5.
Ese resultado se sitúa entre las reducciones anunciadas. Supera el 20% porque la sesión se beneficia de lecturas de caché más baratas, pero permanece por debajo del 60% porque importan otras categorías de tokens.
Anthropic estima por separado que las cargas de trabajo típicas cuestan aproximadamente un 40% menos con la configuración predeterminada. Esa estimación más amplia incluye tanto tarifas más bajas como la expectativa de la empresa de que Opus 5.5 complete el trabajo con mayor eficiencia.
Son afirmaciones distintas. Las cifras del 20% y el 60% proceden directamente de cambios de tarifas publicados. El ejemplo del 31% depende de una combinación ilustrativa de tokens.
La reducción estimada del 40% añade supuestos sobre el comportamiento del modelo. Los desarrolladores no deberían aplicarla automáticamente a cada repositorio, prompt o flujo de trabajo de programación.
Opus 5.5 estuvo disponible el 22 de septiembre a través de la API de Claude y varias plataformas principales de nube. El modelo también llegó a Claude Code y a los productos de suscripción de Anthropic.
Su resumen del modelo indica una ventana de contexto de un millón de tokens y una configuración predeterminada de esfuerzo medio. El pensamiento adaptativo está siempre activo.
Estos detalles afectan a los costes más allá de la nueva tabla de tarifas. Un contexto disponible mayor puede permitir sesiones más largas, mientras que el pensamiento adaptativo añade salida facturable según la dificultad de la tarea.
El resultado es un coste unitario menor junto con un total dependiente de la carga de trabajo. El cambio de tarifas crea la oportunidad, pero el recorrido del agente por una tarea decide cuánto de ella se materializa.
Por qué una tarea de Claude Code cuesta más que su contexto final
Claude Code paga por el procesamiento repetido entre turnos, no solo por la conversación visible al final.
Una tarea de Claude Code funciona como un ciclo. El modelo lee el contexto, selecciona una herramienta, examina el resultado, actualiza su razonamiento y repite esos pasos.
Cada ciclo crea otra solicitud. Esa solicitud incluye gran parte de la conversación acumulada durante turnos anteriores.
Considere una sesión que empieza con un contexto moderado y crece a medida que Claude lee archivos, ejecuta pruebas y recibe salida de terminal. El tamaño de su contexto final no equivale al total de entrada procesada.
Si la tarea requiere muchos turnos, el modelo se enfrenta repetidamente al material anterior. El almacenamiento en caché de prompts abarata esas lecturas repetidas, pero no las hace gratuitas.
Este mecanismo explica por qué dos sesiones que terminan con cambios de código similares pueden tener costes distintos. Un modelo puede localizar inmediatamente los archivos relevantes y terminar tras un breve ciclo de validación.
Otro puede inspeccionar el subsistema equivocado, intentar una corrección, encontrarse con un fallo y rehacer su recorrido. La segunda sesión paga por más llamadas a herramientas, más razonamiento y más contexto repetido.
Por tanto, el número de turnos actúa como multiplicador de costes. Cada turno innecesario incorpora tanto su contenido nuevo como la conversación ya acumulada.
El ejemplo de Anthropic empieza con un contexto que se multiplica por seis y continúa durante 40 turnos. La entrada total procesada se vuelve mucho mayor que la ventana de contexto final.
Reducir ese ejemplo a 25 turnos disminuye sustancialmente la entrada total. El ahorro procede de evitar pasadas repetidas sobre la misma conversación en crecimiento.
Por eso un comando de prueba fiable puede reducir el coste de una tarea de Claude Code. El modelo recibe una señal directa sobre si su cambio funciona.
Sin esa señal, puede inspeccionar más archivos o razonar a través de varias explicaciones especulativas. Una compilación, prueba unitaria o script de reproducción puede acortar esa búsqueda.
La agrupación de herramientas puede producir un efecto similar. Leer varios archivos relacionados en una ronda puede evitar ciclos de solicitud adicionales, aunque una recuperación indiscriminada puede inflar el contexto.
El objetivo útil no es la menor cantidad posible de tokens. Es el camino fiable más corto hacia un resultado correcto y verificado.
Esa distinción importa al comparar Opus 5.5 frente a Opus 5. Un modelo más reciente puede generar más razonamiento durante un turno, pero requerir menos turnos en total.
También puede ocurrir lo contrario. Opus 5.5 siempre utiliza pensamiento adaptativo, y Anthropic afirma que puede pensar más con el mismo nivel de esfuerzo nominal.
Un desarrollador que compare solo la salida de una solicitud puede pasar por alto el patrón completo de la tarea. La unidad significativa incluye exploración, ediciones, pruebas, correcciones e informe final.
Los reintentos merecen especial atención. Una ejecución con menor esfuerzo que falla y debe repetirse puede costar más que una ejecución exitosa con una configuración superior.
Lo mismo se aplica a las bajadas de modelo. Un modelo más pequeño puede ahorrar tokens durante una consulta, pero un resultado erróneo puede llevar al agente principal por un desvío costoso.
El análisis de Anthropic presenta esto como coste por tarea completada. Esa medida recompensa la finalización precisa y penaliza los falsos comienzos, incluso cuando la tarifa subyacente de tokens parece atractiva.
Para los equipos de ingeniería, la lección es práctica. Cuenten el ciclo completo desde una solicitud delimitada hasta un resultado verificado, no una sola respuesta ni una instantánea de contexto.
Las lecturas de caché provocan el mayor vuelco de precios
La mayor reducción de Opus 5.5 se aplica a la categoría de tokens que las sesiones largas de agentes utilizan con más intensidad.
Opus 5 cobraba las lecturas de caché a una décima parte de su tarifa estándar de entrada. Opus 5.5 reduce esa relación a una vigésima parte.
Combinado con la menor tarifa de entrada, esto produce la reducción del 60% en las lecturas de caché. La entrada nueva y la salida reciben la menor reducción del 20%.
Por tanto, una alta proporción de caché acerca una tarea al mayor ahorro. Una solicitud corta con poco contexto reutilizado se mantiene más cerca de la reducción básica de tarifas de tokens.
La calculadora de Anthropic permite a los lectores modificar la entrada total, la parte almacenada en caché, la salida, el volumen diario de tareas y un supuesto de eficiencia. El último control representa menos tokens utilizados por Opus 5.5.
Dejar ese supuesto de eficiencia en cero aísla los precios. Cualquier reducción añadida representa una hipótesis sobre cómo el comportamiento del modelo cambia la tarea.
Esta separación es importante. Una tabla de tarifas es verificable externamente, mientras que la eficiencia de un modelo depende del repositorio y del trabajo solicitado.
El rendimiento de la caché también depende del comportamiento de la sesión. Los prefijos de prompts estables y el trabajo continuo ayudan al servicio a reutilizar contenido procesado previamente.
Varias acciones pueden interrumpir ese patrón. Cambiar de modelo hace que la primera solicitud del nuevo modelo procese la conversación bajo una caché distinta.
Cambiar determinados ajustes mediante un proveedor de nube o gateway también puede reducir la reutilización. Conectar un nuevo servidor de herramientas durante una sesión puede alterar la estructura del prompt.
Las pausas largas pueden permitir que el material almacenado en caché expire. El efecto exacto depende de la duración de la caché y de la forma en que se enruten las solicitudes.
Las escrituras en caché añaden otra salvedad. Escribir material nuevo en la caché cuesta más que leerlo posteriormente.
La calculadora excluye deliberadamente las escrituras en caché de su comparación simplificada. Esto hace que la herramienta sea útil para comprender las principales variables, pero no es un simulador completo de facturas.
Por tanto, la primera pasada por un repositorio grande puede seguir siendo cara. Los ahorros se acumulan cuando los turnos posteriores reutilizan lo que el modelo ya procesó.
La compactación introduce otra compensación. Sustituye el material de conversación anterior por un resumen más corto, reduciendo el contexto reenviado en solicitudes posteriores.
Sin embargo, la compactación también crea un nuevo estado de prompt. La solicitud inmediata debe procesar ese resumen, y puede ser necesario recuperar de nuevo parte del contexto detallado.
Limpiar una sesión entre tareas no relacionadas puede impedir que un contexto antiguo acompañe a un trabajo que ya no lo necesita. Limpiarla durante una tarea coherente puede descartar contexto útil almacenado en caché.
Un cambio de modelo crea un límite similar. Anthropic aconseja cambiar en una pausa natural, cuando el coste de reconstruir el contexto tenga menos probabilidades de borrar la ventaja del modelo.
Los subagentes complican aún más el recibo. Cada subagente posee una ventana de contexto independiente y devuelve un resumen a la conversación principal.
Esa separación puede mantener las búsquedas voluminosas de archivos fuera del contexto principal. Sin embargo, cada subagente sigue consumiendo tokens y hereda un modelo, salvo que se configure de otro modo.
La reducción de caché favorece las sesiones largas y coherentes, pero no convierte las conversaciones interminables en la opción óptima. Las instrucciones antiguas y los resultados irrelevantes de herramientas pueden aumentar cada solicitud posterior.
Los equipos deberían examinar tanto la proporción de caché como la entrada total. Una tasa alta de caché es útil, pero una conversación sobredimensionada aún puede procesar demasiado material.
Una sesión bien gestionada mantiene caliente el contexto reutilizable mientras elimina el trabajo no relacionado. Ese equilibrio importa más en flujos de trabajo con agentes que en chats de respuesta única.
Opus 5.5 frente a Opus 5 es una prueba de carga de trabajo
Los ahorros estimados de Anthropic siguen siendo una proyección del proveedor hasta que los equipos los reproduzcan en sus propias tareas.
La empresa afirma que Opus 5.5 requiere menos capacidad de cómputo para atender solicitudes y genera salida más de un 30% más rápido que Opus 5. También informa de mejores resultados en varios benchmarks internos.
Estos hallazgos respaldan el argumento de una mayor eficiencia de costes. No establecen una reducción universal para bases de código de producción.
Los benchmarks proporcionan comparaciones controladas, mientras que los repositorios reales contienen pruebas incompletas, dependencias inusuales, convenciones internas y requisitos cambiantes. Esos factores modifican el recorrido de un agente.
La variable más incierta es el número de tokens necesarios para terminar un trabajo equivalente. Opus 5.5 puede evitar falsos comienzos, pero el pensamiento adaptativo puede aumentar la salida en algunos prompts.
Su esfuerzo predeterminado es medio, mientras que Opus 5 tenía un valor predeterminado alto. Una comparación que acepta ambos valores predeterminados cambia más que la versión del modelo.
La guía de migración recomienda explícitamente recalibrar el esfuerzo. Mantener una configuración anterior puede producir resultados engañosos.
El modelo también introduce cambios de comportamiento e integración. El razonamiento no puede desactivarse y varios patrones de uso de herramientas requieren actualizaciones.
Las aplicaciones que utilizan una interfaz anterior de uso del ordenador en la API de Claude o Google Cloud deben migrar al conjunto de herramientas más reciente. Algunas configuraciones de elección forzada de herramientas ahora devuelven errores.
El texto de progreso entre llamadas a herramientas también puede llegar mediante bloques de razonamiento. Una interfaz que no gestione esos bloques puede parecer silenciosa durante el trabajo.
Estos cambios no son meros detalles de migración. Las solicitudes fallidas, las herramientas rotas o las visualizaciones de progreso ausentes pueden generar reintentos y elevar el coste operativo de la adopción.
Por tanto, una prueba justa entre Opus 5.5 y Opus 5 debe mantener constante la tarea mientras registra la configuración. Ambas ejecuciones necesitan el mismo estado del repositorio, criterios de aceptación y comando de validación.
Los desarrolladores deberían probar elementos reales del backlog en lugar de prompts de juguete. Una pequeña edición de sintaxis revela poco sobre los bucles de agentes, la reutilización de caché o la recuperación tras un enfoque erróneo.
Entre los candidatos útiles se incluyen un error con una reproducción fiable, una función que abarque varios archivos o una migración con un conjunto de pruebas definido.
Una ejecución no es suficiente. El estado del repositorio, la latencia de las herramientas y el comportamiento no determinista del modelo pueden alterar la ruta seguida durante una tarea.
Tres o cuatro tareas emparejadas ofrecen una muestra inicial más creíble. Los equipos más grandes deberían agrupar los resultados por tipo de tarea, en lugar de informar un único promedio combinado.
Los equipos también deben definir el éxito de forma coherente. Una ejecución que produce código plausible pero no supera las pruebas no debería contar como una finalización más barata.
El tiempo de revisión humana forma parte del análisis operativo, incluso cuando no aparece en el recibo de tokens. Un parche confuso puede consumir tiempo de ingeniería después de que termine la generación.
El informe final de Claude Code puede ayudar a los revisores a entender ejecuciones más largas. Anthropic presenta informes de cierre más claros como otra posible fuente de eficiencia.
Ese beneficio es plausible, pero depende de la carga de trabajo. Los equipos deberían medir si los revisores necesitan menos prompts de seguimiento o dedican menos tiempo a reconstruir las acciones del agente.
La evidencia pública independiente sigue siendo limitada porque Opus 5.5 se lanzó apenas cuatro días antes de este análisis. Los primeros informes de usuarios aún no pueden establecer un promedio estable para el sector.
La conclusión defendible es más acotada. Opus 5.5 tiene tarifas publicadas más bajas, y las tareas con uso intensivo de caché reciben una ventaja estructural mayor.
Que la reducción por tarea completada se aproxime a la estimación de Anthropic depende de los turnos, la salida, el comportamiento de la caché, los reintentos y la calidad de la migración.
Cómo medir el coste de tus propias tareas de Claude Code
El comando `/usage` convierte la afirmación sobre precios en una prueba repetible con tus sesiones reales.
Ejecuta /usage cuando termine una tarea coherente. /cost ofrece la misma vista dentro de Claude Code.
El bloque de sesión informa entrada, salida, entrada en caché y un coste estimado basado en tarifas de lista. Los usuarios de suscripción deberían tratar esa estimación como un indicador de trabajo.
No es una factura adicional de suscripción. Los límites del plan y el uso de API facturado por tokens representan acuerdos de facturación distintos.
Comienza registrando el modelo y la configuración de esfuerzo. Sin esos detalles, dos recibos de sesión pueden parecer comparables mientras representan modos operativos diferentes.
A continuación, registra la definición de la tarea y la prueba de aceptación. Una condición de finalización clara evita que una ejecución se detenga antes que otra.
Después, inspecciona la proporción de caché. Una sesión larga normalmente debería reutilizar una gran parte de su entrada.
Una proporción de caché baja puede indicar pausas, cambios de modelo, cambios de esfuerzo o modificaciones del prompt. También puede reflejar una tarea naturalmente corta o fragmentada.
Compara la entrada total con el mayor contexto observado. Si la entrada total es muchas veces mayor, probablemente la sesión utilizó numerosos turnos.
Esa diferencia no es automáticamente desperdicio. El trabajo de ingeniería en varios pasos necesita de forma natural varias solicitudes, especialmente cuando las pruebas revelan información nueva.
Aun así, la inspección repetida de los mismos archivos puede identificar un bucle evitable. Revisa la transcripción alrededor de esas repeticiones para detectar instrucciones o herramientas de validación ausentes.
La salida merece una comprobación independiente porque incluye razonamiento interno. Una salida elevada ante un pequeño cambio mecánico puede indicar un esfuerzo excesivo o razonamiento repetido.
Para una prueba emparejada, restablece el repositorio al mismo estado inicial. Ejecuta la tarea con Opus 5 y después con Opus 5.5, alternando el orden en las pruebas posteriores.
Registra los turnos, la entrada nueva, las lecturas de caché, la salida, el tiempo transcurrido, los resultados de las pruebas y las correcciones humanas necesarias. Estos campos explican el resultado mejor que un único total.
Utiliza la calculadora solo después de recopilar esas mediciones. Introducir cantidades reales de tokens genera una comparación de tarifas útil.
Mantén su control de eficiencia en cero para el primer cálculo. Eso muestra cómo afectan los cambios en las tarifas publicadas a la misma carga de trabajo de tokens.
Después calcula la diferencia de tokens observada en las ejecuciones emparejadas. Esta segunda vista combina los precios con el comportamiento real del modelo.
No supongas que todas las tareas futuras coincidirán con esa muestra. Separa la depuración, el desarrollo de funciones, la revisión de código, la búsqueda en el repositorio y las ejecuciones de agentes sin supervisión.
El esfuerzo también debería probarse por categoría de tarea. El nivel medio puede encajar con el trabajo diario de alcance definido, mientras que los fallos difíciles pueden justificar un esfuerzo alto.
Un esfuerzo bajo puede ser adecuado para ediciones deterministas, pero solo cuando la verificación hace que los errores sean baratos de detectar. Un intento fallido con esfuerzo bajo debilita cualquier ahorro aparente.
Los equipos que usan gateways necesitan una comprobación adicional. El gateway debe preservar los campos de almacenamiento en caché de prompts y uso, o los informes internos pueden tergiversar la economía de las sesiones.
La documentación de gateways de Anthropic describe el seguimiento centralizado del uso, los presupuestos y la atribución de solicitudes. También advierte que los gateways desactualizados pueden bloquear funciones más recientes.
Las organizaciones más grandes pueden utilizar informes de uso para agregar resultados por desarrollador y modelo. Los totales por usuario siguen siendo insuficientes sin resultados de las tareas.
Una métrica interna útil empareja las tareas completadas con el consumo de tokens. Otra rastrea los reintentos que se producen tras pruebas fallidas o el rechazo del revisor.
Los equipos pueden guardar notas breves de experimentos junto a las decisiones de ingeniería. Una base de conocimiento técnico con búsqueda puede conservar prompts, configuraciones, resultados y hallazgos de migración.
Ese registro ayuda a distinguir los cambios de modelo de los cambios de proceso. También evita que cada equipo repita el mismo benchmark sin una metodología compartida.
El objetivo no es optimizar cada sesión hasta obtener el recibo más pequeño. Es identificar configuraciones que entreguen código aceptado con un coste y un esfuerzo de revisión predecibles.
Tres señales mostrarán si se mantienen los ahorros
La siguiente prueba es si las tarifas más bajas se traducen en una salida estable y verificada en el trabajo ordinario de ingeniería.
La primera señal son los datos emparejados de /usage procedentes de proyectos reales. Reducciones repetidas en depuración, desarrollo de funciones y revisión reforzarían el argumento del coste por tarea.
Esas comparaciones deberían publicar categorías de tokens y criterios de éxito. Un porcentaje destacado sin proporción de caché, esfuerzo y reintentos no puede explicar qué cambió.
La segunda señal es la estabilidad de la caché durante sesiones largas. Los equipos deberían observar si Opus 5.5 mantiene una alta reutilización de caché entre llamadas a herramientas, compactación y transiciones de modelo.
Las proporciones de caché consistentemente bajas debilitarían la ventaja esperada. Sugerirían que el diseño del flujo de trabajo o la infraestructura impiden que los usuarios alcancen la tarifa de caché favorable.
La tercera señal es la frecuencia de reintentos tras la migración. Opus 5.5 cambia los valores predeterminados de esfuerzo, el comportamiento del razonamiento y varias interfaces de herramientas.
Menos bucles fallidos respaldarían la afirmación de Anthropic de que el modelo completa el trabajo con mayor eficiencia. Más errores de integración podrían eliminar temporalmente los ahorros publicados.
Los desarrolladores también deberían resistirse a reducir la comparación únicamente a Opus 5. Los modelos Claude más pequeños pueden seguir siendo más adecuados para búsquedas, lectura de registros y resúmenes económicos.
La decisión relevante es la asignación de cargas de trabajo. Opus 5.5 puede servir como modelo principal para programación supervisada, mientras que los modelos más pequeños gestionan la recuperación acotada.
Las tareas difíciles y sin supervisión pueden justificar un modelo más capaz si evita múltiples fallos. La ruta exitosa más barata puede comenzar con un modelo de mayor coste.
La calculadora de Anthropic mejora esta discusión al mostrar las variables detrás de la estimación. No resuelve el resultado para un equipo concreto.
El coste por tarea de Claude Opus 5.5 es menor con un uso igual de tokens, especialmente cuando las lecturas de caché dominan la entrada. La reducción exacta sigue siendo una cuestión empírica.
Elige un elemento real del backlog, define su prueba de aprobación y ejecútalo una vez con cada modelo. Compara /usage, turnos, salida, proporción de caché y correcciones de revisión.
Repite ese proceso con varios tipos de tareas antes de cambiar un valor predeterminado para todo el equipo. Si Opus 5.5 termina con menos reintentos, la reducción de tarifas se acumula.
Si consume más razonamiento o interrumpe una integración, el ahorro destacado se reducirá. El próximo mes de mediciones emparejadas en producción importará más que cualquier ajuste preestablecido de la calculadora.
