Optimización de costo e inteligencia

Cuando una carga de trabajo pasa de prototipo a producción, el costo se convierte en una restricción de diseño de primer orden. El modelo más capaz puede ser demasiado caro a escala, y el modelo menos costoso puede quedarse corto en calidad. Gestionar bien el costo significa entender cómo cada palanca de costo afecta la calidad del resultado, porque algunas palancas se intercambian por calidad y otras no. La Claude Platform te da control directo sobre ese intercambio. Tú eliges el modelo, el nivel de esfuerzo y la arquitectura para cada solicitud, lo que te permite ubicar una carga de trabajo casi en cualquier punto de la frontera costo-inteligencia.

El costo y la inteligencia suelen representarse como una frontera donde uno compra al otro. El primer grupo de palancas de esta página mueve una carga de trabajo hacia esa frontera al reducir el costo sin tocar la calidad; solo el segundo grupo se mueve a lo largo de ella:

Las palancas son de dos tipos:

• Ganancias gratuitas reducen el gasto sin tocar la calidad: el "prompt caching" (almacenamiento en caché de prompts), la higiene de tokens, una auditoría de prompts contra el modelo que estás ejecutando, el "batch processing" (procesamiento por lotes) con 50% de descuento para trabajo que puede esperar hasta 24 horas, y los límites de gasto del espacio de trabajo como respaldo.
• Compensaciones intercambian costo por inteligencia: elección de modelo, esfuerzo, topes de salida y presupuestos de tarea, y arquitecturas multimodelo.

Cada palanca viene con resultados medidos y la regla de cuándo conviene. En las mediciones de Anthropic, el almacenamiento en caché de prompts fue la palanca más grande por un amplio margen: redujo el costo del bucle de agente por un factor de 2.7 a 5.3 en los benchmarks de esta guía y redujo la factura de un pequeño agente de triaje en un 83%, o un 88% al agregar el recorte de entrada. Las palancas multimodelo son más estrechas; un segundo modelo rindió frutos en dos formas, un asesor y un orquestador.

Empieza aquí

Haz coincidir tu situación con una fila.

Estos resultados son internos de Anthropic (Benchmarks referenciados) y orientativos, no garantías, así que mide en tu propia carga de trabajo con el método de cuatro pasos.

Reduce el gasto sin perder calidad

El almacenamiento en caché de prompts, la higiene de tokens, el procesamiento por lotes y una auditoría de prompts contra tu modelo actual reducen lo que pagas sin reducir la calidad del resultado. Aplican dos advertencias: el procesamiento por lotes intercambia latencia por su descuento, y la edición de contexto, una palanca de higiene de tokens, costó más de lo que ahorró en la ejecución medida en esta sección.

Almacena en caché el contexto repetido

Por qué el almacenamiento en caché va primero

Activa el almacenamiento en caché de prompts antes que cualquier otra palanca, porque cada turno de una tarea agéntica reenvía toda la conversación creciente: la "system prompt" (indicación del sistema), las definiciones de herramientas y cada turno anterior. Una tarea de 40 turnos envía su primer turno 40 veces, así que el costo de la tarea crece aproximadamente con el cuadrado del número de turnos. El almacenamiento en caché no detiene el reenvío, pero cada reenvío cuesta aproximadamente una décima parte y se procesa más rápido: el prefijo se factura a la tarifa de lectura de caché, una décima parte del precio de entrada, y cada turno paga la tarifa de escritura de caché de 1.25x solo por lo que es nuevo.

Cómo se ve un buen resultado. Durante un día completo de tráfico real, los bucles de agente leyeron una mediana del 84% de su entrada desde la caché, y el 10% superior de los arneses, de programación o no, leyó el 94% o más¹⁷. En lo profundo de una tarea, un bucle bien construido paga el precio completo por menos del 1% de su entrada. Por debajo de aproximadamente el 80%, busca algo que esté rompiendo la caché (consulta Qué rompe la caché).

En las ejecuciones medidas por Anthropic, las lecturas de caché son rutinariamente el componente individual más grande del costo de la tarea, lo que hace que el almacenamiento en caché valga más que la mayoría de las decisiones de elección de modelo. Anthropic calculó el precio de las ejecuciones de DeepResearch Bench II⁷ con y sin almacenamiento en caché:

La vida útil predeterminada de la caché es de 5 minutos y los turnos de un bucle de agente están separados por segundos, así que el descuento aplica a la mayoría de los tokens en cada turno. Las ejecuciones del gráfico de almacenamiento en caché leyeron del 79% al 90% de sus tokens de entrada desde la caché. El ahorro varía con la profundidad del episodio, porque los bucles más cortos releen menos, pero el almacenamiento en caché se mantuvo como la palanca individual más grande en cada modelo y benchmark medido.

Elige la duración de la caché

Si tu bucle espera a una persona entre turnos, usa la duración de caché de 1 hora. Cuesta más escribirla (2x el precio de entrada en lugar de 1.25x). Un fallo de caché en cualquiera de las dos duraciones factura todo el prefijo al precio de escritura en lugar del precio de lectura, así que la duración más larga rinde frutos una vez que unos pocos turnos por sesión siguen a una pausa de entre 5 minutos y una hora.

Para decidir, cuenta los intervalos entre solicitudes consecutivas en una conversación:

• Más de aproximadamente 1 intervalo de cada 20 cae entre 5 minutos y una hora, y los intervalos de más de una hora son raros: usa la duración de 1 hora.
• Los turnos llegan con segundos de separación: quédate con el predeterminado de 5 minutos. Cuando nada se pausó, costó 15% menos que la configuración de 1 hora en Claude Sonnet 5 y 11% menos en Claude Opus 5.
• Los intervalos de más de una hora son comunes: quédate con el predeterminado. Un intervalo de más de una hora expira ambas duraciones, y la configuración de 1 hora entonces reescribe el prefijo a su precio de escritura más alto, así que pierde en cada uno de esos intervalos. De tus pausas de más de 5 minutos, si aproximadamente el 60% o más también superan una hora, quédate con el predeterminado; la duración de 1 hora solo conviene cuando al menos aproximadamente el 40% de las pausas largas terminan dentro de la hora.

Anthropic midió el trabajo de triaje de Recorta tokens de entrada y de contexto con pausas insertadas antes de algunos turnos para simular la demora de una persona¹⁶. En ambos modelos medidos, la caché de 1 hora se convirtió en la configuración más barata una vez que aproximadamente 1 turno de cada 30 siguió a una pausa, así que la regla de 1 de cada 20 deja un margen, y la brecha se amplía rápidamente pasado el punto de cruce porque cada turno pausado en la configuración de 5 minutos reescribe todo el prefijo. Todos los modelos actuales usan los mismos multiplicadores de escritura de caché, y todos los modelos excepto Claude Fable 5.1 y Claude Mythos 5.1 el mismo precio de lectura, así que el punto de cruce está en el mismo rango en los otros modelos; Fable 5.1 es el caso que se cubre a continuación. La precisión se mantuvo dentro del ruido entre ejecuciones en cada celda. El turno después de una pausa mantuvo su latencia de caché caliente en la configuración de 1 hora. El siguiente gráfico traza el costo por sesión contra la proporción de turnos pausados en Claude Sonnet 5:

Anthropic también midió solicitudes extra que mantienen caliente la caché de 5 minutos. En Claude Sonnet 5 y Claude Opus 5 no ahorraron nada medible respecto a la duración de 1 hora en ninguna proporción de turnos pausados y costaron más con una pausa antes de cada turno, así que usa la duración en su lugar.

En Claude Fable 5.1 la configuración más barata es otra. Su lectura de caché cuesta 0.025x el precio de entrada ($0.25 por millón de tokens) mientras que sus escrituras de caché mantienen los multiplicadores estándar, así que una solicitud de mantenimiento que relee el prefijo es barata y la prima de escritura de la duración de 1 hora es la factura más grande. Anthropic midió el trabajo de triaje en Claude Fable 5.1 con las mismas tres configuraciones¹⁹. Mantener caliente la caché de 5 minutos costó de 13% a 20% menos por sesión que la caché de 1 hora siempre que las pausas duraron minutos; solo con pausas cercanas a 45 minutos ganó la caché de 1 hora, por aproximadamente 12 centavos por sesión. En Claude Fable 5.1, mantén caliente la caché de 5 minutos mientras una persona se ausenta por minutos, y compra la duración de 1 hora cuando las pausas se acerquen a una hora:

Para mantener caliente la caché, envía de nuevo la solicitud anterior con max_tokens establecido en 0 dentro de los 4 minutos posteriores al inicio de la solicitud anterior, y cada 4 minutos después de eso, quitando stream si estaba establecido. Cuenta desde el inicio de la solicitud, no desde el final de su respuesta: la vida útil de 5 minutos de la caché corre desde el inicio de la solicitud que escribió o refrescó la entrada, así que el tiempo que la respuesta pasó generando cuenta en su contra. Esa es la solicitud de precalentamiento: refresca la vida útil de la caché, no genera nada y factura solo la lectura de caché. No cambies ni un byte del prefijo, y no uses max_tokens: 1, que muestrea un token sin motivo. Reenvía los encabezados de la solicitud además de su cuerpo: si tus solicitudes llevan un encabezado anthropic-beta (para un presupuesto de tarea, por ejemplo), la solicitud de mantenimiento necesita el mismo encabezado, o los campos restringidos por beta en el cuerpo reenviado se rechazan. Una solicitud con max_tokens: 0 se rechaza cuando la solicitud establece thinking.type: "enabled" (el pensamiento adaptativo predeterminado en Claude Fable 5.1 está bien), salidas estructuradas o una elección de herramienta forzada (sus limitaciones); en esas cargas de trabajo, compra la duración de 1 hora en su lugar.

# Dentro de los 4 minutos desde el inicio de la última solicitud (el tiempo de generación cuenta
# contra la vida útil de la caché), reenvía esa solicitud con max_tokens establecido en
# 0, quitando stream (una solicitud con max_tokens: 0 no puede usar streaming). Envía los mismos
# encabezados que la solicitud original, incluido cualquier encabezado anthropic-beta.
jq '.max_tokens = 0 | del(.stream)' last_request.json | \
  curl https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    --data-binary @-

Activa el almacenamiento en caché

La configuración requiere poco trabajo. El almacenamiento en caché automático coloca los puntos de interrupción por ti; de lo contrario, la skill de Claude API que viene con Claude Code puede agregar almacenamiento en caché a una integración existente desde un solo prompt. El siguiente extracto muestra la skill agregándolo al arnés que produjo estas mediciones:

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

