En febrero, la cuenta oficial de Claude publicó una promoción: el doble de uso si lo utilizas fuera de horas pico. Un analista de producto llamado Aakash Gupta desmenuzó los números: Anthropic está gastando alrededor de $7B en infraestructura de inferencia, y sus GPUs están ociosas aproximadamente el 75% de la semana.

Eso no es un truco de marketing. Es demand shaping — el mismo mecanismo que usa tu compañía eléctrica cuando cobra menos por poner la secadora a medianoche. Y señala algo que la mayoría de los equipos de IA empresarial no han internalizado: cuándo llamas a un modelo importa tanto como qué modelo llamas.

En nuestro análisis de economía de IA empresarial, cubrimos qué modelos tienen sentido financiero y cuándo conviene construir vs. comprar. Ese post respondía “¿podemos costear la IA?” Este responde una pregunta diferente: “¿cómo gastamos menos en la IA que ya estamos usando?”

Qué revela realmente la promoción off-peak de Anthropic

La promoción al consumidor (más uso fuera de horas pico) es la punta visible. La señal empresarial debajo es mucho más grande.

La infraestructura de inferencia de IA sigue la misma economía que cualquier servicio con capacidad limitada. Las GPUs son caras. Se deprecian estén computando o paradas. Los proveedores necesitan aplanar la curva de demanda para mejorar los unit economics — exactamente lo que las compañías eléctricas descubrieron hace décadas.

El movimiento de Anthropic refleja una evolución que ya vimos en cloud computing. AWS lanzó spot instances en 2009 como una forma de vender capacidad EC2 sobrante con descuento. Ese experimento se convirtió en una capa de precios que hoy sostiene workloads empresariales masivos. Después vinieron las reserved instances. Después los savings plans.

Los proveedores de IA van por el mismo camino. Hoy es una promoción off-peak al consumidor. Mañana serán precios enterprise por franja horaria, descuentos por uso comprometido y reservas de capacidad. Las empresas que estructuren sus workloads ahora van a estar en posición de capturar esos ahorros cuando lleguen.

Pero no hace falta esperar por futuros modelos de precios. Las palancas ya existen.

Cinco palancas operacionales que la mayoría de las empresas no conocen

Cada semana en IQ Source revisamos arquitecturas de IA empresarial donde el equipo pasó meses seleccionando el modelo correcto pero cero tiempo optimizando cómo lo llama. La factura de API llega, alguien se alarma, y el primer instinto es bajar a un modelo más barato. Esa es la decisión equivocada. Antes de cambiar qué llamas, cambia cómo lo llamas.

Batch APIs: el descuento del 50% escondido a la vista

Tanto Anthropic como OpenAI ofrecen endpoints de procesamiento por lotes con un trato directo: acepta una ventana de procesamiento de 24 horas en lugar de respuestas en tiempo real, y pagas la mitad en cada token.

La pregunta para cada workload: ¿el usuario espera este resultado, o le aparece en un dashboard, reporte o inbox después? Si es lo segundo, es candidato a batch.

Generación de reportes, análisis de contratos, pipelines de enriquecimiento de datos, colas de moderación de contenido, resúmenes nocturnos, borradores de emails para revisión matutina — estos workloads no necesitan latencia de milisegundos. Necesitan resultados para mañana a primera hora. Exactamente lo que las batch APIs entregan, al 50% de descuento.

Prompt caching: 90% menos en tus instrucciones más repetidas

Cada llamada a un modelo de lenguaje incluye un system prompt — las instrucciones que le dicen al modelo cómo comportarse. En aplicaciones empresariales, ese system prompt suele ser el mismo en miles de llamadas: el mismo template, los mismos ejemplos few-shot, las mismas reglas de formato.

El prompt caching almacena ese prefijo repetido para que las llamadas subsecuentes paguen solo el 10% del precio base de input. Para Claude Sonnet 4.6, eso baja los tokens de input cacheados de $3.00/MTok a $0.30/MTok.

