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. Revisión completa el 2 de septiembre de 2026; precios y elegibilidad pueden cambiar. OpenAI publica 50% menos de coste batch y finalización en 24 horas. El mínimo de caché es 1.024 tokens visibles para GPT-5.6 y posteriores, 2.048 para modelos anteriores; desde GPT-5.6 escribir cuesta 1,25x y leer 0,1x. Anthropic cobra 1,25x por escritura de 5 minutos, 2x por una hora, 0,1x por lectura y 50% del precio estándar en batch. Gemini activa caché implícita para 2.5 y posteriores con mínimos por modelo. Revisa fuentes y factura 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 exitosa = (llamadas iniciales + reintentos y fallbacks + retrieval e infraestructura + retrabajo humano) / tareas exitosas.

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_tokens / 1M × normal_input_price) + (cache_read_tokens / 1M × cache_read_price) + (cache_write_tokens / 1M × cache_write_price).

Coloca contenido estable antes que datos volátiles. OpenAI documenta mínimos por modelo: 1.024 tokens visibles para GPT-5.6 y posteriores, 2.048 para modelos anteriores. Desde GPT-5.6, escribir cuesta 1,25x y leer 0,1x; modelos anteriores tienen reglas distintas. Anthropic cobra 1,25x por escritura de 5 minutos, 2x por una hora y 0,1x por lectura. Gemini activa caché implícita para 2.5 y posteriores; los mínimos listados van hoy de 2.048 a 4.096 tokens. Calcula con las categorías de usage observadas.

• 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 = coste síncrono + Σ coste batch real por categorías de input, escritura de caché, lectura de caché y output.

OpenAI documenta 50% menos de coste batch y finalización en 24 horas. Anthropic cobra 50% del precio estándar; la mayoría termina en una hora y los incompletos expiran a las 24 horas. Batch es candidato para evals y trabajos offline que toleren esa semántica. Usa precios reales de input, output y caché batch por categoría, no multipliques a ciegas un total ya descontado.

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 exitosa = (amortized_compute_per_hour + ops_per_hour + redundancy_per_hour + monitoring_per_hour + eval_upkeep_per_hour) / successful_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.

Si esta cifra es el motivo por el que un proyecto está parado, la solución suele ser arquitectónica y no aritmética. Instrumentar el gasto y luego rehacer el enrutado, el caching y el retrieval hasta que se mueva el coste por tarea completada es lo que hace nuestro servicio de habilitación de IA. Hyperstate AI es un caso publicado en el que dividir un monolito intensivo en GPU redujo latencia y coste, y nuestra guía de selección tecnológica aborda esta decisión antes de que exista la factura.