Esas ubicaciones de puntos de interrupción siguen el patrón estándar de Puntos de interrupción de caché explícitos.

Qué rompe la caché

Varias cosas pueden romper tu caché durante una tarea. Cualquier cosa que cambie por solicitud, como una marca de tiempo o una posición en la cola, colocada antes del prefijo estable convierte cada solicitud en una escritura de caché completa: en la ejecución de triaje de Recorta tokens de entrada y de contexto, una línea de estado de 25 tokens al frente de la indicación del sistema costó $4.24 por ejecución en lugar de $0.59, más que ejecutar con el almacenamiento en caché desactivado. Mantén el texto por solicitud en el turno de usuario más reciente.

La caché es una coincidencia de prefijo exacta a nivel de byte sobre la solicitud en orden (herramientas, luego indicación del sistema, luego mensajes), así que un cambio en cualquier lugar invalida todo lo que viene después. Cambiar effort o la configuración de pensamiento entre solicitudes invalida la caché desde ese punto en adelante, y en algunos modelos también las herramientas y la indicación del sistema que están antes; cualquier edición a la indicación del sistema invalida la caché desde ese punto en adelante; establecer o cambiar un formato de salida invalida la caché para toda la conversación; agregar, quitar o reordenar una definición de herramienta la invalida toda. La página de almacenamiento en caché de prompts enumera estos casos, aparte del formato de salida, que cubre salidas estructuradas. En los modelos más recientes, cambia las instrucciones con un mensaje de sistema a mitad de conversación, un mensaje {"role": "system"} agregado a messages, en lugar de editar el campo system de nivel superior: el prefijo en caché permanece intacto. Consulta esa página para ver qué modelos lo admiten. En los modelos que lo admiten, un cambio de esfuerzo por mensaje también deja intacto el prefijo en caché. Lo que está en juego es mayor en Claude Fable 5.1 y Claude Mythos 5.1: una ruptura reescribe el prefijo a 1.25x el precio de entrada en lugar de leerlo a 0.025x, así que en un prefijo de 100,000 tokens un turno roto cuesta $1.25 en lugar de $0.03, 50 veces la lectura, frente a 12.5 veces ($0.63 en lugar de $0.05) en Claude Opus 5.

Anthropic midió esto en las sesiones largas del agente de triaje¹⁸. Un cambio de esfuerzo y una herramienta agregada hechos a mitad de sesión reescribieron 39,000 y 60,000 tokens en caché, y esas sesiones costaron $0.95 por sesión. Los mismos dos cambios en la primera solicitud después de la compactación costaron $0.75, y en la solicitud que activó la compactación $0.92, porque el pase de resumen de la compactación entonces reprocesó el contexto de 81,000 tokens al precio de escritura de caché: ese pase de resumen costó $0.21, frente a $0.04 cuando los mismos cambios llegaron una solicitud después, con la precisión dentro del ruido entre ejecuciones en cada brazo:

Cambiar un presupuesto de tarea a mitad de camino invalida cualquier prefijo en caché que contenga el valor del presupuesto, así que establécelo una vez, en la primera solicitud. Cada pase de edición de contexto invalida el prefijo desde el punto que limpia y la siguiente solicitud paga por volver a almacenar en caché todo lo que viene después, así que limpia en unos pocos lotes grandes en lugar de muchos pequeños. En Claude Fable 5.1 y Claude Mythos 5.1 cada uno de estos cuesta 50 veces el precio de lectura por token, así que importan más ahí. Haz cada cambio que invalide la caché en pausas naturales, luego confirma que las lecturas de caché no hayan caído; si lo han hecho, los diagnósticos de caché muestran dónde divergió el prefijo.

Recorta tokens de entrada y de contexto

La mayoría de las solicitudes de agente llevan tokens que nunca influyen en la respuesta. Recortarlos rara vez cuesta calidad del resultado, aunque no todas las palancas aquí ahorraron dinero cuando se midieron. Dos lugares donde buscar:

• Recorte de entrada. El filtrado dinámico en la herramienta de obtención web mantiene el texto repetitivo fuera de las páginas obtenidas, el redimensionamiento de imágenes ajusta el tamaño de las entradas de visión, y la búsqueda de herramientas con carga diferida carga las definiciones de herramientas solo cuando se necesitan (medido más adelante en esta sección). La llamada programática de herramientas permite que Claude ejecute varias llamadas de herramientas desde código para que solo el resultado filtrado entre al contexto; su documentación reporta 24% menos tokens de entrada en benchmarks de búsqueda agéntica, con una puntuación más alta. Gestiona el contexto de herramientas compara la búsqueda de herramientas, la llamada programática de herramientas, el almacenamiento en caché de prompts y la edición de contexto.
• Ciclo de vida del contexto. La edición de contexto limpia resultados de herramientas obsoletos, y la compactación automática con su umbral evita que los bucles largos arrastren todo su historial.

Las palancas interactúan con la caché y entre sí, así que júzgalas por su efecto neto, y usa los diagnósticos de caché para confirmar que tu prefijo en caché sobrevive a cada cambio. Anthropic las midió en un agente de triaje de issues que trabajó con 20 reportes de errores reales con capturas de pantalla de un repositorio público, y en una variante más larga del mismo trabajo con 2.6 veces los tokens. Con el almacenamiento en caché activado, el recorte de entrada (redimensionamiento de imágenes y búsqueda de herramientas) quitó un 26% adicional a la ejecución corta y un 21% a la larga.

Difiere las definiciones de herramientas no usadas

Cada definición de herramienta adjunta a una solicitud es entrada en cada turno, y unos pocos servidores MCP suman cientos de ellas. Anthropic ejecutó el agente de triaje con sus propias dos herramientas más un catálogo de definiciones de herramientas reales de servidores MCP públicos, para un total de hasta 502 herramientas, cargándolas todas o marcando las extras con defer_loading detrás de la búsqueda de herramientas:

Con cada definición cargada, el costo de la ejecución casi se duplicó a medida que crecía el catálogo, siguiendo los tokens de esquema en cada solicitud. Con la búsqueda de herramientas se mantuvo plano en cada tamaño de catálogo, 45% menos con 502 herramientas. La precisión fue de 15 a 18 de 20 en cada celda de cualquier manera, y el modelo nunca llamó a una herramienta equivocada, así que a esta escala el catálogo cuesta dinero, no corrección. Lo mismo aplica para las herramientas que llegan a través del conector MCP: con un servidor MCP público de GitHub adjunto, diferir su conjunto de herramientas (default_config: {defer_loading: true}) redujo la ejecución un 20% con la misma precisión.

Mantén los archivos de datos fuera del prompt

Cuando el modelo tiene que calcular sobre una tabla, súbela con la Files API y deja que el modelo la consulte con ejecución de código en lugar de pegarla. Anthropic hizo 25 preguntas de agregación¹⁵ (sumas, conteos filtrados, agrupaciones y un filtro de fecha) sobre un CSV público de 1,862 filas, con las respuestas calculadas por pandas:

Pegada en el prompt, la tabla son aproximadamente 91,000 tokens de entrada en cada solicitud, y Claude Sonnet 5 respondió correctamente 6 de 25 preguntas. Subida, con ejecución de código, respondió las 25, y la ejecución costó aproximadamente una doceava parte. Claude Opus 5 mostró el mismo patrón.

Gestiona el ciclo de vida del contexto

Las palancas de contexto solo convienen en una sesión lo suficientemente larga para necesitarlas:

En la ejecución de 20 issues no ahorraron nada, y la edición de contexto costó 74% más. En la ejecución larga la poda ahorró 39% y la compactación 32%, mientras que la edición de contexto no cambió nada. La poda son unas pocas líneas que escribes tú mismo: en cada límite de tarea, reemplaza los resultados de herramientas grandes y obsoletos con un extracto de una línea. Se almacena bien en caché porque las ediciones quedan en la cola de la conversación, donde la siguiente tarea agrega contenido nuevo de todos modos: 89% de lecturas de caché en la primera solicitud después de un límite y 81% en las solicitudes entre límites. A lo largo de toda la ejecución, la poda y la edición de contexto se almacenan en caché aproximadamente igual de bien. La poda es más barata porque la edición de contexto reescribe a mitad de tarea contenido que la poda elimina (aproximadamente dos tercios de la brecha) y porque mantiene el contexto aproximadamente a la mitad del tamaño (el otro tercio). Si usas edición de contexto, limpia en unos pocos lotes grandes. La poda, adaptada del arnés:

import re

PRUNED = "[pruned at issue boundary]"


def prune_task_boundary(messages, tool_name_by_id, threshold=2000):
    """Call once per task boundary. Replaces large, stale search results with a one-line extract."""
    for message in messages:
        if message["role"] != "user" or not isinstance(message["content"], list):
            continue
        for block in message["content"]:
            if not (isinstance(block, dict) and block.get("type") == "tool_result"):
                continue
            if tool_name_by_id.get(block.get("tool_use_id")) != "search_issues":
                continue
            result_text = block.get("content")
            if not isinstance(result_text, str) or len(result_text) <= threshold:
                continue
            if result_text.startswith(PRUNED):
                continue  # already pruned on an earlier boundary
            # limita los resultados de una sola línea para que el extracto sea breve
            first_line = result_text.split("\n", 1)[0].strip()[:200]
            refs = re.findall(r"#(\d+)", result_text)[:5]
            extract = f"{PRUNED} {first_line}"
            if refs:
                extract += " kept refs: " + " ".join("#" + r for r in refs)
            block["content"] = extract

Procesa por lotes el trabajo que puede esperar

La Batch API quita 50% a cada token de una solicitud, incluidos los que están en caché, a cambio de que los resultados lleguen en cualquier momento dentro de 24 horas. Enruta a través de un lote cada solicitud que nadie esté esperando, y mantén la ruta interactiva para el resto. El procesamiento por lotes es la segunda palanca gratuita más grande después del almacenamiento en caché para trabajo de agente no supervisado: ejecuciones de evaluación, rellenos retroactivos y trabajos programados como una ejecución recurrente del agente de triaje de issues de la medición de recorte de tokens. Se combina con todo lo de esta página excepto la interactividad, pero no está disponible para sesiones de Claude Managed Agents, que son interactivas por diseño (consulta precios de Claude Managed Agents).

Audita los prompts contra el modelo actual

