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 entre costo e inteligencia.

Las palancas son de dos tipos:

• Ganancias gratuitas reducen el gasto sin tocar la calidad: "prompt caching" (almacenamiento en caché de prompts), higiene de tokens, una auditoría de prompts contra el modelo que estás ejecutando, procesamiento por lotes con 50% de descuento para trabajo que puede esperar hasta 24 horas, y límites de gasto del workspace como respaldo final.
• Intercambios cambian 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.5 a 3.7 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 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

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, por lo 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.

En las ejecuciones medidas de 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 ejecuciones de WideSearch¹ y DeepResearch Bench II⁷ con y sin almacenamiento en caché:

La duración predeterminada de la caché es de 5 minutos y los turnos de un bucle de agente están separados por segundos, por lo que el descuento se aplica a la mayoría de los tokens en cada turno; las ejecuciones graficadas lograron tasas de acierto del 81% al 90%. El ahorro varía con la profundidad del episodio, porque los bucles más cortos releen menos, pero el almacenamiento en caché siguió siendo la palanca individual más grande en cada modelo y benchmark medido.

Si tu bucle espera a humanos 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) pero se paga sola con el primer fallo de caché evitado, porque un fallo reenvía todo el prefijo a precio completo y lo escribe de nuevo.

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 a partir de 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.

Tres configuraciones pueden romper tu caché durante una tarea. Cambiar effort entre solicitudes invalida el prefijo en caché, así que cámbialo solo donde volverías a almacenar en caché de todos modos, como en un límite de compactación. Cambiar un presupuesto de tarea a mitad de camino hace lo mismo, así que establécelo una vez, en la primera solicitud. Cada pasada 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. Haz los tres cambios 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 no cuesta nada en 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 web fetch 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. La llamada programática de herramientas permite a Claude ejecutar 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 hacia adelante.

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 activó las palancas una a la vez para un agente de triaje de issues que trabajaba con 20 reportes de errores reales con capturas de pantalla de un repositorio público (y, para el segundo panel, una variante más larga del mismo trabajo):

El almacenamiento en caché hizo casi todo el trabajo, y el recorte llevó el total al 88%. Cada barra es una ejecución, por lo que diferencias de $0.10 son ruido; las que se muestran aquí no lo son. La compactación necesita una sesión lo suficientemente larga para activarla: la ejecución de 20 issues nunca alcanzó el piso de 50,000 tokens una vez que se recortaron sus entradas, pero en la variante más larga del segundo panel se activó una vez y redujo la factura un 38% adicional.

La edición de contexto es la única palanca aquí que no es gratuita. Cada pasada de limpieza reescribe la conversación en caché, lo que va en contra del almacenamiento en caché de prompts; en esta ejecución, la edición de contexto costó más de lo que ahorró. Úsala para hacer espacio en la ventana de contexto, y limpia en unos pocos lotes grandes.



Procesa por lotes el trabajo que puede esperar

La Batch API descuenta 50% de 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 cada solicitud que nadie esté esperando a través de un lote, 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, por lo 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é máximamente exhaustivo", un procedimiento paso a paso obligatorio o un bloc de razonamiento hecho a mano. Un modelo más nuevo sigue estas instrucciones al pie de la letra, produciendo rondas de herramientas adicionales y escritura adicional, por lo que la factura sube sin ganancia en precisión. Auditar los prompts contra el modelo que ejecutas ahora, y de nuevo cada vez que cambias 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 contiene 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 al 92%, una ganancia fuera del ruido). En la migración de Claude Sonnet 4.6 a Claude Sonnet 5, la auditoría redujo 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: eliminar "verifica dos veces" redujo el costo por ticket de Opus 5 en un tercio, y eliminar "sé máximamente exhaustivo" casi lo mismo. El texto que ya no se ajusta al modelo cuesta precisión en su lugar: 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 eliminarse:

