Calculadora de Costes LLM 2026: Coste por Tarea, No por Token

La unidad útil para una factura de LLM no es un millón de tokens. Es una tarea completada: un ticket de soporte respondido, una factura extraída, una pull request revisada, una pregunta interna resuelta. El precio por token es solo la lista de precios. El coste por tarea es la realidad de la factura después de reintentos, llamadas a herramientas, contexto, aciertos de caché, routing, descuentos por batch y salidas fallidas.

Perspectiva de ingeniería, no asesoramiento de precios. Las fórmulas son estables; los precios de ejemplo son orientativos y deben reemplazarse por precios actuales antes de comprometer presupuesto. A 8 de julio de 2026: OpenAI lista un descuento del 50% para Batch API y una ventana de 24 horas, OpenAI prompt caching empieza a partir de 1.024 tokens de prompt, Anthropic cobra las lecturas de caché a 0,1x del precio base de input y su Batches API al 50% del precio estándar, y Gemini activa caching implícito por defecto para Gemini 2.5 y modelos posteriores. Revisa las fuentes primarias enlazadas antes de presupuestar.

La calculadora en una fórmula

Empieza con una tarea, no con una llamada API. Una tarea puede incluir varias llamadas al modelo, retrieval, herramientas, un verificador y a veces un reintento. El coste completo es:

Coste por tarea completada = coste del modelo en todas las llamadas + retrieval e infraestructura + reintentos + retrabajo humano.

Por eso escribimos sobre coste por token frente a coste por tarea. Un modelo más barato que necesita más turnos, escribe salidas más largas o falla más a menudo puede salir más caro que el modelo con la lista de precios incómoda.

Qué entradas debe tener la calculadora

• Volumen de tareas. Cuenta unidades de negocio reales: tickets, documentos, presupuestos, pull requests, checks, informes de research.
• Llamadas por tarea. Los flujos agentic gastan mucho en bucles: clasificación, retrieval, borrador, herramienta, verificador, reescritura y resumen de auditoría.
• Input medio por llamada. Separa prefijo estable, contexto recuperado, historial, esquemas de herramientas y datos volátiles del usuario.
• Output medio por llamada. Los agentes de razonamiento y coding pueden ser muy pesados en output.
• Tasa de caché. Mide tokens cacheados, no solo requests. OpenAI expone `cached_tokens`; Gemini expone conteos de tokens cacheados; Anthropic separa escritura y lectura de caché.
• Parte batchable. Todo lo que puede esperar debe ir primero a batch: evals, extracción offline, enrichment, clasificación, resúmenes.
• Tasa de escalado. Si un modelo barato hace el primer pase y uno fuerte cubre los casos difíciles, ese porcentaje es un KPI de producto.
• Suelo de calidad. Pon la tasa de aprobado del eval junto al coste. Sin eso comparas facturas e ignoras si el trabajo sigue funcionando.

"Si tu calculadora no muestra cuánto cuesta una tarea exitosa, no es una calculadora de costes de IA. Es un recibo de tokens."

Ejemplo: triage de soporte

Un flujo de soporte lee un ticket, recupera políticas, redacta una respuesta y verifica si está fundamentada. La hoja ingenua dice: una llamada de respuesta, quizá 4.000 tokens de input y 600 de output. El trace de producción dice otra cosa:

El coste del modelo no es la llamada de respuesta. Son 3,18 llamadas de media, más retrieval, más la cola de reintentos. Si el 60% del input del borrador es prompt de sistema, política y esquema de herramientas estable, el prompt caching pesa más que cambiar de modelo. Si solo el 20% de tickets necesita el modelo fuerte, routing pesa más que ahorrar unos céntimos en el modelo por defecto. Es el mismo patrón que nuestro manual para reducir costes de tokens LLM, pero convertido en calculadora.

Cómo entra el prompt caching

Coste de input = uncached_input * normal_input_price + cached_input * cache_read_price + cache_writes * cache_write_price.

La táctica operativa es simple: contenido estable primero, contenido volátil al final. OpenAI recomienda colocar contenido estático o repetido al principio para prompts de 1.024 tokens o más. Anthropic cobra cache reads a 0,1x, mientras que los cache writes cuestan más que input normal, así que la escritura se paga sola solo cuando se reutiliza. Gemini indica que el caching implícito está activo por defecto para Gemini 2.5 y modelos posteriores, y recomienda poner el contenido común grande al inicio.

• Buen prefijo de caché: instrucción de sistema, definiciones de herramientas, esquema de salida, política de producto, contexto estable.
• Mal prefijo de caché: timestamp, ID de usuario, trace aleatorio, documento de la request, cuerpo del ticket.
• Métrica: tokens de input cacheados dividido por tokens de input totales, por feature y modelo.

Fuentes primarias: OpenAI prompt caching, Anthropic prompt caching y Gemini context caching.

Cómo entran las Batch APIs