Cada generación de modelos responde a los prompts de manera diferente, así que un prompt acumula texto escrito para un modelo que ya no usas. El caso habitual es una instrucción demasiado específica agregada para compensar un modelo más antiguo: "verifica dos veces", "sé lo más exhaustivo posible", un procedimiento paso a paso obligatorio o un bloc de razonamiento hecho a mano. Un modelo más nuevo las sigue al pie de la letra, produciendo rondas de herramientas extra y escritura extra, así que la factura sube sin ganancia en precisión. Auditar los prompts contra el modelo que ejecutas ahora, y de nuevo cada vez que cambies de modelo, es una ganancia gratuita.

La auditoría es un solo comando. La skill de Claude API que viene con Claude Code tiene un comando prompt-audit que lee los prompts y el código de solicitud de un proyecto y reporta lo que fue escrito para un modelo diferente. Este extracto abreviado lo muestra ejecutado contra un prompt de mesa de soporte y código de solicitud que contienen esos patrones:

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

El comando luego propone sus ediciones como un diff (se muestra un fragmento) y enumera lo que deliberadamente dejó intacto: la ventana de reembolso, el requisito de tono y el estándar de calidad. Revisas un parche, no una reescritura.

El efecto es medible. En una evaluación de mesa de soporte¹⁴, los prompts escritos para Claude Opus 4.8 costaron 36% más por ticket en Claude Opus 5 sin cambio en la precisión. Ejecutar la auditoría sobre los mismos prompts hizo que Opus 5 fuera tanto más barato que la versión sin auditar (en un 14%) como más preciso (97% de los tickets, frente a 92%, una ganancia fuera del ruido). En la migración de Claude Sonnet 4.6 a Claude Sonnet 5, la auditoría quitó un 14% con la misma precisión:

Los dos tipos de texto obsoleto tienen costos diferentes. Las instrucciones que el modelo nuevo sigue demasiado literalmente cuestan dinero: quitar "verifica dos veces" redujo el costo por ticket de Opus 5 en un tercio, y quitar "sé lo más exhaustivo posible" casi lo mismo. El texto que ya no se ajusta al modelo cuesta precisión en cambio: una configuración de pensamiento retirada, reglas contradictorias y un bloc hecho a mano que entra en conflicto con el propio pensamiento del modelo restauraron cada uno de 7 a 11 puntos en Opus 5 al quitarse:

Los mismos patrones tienden a aparecer en descripciones de herramientas y skills, que también vale la pena auditar.

Intercambia costo por inteligencia

Estas palancas establecen dónde se ubica un solo modelo entre costo e inteligencia: elección de modelo, esfuerzo, volver a ejecutar los fallos con una configuración más alta, y los presupuestos y topes dentro de los que trabaja. Empieza con un barrido de esfuerzo en tu modelo actual (Ajusta el esfuerzo). De menor a mayor costo y capacidad, los modelos actuales son Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5 y Claude Fable 5.1 (el modelo de frontera); Resumen de modelos tiene la lista completa y los precios.

Compara modelos por costo por tarea

Las listas de precios se escriben por token, y por token el modelo de frontera parece caro: el precio por token de Claude Fable 5.1 es varias veces el de Claude Sonnet 5. Sin embargo, pagas por tareas completadas, así que compara los modelos por costo por tarea completada. Un modelo más capaz termina una tarea con menos trabajo: menos turnos, menos búsqueda, menos relectura de su propio contexto y menos retrocesos. La prima por token a menudo queda superada por hacer menos de todo.

Anthropic midió esto en el subconjunto de SWE-bench Pro³, con el precio calculado como se le factura a un cliente:

Claude Fable 5.1 con esfuerzo low resolvió el 88.6% de las tareas por $0.54 por tarea resuelta, frente al 77.4% por $0.84 de Claude Sonnet 5 con su predeterminado: 11 puntos más por 35% menos por tarea resuelta, a pesar de un precio por token cinco veces mayor. Sin embargo, no siempre gana. En el mismo subconjunto, que ambos modelos saturan en gran medida y cuyas puntuaciones no son comparables con la tabla de clasificación pública, Claude Opus 5 solo igualó a Claude Fable 5.1 solo con el predeterminado (91.7% comparado con 92.1%, dentro del ruido entre ejecuciones) por aproximadamente 15% menos por tarea resuelta ($1.01 frente a $1.19), y Opus 5 con low resolvió el 84.0% por $0.25. Y en bucles de investigación largos el modelo de frontera hace más trabajo, no menos: en DeepResearch Bench II⁷, Fable 5.1 con low puntuó 10 puntos por encima de Sonnet 5 (66% frente a 56%) a aproximadamente cuatro veces el costo por tarea ($4.66 frente a $1.20), porque ejecuta un bucle de investigación más largo sobre un contexto más grande. Claude Opus 5 con su predeterminado puntuó 71% sobre la misma base por $6.71 por tarea, por encima de Fable 5.1 con su predeterminado (65% por $7.12), así que en investigación también Fable 5.1 justifica su precio solo con low.

Para la mayoría de las cargas de trabajo de agente, empieza con Claude Fable 5.1 con esfuerzo low y aumenta el esfuerzo donde falle. Por token cuesta el doble que Claude Opus 5 en entrada sin caché, pero la mitad en entrada en caché ($0.25 frente a $0.50 por millón), y en un bucle de agente la entrada en caché es el término más grande. En el benchmark de programación de Estrategia de asesor, Fable 5.1 con medium igualó a Opus 5 con su predeterminado por aproximadamente un tercio del costo por intento ($2.91 frente a $8.50). En Chartography¹³, un benchmark de lectura de gráficos, Fable 5.1 con low puntuó 62.5 por $0.15 por gráfico, comparado con 49 por $0.38 de Opus 5 con low. En el subconjunto de SWE-bench Pro, Claude Opus 5 con su predeterminado sigue siendo la forma más barata de llegar a la puntuación máxima, como se señaló antes. En el otro extremo, Claude Haiku 4.5 respondió preguntas de GPQA Diamond⁹ a aproximadamente una décima parte del costo por pregunta de Opus 5, con 63% de precisión comparado con 92% de Opus, y quedó mucho más atrás en tareas de programación largas. Se ajusta a trabajo de alto volumen con resultados verificables, no a bucles agénticos largos.

La clasificación se invierte según la carga de trabajo, y ninguna lista de precios te dice en qué dirección. Calcula el precio de cada candidato en costo por tarea completada sobre tu propio tráfico, incluidos Claude Opus 5 y el modelo de frontera con esfuerzo reducido.

Calcula el precio de la cola de tu carga de trabajo, no de la mediana: compara los modelos en la décima parte más difícil de tus tareas, no en la típica. En la tarea típica todos los modelos se ven similares y el más barato se ve mejor, pero la factura la deciden las tareas en las que el modelo más barato falla, porque una tarea fallida igual factura sus tokens, luego el reintento, luego lo que sea que el fallo cueste aguas abajo. La cola también es adonde va el dinero incluso cuando nada falla. En una ejecución de WideSearch¹ de 20 problemas, dos problemas representaron el 43% del gasto:

Las estrategias multimodelo existen para gastar inteligencia de frontera en esa cola sin pagar tarifas de frontera por el resto.

Actualiza el modelo

Si estás uno o dos modelos atrás, la palanca más barata es la cadena del modelo. Anthropic ejecutó modelos recientes de Claude Opus, Claude Sonnet y Claude Fable a través del mismo arnés en el subconjunto de SWE-bench Pro³, cada uno con sus predeterminados de fábrica y con precios de lista, y ejecutó la línea Opus de nuevo en Terminal-Bench 3²⁰:

Anthropic fija el precio de la línea Opus de forma idéntica por token entre versiones, así que cualquier diferencia proviene de cuánto trabajo hace cada modelo por tarea: con el precio calculado como se le factura a un cliente, Claude Opus 4.8 resuelve la misma proporción de tareas que Claude Opus 4.7 por 14% menos por tarea resuelta, y Claude Opus 5 luego resuelve 12 puntos más de tareas por 21% más por tarea resuelta. Claude Opus 5 con esfuerzo low supera al predeterminado de Opus 4.8 en este benchmark por aproximadamente el 30% de su costo por tarea resuelta, así que la actualización más barata es el modelo nuevo con una configuración más baja. El ahorro de Sonnet 5 proviene de su menor precio por token, que compensa con creces los tokens extra que usa por tarea comparado con Sonnet 4.6: 15% menos por tarea resuelta por 5 puntos más. El nivel de frontera ganó de la misma manera: Claude Fable 5.1 iguala la puntuación de Claude Fable 5 por 43% menos por tarea resuelta, la mayor parte por el menor precio de lectura de caché. Esa dirección no está garantizada: en DeepResearch Bench II⁷ la misma actualización cuesta 41% más por tarea con high (79% más con low) por sus 2 a 3 puntos extra en las tareas limpias en cada brazo (referencia 7), porque el modelo nuevo hace más trabajo por tarea ahí. Los precios de entrada y salida son los mismos y la lectura de caché es 4x más barata, así que mide la actualización en tu propia carga de trabajo antes de asumir que ahorra.

En trabajo más difícil la brecha se amplía. En Terminal-Bench 3²⁰, donde las tareas son lo suficientemente difíciles como para que la tasa de aprobación, y no los tokens, determine la factura, Claude Opus 4.7, Opus 4.8 y Opus 5 gastan cada uno de $8 a $15 por tarea pero resuelven el 7%, 15% y 41% de las tareas, así que el costo por tarea resuelta baja de $183 a $63 a $28 subiendo la escalera. La prima del 21% que Claude Opus 5 tiene sobre Opus 4.8 en el subconjunto de programación saturado se convierte en un ahorro del 56% en Terminal-Bench 3, donde el modelo más antiguo falla en su mayoría: cuanto más tu carga de trabajo derrota al modelo antiguo, más ahorra la actualización por resultado.

Compara por costo por tarea resuelta, no por token: el mismo texto cuesta aproximadamente 30% más tokens en Claude Opus 4.7 y posteriores, así que una comparación por token hace que los modelos más nuevos parezcan más caros por construcción.

Ajusta el esfuerzo

El "effort" (esfuerzo) es la forma más directa de ajustar un modelo a tu tarea. El parámetro effort gobierna cuánto pensamiento, cuántas llamadas a herramientas y cuánta autoverificación realiza el modelo, y el valor predeterminado (high) es adecuado para tareas exigentes. El costo escala con toda esa actividad; la precisión escala solo con la parte que tu tarea necesita. Por debajo del techo del modelo, los niveles de esfuerzo más altos pagan por una profundidad que la tarea nunca usa.