Los mismos patrones aparecen en descripciones de herramientas y skills, y también vale la pena eliminarlos allí.



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 cuales 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 (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 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 queda rutinariamente superada por hacer menos de todo.

Anthropic midió esto directamente en DeepResearch Bench II⁷, un benchmark de informes de investigación lo suficientemente difícil para separar los modelos:

El modelo de frontera con esfuerzo low fue más preciso y aproximadamente 10% más barato por tarea que el modelo de nivel medio, a pesar de la brecha por token. Sin embargo, no siempre gana. En el subconjunto de SWE-bench Pro³ de esta página, 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 solo (91.7% comparado con 91.3%, dentro del ruido entre ejecuciones) a aproximadamente el 60% de su costo. En trabajo más difícil, como las tareas de DeepResearch Bench II, la ventaja de Fable reaparece.

Para la mayoría de las cargas de trabajo de agente, empieza con Claude Opus 5: por token cuesta la mitad de lo que cuesta Fable 5 y 2.5 veces lo que cuesta Sonnet 5, y en ese subconjunto de programación igualó la precisión de Fable. 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% para Opus, y quedó mucho más atrás en tareas largas de programación. Se ajusta a trabajo de alto volumen con salidas 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 parece el 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 donde 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.



Ajusta el esfuerzo

El esfuerzo es la forma más directa de ajustar un modelo a tu tarea. El parámetro effort gobierna cuánto pensamiento, llamadas de herramientas y autoverificación hace el modelo, y el valor predeterminado (high) se adapta a 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 contra costo es casi plana: low cedió de 1 a 3 puntos por un tercio a la mitad de descuento en el costo por tarea, medium igualó la precisión del valor predeterminado al 70% a 85% de su costo, y el valor predeterminado no compró nada medible sobre medium en ninguno de los cuatro. En DeepWideSearch, low también igualó a un orquestador con un trabajador Claude Sonnet 5 a un costo 20% menor: bajar el esfuerzo superó a un cambio de arquitectura.

Las configuraciones más bajas también son más rápidas, lo que importa cuando la latencia es la restricción. En estas ejecuciones, low tomó 4.5 minutos por problema en DeepWideSearch, comparado con 7.9 minutos con el valor predeterminado. En el benchmark de corpus, cuya entrada no cabe en ninguna ventana de contexto individual, Fable 5 tomó 7.9, 9.1 y 11.4 horas por episodio con low, medium y el valor predeterminado.

La programación de horizonte largo es la otra forma. En SWE-bench Pro³, Claude Opus 5 cedió aproximadamente 2 puntos con medium por la mitad del costo y aproximadamente 8 puntos con low por una cuarta parte: un intercambio real, que volver a ejecutar los fallos con mayor esfuerzo convierte de nuevo en un ahorro. Este gráfico traza la precisión contra el 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 agregar 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 a través de los niveles de esfuerzo.

Un esfuerzo menor sí cuesta precisión en cargas de trabajo que alcanzan el techo del modelo, donde la precisión genuinamente escala con la profundidad del razonamiento. En DeepResearch Bench II⁷, donde cada informe recompensa el razonamiento profundo por subtema, cada paso de esfuerzo compró aproximadamente 2.4 puntos de puntuación de rúbrica; no hay reducción de costo gratuita en esa curva:

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 a mitad de sesión invalida la caché (consulta Almacena en caché el contexto repetido) y distorsiona la comparación. Para 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 una configuración fija: ejecuta cada tarea con una configuración baja y vuelve a ejecutar solo los fallos con una más alta.

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 aproximadamente $0.70 cada una, frente al 91.7% por $1.39 ejecutando todo con el valor predeterminado: la misma tasa de aprobación por la mitad del costo, contando los intentos baratos fallidos. Empezar con medium en su lugar resolvió aproximadamente el 94% por aproximadamente $0.95. 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:

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 topes 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 a medida que el presupuesto se ajustaba:

Un presupuesto generoso cedió aproximadamente 2.7 puntos de tasa de aprobación por un ahorro de costo del 18%, y el presupuesto más ajustado permitido cedió 4.4 puntos por un ahorro del 47%. Los presupuestos compraron eficiencia aquí, no precisión.

Tres controles hacen tres trabajos diferentes. Un presupuesto de tarea ahorra dinero, porque el modelo lo ve. max_tokens es un tope de seguridad que no ahorra nada. 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 tope de sesión para la ejecución que nunca quieres ver en una factura, con un límite de gasto del workspace como respaldo final.

• Los presupuestos de tarea están en beta (encabezado beta task-budgets-2026-03-13) en Claude Opus 5, Claude Fable 5, Claude Opus 4.8 y Claude Opus 4.7, pero no en Claude Sonnet 5; revisa primero la tabla de soporte. Empieza cerca del uso de tokens del percentil 90 de tu bucle, 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 a un 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 tope de 16,384 tokens terminó el 15% de los intentos de Claude Opus 5 y un tercio de los de Claude Fable 5, ninguno de ellos resuelto. Las ejecuciones con tope gastaron menos por intento pero compraron proporcionalmente menos resoluciones, por lo que el costo por tarea resuelta fue el mismo que con 64,000. Con esa configuración nada se cortó, y Fable resolvió el 54.6% de las tareas en lugar del 36.6% en los problemas que ambas ejecuciones puntuaron (en un corte separado del subconjunto de SWE-bench Pro³, descrito en la referencia 12, 92% en lugar de 90%). Reintentar los intentos con tope solo agrega costo: con el mismo tope nunca tuvieron éxito, y con uno más alto también pagas por el intento desperdiciado. Establece max_tokens en 64,000 para trabajo agéntico (128,000, el máximo, con esfuerzo xhigh o max), 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 tope en dólares sobre una sesión a tarifas de lista para tokens, búsquedas y tiempo de sesión. Al llegar al tope, la sesión se pausa con stop_reason: budget_reached; aumentar el presupuesto la reanuda. Lo aplica la plataforma, funciona en cualquier modelo con un precio de lista (incluido Claude Sonnet 5) y se combina con el presupuesto de tarea orientativo. Los despliegues aplican el mismo campo a cada ejecución.

El primero de dos gráficos de max_tokens traza el costo por intento y por tarea resuelta con cada tope:

El segundo traza la longitud de salida por turno contra los topes:



Combina modelos

Las arquitecturas multimodelo se ajustan a cargas de trabajo cuya complejidad de tareas varía lo suficiente como para que diferentes pasos sean mejor atendidos por diferentes 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 solo 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: escalar las decisiones difíciles

En la estrategia de asesor (advisor), un modelo 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 las tarifas del ejecutor, y solo las consultas ocasionales a las tarifas del asesor.

Para usarla, agrega 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 ningún código de orquestación. En Claude Managed Agents, dale a la sesión un asesor agregando 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, así que dos cosas deciden cuánto ayuda.

La primera es la brecha entre los modelos. El asesor solo puede aportar la capacidad que le falta al ejecutor: 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, o consult rate). Un ejecutor con esfuerzo bajo puede dejar de notar 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 reduce 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, recorre la mayor parte del camino. En los emparejamientos del siguiente gráfico, el asesor cerró entre el 60% y el 90% de la brecha con el modelo más fuerte mientras que ese modelo se pagó solo en las consultas, lo que hace posibles los casos de ahorro de costos:

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 proporciona una "system prompt" (indicación del sistema) que pide una llamada antes del trabajo sustancial y una antes de terminar, alrededor de dos a tres llamadas por tarea. El emparejamiento de programación medido a continuación funcionó 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 se desploma.

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 superior al 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 fue la configuración más precisa medida: 85.7% de los intentos resueltos por $8.40 por intento. Se sitúa por encima de la línea que pasa por los propios ajustes de esfuerzo de cada modelo, pero solo uno o dos puntos por encima del mejor de ellos (Opus solo en el ajuste predeterminado, 84.4% por $8.50, y Fable solo en medium, 83.4% por $8.20), lo que una sola ejecución no separa del ruido. Fable solo con esfuerzo medium alcanza aproximadamente la misma precisión que el emparejamiento (83.4% frente a 85.7%) por aproximadamente el mismo dinero ($8.20 frente a $8.40 por intento):

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, no como un ahorro: en la parte alta del rango el asesor compra un poco de precisión al precio de frontera, y el caso de costo pertenece a emparejamientos con una brecha de capacidad más amplia, como el siguiente caso de lectura de gráficos. 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 compensa en lugar de aumentar el esfuerzo. Donde la brecha de capacidad es más amplia y la precisión de una carga de trabajo responde al esfuerzo, un ejecutor con esfuerzo bajo que consulta a un asesor puede ser un paso adelante más barato que aumentar el propio esfuerzo del ejecutor, porque el asesor se paga solo en las tareas que lo necesitan.