Coste total del modelo = live_cost + batchable_cost * batch_multiplier.

OpenAI documenta un descuento del 50% para Batch API frente a APIs síncronas y una ventana de 24 horas. Anthropic dice que Message Batches reduce los costes en un 50%, con la mayoría de batches terminando en menos de una hora y resultados al completarse todos los mensajes o al llegar a 24 horas. Batch debe ser el defecto para evals, enrichment nocturno, extracción offline, backfills, moderación y resúmenes analíticos.

No pongas en batch una experiencia en vivo donde el usuario espera. Sí pon en batch tu eval harness. Muchos equipos pagan continuamente por re-testear prompts y modelos, y olvidan que esas pruebas no necesitan latencia en vivo. Lo cubrimos en cuándo un eval LLM se paga solo.

Fuentes primarias: OpenAI Batch API y Anthropic batch processing.

Routing: ahorro con trampa de calidad

Coste con routing = cheap_path_cost * (1 - escalation_rate) + strong_path_cost * escalation_rate + verifier_cost.

RouteLLM formula bien la idea: consultas simples a modelos baratos, modelos fuertes para casos difíciles, y un threshold calibrado sobre tráfico parecido al tuyo. Su README reporta hasta 85% de reducción de coste manteniendo el 95% de rendimiento GPT-4 en benchmarks. Trátalo como referencia de investigación, no como tu número de producción.

1. Modelo barato por defecto. Empieza con el modelo más barato que aprueba la mayoría fácil.
2. Verificador. Comprueba esquema, grounding, política y confianza.
3. Escalado. Casos inciertos, caros o fallidos van al modelo fuerte.
4. Puerta de eval. Compara camino barato, camino fuerte y routing sobre ejemplos reales.
5. Monitorización. Si sube el porcentaje fuerte, cambió el tráfico o el modelo barato está sobrecargado.

Aquí ayudan los gateways y routers LLM. LiteLLM, Portkey, OpenRouter o una capa propia con RouteLLM centralizan logs, mezcla de modelos, fallback, presupuestos y routing.

Investigación y herramientas: RouteLLM, paper de RouteLLM, routing por batch bajo coste y capacidad y routing con batch prompting.

Modelos locales y self-hosting

Self-hosting no convierte la inferencia en gratis. Cambia coste variable por coste de GPU, riesgo de utilización, ops, redundancia y mantenimiento de evals:

Coste self-host por tarea = (gpu_hour_cost + ops_hour_cost + redundancy + monitoring + eval_upkeep) / completed_tasks_per_hour.

El denominador decide. Una GPU al 80% todo el día puede tener sentido. Una GPU al 12% porque tu tráfico llega en picos es un símbolo de soberanía muy caro. Por eso nuestra guía de coste de self-hosting LLM en la UE empieza por volumen y residencia de datos, no por la ficha de la GPU.

• Residencia de datos o governance obliga. Entonces el coste es la segunda pregunta.
• Volumen alto y estable llena el hardware. Contra APIs open-weight baratas, necesitas carga sostenida, no picos ocasionales.

La elección de modelo viene después. Nuestra comparación de LLM open-weight cubre DeepSeek, Qwen, Kimi, GLM y Llama desde una perspectiva europea de despliegue. La calculadora debe incluir la tasa de aprobado en tu eval, no solo tokens por segundo.

Compresión de contexto y semantic caching

• Semantic caching. Si una nueva petición se parece lo suficiente a una anterior, devuelves la respuesta previa o una adaptación ligera. Ahorra mucho en soporte repetitivo y asistentes internos, pero puede crear respuestas obsoletas, personalizadas de forma incorrecta o no autorizadas.
• Compresión de contexto. Envía el contexto correcto más pequeño: resúmenes, mapas de archivos, snippets relevantes y salidas de herramientas podadas en lugar de reenviar todo el workspace.

Esto conecta con por qué los agentes de coding fallan por contexto, no por inteligencia, y con nuestro texto sobre ahorro de tokens renderizando texto como imagen. La compresión es potente, pero valores exactos, IDs, importes, hashes, cláusulas legales y permisos deben seguir exactos. Si la optimización tiene pérdidas, la calculadora necesita una línea de coste de fallo.

Una hoja que puedes copiar

En qué orden optimizar

1. Instrumenta coste por tarea. Loguea task ID, modelo, tokens, cache hits, reintentos, latencia, estado y veredicto del eval.
2. Tómate en serio el caching. Prefijo estable primero, datos volátiles al final.
3. Pon en batch el trabajo offline. Evals y enrichment no deberían pagar precios live.
4. Routea con verificador. Default barato, fallback fuerte, tasa de escalado monitorizada.
5. Ajusta el modelo al trabajo. Prueba modelos open-weight y modelos pequeños en tu eval.
6. Comprime contexto. Quita historial irrelevante y contexto repetido.
7. Self-host solo por volumen o governance. Precia utilización e ingeniería, no solo horas GPU.