En los benchmarks de investigación y trabajo de conocimiento (WideSearch¹, DeepWideSearch⁶, BrowseComp⁴ y GDPval², todos con Claude Fable 5), la curva de precisión frente a costo es casi plana: low cedió de 1 a 3 puntos a cambio de entre un tercio y la mitad menos de costo por tarea, medium igualó la precisión del valor predeterminado a aproximadamente entre el 70% y el 87% de su costo, y el valor predeterminado no compró nada medible por encima de medium en ninguno de los cuatro. En DeepWideSearch, low también igualó a un orquestador con un trabajador Claude Sonnet 5 a un costo 29% menor: bajar el esfuerzo superó a un cambio de arquitectura.

Los ajustes de esfuerzo más bajos suelen ser más rápidos, lo que importa cuando la "latency" (latencia) es la restricción. En estas ejecuciones, low tomó 4.5 minutos por problema en DeepWideSearch, frente a 7.9 minutos con el valor predeterminado. En el benchmark de corpus, cuya entrada no cabe en ninguna "context window" (ventana de contexto) individual, Fable 5.1 tomó 15.2, 17.5 y 19.9 horas por episodio en low, medium y high.

La programación de horizonte largo es donde el esfuerzo realmente compra precisión. En SWE-bench Pro³, Claude Opus 5 cedió unos 2 puntos en medium por la mitad del costo y unos 8 puntos en low por una cuarta parte: una compensación real, que volver a ejecutar los fallos con mayor esfuerzo convierte de nuevo en un ahorro. Este gráfico traza la precisión frente al costo para los benchmarks de investigación y trabajo de conocimiento y para SWE-bench Pro:

Se derivan dos consecuencias. Primero, traza esta curva para tu propia carga de trabajo antes de añadir un segundo modelo: en estas mediciones internas, una configuración multimodelo que parecía más barata que el modelo único predeterminado costó más que ese mismo modelo con menor esfuerzo. Segundo, esta curva es la línea base de modelo único que cualquier estrategia multimodelo debe superar, por lo que el paso 2 de medir en tu propia carga de trabajo establece líneas base en todos los niveles de esfuerzo.

El trabajo difícil no necesita automáticamente un esfuerzo alto. En DeepResearch Bench II⁷, Claude Fable 5.1 obtuvo casi la misma puntuación en low, medium y high mientras el costo por tarea subía de $4.66 a $7.12, por lo que aumentar el esfuerzo en este caso no incrementa la calidad de la salida de forma notable; en las 21 tareas limpias en cada brazo (referencia 7), Claude Fable 5 también se mantuvo plano a lo largo del esfuerzo, aunque la base de 33 tareas del gráfico, que descarta los intentos interrumpidos de cada modelo, lo muestra subiendo. Mide la curva en el modelo que despliegas, no en el que mediste la última vez:

La descripción de la tarea por sí sola no revela qué tipo de carga de trabajo tienes, así que barre dos o tres niveles de esfuerzo en una muestra de tu propio tráfico y lee la respuesta en la curva. Prueba cada nivel en una sesión separada: cambiar el esfuerzo de nivel superior a mitad de sesión invalida la caché (consulta Almacena en caché el contexto repetido) y distorsiona la comparación. Para los detalles del parámetro, consulta Esfuerzo.

Vuelve a ejecutar los fallos con mayor esfuerzo

Cuando el resultado de una tarea es verificable, la política más barata en la curva de esfuerzo no es un ajuste fijo: ejecuta cada tarea con un ajuste bajo y vuelve a ejecutar solo los fallos con uno más alto.

Anthropic calculó esta política tarea por tarea a partir de las ejecuciones de esfuerzo en el subconjunto de SWE-bench Pro³ de Ajusta el esfuerzo. Con Claude Opus 5 en low, el 16% de las tareas fallaron; con esas vueltas a ejecutar con el valor predeterminado, aproximadamente el 93% aprobaron por unos $0.45 cada una, frente al 91.7% por $0.93 ejecutando todo con el valor predeterminado: la misma tasa de aprobación por la mitad del costo, contando los intentos baratos fallidos. Empezar en medium en su lugar resolvió aproximadamente el 94% por unos $0.61. La mayor parte de la pequeña mejora es el segundo intento (volver a ejecutar los propios fallos del valor predeterminado con el valor predeterminado puntúa aproximadamente igual, por más dinero), así que usa esta política por el ahorro, no por la mejora:

Se aplican dos condiciones. Primero, necesitas una señal de fallo (aquí, las propias pruebas del benchmark); un verificador que aprueba trabajo malo deja pasar esos fallos. Segundo, cada fallo de primera pasada toma el tiempo de reloj de dos ejecuciones, por lo que el ahorro se paga en latencia en los fallos.

Establece presupuestos y límites de salida

La mayoría de las ejecuciones de tareas agénticas son baratas, pero una minoría gasta muchas veces el costo mediano en buscar, volver a verificar y probar en exceso. Un presupuesto de tarea apunta a esa cola. El modelo ve una cuenta regresiva de tokens en vivo para toda la tarea y se autorregula, recortando búsquedas de bajo valor, omitiendo verificaciones redundantes y concluyendo en lugar de entrar en espiral.

Anthropic midió la tasa de aprobación y el costo por tarea en SWE-bench Pro³ con Claude Fable 5.1 a medida que el presupuesto se ajustaba:

Un presupuesto generoso redujo el costo por tarea un 44% por unos 3 puntos de tasa de aprobación, al borde del ruido entre ejecuciones, y el presupuesto más ajustado permitido lo redujo un 58% por 6 puntos. Los presupuestos compraron eficiencia aquí, a un precio en tasa de aprobación que crece a medida que el presupuesto se ajusta.

Tres controles hacen tres trabajos diferentes. Un presupuesto de tarea ahorra dinero, porque el modelo lo ve. max_tokens es un límite de seguridad: bajarlo redujo el costo por intento sin bajar el costo por tarea resuelta. En Claude Managed Agents, un presupuesto de sesión es el tope duro en dólares detrás de ambos. Establece los tres: un presupuesto de tarea, un max_tokens alto y un límite de sesión para la ejecución que nunca quieres ver en una factura, con un límite de gasto del espacio de trabajo como respaldo final.

• Los presupuestos de tarea están en beta (encabezado beta task-budgets-2026-03-13) en los modelos más recientes; consulta la tabla de soporte para ver cuáles. Empieza cerca del uso de tokens del percentil 90 de tu bucle y luego ajusta (Elegir un presupuesto muestra cómo recopilar esa distribución). Los presupuestos por debajo del piso actual de 20,000 tokens se rechazan, y los presupuestos muy ajustados pueden producir un comportamiento similar al rechazo. Establece el presupuesto una vez, en la primera solicitud, porque un cambio a mitad de tarea invalida la caché. El presupuesto es orientativo, guía al modelo en lugar de detenerlo, así que verifica el cumplimiento en tu carga de trabajo.
• max_tokens limita una sola respuesta, de forma invisible para el modelo, por lo que bajarlo no hace que el modelo economice. Los turnos que necesitaban el espacio se descartan y aun así se facturan. En un benchmark interno de tareas de repositorio¹², un límite de 16,384 tokens terminó el 15% de los intentos de Claude Opus 5 y el 43% de los de Claude Fable 5.1 con el esfuerzo predeterminado, y solo 9 de los 117 intentos limitados de Fable aun así aprobaron. Las ejecuciones limitadas gastaron menos por intento pero compraron proporcionalmente menos resoluciones, por lo que el costo por tarea resuelta fue aproximadamente el mismo que con 64,000 ($21 frente a $22). Con 64,000, 2 de unos 14,000 turnos con el esfuerzo predeterminado aún se cortaron, y Fable 5.1 resolvió el 58.5% de las tareas en lugar del 36.3% (en un corte separado del subconjunto de SWE-bench Pro³, descrito en la referencia 12, sin diferencia: 94 de 100 con cualquiera de los dos límites). Reintentar los intentos limitados rara vez ayuda: con el mismo límite la mayoría vuelve a fallar, y con uno más alto también pagas por el intento desperdiciado. Establece max_tokens en 64,000 para trabajo agéntico, o en 128,000, el máximo, cuando un solo intento cortado es costoso; con 128,000 Fable 5.1 resolvió el 60.0% por el mismo costo por tarea resuelta. Transmite por streaming las respuestas de ese tamaño, trata stop_reason: max_tokens como un fallo y ahorra dinero con el esfuerzo y los presupuestos de tarea, que el modelo puede ver.
• Los presupuestos de sesión en Claude Managed Agents son el tope duro. Un presupuesto de sesión es un límite en dólares para una sesión a tarifas de lista para tokens, búsquedas y tiempo de sesión. Al llegar al límite, la sesión se pausa con stop_reason: budget_reached; aumentar el presupuesto la reanuda. Lo aplica la plataforma, funciona en cualquier modelo con precio de lista, incluidos los modelos donde los presupuestos de tarea aún no están disponibles, y se combina con el presupuesto de tarea orientativo. Los despliegues aplican el mismo campo a cada ejecución.

Pide respuestas más cortas. Los tokens de salida cuestan cinco veces más que los tokens de entrada en Claude Sonnet 5, y en un bucle de agente cada token que el modelo escribe vuelve como entrada en cada turno posterior, por lo que pagas por una respuesta larga una y otra vez. Anthropic ejecutó el trabajo de triaje bajo tres instrucciones de respuesta final, tres ejecuciones cada una, con el mismo modelo y las mismas herramientas. La original pedía dos líneas:

4. Finish with exactly two lines:
LABEL: <one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish>
SUMMARY: <one or two sentences for the engineering team>

La variante más corta pedía una:

4. Finish with exactly one line in this form:
DECISION | LABEL | REASON
where DECISION is one of: triage-now, needs-info, close-duplicate; LABEL is one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish; REASON is one clause under 15 words. Output nothing after that line.

La variante más larga pedía un memorando con cinco secciones con encabezado: resumen del problema, evidencia, verificación de duplicados, etiqueta recomendada y próximos pasos. Para un issue, un prompt en cola que nunca se envía después de una pregunta omitida, las dos primeras respuestas fueron:

LABEL: bug-confirmed
SUMMARY: When a user submits a new prompt instead of answering an agent's pending question, the question is cancelled/skipped but the new prompt remains stuck in "QUEUED" state indefinitely since it's waiting on a response to the now-cancelled question; the queued prompt should be processed immediately after cancellation.

triage-now | bug-confirmed | Clear repro steps show prompt queues indefinitely after cancelled question.