Si tu aplicación envía un system prompt de 2,000 tokens con cada request, y haces 10,000 requests/día, son 20M tokens/día solo en system prompts. Sin caching: $60/día. Con caching: $6/día. Mismo modelo, misma calidad de output, mismo system prompt — $1,620/mes ahorrados solo en ese componente.

Scheduling off-peak: posicionarse para la curva de precios

La promoción off-peak para consumidores es un adelanto de hacia dónde se dirigen los precios enterprise. Aunque no existan tiers enterprise formales de off-peak hoy, estructurar tus workloads para correr en ventanas de baja demanda reduce tiempos de cola y te posiciona para precios por horario cuando lleguen.

Para workloads que ya usan batch APIs (ventana de 24 horas), esto pasa naturalmente. Para workloads cerca del tiempo real que toleran algunas horas de retraso — compilación de reportes nocturnos, enriquecimiento de datos temprano en la mañana, corridas batch de fin de semana — programarlos fuera del horario laboral en zonas horarias de EE.UU. es una estrategia práctica.

Consolidación de requests: menos llamadas, mejor rendimiento de caché

Diez llamadas separadas a la API con el mismo system prompt no cachean tan eficientemente como una sola llamada consolidada que procesa diez ítems. Cada llamada tiene overhead — latencia de red, parsing de tokens, búsqueda de caché. Consolidar donde sea posible reduce el costo por unidad y mejora el hit rate de caché.

Esto no significa meter todo en un solo prompt enorme. Significa analizar tus patrones de requests: si estás llamando a la API una vez por fila de una hoja de cálculo, probablemente puedas agrupar 20-50 filas por llamada. Si estás generando borradores de email uno a uno, puedes generar un lote y distribuir.

Optimización de output: pagando por tokens que nadie lee

Esta es la palanca que la mayoría de los equipos pasa por alto completamente. Los tokens de output cuestan entre 3x y 5x más que los de input en todos los proveedores principales. Claude Sonnet 4.6 cobra $3/MTok por input pero $15/MTok por output — un multiplicador de 5x.

Tres ajustes rápidos:

• Output en JSON estructurado en vez de prosa larga. Si el sistema downstream parsea la respuesta de forma programática, no necesitas que el modelo escriba párrafos. Especifica response_format: json y define el schema.
• Configurar max_tokens con intención. Si tu tarea de clasificación necesita una respuesta de una palabra, no dejes el default en 4,096 tokens. No vas a pagar por tokens no usados, pero un modelo sin restricción a veces produce outputs más largos de lo necesario.
• System prompts más cortos. Reescribe las instrucciones priorizando densidad. “Eres un asistente que siempre responde en formato JSON con los siguientes campos…” generalmente se puede comprimir un 40% sin perder comportamiento. Menos tokens de instrucción = menor costo por llamada, especialmente antes de que el caching entre en juego.

Los números: antes y después en tres workloads comunes

La teoría es fácil. Vamos a correr números con precios publicados de Anthropic para Claude Sonnet 4.6 (el modelo que la mayoría de las empresas usa en producción).

Pipeline de análisis de contratos: 500 contratos/mes

Cada contrato promedia 8,000 tokens de input (texto del documento) más un system prompt de 2,000 tokens (template de extracción). El output promedia 1,500 tokens (JSON estructurado con cláusulas clave, fechas, partes, obligaciones).

Antes de optimizar (API estándar):

Componente	Tokens/llamada	Llamadas/mes	Tokens mensuales	Costo/MTok	Costo mensual
Input (documento + system prompt)	10,000	500	5M	$3.00	$15.00
Output (datos extraídos)	1,500	500	750K	$15.00	$11.25
Total					$26.25

Después de optimizar (batch + caching + ajuste de output):

El system prompt de 2,000 tokens es idéntico en las 500 llamadas — candidato ideal para caching. La extracción no necesita resultados en tiempo real — candidato para batch. El output ya es JSON estructurado, pero ajustar el schema elimina ~20% de los tokens de output.