En Chartography¹³, un benchmark público de lectura de gráficos ejecutado en Claude Managed Agents con su asesor, un ejecutor Claude Opus 5 con esfuerzo low y un asesor Claude Fable 5 obtuvo 67.5 por $0.60 por tarea. Eso está por encima de la línea que pasa por los propios ajustes de esfuerzo de cualquiera de los dos modelos (Opus solo pasó de 49 a 75 entre low y medium por $0.38 a $0.94), aunque los propios ajustes medium y predeterminado del ejecutor aún mantienen las puntuaciones más altas, a 1.6 y 3.3 veces el precio:

El ejecutor con esfuerzo bajo consultó al asesor en el 86% de las tareas, la condición que el emparejamiento de SWE-bench Pro no cumplió. Mide la tasa de consulta en tu bucle de agente antes de confiar en esta configuració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 mayormente 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: delegar el trabajo masivo

En la estrategia de orquestador (orchestrator), el modelo de frontera mantiene el bucle. Descompone la tarea, despacha subtareas a modelos 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 las tarifas de los trabajadores mientras que 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 Claude Fable 5 y trabajadores Claude Sonnet 5, consulta la receta del Claude Cookbook Patrón de coordinador: modelos grandes para planificar, modelos pequeños para ejecutar.

Este patrón ahorra tiempo de reloj cuando los trabajadores pueden ejecutarse en paralelo: en el benchmark de corpus⁸, un episodio tomó un poco más de 2 horas con el coordinador ejecutando el límite documentado de la plataforma de 25 trabajadores concurrentes, frente a 11.4 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 todas las veces.

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 las tarifas del trabajador.

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