La respuesta de una línea usó un 39% menos de tokens de salida que la original de dos líneas y costó un 14% menos por ejecución. El memorando usó seis veces los tokens de salida y costó 2.8 veces la respuesta de una línea. Las tres puntuaron dentro del ruido entre ejecuciones unas de otras frente a las etiquetas de referencia, por lo que los formatos difieren mucho más en lo que pagas que en lo que aciertan. Pide la respuesta que vas a leer, no la que parece exhaustiva.

Con el límite de max_tokens más bajo, ambos modelos gastan menos por intento pero resuelven proporcionalmente menos tareas, por lo que el costo por tarea resuelta apenas se mueve:

Casi todos los turnos terminan muy por debajo de cualquiera de los dos límites. El turno largo poco frecuente es lo que compra el límite más alto:

Combina modelos

Las arquitecturas multimodelo se adaptan a cargas de trabajo cuya complejidad de tareas varía lo suficiente como para que distintos pasos se atiendan mejor con distintos modelos. Cuando tu tráfico mezcla trabajo rutinario que un modelo más pequeño maneja de forma confiable con pasos más difíciles que necesitan capacidad de frontera, dividir el trabajo mantiene la inteligencia de frontera donde importa mientras la mayoría de los tokens se facturan a tarifas de modelo más pequeño. Cuando una carga de trabajo carece de esa mezcla, porque su dificultad es uniforme o es una sola cadena dependiente, un único modelo bien ajustado suele ser la mejor opción. Cada sección de estrategia da la regla para distinguir los dos casos.

Dos estrategias cubren la mayoría de las cargas de trabajo, y difieren en qué modelo sostiene el bucle principal:

Estrategia de asesor: escala las decisiones difíciles

En la estrategia de "advisor" (asesor), un modelo "executor" (ejecutor) de menor costo ejecuta el bucle del agente y realiza la mayoría de los turnos. Cuando llega a una decisión que necesita un juicio más profundo, como elegir un enfoque o recuperarse de un fallo, llama a un modelo asesor de mayor inteligencia para obtener orientación estratégica y luego continúa. La mayoría de los tokens se facturan a tarifas del ejecutor, y solo las consultas ocasionales a tarifas del asesor.

Para usarla, añade la herramienta de asesor a tu solicitud. Esta función beta ejecuta toda la estrategia del lado del servidor en una sola solicitud /v1/messages: el ejecutor emite una llamada a herramienta, Anthropic ejecuta la inferencia del asesor y el ejecutor continúa con el consejo; no escribes código de orquestación. En Claude Managed Agents, dale a la sesión un asesor añadiendo una entrada advisor a la lista multiagent del agente; el hilo principal de la sesión lo consulta de la misma manera. Claude Code también lo admite; consulta escalar decisiones difíciles con la herramienta de asesor.

Qué determina el beneficio. El asesor ve la tarea solo a través de las llamadas del ejecutor, por lo que dos cosas deciden cuánto ayuda.

La primera es la brecha entre los modelos. El asesor solo puede entregar capacidad que el ejecutor no tiene: en GPQA Diamond⁹ un ejecutor Claude Haiku 4.5 ganó mucho con un asesor Claude Opus 5, un ejecutor Claude Sonnet 5 ganó unos pocos puntos y un ejecutor de frontera casi nada.

La segunda, y la frágil, es si el ejecutor realmente pregunta (la tasa de consulta). Un ejecutor con esfuerzo bajo puede dejar de detectar que está atascado: un emparejamiento que consulta en la mayoría de las tareas con el esfuerzo predeterminado puede caer a consultar en casi ninguna cuando se baja el esfuerzo, y entonces puntúa por debajo del ejecutor solo. La tasa también varía según la tarea: en DeepSWE¹⁰ un ejecutor Sonnet 5 con esfuerzo bajo siguió preguntando y ganó 23 puntos; en SWE-bench Pro³ el mismo ejecutor dejó de hacerlo. Cuando el ejecutor sí pregunta, recupera gran parte de la brecha. En los emparejamientos del siguiente gráfico cuyo ejecutor siguió preguntando, el asesor cerró al menos la mitad de la brecha con el modelo más fuerte (el emparejamiento de programación superó directamente al modelo más fuerte), y pagas por el modelo más fuerte solo en las consultas, que es lo que hace posibles los casos de costo:

La tasa de consulta responde al prompting. Con solo la descripción integrada de la herramienta, los ejecutores llaman de menos, especialmente en trabajo de programación, por lo que la documentación de la herramienta de asesor da una "system prompt" (indicación del sistema) que pide una llamada antes del trabajo sustantivo y una antes de terminar, unas dos a tres llamadas por tarea. El emparejamiento de programación medido a continuación se ejecutó con esa cadencia, unas dos consultas en cada tarea. Esa página también cubre cómo empujar a un ejecutor que llama de menos y cómo limitar las llamadas del lado del cliente para acotar el costo. Así que vigila la tasa de consulta: pídela en el prompt, mídela y restaura el esfuerzo del ejecutor si colapsa.

Cuándo compensa en costo. Un asesor ahorra dinero cuando unas pocas consultas cortas, facturadas a la tarifa del asesor, reemplazan ejecutar el modelo del asesor durante toda la tarea. Eso funciona mejor cuando el modelo del asesor tiene un precio muy por encima del del ejecutor, por lo que la configuración más rentable es un asesor de frontera sobre un ejecutor de nivel medio. Un emparejamiento puede sostenerse incluso en la parte alta del rango, porque el consejo también ahorra tokens del ejecutor: un ejecutor al que se le indica el enfoque correcto explora menos callejones sin salida, lo que puede cubrir las consultas.

En un benchmark interno de programación agéntica¹¹, ejecutado con un agente de API simple, un ejecutor Claude Opus 5 con un asesor Claude Fable 5.1 fue la configuración más precisa medida, a $7.69 por intento. Se sitúa por encima de la línea que pasa por los propios ajustes de esfuerzo de cada modelo: 3.5 puntos sobre Opus 5 solo con el ajuste predeterminado por un poco menos de dinero, una brecha que cinco intentos por tarea sí separan del ruido, y unos 2.5 puntos sobre el modelo del asesor solo por aproximadamente la mitad más de dinero:

Una medición anterior a través del modo asesor de Claude Code produjo el mismo orden. Lee este resultado como una forma a probar en tu carga de trabajo: el asesor compra unos pocos puntos a aproximadamente el propio precio del ejecutor. Una brecha de capacidad más amplia no garantiza un mejor trato. El costo en latencia son las propias consultas: unas dos llamadas adicionales al modelo de frontera por tarea en este benchmark, cada una en la ruta crítica de la tarea.

Cuándo el modelo más fuerte solo es el mejor paso. Donde la precisión de una carga de trabajo responde al esfuerzo, compara el emparejamiento con el modelo del asesor solo con un ajuste reducido antes de construirlo: el asesor se paga solo en las tareas que lo necesitan, pero una consulta que se dispara en la mayoría de las tareas cuesta más que ejecutar el propio modelo más fuerte. En Chartography¹³ el mismo emparejamiento igualó a Claude Fable 5.1 solo en medium dentro del ruido entre ejecuciones (65.0 frente a 67.5) a unas 2.6 veces el costo por tarea, porque el asesor fue consultado en casi todas las tareas. Mide primero tu propia tasa de consulta: si el ejecutor pregunta en la mayoría de sus tareas, estás pagando tarifas de asesor en toda la carga de trabajo, y ejecutar el propio modelo del asesor es la forma más barata de llegar a la misma puntuación.

Sea cual sea el emparejamiento, primero calcula el precio del modelo del asesor solo con esfuerzo bajo; esa es la línea base a superar. Vuelve a comprobarlo en cada lanzamiento de modelo, porque los lanzamientos mueven tanto la brecha de capacidad como la relación de precios.

Cuándo encaja. La estrategia de asesor se adapta a cargas de trabajo donde los turnos son mayoritariamente mecánicos pero un plan excelente importa: agentes de programación, uso de computadora y pipelines de investigación de varios pasos. Encaja mal cuando cada turno realmente necesita capacidad de frontera, cuando no hay nada que planificar (preguntas y respuestas de un solo turno) o cuando tu ejecutor ya está cerca de la capacidad del asesor.

Estrategia de orquestador: delega el trabajo masivo

En la estrategia de "orchestrator" (orquestador), el modelo de frontera sostiene el bucle. Descompone la tarea, despacha subtareas a modelos "worker" (trabajadores) de menor costo y fusiona sus resultados. La propia transcripción del orquestador se mantiene corta porque los trabajadores absorben la exploración intensiva en tokens, por lo que la mayoría de los tokens se facturan a tarifas de trabajador mientras el plan y la síntesis siguen viniendo del modelo de frontera.

Para construir uno, usa la orquestación multiagente en Claude Managed Agents: configura un agente coordinador (el orquestador) y una lista de agentes trabajadores, cada uno con su propio modelo. Para un ejemplo funcional completo con un coordinador de frontera y trabajadores Claude Sonnet 5, consulta la receta del Claude Cookbook Coordinator pattern: big models for planning, small models for execution.

Este patrón ahorra tiempo de reloj cuando los trabajadores pueden ejecutarse en paralelo: en el benchmark de corpus⁸, un episodio tomó unas 2.3 horas con el coordinador ejecutando el límite documentado de la plataforma de 25 trabajadores concurrentes, frente a 15 a 20 horas en solitario. Ahorró dinero solo en dos situaciones medidas. En trabajo que un solo modelo podía manejar por sí mismo, el mismo modelo con menor esfuerzo fue más barato cada vez.

Caso 1: seguro contra la cola de costos en trabajo rutinario. Un modelo de frontera ejecutándose solo ocasionalmente entra en espiral en un problema rutinario que normalmente resolvería. Como no puedes saber de antemano cuáles serán, unas pocas de esas ejecuciones dominan la factura. Un coordinador que entrega el trabajo rutinario a un trabajador de menor costo limita esa cola, porque cualquier espiral ahora ocurre a tarifas de trabajador.

Anthropic midió esto en una porción deliberadamente fácil de BrowseComp⁴ (10 problemas que el modelo en solitario resuelve de forma confiable; 50 ejecuciones delegadas y 70 en solitario). Un coordinador Claude Fable 5 con un trabajador Claude Sonnet 5 costó aproximadamente la mitad que Claude Fable 5 solo en promedio y aproximadamente un tercio en el percentil 90 ($12 frente a $33), y la ejecución individual más cara del modelo en solitario, a $84, también fue incorrecta:

