Cómo reducir tu factura de la API de Claude: guía práctica sobre el coste de los tokens

El modelo mental del presupuesto de tokens

Cada solicitud tiene dos factores de coste:

• Tokens de entrada: el prompt de sistema, el mensaje del usuario, el historial de conversación, las definiciones de herramientas, los documentos recuperados y cualquier prefijo almacenado en caché que siga contabilizándose cuando no se use la caché.
• Tokens de salida: la respuesta del modelo, incluida la verbosidad accidental y los reintentos.

Una fórmula mental útil es:

request_cost ≈ input_tokens × input_rate + output_tokens × output_rate

Parece obvio, pero cambia la forma de investigar el gasto. Si la solicitud media es «barata» en la salida pero cara en la entrada, reducir 400 tokens del prompt de sistema puede ser más importante que pedir al modelo que sea más conciso.

Empieza por elegir el modelo

No todas las tareas requieren el modelo más capaz. En sistemas reales, la selección del modelo suele ser la optimización más barata.

Un error habitual es «elegir por defecto un modelo superior». Los equipos suelen enviar todos los prompts al modelo de gama más alta porque parece más seguro. En la práctica, es un seguro caro para tareas que no se benefician de él. Una capa de enrutamiento suele merecer el esfuerzo:

• Haiku para clasificación rápida, extracción de JSON, etiquetado de registros y evaluación inicial.
• Sonnet para la mayoría de las cargas de trabajo de agentes o herramientas de desarrollo.
• Opus solo cuando la tarea realmente necesita un razonamiento más potente, una síntesis con matices o cuando hayas medido el coste de los fallos.

Una política sencilla que funciona bien es:

1. Prueba Haiku para tareas estructuradas de bajo coste.
2. Pasa a Sonnet si la confianza es baja o la salida tiene un formato incorrecto.
3. Pasa a Opus solo para los casos realmente difíciles.

Este tipo de cadena de alternativas suele ser más barato que pagar las tarifas de Opus en cada solicitud.

Recorta el prompt de sistema sin contemplaciones

El prompt de sistema es donde el desperdicio de tokens se esconde a plena vista. Tiende a crecer como la deuda técnica: una línea de política aquí, una regla de estilo allá, cinco ejemplos que nadie eliminó.

Qué eliminar

• Instrucciones duplicadas que la aplicación ya hace cumplir.
• Textos largos sobre «ser útil» que no cambian el comportamiento.
• Ejemplos antiguos de casos límite que ya no importan.
• Texto de políticas repetido en cada solicitud.
• Descripciones extensas de herramientas cuando basta con un esquema compacto.

Qué conservar

• Restricciones de comportamiento no negociables.
• Reglas de formato de salida.
• Instrucciones críticas para la seguridad.
• Ejemplos mínimos que mejoren de forma sustancial la fiabilidad.

En la práctica, he visto a equipos eliminar cientos o miles de tokens del prefijo repetido sin cambiar la calidad del modelo. El truco consiste en tratar el prompt de sistema como código de producción: eliminar texto obsoleto, quitar reglas duplicadas y conservar solo lo que influye en el comportamiento.

Un patrón mejor es codificar la estructura en lugar de usar prosa:

{
  "style": "concise",
  "output": "json",
  "must_include": ["root_cause", "next_steps"],
  "must_avoid": ["speculation", "apologies"]
}

Eso resulta más fácil de analizar que tres párrafos de instrucciones narrativas.

Usa la caché de prompts para prefijos estables

Si tu entorno tecnológico admite la caché de prompts, úsala para todo lo que se repita entre solicitudes: prompts de sistema, esquemas de herramientas, ejemplos de aprendizaje con pocos casos y bloques largos de políticas.

La idea importante no es que «la caché sea gratis». No lo es. La ventaja es que dejas de pagar el precio completo por el mismo prefijo en cada llamada.

Buenos candidatos para la caché

• Prompts de sistema comunes a todo el producto
• Definiciones extensas de funciones o herramientas
• Instrucciones de recuperación reutilizadas
• Ejemplos estáticos de formato o estilo
• Estructura de soporte del agente que rara vez cambia

Malos candidatos para la caché

• Contexto del usuario específico de cada solicitud
• Documentos recién recuperados
• Instrucciones que cambian rápidamente
• Contenido de notas de trabajo específico de la sesión

El error habitual es incluir contenido muy variable en el prefijo y luego preguntarse por qué hay tan pocos aciertos de caché. Para obtener valor, mantén estable el segmento almacenado en caché y coloca después los datos específicos de la solicitud.