La delegación compensó en la parte rutinaria y normalmente resoluble del trabajo, lo contrario de 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 larga cola de costos en tareas rutinarias, este es el caso de orquestador a medir primero.

Caso 2: trabajo más grande que una ventana de contexto. Un modelo solo debe procesar una entrada tan grande de forma serial, una "context window" (ventana de contexto) a la vez, pagando por releer 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. Reducir el esfuerzo no puede ayudar, porque la factura es la propia lectura del corpus: Claude Fable 5 en solitario costó de $720 a $764 por episodio en cada ajuste de esfuerzo, y solo se movió su precisión. La configuración de coordinador costó más de un 60% menos que cualquiera de esos ajustes y puntuó de 2 a 6 puntos por debajo de Fable en medium o el predeterminado, mientras superaba claramente una línea base de Claude Sonnet 5 en solitario:

La contabilidad de tokens muestra por qué. Ambas facturas son mayormente lectura del corpus servida desde la caché: la configuración de coordinador leyó unos 570 millones de tokens en caché por episodio, casi tres veces los aproximadamente 200 millones del modelo solo, y aun así costó menos de la mitad, porque sus lecturas se facturaron a la tarifa de lectura de caché de Claude Sonnet 5 en lugar de la de Claude Fable 5. Fable 5 con esfuerzo predeterminado aún mantiene la precisión máxima, a 2.8 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 volumen que entregar: muchas piezas independientes, idealmente demasiadas para una ventana de contexto. Cuando el trabajo es una 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 este tipo medido, el modelo del coordinador solo con menor esfuerzo salió ganando.

