Reducción de costes y mejora del rendimiento con Claude Platform

Ajustar el caché de indicaciones, las instrucciones y el esfuerzo puede reducir el costo de Claude sin sacrificar el rendimiento de la aplicación.

El rendimiento y el costo a menudo se ven como un equilibrio: para gastar menos, aceptas peores resultados. En la práctica, hemos descubierto que muchas aplicaciones que usan Claude Platform pueden reducir costos sin sacrificar rendimiento con tres ajustes: maximizar la tasa de aciertos del caché de indicaciones, eliminar los antipatrones de tus indicaciones al actualizar a los modelos Claude de frontera, y calibrar el esfuerzo según la tarea. Hemos incluido esta guía en la habilidad claude-api. En este artículo, mostramos cómo Claude Code con la habilidad claude-api a menudo puede encontrar formas de reducir costos mientras mantiene o mejora el rendimiento.

Caché de indicaciones

Antes de que Claude genere una respuesta, primero procesa tu indicación en un estado de trabajo interno. Este paso, llamado prefill, es la parte costosa del manejo de la entrada. El almacenamiento en caché de indicaciones guarda ese estado (el caché de clave-valor, o KV): cuando una solicitud comienza con el mismo prefijo, Claude lo lee en lugar de volver a calcularlo. Las lecturas de caché se facturan a una fracción del precio de entrada completo.

Hay algunas consideraciones prácticas para asegurar el uso efectivo del caché de indicaciones. Primero, el caché de indicaciones está vinculado a un modelo específico. Segundo, las lecturas del caché de indicaciones deben ser byte-exactas en todo el prefijo. Finalmente, el caché de indicaciones tiene un tiempo de vida limitado (TTL).

Con estos puntos en mente, aquí hay algunos consejos prácticos:

• Ten cuidado al cambiar la configuración de esfuerzo a mitad de la conversación. Estas configuraciones se renderizan en la indicación antes de tu contenido, por lo que son parte del prefijo almacenado en caché. Solo con modelos Claude selectos, incluidos Opus 5 y Fable 5.1, puedes actualizar el esfuerzo a mitad de la conversación sin romper el caché.
• Mantén los valores volátiles fuera del prefijo. Una marca de tiempo o ID dinámico en la indicación del sistema puede cambiar entre llamadas al modelo y romper el caché.
• Evita definiciones de herramientas que se reordenen solas. Al usar la API de mensajes de Claude, la indicación se ensambla en un orden fijo con las definiciones de herramientas renderizadas al principio. Cualquier cambio en la definición de la herramienta romperá el caché.
• Ten cuidado al bifurcar conversaciones. Los subagentes y las ramas solo comparten el caché del padre cuando el prefijo de la bifurcación es byte-idéntico, en el mismo modelo y usando el mismo esfuerzo.

Cómo solucionarlo

Hemos acumulado algunas lecciones para la gestión del caché de indicaciones:

• Monitorea cuidadosamente tu tasa de aciertos del caché de indicaciones. Claude Console y la API de diagnóstico de caché proporcionan diagnósticos del caché de indicaciones, incluyendo las razones de los fallos del caché de indicaciones (Figura 1) y exactamente dónde divergieron dos solicitudes.

• Difiere las herramientas de uso poco frecuente. Declara todas tus herramientas por adelantado, pero marca las de uso poco frecuente como defer_loading: permanecen fuera del prefijo almacenado en caché y se añaden a la conversación solo cuando Claude las busca con la búsqueda de herramientas, por lo que el caché se conserva.
• Aplica las actualizaciones de la indicación del sistema como mensajes. Ciertos modelos Claude te permiten agregar una instrucción del sistema como un mensaje a mitad de la conversación en lugar de editar la indicación del sistema, lo que preserva el caché.
• Organiza la solicitud para que la parte estable permanezca estable. Agrega el contexto estático (definiciones de herramientas e indicación del sistema) primero y la conversación en crecimiento detrás de ellos (Figura 2).