La delegación compensó en la parte rutinaria y normalmente resoluble del trabajo, lo opuesto a la intuición de que los trabajadores son para problemas difíciles. En el conjunto completo y más difícil de BrowseComp, la economía se invirtió. Si tu tráfico tiene una cola de costos larga en tareas rutinarias, este es el caso de orquestador que debes medir primero.

Caso 2: trabajo más grande que una ventana de contexto. Un modelo en solitario debe procesar una entrada de ese tamaño en serie, una ventana de contexto a la vez, pagando por volver a leer su propio estado en cada pasada. Los trabajadores leen cada uno su propia partición, en paralelo y a tarifas de trabajador. El trabajo intensivo en lectura que aún cabe en una ventana de contexto es un problema de elección de modelo, no de delegación: solo en costo de lectura, el orquestador sale ganando únicamente cuando ningún contexto individual puede contener el trabajo.

Anthropic construyó un benchmark para este caso⁸: un corpus de 21.6 millones de tokens de 14 paquetes públicos de Python con 130 defectos plantados, demasiado grande para cualquier ventana de contexto. Bajar el esfuerzo no puede ayudar, porque la factura es la propia lectura del corpus: Claude Fable 5.1 en solitario costó de $468 a $552 por episodio en los tres ajustes de esfuerzo, y solo se movió su precisión. La configuración de coordinador, un líder Claude Fable 5.1 sobre 25 trabajadores Claude Sonnet 5, costó aproximadamente la mitad que esos ajustes (entre un 47% y un 55% menos) y puntuó de 10 a 12 puntos por debajo de ellos, en unas 2.3 horas por episodio frente a 15 a 20, mientras superaba directamente a una línea base de Claude Sonnet 5 en solitario:

La contabilidad de tokens muestra la escala de la lectura: la configuración de coordinador leyó unos 560 millones de tokens en caché por episodio, aproximadamente una vez y media los cerca de 365 millones del modelo en solitario, casi todos a la tarifa de lectura de caché de Claude Sonnet 5, y aun así costó aproximadamente la mitad en total. Fable 5.1 con esfuerzo high sigue manteniendo la precisión máxima, a unas 2.2 veces el costo de la configuración de coordinador, por lo que la delegación aquí compra la mayor parte de la precisión, no toda.

Cuándo la delegación no compensa. Un orquestador compra algo solo cuando hay trabajo masivo que entregar: muchas piezas independientes, idealmente demasiadas para una ventana de contexto. Cuando el trabajo es una sola cadena dependiente, o cabe en un solo contexto, el orquestador paga por un plan, una entrega y una fusión que un solo modelo obtiene gratis. En cada caso de ese tipo medido, el modelo del coordinador solo con menor esfuerzo salió ganando.

El límite es la dificultad de la tarea, no el benchmark: en el conjunto completo y más difícil de BrowseComp⁴, Claude Fable 5 solo alcanzó la precisión de la configuración de coordinador a un costo entre un 22% y un 30% menor. Trabajo externo independiente reporta el mismo patrón⁵. Si el trabajo es una sola cadena, cabe en un contexto sin una cola de costos larga, o un solo modelo con menor esfuerzo ya cumple tu estándar, no construyas un orquestador.

Elige entre las estrategias

La mayoría de los casos se reducen a una pregunta: ¿el trabajo se divide en piezas independientes, o es una sola respuesta alcanzada a través de una cadena de pasos dependientes? La tabla de estrategias asigna las dos respuestas a las dos estrategias.

Si no estás seguro, no construyas nada todavía:

1. Barre primero el esfuerzo en tu modelo actual. Es el experimento más barato de esta página, y la mayoría de las cargas de trabajo terminan ahí.
2. Si el barrido muestra una brecha, calcula el precio del modelo más fuerte solo con esfuerzo bajo. Ese es el número que un emparejamiento de asesor tiene que superar, y los emparejamientos de esta página que lo superaron fueron aquellos cuyo ejecutor realmente consultó.

Los resultados multimodelo de esta página se juzgaron frente al mismo modelo con menor esfuerzo y frente al siguiente modelo inferior ejecutándose solo. Esa es la comparación que debes ejecutar en tu propia carga de trabajo, y la razón por la que el primer paso es un barrido de esfuerzo.

Cuando sí añades un asesor, es una definición de herramienta en lugar de una rearquitectura.

Mide en tu propia carga de trabajo

Los números de esta página reflejan precios de lista en el momento de la medición y se desviarán a medida que cambien los modelos y los precios. Tu tasa de escalamiento, qué tan limpiamente se dividen las tareas y la longitud de la transcripción también los mueven. El método sigue siendo el mismo:

1. Extrae unas pocas tareas de los registros de producción, ponderadas como el tráfico real, y escribe verificaciones de resultado para cada una: las pruebas pasan, el ticket se cierra, el conteo de filas es correcto. Registra el costo por tarea junto a la puntuación: calcula el precio de los cinco conteos de tokens con precio en el usage de cada respuesta a sus propias tarifas (entrada sin caché, escrituras de caché de 5 minutos y 1 hora a 1.25x y 2x el precio de entrada, lecturas de caché y salida), sumados en todas las solicitudes de la tarea (la API de uso y costo reporta el agregado).
2. Establece la línea base de los niveles de modelo en todos los niveles de esfuerzo, no solo el predeterminado, y traza la puntuación frente al gasto. Una configuración multimodelo debe superar toda la curva del modelo único.
3. Si la curva muestra una brecha que el esfuerzo no puede cerrar, añade la estrategia multimodelo que encaje y vuelve a ejecutar la suite.
4. Ejecuta al ganador en modo sombra en una porción del tráfico antes del cambio, y luego mantén la suite en ejecución.

El siguiente ejemplo calcula el costo del paso 1 de una solicitud a los precios de lista de Claude Opus 5:

# Precios por millón de tokens de la página de precios; cambia estos tres para otro modelo.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
# 0.1x el precio de entrada; 0.025x en Claude Fable 5.1 y Claude Mythos 5.1
CACHE_READ_PER_MTOK = 0.50
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cache_writes = usage.cache_creation
writes_1h = cache_writes.ephemeral_1h_input_tokens if cache_writes else 0
writes_5m = cache_writes.ephemeral_5m_input_tokens if cache_writes else 0
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Las escrituras en caché de 1 hora se facturan a 2x el precio de entrada, las de 5 minutos a 1.25x; las lecturas al precio de lectura de caché.
    + writes_1h * INPUT_PER_MTOK * 2.0
    + writes_5m * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * CACHE_READ_PER_MTOK
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

En los bucles de agente, el término de lectura de caché suele ser el mayor de los cinco; si no, comprueba que el almacenamiento en caché esté activo. Cuando la herramienta de asesor o la compactación están habilitadas, algunos tokens se reportan solo en usage.iterations y no en los totales de nivel superior, así que suma sobre usage.iterations en su lugar, calculando el precio de las entradas advisor_message a las tarifas del modelo asesor.

La siguiente tabla enumera las palancas en el orden en que debes probarlas:

Benchmarks referenciados