Ejemplo de estructura de solicitud:

{
  "system": "Stable application prompt + tool definitions + output contract",
  "messages": [
    { "role": "user", "content": "New ticket text here" }
  ]
}

Si mantienes estable la parte estable, das a la caché la oportunidad de aportar un valor real. Si el prefijo cambia en cada solicitud, solo estás pagando el coste adicional de gestionar la caché sin obtener ningún beneficio.

Configura max_tokens Con determinación

Uno de los costes silenciosos más fáciles de pasar por alto es un límite de generación demasiado alto. Si configuras max_tokens con un valor enorme «por si acaso», favoreces las respuestas largas, especialmente cuando el modelo tiene dudas o tiende a extenderse.

Usa el límite más bajo que siga cubriendo la tarea.

Rangos prácticos

• Extracción / clasificación: 32–128 tokens
• Resúmenes breves: 128–256 tokens
• Diferencias de código / explicaciones: 256–800 tokens
• Generación abierta: solo tan alto como sea necesario

Si la tarea es «devolver un objeto JSON», establece un límite estricto. Si la tarea es «explicar esta arquitectura», no dejes al modelo margen para escribir una novela, salvo que eso sea lo que quieras.

Muchos equipos también se olvidan de limitar los bucles de reintentos. Si falla el análisis y pides automáticamente al modelo que lo intente de nuevo con el mismo límite generoso de salida, puedes duplicar o triplicar el gasto de salida en una sola acción del usuario.

Agrupa las tareas pequeñas en lotes

El procesamiento por lotes ayuda cuando tienes muchas tareas pequeñas e independientes con una sobrecarga de instrucciones similar.

En lugar de esto:

• 50 solicitudes de clasificación independientes
• 50 prompts de sistema repetidos
• 50 definiciones de herramientas repetidas

Haz esto:

• Una solicitud que contenga 50 elementos
• Un bloque de instrucciones compartido
• Un esquema de salida compacto

Ejemplo de estructura de prompt:

Classify each item into one of: bug, feature, question, billing.

Items:
1. "App crashes after login"
2. "Can you add dark mode?"
3. "How do I reset my password?"

Y el contrato de respuesta:

[
  {"id": 1, "label": "bug"},
  {"id": 2, "label": "feature"},
  {"id": 3, "label": "question"}
]

Esto reduce la sobrecarga repetida y suele mejorar la capacidad de procesamiento. La contrapartida es el alcance de los fallos: si un elemento incumple el formato, puede ser necesario recuperar todo el lote. Para flujos de alto valor o de cara al usuario sensibles a la latencia, los lotes más pequeños pueden seguir siendo mejores.

El streaming mejora la capacidad de respuesta, no el coste de los tokens

El streaming es excelente para la experiencia de usuario y, a veces, para controlar los costes, pero no no reduce mágicamente por sí solo los tokens facturados. Sigues pagando por todo lo que genere el modelo.

Donde el streaming sí ayuda es en la interrupción anticipada:

• El usuario ve el progreso antes.
• Tu aplicación puede cancelar la generación cuando tenga suficiente contenido.
• Puedes detener una respuesta descontrolada antes de que alcance el límite configurado.

Este último punto importa. Si estás generando una respuesta para un analizador posterior y los primeros 120 tokens ya contienen el JSON necesario, no sigas recopilando otros 800 tokens de explicación.

En la práctica, el streaming merece la pena cuando tu aplicación puede reaccionar durante la generación. Si simplemente envías el contenido a un registro mediante streaming y de todos modos esperas a recibir la respuesta completa, obtienes el beneficio para la experiencia de usuario, pero apenas reduces los costes.

Mide el coste por solicitud, no solo por mes

El gasto mensual te indica que tienes un problema. Las métricas por solicitud te indican dónde está.

Registra al menos:

• input_tokens
• output_tokens
• cache_hit_tokens si está disponible
• nombre del modelo
• endpoint / ruta de la funcionalidad
• latencia
• número de reintentos
• tasa de truncamiento o de fallos de análisis

Una estructura sencilla de datos de registro podría tener este aspecto:

usage = response["usage"]

record = {
    "model": response["model"],
    "input_tokens": usage["input_tokens"],
    "output_tokens": usage["output_tokens"],
    "latency_ms": latency_ms,
    "cache_hit_tokens": usage.get("cache_read_input_tokens", 0),
    "request_type": "ticket_summary",
}
print(record)

Después, calcula el coste de forma centralizada:

def estimate_cost(input_tokens, output_tokens, input_rate, output_rate):
    return (input_tokens * input_rate) + (output_tokens * output_rate)

Las tarifas exactas dependen de tu proveedor y del modelo, pero el flujo de trabajo sigue siendo el mismo. Una vez que puedes ordenar las solicitudes por coste, los responsables suelen saltar a la vista:

• Un prompt «pequeño» con un enorme prefijo oculto
• Una llamada a una herramienta que vuelve a enviar documentos completos en cada turno
• Un límite de generación que es 10x lo que necesita la tarea
• Un bucle de reintentos que duplica silenciosamente el uso
• Una ruta que debería usar Haiku, pero siempre usa Opus

Evita el desperdicio silencioso

La mayor parte del desperdicio de tokens es poco llamativa, por eso pasa desapercibida en las revisiones de código.

Causas habituales

• Volver a enviar el mismo historial largo de conversación en cada turno
• Incluir archivos de código fuente completos cuando solo se necesita una diferencia de código
• Pedir texto en prosa cuando bastaría con JSON estructurado
• Devolver explicaciones extensas a sistemas que consumen la salida
• Pasar esquemas de herramientas que son más grandes que la tarea en sí
• Permitir que los reintentos automáticos vuelvan a ejecutar el mismo prompt costoso
• Mantener registros o notas internas dentro del contexto del modelo

Una trampa especialmente problemática es la «ampliación útil del contexto». Los sistemas de recuperación suelen obtener demasiada información porque alguien quería ir sobre seguro. Si el modelo solo necesita los tres párrafos más relevantes, no le proporciones el documento completo solo porque la capa de fragmentación lo facilite.

Otra: si añades una segunda capa de instrucciones al modelo con un prompt que dice «sé conciso», puede que acabes de añadir tokens para resolver un problema de verbosidad que debería haberse resuelto con un esquema de salida más restrictivo.

Un diseño práctico de solicitud

Este es un patrón que funciona bien para muchas tareas en producción:

request = {
    "model": "claude-sonnet-4.6",
    "max_tokens": 180,
    "system": "Extract the root cause and next action. Return strict JSON.",
    "messages": [
        {
            "role": "user",
            "content": "Investigate this incident summary: ... "
        }
    ]
}

Por qué funciona esta estructura:

• El modelo elegido tiene capacidad suficiente para un razonamiento de complejidad moderada.
• El límite de salida restringe la verbosidad descontrolada.
• El prompt de sistema es breve y específico.
• El formato de salida es fácil de procesar por máquinas.
• Los datos enviados por el usuario contienen únicamente la entrada necesaria para la tarea.

Si necesitas más contexto, añádelo de forma deliberada. No dejes que se acumule por accidente.

Lo que realmente influye en la factura

Si tuviera que ordenar las mejoras con mayor impacto, sería así:

1. Elige un modelo más barato para las tareas sencillas
2. Reduce el exceso de contenido del prompt
3. Limita max_tokens de forma estricta
4. Usa el almacenamiento en caché de prompts para prefijos estables
5. Agrupa en lotes las tareas pequeñas e independientes
6. Mide el uso por solicitud
7. Evita que los bucles de reintentos dupliquen el gasto

Ese orden importa. Los equipos suelen empezar con optimizaciones sofisticadas antes de corregir lo evidente: simplemente están pidiendo demasiado, con demasiada frecuencia, al modelo más caro y con demasiado contexto.

Conclusiones prácticas

• Usa Haiku para la extracción y el enrutamiento sencillos, Sonnet para la mayoría de las tareas de producto, y Opus solo cuando la tarea lo justifique.
• Trata la prompt de sistema como un centro de costes; elimina la prosa repetida y conserva solo las instrucciones que cambien el comportamiento.
• Activa el almacenamiento en caché de prompts para prefijos estables, como políticas, esquemas de herramientas y ejemplos de aprendizaje con pocas muestras.
• Configura max_tokens al límite útil más bajo y revísalo para cada tarea.
• Agrupa en lotes las tareas pequeñas e independientes cuando predomine la sobrecarga de instrucciones.
• Registra los tokens de entrada, los tokens de salida, los aciertos de caché, los reintentos y la latencia por solicitud.
• Vigila el desperdicio silencioso: historial repetido, recuperación excesiva de información, salidas extensas y bucles de reintentos automáticos.

Si quieres, puedo convertir esto en un artículo complementario con un ejemplo concreto de panel de costes y algunas reglas de enrutamiento para Haiku/Sonnet/Opus.