• Realiza cambios en el modelo o el esfuerzo cuando el caché de indicaciones ya esté roto. Ciertas operaciones, como la compactación, ya reescriben gran parte del caché (la conversación). Ese es un buen momento para cambiar de modelo o esfuerzo, ya que de todos modos estás pagando por un fallo.
• Mueve el punto de ruptura del caché a medida que la conversación crece. Con Claude Platform, puedes configurar el almacenamiento en caché automático para aplicar el punto de ruptura del caché al último bloque almacenable en caché.
• Precalienta el caché. Para reducir la latencia, envía una solicitud con max_tokens: 0 y un punto de ruptura de caché explícito, usando la misma configuración de esfuerzo que tu tráfico real. Esto procesa la indicación y la escribe en el caché sin generar nada. Si lo ejecutas al inicio de la sesión (por ejemplo, mientras un usuario está escribiendo), la primera solicitud real encontrará un caché cálido.
• No excedas el TTL del caché de indicaciones. El TTL de caché de 5 minutos se cuenta desde el inicio de la solicitud. Si un agente se bloquea en llamadas a herramientas o solicitudes de subagentes que duran más de 5 minutos, el caché del padre caduca antes de que regrese el resultado. En casos como este, considera establecer un TTL de 1 hora en el prefijo.

Instrucciones

Las indicaciones pueden acumular instrucciones que parchean las debilidades del modelo. Estas instrucciones pueden desviarse en relación con las capacidades de los últimos modelos Claude. Aquí hay algunos "antipatrones" de indicaciones comunes que obstaculizan los modelos Claude de frontera y pueden aumentar inadvertidamente los costos:

• Rituales de verificación. Instrucciones como "revisa tu trabajo" o "verifica dos veces antes de responder" a menudo son tomadas literalmente por los modelos de frontera y pueden desperdiciar tokens.
• Potenciadores de exhaustividad y énfasis. "Sé máximamente exhaustivo", "CRÍTICO: SIEMPRE DEBES…" pueden llevar a verbosidad y llamadas a herramientas adicionales al trabajar con modelos de frontera.
• Procedimientos obligatorios y andamios de bloc de notas. Los procesos de pasos fijos (por ejemplo, "piensa paso a paso en un bloc de notas") o las plantillas de razonamiento son rituales que los modelos de frontera no necesitan. Este andamiaje puede apilarse sobre el razonamiento nativo y usar tokens innecesarios.
• Ejemplos obsoletos. Los ejemplos de pocas tomas ajustados a los modos de fallo de un modelo más antiguo pueden enseñar a un modelo de frontera a imitar cadenas de razonamiento largas en solicitudes que no las necesitan.
• Reglas contradictorias. Los modelos de frontera son mejores siguiendo instrucciones. Las instrucciones contradictorias ("siempre reembolsar según la política" vs. "nunca emitir reembolsos sin escalación") pueden ser seguidas más literalmente por los modelos de frontera, resultando en un rendimiento degradado.
• Configuración desactualizada. La configuración escrita para una generación anterior de Claude (por ejemplo, presupuestos de pensamiento manuales) puede ser rechazada por Claude Platform con modelos más nuevos.

Cómo solucionarlo

Hemos actualizado la habilidad claude-api con un nuevo comando que vigila estos antipatrones. En Claude Code, ejecuta /claude-api prompt-audit contra tus indicaciones, habilidades o descripciones de herramientas. La auditoría cubre cualquier cosa en tu directorio de trabajo, incluyendo el código de la aplicación que llama a la API de Claude y la propia configuración de Claude Code (por ejemplo, CLAUDE.md o habilidades).

Por ejemplo, probamos una migración de modelo de Opus 4.8 a Opus 5 en un punto de referencia de atención al cliente. Comenzamos con una indicación limpia e introdujimos un antipatrón a la vez (una configuración de pensamiento retirada, un par de reglas de reembolso contradictorias, un bloc de notas manual, "verificar dos veces", "ser máximamente exhaustivo" y un procedimiento obligatorio de seis pasos), dando seis indicaciones heredadas.

Ejecutamos cada una en Opus 4.8, en Opus 5 con solo el ID del modelo cambiado, y en Opus 5 después de ejecutar /claude-api prompt-audit una vez por indicación (la Figura 3 muestra el promedio de las seis).

Con Opus 5, los rituales de verificación ("verificar dos veces") usan tokens innecesarios al duplicar la búsqueda de pedidos en cada reembolso. Los potenciadores de énfasis ("ser máximamente exhaustivo") se convirtieron en docenas de búsquedas innecesarias en la base de conocimientos.

Ejecutar /claude-api prompt-audit eliminó los antipatrones, disminuyendo los costos en un 14.6% y aumentando la precisión en un 5.3% en promedio. El costo disminuyó porque se eliminaron las llamadas a herramientas adicionales y el razonamiento duplicado. La precisión aumentó por tres razones. La configuración de pensamiento retirada hizo que la API rechazara directamente cada solicitud de enrutamiento. Las reglas de reembolso contradictorias llevaron a Opus 5 a retener cuatro reembolsos que debía mientras le pedía al cliente que confirmara. Y el bloc de notas manual chocó con el pensamiento integrado de Opus 5: en tres tickets, escribió la llamada a la herramienta dentro de su razonamiento y nunca la ejecutó.