Componente	Tokens/llamada	Llamadas/mes	Tokens mensuales	Costo/MTok	Costo mensual
Input cacheado (system prompt, batch)	2,000	500	1M	$0.15	$0.15
Input no cacheado (documento, batch)	8,000	500	4M	$1.50	$6.00
Output (schema ajustado, batch)	1,200	500	600K	$7.50	$4.50
Total					$10.65

Ahorro: $15.60/mes por pipeline (reducción del 59%). A escala empresarial — un departamento legal procesando 5,000 contratos/mes con múltiples templates — esos $156/mes se multiplican.

Triage de soporte al cliente: 10,000 tickets/mes

Cada ticket: 500 tokens de texto del cliente, 1,500 tokens de system prompt (reglas de triage, definiciones de categoría, matriz de prioridad), 200 tokens de output (categoría, prioridad, routing, resumen).

Antes de optimizar:

Componente	Tokens/llamada	Llamadas/mes	Tokens mensuales	Costo/MTok	Costo mensual
Input	2,000	10,000	20M	$3.00	$60.00
Output	200	10,000	2M	$15.00	$30.00
Total					$90.00

Este workload tiene una característica crítica: el 75% de los tokens de input son el mismo system prompt repetido 10,000 veces. Y el triage no necesita tiempo real — un retraso de 5 minutos es invisible en una cola de soporte.

Después de optimizar (batch + caching):

Componente	Tokens/llamada	Llamadas/mes	Tokens mensuales	Costo/MTok	Costo mensual
Input cacheado (system prompt, batch)	1,500	10,000	15M	$0.15	$2.25
Input no cacheado (texto del ticket, batch)	500	10,000	5M	$1.50	$7.50
Output (batch)	200	10,000	2M	$7.50	$15.00
Total					$24.75

Ahorro: $65.25/mes (reducción del 72%). El caching del system prompt concentra la mayor parte del ahorro — 15M tokens/mes de instrucciones que se estaban reenviando y cobrando de nuevo en cada llamada.

Generación diaria de reportes: 200 reportes/día

Cada reporte: 3,000 tokens de datos de input, 2,500 tokens de system prompt (template de reporte, reglas de formato, estructura de secciones), 2,000 tokens de output (texto formateado del reporte).

Antes de optimizar:

Volumen mensual: 200 × 22 días laborales = 4,400 reportes.

Componente	Tokens/llamada	Llamadas/mes	Tokens mensuales	Costo/MTok	Costo mensual
Input	5,500	4,400	24.2M	$3.00	$72.60
Output	2,000	4,400	8.8M	$15.00	$132.00
Total					$204.60

Los reportes no necesitan generación en tiempo real. Necesitan estar listos a las 8 AM. El system prompt es idéntico en todos los reportes. Y el output — actualmente párrafos en prosa — podría ser data estructurada que un frontend renderiza, recortando los tokens de output ~35%.

Después de optimizar:

Componente	Tokens/llamada	Llamadas/mes	Tokens mensuales	Costo/MTok	Costo mensual
Input cacheado (template, batch)	2,500	4,400	11M	$0.15	$1.65
Input no cacheado (datos, batch)	3,000	4,400	13.2M	$1.50	$19.80
Output (estructurado, batch)	1,300	4,400	5.72M	$7.50	$42.90
Total					$64.35

Ahorro: $140.25/mes (reducción del 69%). La mayor ganancia acá es la optimización de output — pasar de prosa a JSON estructurado que el frontend formatea ahorra más que el descuento de batch en tokens de output.

El patrón en los tres escenarios

Los ahorros van del 59% al 72%. No porque sea un número redondo para una presentación — sino porque la matemática muestra consistentemente que la mayoría de los workloads empresariales tienen tres características: system prompts repetidos (candidato de caching), tolerancia a resultados diferidos (candidato de batch), y tokens de output que podrían ser estructurados (candidato de optimización de output). Cuando apilas las tres, las reducciones se multiplican.