BrowseComp⁴ muestra el límite dentro de un mismo benchmark. La delegación compensó en la porción rutinaria y perdió en el conjunto completo y más difícil, donde el modelo de frontera solo alcanzó la precisión de la configuración de coordinador con un costo entre un 22% y un 30% menor. Trabajo externo independiente reporta el mismo patrón⁵. Si el trabajo es una cadena, cabe en un contexto sin una larga cola de costos, o un solo modelo con menor esfuerzo ya cumple tu estándar, no construyas un orquestador.



Elegir entre las estrategias

La mayoría de los casos se reducen a una pregunta: ¿el trabajo se divide en piezas independientes, o es una 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. Primero haz un barrido de 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 a ejecutar en tu propia carga de trabajo, y la razón por la que el primer paso es un barrido de esfuerzo.

Cuando sí agregues 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 son de julio y agosto de 2026, a los precios de lista de ese momento, 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 algunas 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 cerró, el conteo de filas es correcto. Registra el costo por tarea junto a la puntuación: calcula el precio de los cuatro conteos de tokens en el usage de cada respuesta a sus propias tarifas, sumados a lo largo de 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 grafica 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, agrega la estrategia multimodelo que encaje y vuelve a ejecutar la suite.
4. Ejecuta la ganadora en modo sombra sobre 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 dos para otro modelo.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
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
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Las escrituras en caché se cobran a 1.25x el precio de entrada (caché de 5 minutos); las lecturas de caché a 0.1x.
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + 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 cuatro; si no, verifica 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 conviene probarlas:



Benchmarks referenciados