Excepto donde una referencia indique lo contrario, las mediciones son ejecuciones internas de Anthropic de estos benchmarks. A menos que se indique, los costos están en USD a los precios de lista vigentes cuando se ejecutó cada benchmark; las cifras de Claude Sonnet 5 usan $2 y $10 por millón de tokens de entrada y salida. Los gráficos etiquetados como "notional USD" (USD nocionales) valoran los conteos de tokens de cada solicitud a esas tarifas en lugar de reportar facturas.

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. Tareas amplias de investigación web calificadas según la completitud y precisión de una tabla de muchas filas; 200 problemas, 3 ejecuciones por configuración, ejecutadas del 1 al 2 de agosto de 2026. El gráfico de concentración de costos es una ejecución separada de 20 problemas, 3 ejecuciones por problema, ejecutada del 3 al 4 de agosto de 2026, con costos calculados a partir de registros de facturación por solicitud.
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. Entregables de trabajo de conocimiento calificados contra rúbricas de tareas; una ejecución de 210 tareas del conjunto gold publicado, un intento por tarea, ejecutada el 2 de agosto de 2026. Un modelo Claude califica, por lo que las puntuaciones absolutas pueden diferir de los resultados publicados.
3. SWE-bench Pro: Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025. Un subconjunto de 482 problemas seleccionado por compatibilidad con el arnés de evaluación de Anthropic; las puntuaciones no son comparables con la tabla de clasificación pública. Claude Opus 5 con el esfuerzo predeterminado promedia dos ejecuciones; las configuraciones de esfuerzo reducido son ejecuciones únicas; todas se ejecutaron el 4 de agosto de 2026. Las cifras de escalamiento provienen tarea por tarea de esas ejecuciones: low primero, luego el predeterminado en sus fallos, resolvió del 92.5% al 93.6% entre emparejamientos de ejecuciones por aproximadamente $0.45; medium primero, del 93.8% al 94.2% por aproximadamente $0.61; el predeterminado reejecutado en sus propios fallos, 94.0% por $1.06; todo con el predeterminado, del 90.9% al 92.5% por $0.93. Los costos en este subconjunto se valoran como se mide la organización de un cliente: el prompt previo de cada solicitud como una lectura de caché y sus tokens nuevos como una escritura de caché de 5 minutos, a partir de los propios registros de uso de las ejecuciones, verificados contra un libro contable de cliente; la propia medición de la organización de evaluación, que factura la caché en páginas de 8,192 tokens, dio cifras de 1.4 a 1.8 veces más altas. Los emparejamientos con ejecutor Claude Sonnet 5 en el gráfico del asesor provienen de la misma serie de mediciones en este subconjunto: el emparejamiento Sonnet más Opus se ejecutó dos veces (7 de agosto y 8 de agosto de 2026, una ejecución y una replicación exacta), el emparejamiento de bajo esfuerzo una vez (8 de agosto de 2026), y Claude Sonnet 5 solo dos veces (77.4%, la línea base para ambas filas de Pro). El punto de Claude Fable 5 en Actualizar el modelo es la media de tres ejecuciones con el esfuerzo predeterminado, ejecutadas el 26 de agosto de 2026, valoradas de la misma manera. Las cifras de presupuesto de tarea de Claude Fable 5.1 son una ejecución por presupuesto (dos a 35,000 tokens) en el mismo subconjunto con el esfuerzo predeterminado, ejecutadas el 26 de agosto de 2026, con una ejecución sin presupuesto el mismo día (92.1%, $1.10 por tarea) como línea base; un conjunto anterior con esfuerzo low, ejecutado el 21 de agosto de 2026, obtuvo 88.6% sin presupuesto a $0.48 por tarea. La comparación de Comparar modelos empareja esa ejecución única con las dos ejecuciones agrupadas de Claude Sonnet 5 del mismo subconjunto; con el esfuerzo predeterminado de Fable 5.1 el par se lee al revés, 41% más por tarea resuelta que Sonnet 5. La escalera de actualización es una ejecución por modelo con sus valores predeterminados de lanzamiento (dos cada uno para Opus 5 y Sonnet 5, y el punto de Fable 5 como se describió arriba), las ejecuciones de Opus y Sonnet la misma semana en un mismo arnés y organización.
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. Las cifras de esfuerzo usan un corte de 500 problemas, de una a tres ejecuciones por configuración, ejecutadas el 3 de agosto de 2026, con el punto predeterminado agrupando dos ejecuciones del 26 al 27 de julio de 2026. El gráfico de seguro de costos usa 10 problemas resueltos de forma confiable de una porción de 26 problemas, 50 ejecuciones delegadas (del 1 al 2 de agosto de 2026) y 70 ejecuciones en solitario (50 del 2 al 3 de agosto de 2026; 20 archivadas del 12 al 13 de julio y del 1 de agosto de 2026), $6.45 comparado con $11.99 por ejecución en expectativa; las cifras delegadas tienen una banda de medición de aproximadamente 20%.
5. Escalamiento de arquitectura de agentes: Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025. Estudio externo independiente, citado solo por la dirección del hallazgo sobre cuándo la delegación no compensa, no por ninguna cifra.
6. DeepWideSearch: "DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025. Las 220 preguntas abarcan 15 dominios, cada una combinando recolección de muchas filas con recuperación de múltiples saltos; medido en el conjunto de filas vigente del benchmark, 3 ejecuciones por configuración, ejecutadas el 2 de agosto de 2026 (el punto del equipo de un solo trabajador se ejecutó del 26 al 27 de julio de 2026).
7. DeepResearch Bench II: Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026. Sus 132 tareas de investigación en 22 dominios se califican contra rúbricas binarias derivadas de expertos; medido en un subconjunto de 50 tareas estratificado entre todos los temas, un intento por tarea, 3 ejecuciones por configuración, en Claude Managed Agents con las propias herramientas de búsqueda web y fetch de la plataforma (del 26 al 27 de agosto de 2026); puntuado en las 33 tareas que ninguna configuración rechazó, con los intentos que los clasificadores de seguridad de producción interrumpieron eliminados; los costos son lo que se factura a un cliente, las solicitudes de la plataforma más las tarifas de búsqueda web. Las puntuaciones son la media de cada modelo sobre la base de 33 tareas con sus propias tareas interrumpidas eliminadas; en las 21 tareas limpias en cada brazo, Claude Fable 5.1 mantiene una ventaja de 2 a 3 puntos sobre Claude Fable 5 en cada nivel de esfuerzo y ambos modelos se mantienen planos a través del esfuerzo. El gráfico de caché revalora las mismas solicitudes con cada token de entrada a la tarifa sin caché. Claude Opus 4.6 juzga bajo el protocolo de rúbricas del benchmark; el original usa un juez diferente, y un juez de Anthropic puede favorecer el estilo de la casa. Claude Opus 5 con su esfuerzo predeterminado se ejecutó en la misma superficie y subconjunto, tres ejecuciones, el 28 de agosto de 2026: 68.8% en las 50 tareas brutas, 70.8% sobre la base de 33 tareas y 71.1% en el conjunto de 21 tareas, a $6.71 por tarea ($23.72 sin caché); ninguno de sus intentos fue interrumpido por los clasificadores de seguridad, bajo un despliegue de salvaguardas más reciente que aquel bajo el cual se ejecutaron los otros modelos.
8. Barrido de defectos en corpus: Interno de Anthropic, para trabajo más grande que una ventana de contexto: un corpus de 21.6 millones de tokens de 14 fuentes públicas de paquetes de Python con 130 defectos plantados y calificación determinista; protocolo fijado antes de las ejecuciones y revisado internamente; tres ejecuciones por configuración. Cada configuración se ejecutó en Claude Managed Agents. La configuración de equipo graficada es una ejecución en la que el coordinador Claude Fable 5.1 ejecutó todo el barrido dentro de la plataforma en su límite documentado de 25 trabajadores Claude Sonnet 5 concurrentes, ejecutada el 30 de agosto de 2026; sus tres episodios obtuvieron F1 de 0.764, 0.825 y 0.791 después de la auditoría de extras (brutos 0.751, 0.821 y 0.781) por $225, $234 y $283. La configuración de Claude Sonnet 5 en solitario se ejecutó del 3 al 4 de agosto de 2026; las configuraciones de Claude Fable 5.1 en solitario se ejecutaron del 24 al 25 de agosto de 2026, bajo los ajustes de servicio de lanzamiento de la plataforma, tres semillas por configuración de esfuerzo, en la misma compilación del corpus. La imagen del sandbox contenía copias instaladas de parte del corpus, y el paso de ensamblaje final de Claude Fable 5.1 comparó contra ellas en 7 de 9 episodios; recalificar sin esas adiciones movió las semillas afectadas hasta 3 puntos. El F1 absoluto es específico de esta compilación del corpus, no comparable entre benchmarks; las comparaciones de configuración son equivalentes entre sí.
9. GPQA Diamond: Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023. El subconjunto Diamond de 198 preguntas, dos ejecuciones por configuración, ejecutadas el 7 de agosto de 2026, calificado por modelo contra respuestas de referencia, tokens del asesor medidos por solicitud. Una verificación de seguridad de la plataforma rechazó dos preguntas de biología en los ejecutores Sonnet y Opus; excluirlas no cambia ninguna comparación en más de un punto.
10. DeepSWE: Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026. El conjunto tiene 113 tareas originales en cinco lenguajes con verificadores basados en programas. Los emparejamientos son dos ejecuciones cada uno, ejecutadas el 7 de agosto de 2026, con tokens del asesor medidos por solicitud, y usaron un bucle de asesor del lado del cliente en lugar de la herramienta de asesor, con contabilidad idéntica. Los barridos de esfuerzo de un solo modelo son ejecuciones únicas valoradas a partir de conteos de tokens, una aproximación consciente de la caché. Los costos por tarea son los totales de ejecución divididos por 113.
11. Benchmark interno de codificación agéntica: Interno de Anthropic: 370 tareas de repositorio calificadas por las propias pruebas de los repositorios. Las cifras de la API se midieron con un límite de salida de 128,000 tokens, una ejecución por configuración: Opus 5 solo con el esfuerzo predeterminado del 9 al 10 de agosto de 2026, Claude Fable 5.1 solo con cinco valores de esfuerzo establecidos explícitamente el 20 de agosto de 2026, y el emparejamiento del 24 al 25 de agosto de 2026. Intentos por tarea: cinco para el emparejamiento y el control de Opus solo, uno para los puntos de un solo modelo; el emparejamiento promedió aproximadamente dos consultas al asesor por intento; los costos son por intento. Las cifras de Claude Code son ejecuciones de las mismas tareas del 8 al 23 de julio de 2026, una ejecución por configuración, costos aproximados.
12. Benchmark interno de tareas de repositorio (medición de límite): Un conjunto interno de Anthropic separado de aproximadamente 130 tareas de repositorio, ejecutado del 8 al 10 de agosto de 2026 (Claude Opus 5) y el 20 de agosto de 2026 (Claude Fable 5.1), con un bucle de agente de API simple, un intento por tarea. Las ejecuciones de Claude Fable 5.1 son 135 tareas por límite con el esfuerzo predeterminado establecido explícitamente: la cifra de 16,384 tokens promedia dos ejecuciones (36.3% en ambas); las cifras de 64,000 y 128,000 son ejecuciones únicas (58.5% y 60.0%). Seis problemas provocaron un rechazo de seguridad en cada ejecución y cuentan como fallos. La cifra de 16,384 tokens de Opus 5 promedia dos ejecuciones y su cifra de 64,000 es una ejecución única (124 tareas puntuadas). Las cifras de límite de SWE-bench Pro son una ejecución de Claude Fable 5.1 por límite con el esfuerzo predeterminado, ejecutadas el 26 de agosto de 2026, en un subconjunto de 100 problemas estratificado del conjunto de 482 problemas de la referencia 3, no comparable con sus puntuaciones; los dos límites obtuvieron la misma puntuación con el predeterminado. Las distribuciones por turno del gráfico provienen de la ejecución de Opus a 64,000 y la ejecución de Claude Fable 5.1 a 128,000; ningún turno de Opus alcanzó su límite, y un turno de Fable 5.1 alcanzó 128,000 (0.46% de sus turnos excedieron 16,384).
13. Chartography: Surge AI, "Chartography," 2026. El conjunto completo publicado de 100 preguntas, medido del 8 al 10 de agosto de 2026, con la implementación de Anthropic en Claude Managed Agents (sandbox en la nube estándar; las configuraciones de asesor usan el asesor de Managed Agents). Claude Sonnet 4.6 califica en lugar del juez de referencia y el benchmark se ejecuta con herramientas, por lo que las puntuaciones se comparan entre configuraciones aquí pero no con la tabla de clasificación publicada. Dos ejecuciones por configuración, agrupadas; las dispersiones entre ejecuciones fueron de 4 a 10 puntos. Los costos excluyen el tiempo de sandbox, que agregó menos del 1%. Las ejecuciones de Claude Fable 5.1 en solitario son del 24 de agosto de 2026, bajo los ajustes de servicio de lanzamiento de la plataforma, dos ejecuciones por configuración; seis intentos alcanzaron el límite de sesión de 15 minutos y puntúan 0, y dos gráficos por ejecución fueron respondidos por Claude Opus 5 después de un rechazo de seguridad. El ejecutor Claude Opus 5 de bajo esfuerzo con un asesor Claude Fable 5.1 se ejecutó dos veces el 30 de agosto de 2026, bajo los mismos ajustes (63.0 y 67.0, media 65.0, a $0.72 por gráfico; el asesor fue consultado en el 88% de las tareas en cada ejecución, y 4 de sus 219 respuestas provinieron de Claude Opus 5 en su lugar, cada una después de que un filtro de seguridad de producción detuviera la propia respuesta del asesor). La comparación de tasa de consulta para los emparejamientos anteriores proviene de reejecutar las mismas configuraciones en la Messages API con un conjunto de herramientas de contenedor, del 10 al 11 de agosto de 2026.
14. Evaluación de auditoría de prompts de mesa de soporte: Un conjunto construido por Anthropic de 44 tickets de soporte con calificación determinista, ejecutado a principios de agosto de 2026 y reportado el 8 de agosto de 2026, bajo seis indicaciones del sistema, cada una agregando al mismo prompt limpio un patrón común en prompts escritos para Claude Opus 4.8 y Claude Sonnet 4.6. Cada punto del gráfico es uno de tres casos (modelo anterior, modelo más nuevo con el mismo prompt, modelo más nuevo después de la auditoría) promediado sobre los seis prompts y 44 tickets. La ganancia de precisión de Opus 5 tiene un intervalo de confianza del 95% de 3 a 8 puntos; las diferencias de precisión de Sonnet están dentro del ruido.
15. Conjunto de preguntas sobre archivo de datos: Un conjunto construido por Anthropic de 25 preguntas agregadas sobre una porción de 1,862 filas de un CSV público de ventas de licores, con la verdad de referencia calculada por pandas y calificación de coincidencia exacta, ejecutado en Claude Sonnet 5 y Claude Opus 5 con el pensamiento deshabilitado (el brazo en contexto no puede completarse con el predeterminado), un límite de salida de 4,000 tokens y sin almacenamiento en caché de prompts, tres ejecuciones por configuración, ejecutadas el 19 de agosto de 2026. El brazo de archivo sube el CSV a través de la Files API y usa la herramienta code_execution_20260120.
16. Medición de duración de caché: El trabajo de triaje de 20 issues de Recortar tokens de entrada y contexto, ejecutado el 23 de agosto de 2026, en Claude Sonnet 5 y Claude Opus 5 en la Messages API con el mismo arnés, las celdas de Claude Opus 5 con max_tokens elevado a 4,096, con pausas insertadas antes de una proporción de turnos elegida aleatoriamente (ninguna, 5%, 10% y cada turno a 6 minutos en los 20 issues en ambos modelos, más cada turno a 2 minutos en Claude Sonnet 5; pausas de 20 minutos en un subconjunto de 5 issues en ambos modelos; pausas de 45 minutos en un subconjunto de 5 issues solo en Claude Sonnet 5). Tres ejecuciones por celda, costo calculado a partir de los campos usage de cada respuesta en una organización facturada como cliente a precios de lista, precisión contra las mismas etiquetas gold. El punto de cruce es aproximadamente el 3.3% de los turnos en ambos modelos: la mediana de la proporción de equilibrio de cada sesión, calculada por el modelo de costos a partir de los tamaños de contexto turno por turno de esa sesión, sobre las 45 sesiones de veinte issues de Claude Sonnet 5 y las 36 de Claude Opus 5 en el análisis (cada programa de pausas ejecutado en el trabajo completo, bajo las tres configuraciones de caché, tres ejecuciones cada una; las celdas de 5 issues no están incluidas). La celda del 5% empató en Claude Sonnet 5 porque las pausas de ese sorteo cayeron en prefijos pequeños. La regla de 1 en 20 de la página se sitúa por encima del punto de cruce medido. Anthropic midió solicitudes keep-alive que refrescan la caché de 5 minutos solo como comparador. En el mejor de los casos igualaron la configuración de 1 hora y costaron más con una pausa antes de cada turno, así que no las uses en estos dos modelos; en Claude Fable 5.1 la aritmética se invierte (referencia 19).
17. Proporción de lecturas de caché en producción: Uso agregado de primera parte de la Claude API durante los 14 días que terminan el 23 de agosto de 2026, solo el producto de API directa, organizaciones internas de Anthropic excluidas, ninguna organización identificada. Un día-organización cuenta como un bucle de agente cuando sus solicitudes llevan definiciones de herramientas y resultados de herramientas, sus prompts contienen 9 o más llamadas a herramientas previas en promedio, se usó caché, y realizó al menos 10 solicitudes de ese tipo (la API no tiene identificador de conversación, por lo que esto sustituye a la longitud de la conversación): 303,003 días-organización en 106,487 organizaciones, proporción mediana de lecturas de caché del 84.2% de todos los tokens de entrada, cuartil superior 91.7%. Las etiquetas de caso de uso (el caso de uso declarado de la organización, o de lo contrario su caso clasificado) cubren el 74% de esos días-organización y el 99% de sus tokens; las organizaciones de codificación aportan el 87% de los tokens de entrada agénticos y leen una mediana del 88.5% (90.9% con 25 o más llamadas a herramientas previas), cuartil superior 93.4%, con aproximadamente el 72% de los días-organización de codificación en 80% o más; los agentes de soporte, investigación y datos leen del 84% al 85%. El decil superior de días-organización lee 95.9% o más para codificación y del 94.2% al 94.8% para agentes de soporte, investigación, datos y otros. La división a nivel de solicitud con 25 o más llamadas a herramientas previas proviene de una muestra de seis horas: codificación 92% lectura, 7% escritura, menos del 1% sin caché. Las organizaciones sin etiqueta, en su mayoría pequeñas, leen una mediana del 11%. Los días-organización sin definiciones de herramientas leen una mediana del 34.6%. Una consulta independiente sobre la misma ventana que reconstruye conversaciones de 10 o más solicitudes, en lugar de puntuar días-organización, sitúa la mediana en 90.2%; la diferencia es de alcance, no de datos.
18. Medición del momento de compactación: La variante larga del agente de triaje de Recortar tokens de entrada y contexto, ejecutada el 24 de agosto de 2026, en Claude Sonnet 5 con la caché de 5 minutos, costo a partir de los campos de uso a precios de lista, cinco sesiones por brazo: un brazo sin cambios con el esfuerzo predeterminado en todo momento ($0.81 por sesión), y dos brazos que comienzan con bajo esfuerzo y realizan los mismos dos cambios que rompen la caché, un cambio al esfuerzo predeterminado y una herramienta agregada, ya sea a mitad de sesión en las solicitudes 12 y 17 ($0.95) o juntos en la primera solicitud después de la primera compactación ($0.75). Un cuarto brazo de seis sesiones, ejecutado el 25 de agosto de 2026, realizó los mismos dos cambios en la solicitud que activó la primera compactación ($0.92 por sesión): el pase de resumen de esa solicitud escribió el contexto de 81,000 tokens en la caché en lugar de leerlo, por lo que ese pase costó $0.21 frente a $0.04 para el mismo pase en el brazo de frontera. Las sesiones se compactaron por primera vez en las solicitudes 21 a 25 (16 de las 21 sesiones en la solicitud 22), una vez que el prompt superó el disparador de compactación de 80,000 tokens, y dos sesiones sin cambios se compactaron una segunda vez cerca del final. El total más bajo del brazo de frontera respecto al brazo sin cambios refleja sus solicitudes de bajo esfuerzo antes del cambio y esas segundas compactaciones más que el almacenamiento en caché: los costos de reescritura de los dos brazos difieren en menos de un centavo. El brazo de mitad de sesión pagó $0.23 por sesión en reescrituras de caché; la diferencia entre los brazos de mitad de sesión y de frontera fue de $0.20 con un intervalo de confianza del 95% de $0.11 a $0.29. Una sesión de mitad de sesión resultó barata ($0.82) después de que su modelo llamara incorrectamente a la herramienta de búsqueda tras la compactación y obtuviera resultados vacíos; está incluida, y sin ella el brazo promedia $0.98. La precisión promedió 14.2 de 20 etiquetas en cada brazo del 24 de agosto y 14.7 en el brazo del 25 de agosto; las lecturas de caché fueron el 91% de los tokens de prompt sin cambios, 85% a mitad de sesión, 91% en la frontera y 86% con los cambios en la solicitud activadora.
19. Medición de duración de caché en Claude Fable 5.1: El mismo trabajo de triaje de 20 issues y arnés que la referencia 16, ejecutado el 23 de agosto y el 26 de agosto de 2026, en el snapshot de lanzamiento de Claude Fable 5.1 a sus precios de lanzamiento ($10 entrada, $12.50 escritura de 5 minutos, $20 escritura de 1 hora, $0.25 lectura de caché, $50 salida por millón de tokens), tres configuraciones por programa: la caché de 5 minutos, la caché de 1 hora y la caché de 5 minutos mantenida activa por una solicitud max_tokens: 0 sobre el prefijo sin cambios cada 4 minutos de tiempo inactivo (las ejecuciones del 23 de agosto hicieron ping con max_tokens: 1; cada ping del 26 de agosto refrescó la caché y no facturó salida). Programas: sin pausas, 10% de los turnos y cada turno a 6 minutos en los 20 issues, y pausas de 45 minutos en el subconjunto de 5 issues; tres ejecuciones por celda, costo calculado a partir de los campos usage de cada respuesta a precios de lista, precisión contra las mismas etiquetas gold (de 12 a 17 etiquetas exactas de 20). Medias por sesión el 26 de agosto para las configuraciones de 5 minutos, 1 hora y keep-alive: sin pausas $2.42, $3.09, $2.29; 10% pausado $4.50, $2.96, $2.36; cada turno $22.89, $3.01, $2.62; las celdas del 23 de agosto coinciden dentro del 6%. Las cifras de 45 minutos ($1.68, $0.59 y $0.71 por sesión de 5 issues) son de una reejecución limpia el 26 de agosto después de que un incidente de facturación de caché arruinara las primeras celdas de ese día; las ejecuciones del 23 de agosto dieron $1.67, $0.58 y $0.70. El punto de cruce entre las configuraciones de 5 minutos y 1 hora es el 3.1% de los turnos, la misma medida que la referencia 16.
20. Terminal-Bench 3: las 74 tareas del benchmark público de agentes de terminal, ejecutadas en Claude Managed Agents con dos herramientas personalizadas, un shell y un editor de archivos que el arnés de evaluación ejecuta en el propio contenedor de cada tarea, en lugar de las herramientas integradas de la plataforma, y por lo demás con los ajustes predeterminados de la plataforma para cuentas externas, dos ejecuciones por modelo con esfuerzo high, del 27 al 28 de agosto de 2026. Las puntuaciones son tasas de aprobación brutas sobre los 148 intentos por modelo; las ejecuciones únicas varían de 5 a 11 puntos. Los costos son lo que se facturaría a un cliente a precios de lista, revalorados solicitud por solicitud a partir de los registros de uso de las ejecuciones con la duración de caché de 5 minutos. Claude Opus 4.7 terminó 11 de sus 148 intentos en su límite de salida.

Próximos pasos