Calcular el coste de Claude Opus 4.7 no consiste solo en mirar cuántos tokens tiene una petición aislada. La factura se dispara cuando una aplicación reenvía el mismo documento largo, o todo el historial de una conversación, en cada turno. Si ese contexto se reutiliza, el prompt caching puede ser la frontera entre un coste asumible y uno incómodo.
Anthropic indica que los desarrolladores pueden usar claude-opus-4-7 mediante la Claude API.[11] Los ejemplos de esta guía usan únicamente los precios públicos de la Claude API; no incluyen contratos empresariales, endpoints de plataformas cloud, routers de terceros, impuestos ni variaciones por tipo de cambio.
Primero: entender el precio por MTok
La documentación de precios de Claude API publica las tarifas de Claude Opus 4.7 por millón de tokens, o MTok: entrada base, salida y prompt caching.[2]
| Concepto de facturación | Precio público de Claude Opus 4.7 |
|---|---|
| Tokens de entrada base | 5 USD / 1M tokens |
| Tokens de salida | 25 USD / 1M tokens |
| Escritura de caché de 5 minutos | 6,25 USD / 1M tokens |
| Escritura de caché de 1 hora | 10 USD / 1M tokens |
| Cache hit / refresh | 0,50 USD / 1M tokens |
Sin caché, la fórmula básica es:[2]
Coste = input_tokens / 1.000.000 × 5
+ output_tokens / 1.000.000 × 25Con prompt caching, conviene separar el contexto reutilizable del resto: la primera escritura en caché de 5 minutos se cobra a 6,25 USD/MTok; la de 1 hora, a 10 USD/MTok; los usos posteriores con cache hit o refresh se cobran a 0,50 USD/MTok. Las preguntas nuevas o mensajes no cacheados siguen pagando el precio normal de entrada, y la respuesta del modelo sigue pagando el precio de salida.[2]
Documento largo de un solo uso: input + output
Si vas a analizar un documento una sola vez y no habrá preguntas posteriores, el cálculo es directo: documento, instrucciones del sistema y pregunta cuentan como tokens de entrada; la respuesta del modelo cuenta como tokens de salida. Con el precio público de la Claude API, quedarían ejemplos así:[2]
| Caso | Entrada | Salida | Coste estimado |
|---|---|---|---|
| Resumen de documento largo, pero moderado | 100k | 5k | aprox. 0,625 USD |
| Análisis de documento mediano-grande | 300k | 8k | aprox. 1,70 USD |
| Análisis de documento muy grande | 1M | 10k | aprox. 5,25 USD |
Ejemplo con 300k tokens de entrada y 8k de salida:
300.000 / 1.000.000 × 5 = 1,50
8.000 / 1.000.000 × 25 = 0,20
Total = 1,70 USDSi migras desde un modelo anterior, no conviene reutilizar sin más las estimaciones antiguas de tokens. Anthropic señala que Opus 4.7 usa un nuevo tokenizer, y que el número de tokens para un texto fijo puede aumentar hasta un 35%.[2]
Por ejemplo, una estimación original de 300k tokens de entrada puede presupuestarse de forma conservadora como 405k. Con 8k tokens de salida:
405.000 / 1.000.000 × 5 = 2,025
8.000 / 1.000.000 × 25 = 0,20
Total ≈ 2,23 USDEl mismo documento con varias preguntas: ahí manda la caché
En productos basados en documentos largos, el coste que más se subestima no suele ser la respuesta del modelo, sino reenviar el mismo texto enorme en cada turno. Si un documento se consultará varias veces, el prompt caching debería entrar en el modelo de presupuesto desde el principio.[2]
Supongamos:
- Documento: 300k tokens
- Nueva pregunta por turno: 2k tokens
- Respuesta por turno: 2k tokens de salida
- Caché de prompt de 5 minutos
| Estrategia | Composición del coste | Coste estimado |
|---|---|---|
| Primera consulta: crear caché de 5 minutos | 300k × 6,25 USD/MTok + 2k × 5 USD/MTok + 2k × 25 USD/MTok | aprox. 1,935 USD |
| Consulta posterior con cache hit | 300k × 0,50 USD/MTok + 2k × 5 USD/MTok + 2k × 25 USD/MTok | aprox. 0,21 USD |
| Sin caché: reenviar todo cada vez | 302k × 5 USD/MTok + 2k × 25 USD/MTok | aprox. 1,56 USD |
En este ejemplo, la primera ronda con caché es más cara que una petición sin caché. Pero a partir de la segunda consulta sobre el mismo documento, el coste total ya baja:
Sin caché, dos turnos: aprox. 1,56 × 2 = 3,12 USD
Con caché de 5 minutos, dos turnos: aprox. 1,935 + 0,21 = 2,145 USDPor eso, en preguntas y respuestas sobre documentos largos, la métrica clave es la tasa de cache hit: si el documento se consulta realmente varias veces, si las preguntas llegan dentro de la ventana de caché y si cada turno añade mucho contenido nuevo no cacheado.[2]
Conversaciones largas: no recalcules todo el historial en cada turno
La lógica para chats largos es parecida. Si la aplicación reenvía una gran cantidad de historial en cada mensaje, el coste de entrada crece muy rápido. El contexto estable y reutilizable debería evaluarse como candidato a prompt caching.[2]
Supongamos:
- Historial de conversación: 200k tokens
- Nuevo mensaje por turno: 1k tokens
- Salida por turno: 2k tokens
| Estrategia | Coste estimado |
|---|---|
| Sin caché: 200k de historial + 1k mensaje nuevo + 2k de salida en cada turno | aprox. 1,055 USD / turno |
| Escribir 200k de historial en caché de 5 minutos: primer turno | aprox. 1,305 USD |
| Después, con cache hit de 5 minutos | aprox. 0,155 USD / turno |
| Escribir 200k de historial en caché de 1 hora: primer turno | aprox. 2,055 USD |
| Después, con cache hit de 1 hora | aprox. 0,155 USD / turno |
La elección entre caché de 5 minutos y de 1 hora no debería depender solo del precio de escritura. Depende del comportamiento real del usuario:
- Si suele hacer varias preguntas seguidas en menos de 5 minutos, empieza modelando la caché de 5 minutos.
- Si vuelve con frecuencia después de más de 5 minutos, pero normalmente dentro de una hora, la caché de 1 hora cuesta más al principio, pero puede evitar reconstrucciones repetidas.
- Si los intervalos son impredecibles, conviene medir tráfico real, calcular la tasa de cache hit y ajustar la arquitectura.
Tareas por lote: presupuesta primero con el precio síncrono
Las tareas batch suelen aparecer en análisis offline, etiquetado de datos, resúmenes masivos o clasificación a gran escala. Pero si todavía no has confirmado qué precio por lote se aplica a tu cuenta, contrato o endpoint, no es prudente incluir descuentos no verificados en un presupuesto formal. Una forma conservadora es estimar primero con el precio público síncrono y después sustituirlo por la tarifa real cuando la tengas confirmada.[2]
La fórmula conservadora sería:
Coste total = tokens de entrada totales / 1.000.000 × 5
+ tokens de salida totales / 1.000.000 × 25Ejemplo: 10.000 tareas, cada una con 2k tokens de entrada y 500 tokens de salida.
Entrada total = 10.000 × 2.000 = 20.000.000 tokens
Salida total = 10.000 × 500 = 5.000.000 tokens
Coste de entrada = 20 × 5 = 100 USD
Coste de salida = 5 × 25 = 125 USD
Total = 225 USDEse total de 225 USD es una estimación conservadora sin aplicar ningún descuento batch. Si después confirmas una tarifa por lote, basta con reemplazar los precios unitarios.
También importa por dónde accedes al modelo. Si no llamas directamente a la Claude API de Anthropic y usas una plataforma cloud o un router de terceros, la factura puede cambiar. CloudPrice, una fuente de terceros, lista Opus 4.7 en Anthropic / global a 5 USD de entrada y 25 USD de salida por MTok, y también muestra algunos códigos regionales de AWS Bedrock a 5,50 USD de entrada y 27,50 USD de salida por MTok. Ese tipo de referencia sirve como alerta de comprobación; para compras reales, manda la página de facturación de tu plataforma, tu contrato y la documentación oficial aplicable.[12]
Añade margen: el cálculo teórico rara vez basta
Si aún no tienes una distribución real de tokens, un presupuesto puramente teórico suele quedarse corto. Como mínimo, incluye tres colchones:
- Riesgo de tokenizer: el nuevo tokenizer de Opus 4.7 puede aumentar hasta un 35% los tokens de un texto fijo.[
2]
- Incertidumbre de la caché: la caché solo reduce costes de forma notable si el contexto se reutiliza y sigue dentro de la ventana válida.[
2]
- Uso real del producto: los usuarios pueden pedir respuestas más largas, reintentar, subir documentos mayores o mantener conversaciones más extensas de lo previsto.
Como guía no oficial de presupuesto:
| Fase | Multiplicador prudente |
|---|---|
| PoC o prueba inicial | valor teórico × 1,2 a 1,5 |
| Producción con tráfico estable | valor teórico × 1,35 a 1,6 |
| Migración desde un modelo anterior a Opus 4.7 con mucho contexto largo | valor teórico × 1,5 a 1,8 |
Estos multiplicadores no son una tarifa oficial de Anthropic. Son una forma conservadora de gestionar presupuesto. Una vez en producción, lo ideal es recalibrar con logs reales de tokens, tasa de cache hit y facturas.
Plantilla rápida de cálculo mensual
Sin caché:
Coste mensual ≈ solicitudes diarias × 30
× (input medio / 1.000.000 × 5
+ output medio / 1.000.000 × 25)Con caché, separa los componentes:
Coste mensual ≈ coste de entrada normal
+ coste de escrituras de caché
+ coste de cache hit / refresh
+ coste de salidaAntes de implementar, al menos rellena estas variables:
| Variable | Ejemplo |
|---|---|
| Tokens medios de entrada por petición | 300.000 |
| Tokens medios de salida por petición | 8.000 |
| Solicitudes diarias | 1.000 |
| Tokens de cache write | 300.000 por documento |
| Tokens de cache hit | 300.000 por acierto |
| Tasa de cache hit | 60% |
| Margen por cambio de tokenizer | hasta × 1,35 |
| Margen operativo | por ejemplo × 1,35 a 1,6 |
Regla práctica final
Para un análisis único de documento largo, usa directamente 5 USD/MTok de entrada y 25 USD/MTok de salida.[2]
Para el mismo documento con varias preguntas, o para conversaciones largas que arrastran mucho historial, calcula el prompt caching desde el diseño. En el ejemplo de documento de 300k tokens, pregunta de 2k y salida de 2k, una segunda ronda con caché de 5 minutos cuesta unos 0,21 USD; reenviar todo cada vez cuesta unos 1,56 USD.[2]
Para batch jobs, empieza con el precio público síncrono si aún no tienes confirmado el descuento, endpoint o contrato aplicable. Y si migras desde un modelo anterior a Opus 4.7, presupuestar la entrada con un margen de hasta ×1,35 por tokenizer, más un colchón operativo, suele estar más cerca de la factura real que mirar solo el precio de lista.[2]