Esfuerzo

El esfuerzo le dice a Claude "qué tan duro trabajar". Con esfuerzo bajo, Claude generalmente llega a conclusiones más rápido. Con esfuerzo alto, Claude delibera, verifica y explora alternativas antes de responder.

La relación costo-rendimiento entre los niveles de esfuerzo en un solo modelo puede variar. Por ejemplo, Claude Fable 5 obtiene un 11.5% con esfuerzo bajo por $5.35 por tarea en FrontierCode Diamond (las 50 tareas más difíciles). Con esfuerzo máximo, Fable 5 obtiene un 30.9% por $19.00 por tarea; cambiar el esfuerzo aumenta la puntuación aproximadamente 2.7x (+19 puntos) por aproximadamente 3.5x el costo (Figura 4).

En Claude Fable 5.1, Humanity's Last Exam (sin herramientas) muestra una curva pronunciada con un último paso decreciente. Obtiene aproximadamente un 53% con esfuerzo bajo por aproximadamente $0.30 por pregunta y aproximadamente un 61% con esfuerzo máximo por aproximadamente $2.23; el último paso hasta el máximo agrega aproximadamente medio punto por un 46% más de costo. La ganancia cae dentro del ruido de ejecución a ejecución del punto de referencia, por lo que pagas más sin una ganancia medible.

El esfuerzo puede estar mal calibrado en cualquier dirección:

• Asumir que más alto siempre es mejor. El esfuerzo alto puede causar sobrepensamiento. Claude pasa más tiempo deliberando de lo que la tarea justifica, lo que agrega costo y latencia, y puede degradar la calidad de la respuesta. La deliberación solo ayuda mientras todavía hay evidencia que encontrar.
• Sesgo hacia el esfuerzo bajo. Configurado demasiado bajo, Claude se detiene antes de tener suficiente evidencia. Hace menos llamadas a herramientas, por lo que puede responder desde el primer resultado de búsqueda en lugar del tercero. Piensa menos en los pasos difíciles y se salta la verificación que normalmente ejecutaría por su cuenta. La respuesta parece completa, pero está construida sobre información parcial.

Cómo solucionarlo

Hay algunas formas útiles de calibrar el esfuerzo:

• Prueba modelos más fuertes con esfuerzo bajo. Un modelo más fuerte con esfuerzo bajo puede ser más barato que un modelo más débil trabajando duro (esfuerzo alto). Por ejemplo, en CursorBench 3.2, Claude Fable 5.1 con esfuerzo bajo iguala el rendimiento de Fable 5 con esfuerzo alto a un tercio del costo (Figura 5). Dos cosas hacen que el modelo más nuevo sea más barato: con esfuerzo bajo hace menos trabajo por tarea, y las lecturas de caché de indicaciones de Fable 5.1 tienen un precio de $0.25 por millón de tokens frente a $1.00 para Fable 5. Incluso a los precios de Fable 5, Fable 5.1 con esfuerzo bajo costaría aproximadamente un 40% menos.

• Comprende la forma de tu tarea. Medir el rendimiento de la aplicación a través de un barrido de niveles de esfuerzo es una forma útil de entender la compensación costo-rendimiento para tu tarea particular. En una evaluación no saturada, una curva plana de costo-rendimiento a través de los niveles de esfuerzo sugiere que la tarea no está limitada por el cómputo de pensamiento; aumentar el esfuerzo no es beneficioso.

Esta calificación a menudo implica ejecutar una evaluación a través de modelos y niveles de esfuerzo. En Claude Code, /claude-api hillclimb realiza esta búsqueda por ti: divide tu evaluación en conjuntos de entrenamiento y prueba, propone cambios de configuración y lee ejemplos de entrenamiento fallidos para solucionar lo que encuentra.

Lo ejecutamos en un punto de referencia de atención al cliente, comenzando desde Opus 4.8 en su esfuerzo predeterminado (alto). El escalador primero probó Opus 5 con esfuerzo bajo, aplicando prompt-audit para eliminar rituales obligatorios de llamadas a herramientas, pasos de bloc de notas y reglas contradictorias. Eso superó la línea base de Opus 4.8 con un 98.9% de precisión en entrenamiento y redujo el costo a 2.6 centavos por ticket (Figura 6).

Luego bajó a Sonnet 5 con esfuerzo bajo, que era aún más barato a 1 centavo por ticket, pero la precisión cayó al 88.9%. Al leer los tickets de entrenamiento fallidos, Claude agregó reglas de enrutamiento y una referencia cruzada de límite de reembolso a la indicación, llevando a Sonnet 5 de vuelta al 98.9% al mismo costo.

