Claude Sonnet 4.5 con herramientas: calcula el coste de una tarea, no solo de una llamada

El coste de una llamada no es el coste de una tarea

Una integración puede mostrar una sola petición de usuario y, sin embargo, enviar varias solicitudes a Claude antes de terminar el trabajo. El modelo puede proponer el uso de una herramienta; la aplicación ejecuta esa operación y devuelve su resultado; después, el modelo vuelve a procesar el contexto y decide si responde o necesita otra herramienta. Para estimar el gasto de la tarea hay que contar cada solicitud al modelo, no solo la petición inicial ni la respuesta final.

Esta guía propone una hoja de cálculo para Claude Sonnet 4.5. Separa los tokens de entrada, los de salida y los cargos que puedan corresponder a herramientas alojadas en servidor. No incluye caché ni Batch API. Tampoco supone que todas las tareas tengan el mismo número de rondas: una búsqueda sencilla, un flujo de varios pasos y un intento fallido pueden tener costes distintos.

El cálculo se refiere al uso de la API de Claude y a un flujo acotado cuya aplicación ejecuta herramientas. No debe trasladarse automáticamente a Bedrock, Google Cloud u otra plataforma: pueden intervenir identificadores, tarifas, unidades de facturación o calendarios distintos. Para enlazar con la guía de precios, puede consultarse la ruta interna pricing.index; para el modelo, Claude Sonnet 4.5; y para el proveedor, Anthropic.

Fija modelo, canal e identificador antes de estimar

El nombre comercial no basta para reproducir un cálculo. Para Claude API, la documentación de identificadores distingue el alias claude-sonnet-4-5 de la versión fechada claude-sonnet-4-5-20250929. La página de ciclo de vida aportada identifica esa versión como activa y señala que su retirada no será antes del 29 de septiembre de 2026. Es una referencia útil, no una garantía de disponibilidad futura: comprueba el estado justo antes de publicar o reutilizar la hoja.

Registra también el canal. Las páginas de Anthropic describen identificadores equivalentes para otros proveedores, pero no se debe asumir que un mismo precio, calendario o formato de uso se aplica a todos ellos. La tarifa que se introduzca en la hoja debe corresponder al canal real y a la fecha de la ejecución. La documentación de precios es la referencia para verificar las tarifas vigentes, posibles diferencias regionales y condiciones de plataformas asociadas.

Como el material de verificación aportado no incluye las cifras actuales de tarifa de entrada y salida ni el importe de las diferencias regionales, no se presentan aquí como datos confirmados. La plantilla mantiene esas tarifas como campos editables. Antes de convertir el resultado en presupuesto, sustitúyelos por los valores que muestre la documentación aplicable y anota la fecha de consulta.

Cuenta una ronda completa del ciclo de herramientas

En el uso de herramientas del lado del cliente, una respuesta del modelo puede contener una solicitud de uso de herramienta. La aplicación ejecuta la acción y envía un resultado de herramienta en un mensaje posterior; entonces el modelo procesa la continuación. Ese intercambio puede repetirse. El mensaje que solicita la herramienta no equivale a una tarea terminada.

Para cada solicitud al modelo, cuenta la entrada realmente enviada en esa solicitud. Puede incluir el mensaje de sistema, mensajes anteriores, definiciones de herramientas, el mensaje del usuario y resultados previos que la aplicación haya mantenido en el contexto. Si una nueva petición vuelve a incluir contenido anterior, ese contenido vuelve a formar parte del cómputo de entrada de esa petición. No cuentes el resultado de la herramienta como entrada del modelo hasta que efectivamente se lo envíes.

La salida también se cuenta por solicitud. En una ronda intermedia puede consistir en una instrucción de herramienta y argumentos; en la última, en una respuesta dirigida al usuario. No supongas que una salida intermedia tiene coste cero. Para Claude Sonnet 4.5, el uso de herramientas puede añadir tokens de sistema asociados a la herramienta elegida. El número depende de la configuración; la documentación de precios es la fuente para comprobarlo. No se debe sumar un valor genérico sin verificar qué herramienta y modalidad se usan.

Una herramienta alojada en el servidor requiere una separación adicional. Sus operaciones pueden tener cargos propios y algunos bucles pueden ejecutarse internamente en el servicio. En ese caso, no siempre equivale cada operación interna a una llamada visible del cliente. Mantén por separado el contador de solicitudes al modelo y el contador de operaciones de herramienta, y factura cada concepto según su unidad documentada.

Plantilla de cálculo por ronda y por tarea

Organiza la hoja con una fila por solicitud al modelo y otra tabla, o un bloque separado, para cargos de herramientas. Para cada fila de modelo anota tokens de entrada facturables, tokens de salida facturables, precio de entrada y precio de salida, todos correspondientes al canal y fecha registrados. Si se usa una herramienta alojada, registra además cada operación que facture esa herramienta. Así se puede sumar el gasto de una tarea sin mezclar unidades.

La estimación por tokens de cada llamada es: (tokens de entrada ÷ unidad de tarifa) × precio de entrada + (tokens de salida ÷ unidad de tarifa) × precio de salida. La unidad de tarifa debe ser la que publique el proveedor; si el precio se expresa por millón de tokens, la unidad es un millón. Para una tarea, suma el resultado de todas las llamadas al modelo y añade, por separado, los cargos de herramientas aplicables.