Cómo auditar tu gasto actual en IA en una tarde

No necesitas un consultor para el paso uno. Necesitas tu dashboard de API y unas cuatro horas.

Extraer los logs de uso de tu API. Todos los proveedores principales (Anthropic, OpenAI, Google) tienen un dashboard de uso que muestra requests por modelo, conteo de tokens (input vs. output), y gasto por período. Exporta los últimos 30 días. Si estás usando múltiples modelos, separa los datos por modelo.

Clasificar cada workload por sensibilidad a latencia. Revisa tus integraciones de API y etiqueta cada una:

• 🔴 Tiempo real — el usuario espera la respuesta (chatbot, asistente en vivo, autocompletado)
• 🟡 Casi tiempo real — resultado necesario en minutos (triage de soporte, procesamiento de alertas)
• 🟢 Asíncrono — resultado necesario en horas o para la mañana siguiente (reportes, análisis, enriquecimiento, pasos nocturnos de agentes)

En nuestra experiencia, la mayoría de los equipos descubren que el 60-70% de sus llamadas a la API caen en las categorías 🟡 o 🟢. Esos son tus candidatos de batch.

Identificar prefijos de prompt repetidos. Busca en tu codebase los system prompts. ¿Cuántos prompts distintos tienes? ¿Cuántas llamadas comparten el mismo? Cualquier prompt que se envíe más de 100 veces/día es un candidato de alto valor para caching. Esto conecta directamente con los patrones de orquestación de agentes — las batch APIs funcionan especialmente bien para los pasos de procesamiento nocturno en workflows de agentes.

Calcular el ratio de tokens input-a-output. Para cada workload, compara tokens de input contra tokens de output. Si estás mandando 5,000 tokens y recibiendo 200 (tareas de clasificación), tu costo está dominado por el input — el caching es tu palanca principal. Si mandas 2,000 y recibes 3,000 (generación de contenido), la optimización de output importa más.

Mapear workloads elegibles a endpoints de batch. Para cada workload 🟡 y 🟢, verifica si tu proveedor ofrece batch API para ese modelo. Tanto Anthropic como OpenAI lo ofrecen. La migración generalmente es directa — mismo formato de prompt, endpoint diferente, resultados devueltos asincrónicamente.

Qué significa esto para tu arquitectura de IA

Elegir el modelo correcto es la decisión que se lleva toda la atención. En nuestro análisis de arquitecturas de modelos por tiers, mostramos cómo rutear el 90% de las requests a modelos eficientes y el 10% a modelos premium reduce costos drásticamente. Esa es la palanca del “qué”.

Las palancas de este post — batch APIs, prompt caching, scheduling off-peak, optimización de output — son las palancas del “cuándo y cómo”. Se apilan encima de la selección de modelo. Una arquitectura por tiers que usa batch APIs y prompt caching multiplica los ahorros de ambos enfoques.

Las empresas que tratan la inferencia de IA como un costo de servicio — analizando curvas de demanda, optimizando scheduling, cacheando operaciones repetidas — van a gastar entre 40-70% menos que las que tratan cada llamada a la API de la misma manera. Esa brecha se agranda a medida que el uso escala.

En IQ Source hacemos auditorías de costos de IA. El proceso es directo: compartes tu dashboard de proveedor y tus logs de uso, y nosotros identificamos qué workloads deberían moverse a endpoints de batch, qué prompts son candidatos de caching, dónde los tokens de output están inflados, y cómo tus patrones de requests podrían consolidarse. Lo hemos hecho para equipos que gastan $5K/mes en llamadas a API y para equipos que gastan $50K — los patrones de optimización son los mismos, los ahorros absolutos solo tienen más ceros.

Si tu factura de API viene creciendo y la respuesta ha sido “pasemos a un modelo más barato” — esa es la conversación equivocada. La correcta empieza con tus datos de uso.

Compártenos tus números de uso de API — te mostramos qué cambia →