En los 14 tickets retenidos que la búsqueda nunca vio, la configuración final obtuvo un 90.5% frente al 78.6% de la configuración original, a aproximadamente una quinta parte del costo.

Automatizando la reducción de costos

El almacenamiento en caché de indicaciones, las instrucciones y el esfuerzo son palancas comunes para reducir costos. Nuestra documentación cubre aún más. Para realizar una auditoría de costos holística del código de la aplicación que usa la API de Claude, hemos agregado /claude-api cost-optimize: perfila dónde va tu gasto, aplica reducciones de costos y, si proporcionas una evaluación, muestra cómo los ahorros se compensan con el rendimiento.

cost-optimize comienza encontrando a dónde van tus tokens: desde los informes de uso y costos de tu organización si tienes una clave de API de administrador de Claude, desde el objeto de uso en cada respuesta de la API si tu aplicación lo registra, o, si fallan ambos, leyendo tu código de construcción de solicitudes y estimando.

Luego clasifica los ahorros disponibles, comenzando con el almacenamiento en caché de indicaciones, recortando lo que cada solicitud lleva (incluyendo una prompt-audit), limitando la salida y procesando por lotes el trabajo no supervisado. Si proporcionas una evaluación, va más allá y calcula el costo y el rendimiento en todos los niveles de esfuerzo y opciones de modelo. Ejecutamos esto en cuatro puntos de referencia públicos con Sonnet 5 como línea base (Figura 7):

• LegalBench (~58% de costo más bajo): cost-optimize propuso almacenar en caché un prefijo compartido entre tareas, establecer un esfuerzo bajo y procesar las tareas a través de la API por lotes. Los tokens de pensamiento cayeron de 102,779 a 8,284 y la tasa de aprobación se mantuvo dentro del ruido y el costo disminuyó aproximadamente un ~58%.
• tau2-bench retail (~73% de costo más bajo): Al implementar el almacenamiento en caché de indicaciones con colocación explícita del punto de ruptura, cost-optimize redujo el gasto en un 72% mientras mantenía la tasa de aprobación plana.
• OfficeQA Pro (~52% de costo más bajo): cost-optimize agregó procesamiento por lotes y almacenamiento en caché de documentos, lo que redujo el costo de $136.20 a $64.87.
• SWE-bench Verified (~55% de costo más bajo): cost-optimize encontró que la configuración predeterminada ya almacena en caché correctamente. Los ahorros provinieron de establecer el esfuerzo en medio y restringir la salida del agente a solo unas pocas oraciones concisas. Los pasos medios por tarea pasaron de 29 a 17 y los tokens de indicación cayeron de 75.2M a 33.7M.

Cómo empezar

Comienza con /claude-api prompt-audit cuando hayas migrado a un modelo Claude de frontera y quieras verificar tus indicaciones existentes. Escanea las indicaciones, habilidades y descripciones de herramientas en tu directorio de trabajo. Esto puede ser código de aplicación que llama a la API de Claude o la configuración de Claude Code (CLAUDE.md, habilidades). Elimina los antipatrones comunes que obstaculizan los modelos de frontera.

Recurre a /claude-api cost-optimize cuando tu aplicación use la API de Claude y quieras una auditoría de costos. Perfila el gasto de tokens y luego prueba diferentes palancas: aplica prompt-audit, pero también busca formas de reducir el costo a través del almacenamiento en caché de indicaciones, el procesamiento por lotes del trabajo no supervisado o la limitación de la salida. Si proporcionas una evaluación, mide las compensaciones de esfuerzo y selección de modelo.

Finalmente, usa /claude-api hillclimb para una búsqueda de costo y rendimiento. Dada una evaluación, Claude la divide en conjuntos de entrenamiento y prueba, luego propone actualizaciones a tu aplicación que apuntan a reducir el costo mientras mantienen el rendimiento de la línea base. Claude lee los casos de entrenamiento fallidos para guiar la búsqueda, y la configuración final se puntúa en el conjunto de prueba retenido.

Para obtener más información:

• Consulta nuestra documentación aquí
• Consulta nuestro libro de cocina de reducción de costos aquí
• Consulta la habilidad claude-api aquí; la habilidad también está integrada en Claude Code
• Consulta este artículo en el Blog de Claude aquí

Escrito por Lance Martin (@RLanceMartin), Brad Abrams (@brada), Isabella He (@IsabellaKHe) y Ben Lehrburger (@benlehrburger).