La suma de entrada no debe deduplicar el contexto de manera teórica. Si un mensaje de sistema, un esquema de herramienta o un resultado previo aparece en tres solicitudes facturables, cuenta el uso registrado en cada solicitud, aunque el texto sea idéntico. A la inversa, no añadas tokens estimados para contenido que no se envió. Cuando falten medidas fiables, marca la cifra como estimación y contrástala con la herramienta de conteo de tokens o con los datos de uso devueltos por la API.

Tres escenarios ilustrativos

Los escenarios siguientes explican cómo estructurar el conteo, no predicen un uso universal. Los volúmenes de tokens son números de ejemplo para practicar la hoja, no mediciones de Claude ni tarifas publicadas. Para obtener un coste monetario real, reemplaza los tokens ilustrativos con los registros de tu aplicación y los precios verificados para tu canal.

Escenario A: una consulta respondida sin herramientas. Cuenta la única petición al modelo, incluidos los mensajes y el contexto enviados, y la salida generada. Si la aplicación incorpora una definición de herramienta aunque no se use, revisa el contenido efectivo de la solicitud y no supongas que esa definición fue gratuita o inexistente. En este caso hay una sola ronda de modelo, pero eso no significa que todas las consultas del producto tengan el mismo coste.

Escenario B: una pregunta que requiere una búsqueda. Cuenta la primera llamada, la respuesta que solicita la herramienta, la operación de búsqueda y la llamada posterior que incluye el resultado. Si se utiliza una herramienta alojada en servidor, registra su cargo con la unidad indicada por su documentación; no lo conviertas en tokens. Si la aplicación integra una búsqueda externa del lado del cliente, registra el gasto externo que corresponda fuera de la factura de tokens de Claude.

Escenario C: una acción con varias llamadas secuenciales o un intento fallido. Si la primera herramienta devuelve un error y la aplicación solicita al modelo que lo corrija, suma esa llamada y las siguientes. Si el proceso se reinicia como un intento nuevo, conserva el identificador del intento y suma su consumo al coste de la tarea completada. Informar solo del intento exitoso ocultaría el gasto necesario para alcanzar el resultado.

Qué variables pueden cambiar el resultado

El número de rondas suele ser una variable decisiva. Una tarea que termina tras la primera respuesta puede tener menos llamadas que otra que requiere tres decisiones del modelo. Pero no atribuyas toda diferencia al modelo: puede depender de la lógica de la aplicación, del estado de la herramienta, de la calidad de los datos, del límite de reintentos o del criterio de éxito.

También influye cuánto contexto conserva el cliente. Enviar definiciones extensas, mensajes anteriores y resultados voluminosos puede aumentar la entrada de rondas posteriores. Reducir el historial puede cambiar el consumo, pero solo es correcto si se mantiene la información necesaria para la tarea. Mide el efecto en una ejecución controlada en vez de asumir que el contexto se resume o se cobra una sola vez.

Los esquemas de herramientas y los tokens de sistema asociados añaden otra variable. La cantidad concreta depende de la herramienta y la configuración, por lo que debe comprobarse en la documentación de precios y en el conteo de la solicitud. Un resultado de herramienta largo también puede elevar la entrada de la siguiente llamada, siempre que se envíe al modelo.

Por último, separa las tareas fallidas, los reintentos automáticos y las correcciones solicitadas por el usuario. Un presupuesto basado en el promedio de tareas completadas puede subestimar el gasto si omite intentos fallidos. Conviene publicar tanto el coste por intento como el coste agregado por tarea completada, junto con el periodo y el conjunto de ejecuciones medido.

Contrasta la hoja con producción y declara exclusiones

Para una auditoría, conserva un identificador de tarea y de intento, el identificador del modelo, el canal, el número de cada solicitud, las herramientas disponibles, los resultados enviados al modelo y los datos de uso de cada respuesta. Registra también las llamadas fallidas y las operaciones que no llegaron a producir una respuesta útil. Evita guardar datos personales o secretos que no sean necesarios para el análisis; las métricas de coste pueden asociarse a identificadores internos seudónimos.

La documentación de la API incluye un endpoint de conteo de tokens que admite mensajes, instrucciones de sistema y herramientas. Puede ayudar a estimar una solicitud antes de enviarla. No sustituye el contraste con el uso devuelto en ejecución ni con la factura final, especialmente cuando hay múltiples rondas, errores o cargos de herramientas. Usa la estimación previa para planificar y los registros efectivos para auditar.

Compara el coste calculado con la factura dentro de un periodo y canal equivalentes. Investiga discrepancias buscando llamadas ausentes, unidades de tarifa mal interpretadas, diferencias regionales o cargos separados por herramientas. Mantén una columna de exclusiones explícitas. En este cálculo quedan fuera caché y Batch API; pueden requerir tratamientos propios y no deben añadirse a la fórmula como si fueran parte del flujo base.

Una cifra útil no es necesariamente una predicción exacta. Publica el método, la fecha de precios, el conjunto de tareas, el número de intentos y las exclusiones. Si la muestra contiene poca variedad, preséntala como resultado de esa muestra, no como coste típico de cualquier tarea con Sonnet 4.5.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.