Todas las mediciones son ejecuciones internas de Anthropic de estos benchmarks. Salvo que se indique lo contrario, los costos están en USD a precios de lista de agosto de 2026; 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) calculan el precio de 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. Los gráficos de caché y de esfuerzo provienen de ejecuciones separadas, por lo que los costos por problema difieren ligeramente. El gráfico de concentración de costos es una ejecución separada de 20 problemas, 3 ejecuciones por problema, 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 frente a rúbricas de tarea; una ejecución de 210 tareas del conjunto gold publicado, un intento por tarea. 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; los ajustes de esfuerzo reducido son ejecuciones únicas. 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% a lo largo de los emparejamientos de ejecuciones por unos $0.70; medium primero, del 93.8% al 94.2% por unos $0.95; el predeterminado vuelto a ejecutar en sus propios fallos, 94.0% por $1.58; todo en el predeterminado, del 90.9% al 92.5% por $1.39. Los emparejamientos del ejecutor Claude Sonnet 5 en el gráfico de asesor provienen de la misma serie de agosto de 2026 en este subconjunto: el emparejamiento Sonnet más Opus se ejecutó dos veces (una ejecución y una replicación exacta) y el emparejamiento de esfuerzo bajo una vez; las cifras de presupuesto de tarea son una ejecución por presupuesto en el mismo subconjunto. La cifra de Claude Fable 5 en Compara modelos es una única ejecución de julio de 2026, también la línea base sin presupuesto del gráfico de presupuesto de tarea; cada ejecución con presupuesto completó los 482 problemas sin errores del arnés.
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 ajuste. El gráfico de seguro de costos usa 10 problemas resueltos de forma fiable de una porción de 26 problemas, 50 ejecuciones delegadas y 70 en solitario ($6.45 frente a $11.99 por ejecución en valor esperado); las cifras delegadas tienen una banda de medición de alrededor del 20%.
5. Escalado de arquitecturas 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.
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 frente a rúbricas binarias derivadas de expertos; medido en un subconjunto de 50 tareas estratificado en todos los temas, un intento por tarea, 3 ejecuciones, puntuado en las tareas que ninguna configuración rechazó. 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. Las ejecuciones son anteriores a Claude Opus 5, de ahí su ausencia en el gráfico de Compara modelos. El costo de Sonnet 5 difiere ligeramente entre el gráfico de caché (costo de inferencia, con y sin caché) y ese gráfico (costo total, caché activada); ambos provienen de las mismas ejecuciones.
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 de paquetes públicos 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 de agosto de 2026 en la que el coordinador Claude Fable 5 ejecutó todo el barrido dentro de la plataforma en su límite documentado de 25 trabajadores Claude Sonnet 5 concurrentes; sus tres episodios obtuvieron F1 de 0.842, 0.805 y 0.810 por $263, $299 y $261. Las configuraciones en solitario son ejecuciones de julio de 2026 sobre la misma compilación del corpus. El F1 absoluto es específico de esta compilación del corpus, no comparable entre benchmarks; las comparaciones de configuraciones 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, medido en agosto de 2026, dos ejecuciones por configuración, calificado por modelo frente a 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. Medido en agosto de 2026: 113 tareas originales en cinco lenguajes con verificadores basados en programas. Los emparejamientos son dos ejecuciones cada uno 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 modelo único son ejecuciones únicas con precio calculado a partir de conteos de tokens, una aproximación que tiene en cuenta la caché. Los costos por tarea son los totales de la ejecución divididos por 113.
11. Benchmark interno de programación agéntica: Interno de Anthropic: 370 tareas de repositorio calificadas por las propias pruebas de los repositorios. Las cifras de la API (Opus 5 solo, Fable 5 solo y el emparejamiento) se midieron en agosto de 2026 con el esfuerzo predeterminado y un límite de salida de 128,000 tokens, una ejecución por configuración: cinco intentos por tarea en los ajustes predeterminados y para el emparejamiento, uno en low y medium; el emparejamiento promedió unas dos consultas al asesor por intento; los costos son por intento. Las cifras de Claude Code son ejecuciones de julio de 2026 de las mismas tareas, una ejecución por configuración, costos aproximados.
12. Benchmark interno de tareas de repositorio (medición de límites): Un conjunto interno de Anthropic separado de unas 130 tareas de repositorio, ejecutado en agosto de 2026 con un bucle de agente de API simple, un intento por tarea. Las cifras de 16,384 tokens promedian dos ejecuciones por modelo; las cifras de 64,000 tokens son ejecuciones únicas (124 tareas puntuadas para Opus 5; 108 para Claude Fable 5, ya que el entorno omitió el resto antes de que el modelo se ejecutara). Alrededor de la mitad de los intentos de Fable que el límite de 16,384 había terminado se resolvieron con 64,000; una ejecución adicional de Fable con 128,000 obtuvo 56.1%, dentro del ruido de la ejecución de 64,000. Las cifras de límite de SWE-bench Pro son una ejecución de Claude Fable 5 por límite con el esfuerzo predeterminado en un subconjunto de 100 problemas estratificado a partir del conjunto de 482 problemas de la referencia 3, no comparable con sus puntuaciones. Las distribuciones por turno del gráfico provienen de la ejecución de Opus con 64,000 y la ejecución de Fable con 128,000, por lo que ninguna está cortada por su propio límite.
13. Chartography: Surge AI, "Chartography," 2026. El conjunto completo publicado de 100 preguntas, medido en 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%. La comparación de tasas de consulta proviene de volver a ejecutar las mismas configuraciones en la Messages API con un conjunto de herramientas de contenedor.
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 en agosto de 2026 bajo seis indicaciones del sistema, cada una agregando a la misma indicación limpia 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 los 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.



Próximos pasos