Cuánto cuesta de verdad la IA en producción

Empecemos por lo comprobable. Estos son los precios de lista de los modelos de frontera de las dos casas, tomados de sus propias páginas de precios. Son precios por millón de tokens, en dólares, sin descuentos aplicados.

Fuentes y fecha de consulta: OpenAI API Pricing · Anthropic Pricing · 7 de septiembre de 2026. Los precios cambian con frecuencia y los contextos muy grandes pueden tener tarifas distintas: confirma siempre en la documentación oficial vigente antes de presupuestar.

La forma de salir de la discusión teórica es hacer la cuenta, y la cuenta es más sencilla de lo que parece. Necesitas tres datos: cuántas operaciones al mes, cuántos tokens de entrada y de salida consume cada una, y el precio del modelo que vas a usar.

Coste mensual ≈ operaciones/mes ×
  [ (tokens de entrada × precio de entrada)
  + (tokens de salida × precio de salida) ]
  / 1.000.000

Supongamos un asistente interno que responde sobre documentación propia: 2.000 conversaciones al mes, cada una con 8.000 tokens de entrada —el fragmento recuperado más el historial— y 600 de salida, sobre Claude Sonnet 5. De esos 8.000 tokens de entrada, 6.000 son documentación fija que se repite en todas las peticiones y por tanto es cacheable.

• Un asistente que atiende 2.000 conversaciones al mes cuesta unas decenas de dólares, no miles.
• Aprovechar la caché en la parte fija del contexto casi divide la factura por dos.
• La salida, que es solo el 7 % de los tokens, se lleva el 54 % del coste.

Para simplificar el ejemplo asumimos un 100 % de aciertos de caché sobre los 6.000 tokens reutilizables y omitimos el coste inicial de escritura del caché. En producción, el ahorro real dependerá del porcentaje de aciertos, la duración del caché y la reutilización efectiva del prefijo. Los supuestos de volumen son inventados: lo que importa es el método.

El segundo caso es donde la aritmética se pone interesante. Supongamos diez desarrolladores usando un agente de programación, cada uno consumiendo dos millones de tokens al día, veinte días al mes. Son 400 millones de tokens mensuales, repartidos aproximadamente en un 80 % de entrada y un 20 % de salida.

Con Claude Sonnet 5 a precio de lista, eso son unos 640 $ de entrada y 800 $ de salida: alrededor de 1.440 $ al mes de coste equivalente a precio público de API. Diez asientos de tarifa plana a 20 $ costarían 200 $.

Conviene ser preciso con lo que significa esa diferencia. Que una tarifa plana de 200 $ cubra un consumo equivalente a 1.440 $ en precios públicos de API no significa que al proveedor le cueste 1.440 $ servir ese uso: el precio de lista incluye margen, y el coste marginal real de la inferencia no es público. Lo que sí muestra es la distancia que puede existir entre una suscripción fija y el valor del mismo volumen de inferencia cuando se factura de forma medida. Y esa distancia es la que tensiona el modelo.

El ejercicio no es para que dejes de usar agentes, que compensan de sobra. Es para que sepas cuál de las dos cifras se parece más a tu consumo real, porque el día que tu proveedor ajuste límites o modelo de precios, tu presupuesto se moverá hacia la de arriba y no hacia la de abajo.

Los precios de lista no solo son bajos: llevan años cayendo. GPT-4o pasó de 5,00 $ a 2,50 $ por millón de tokens de entrada, y el índice de precio de token de los modelos de frontera está un 84 % por debajo de su base de marzo de 2023, según el seguimiento de tendencias de precios de BenchLM a 2 de septiembre de 2026. Modelos más eficientes, competencia de los laboratorios chinos y hardware más barato por unidad de cómputo han empujado el precio unitario a la baja de forma sostenida.

Aquí conviene una advertencia que se olvida con facilidad: que el precio unitario baje no significa que tu factura baje. Suele ocurrir lo contrario. Cuando un token cuesta la décima parte, aparecen casos de uso que antes no salían a cuenta, y el consumo crece más rápido de lo que cae el precio. Es la paradoja de Jevons aplicada a la inferencia, y es la razón por la que muchas empresas ven bajar el precio por token y subir la línea de gasto en el mismo trimestre.

Mirar solo el precio por token se queda corto, porque el token de hoy no compra lo mismo que el de hace tres años. La forma más útil de medirlo es preguntarse cuánto cuesta alcanzar un nivel de capacidad determinado.

En el periodo analizado por Epoch AI, el precio necesario para alcanzar un nivel fijo de rendimiento cayó entre 9 y 900 veces por año según la tarea, con una mediana en torno a 50 veces. Es una medición sobre un conjunto concreto de pruebas y un periodo concreto, no una previsión; lo que sí puede comprobarse en la tabla de precios de más arriba es que la tendencia descendente ha continuado.

El matiz importante es que esa caída no es uniforme. Es muy pronunciada en tareas de conocimiento y razonamiento, donde los modelos pequeños han alcanzado a los grandes de hace dos años, y bastante más lenta en tareas largas y agénticas, donde la capacidad sigue concentrada en los modelos de frontera. Por eso la decisión relevante ya casi nunca es qué modelo es mejor, sino cuál es el modelo más barato que resuelve tu tarea concreta.

En la práctica esto significa que revisar la elección de modelo cada pocos meses tiene retorno directo. Una carga que hace un año exigía el modelo tope de gama es muy probable que hoy la resuelva uno intermedio a una fracción del precio, sin que nadie en el equipo se haya enterado.

Hay un detalle de la tabla de precios que suele pasarse por alto y que tiene consecuencias directas en cómo se escribe el código: el token de salida cuesta entre cinco y seis veces más que el de entrada en casi todos los modelos. Claude Sonnet 5 está a 2 $ de entrada y 10 $ de salida; GPT-5.6 Terra, a 2 $ y 12 $; GPT-6 Astra, a 10 $ y 50 $.

La consecuencia es contraintuitiva para quien viene de optimizar prompts pensando en la ventana de contexto. Meter contexto es barato; pedir respuestas largas es caro. Un prompt de 8.000 tokens con documentación recuperada cuesta menos que una respuesta de 2.000 tokens que nadie va a leer entera.

De ahí salen tres decisiones de diseño que se pagan solas: pedir salidas estructuradas y acotadas en lugar de texto libre, no pedirle al modelo que repita en la respuesta información que ya tenía en el prompt, y usar salidas cortas con una segunda llamada bajo demanda en lugar de una respuesta larga por si acaso.

Y la otra palanca, la mayor de todas, es el prompt caching. Cuando el contexto se repite entre peticiones —el caso típico de un asistente que responde siempre sobre la misma base documental, como en las arquitecturas RAG— el descuento sobre esa parte fija cambia el orden de magnitud de la factura, como se ve en el ejemplo 1.

Si la API baja de precio y los laboratorios pierden dinero, algo no cuadra. Lo que no cuadra es que estamos mezclando dos modelos de negocio distintos bajo la misma etiqueta.

Del negocio de API por consumo, los análisis de terceros apuntan a márgenes brutos saludables —del orden del sesenta y tantos por ciento para Anthropic en 2026, según estimaciones externas—, pero conviene no generalizar: ninguno de los dos laboratorios publica el margen de inferencia por separado, y el margen varía por modelo, por región y por tipo de carga. Las pérdidas agregadas que se leen en prensa provienen sobre todo del entrenamiento y de la inversión en infraestructura, no de servirte a ti una respuesta.

El problema económico está en otro sitio. Aparece cuando determinadas cargas intensivas se empaquetan dentro de una tarifa plana diseñada originalmente para un uso mucho más ligero. La tarifa plana se pensó para un patrón conversacional: alguien que abre el chat unas cuantas veces al día y consume decenas de miles de tokens. Un bucle agéntico —un asistente que explora el repositorio, edita ficheros, ejecuta pruebas, lee los errores y vuelve a intentarlo— consume millones de tokens en una sola sesión y puede encadenarlas durante horas. El mismo asiento, la misma cuota, dos o tres órdenes de magnitud más de cómputo.

La tensión ya se ha visto en el mercado. Anthropic llegó a experimentar con retirar Claude Code del plan Pro de 20 $ para una pequeña parte de las nuevas altas, y revirtió el experimento. El hecho relevante no es que la función desapareciera —no lo hizo—, sino que los patrones de uso agéntico están tensionando los planes de tarifa plana lo suficiente como para que los proveedores prueben dónde está el límite.

La dirección del mercado es bastante clara, y conviene contar con ella al presupuestar: límites de uso, paquetes adicionales, consumo medido y restricciones para determinadas cargas.

GPT-6 Astra es el modelo más potente de OpenAI en esta comparativa, pensado para trabajo complejo de extremo a extremo. Su precio de lista es de aproximadamente 10 $ por millón de tokens de entrada, 50 $ por millón de tokens de salida y 1 $ por millón de tokens de entrada en caché, según la documentación oficial consultada el 7 de septiembre de 2026.

Tener acceso al modelo más potente no significa que debas utilizarlo para todo. Con 50 $ por millón de tokens de salida, una arquitectura que envíe indiscriminadamente todas sus peticiones a Astra puede multiplicar el coste sin mejorar proporcionalmente el resultado. En producción, la optimización real consiste en reservar los modelos de frontera para las tareas que de verdad necesitan su capacidad y delegar el resto en modelos más baratos.

A eso se le llama routing de modelos o tiering: en lugar de elegir un modelo para toda la aplicación, se clasifica cada tarea y se envía al modelo más barato que la resuelve con la calidad exigida. Clasificación, extracción de campos, enrutado de peticiones, resúmenes cortos y transformaciones deterministas suelen resolverse perfectamente con modelos pequeños que cuestan una fracción. El razonamiento largo, la planificación de varios pasos y las tareas agénticas complejas son las que justifican el modelo de frontera.

Una advertencia de letra pequeña: los contextos extremadamente grandes pueden tener condiciones y tarifas distintas de las de la tabla, con escalones de precio según la longitud. Si tu caso de uso trabaja con ventanas muy amplias, revísalo en la documentación oficial vigente antes de extrapolar.

• Clasificar cada tarea por la capacidad que realmente necesita, no por comodidad.
• Modelo pequeño por defecto; modelo de frontera solo cuando la tarea lo exija.
• Medir calidad con un conjunto de pruebas propio, no con la impresión del equipo.
• Reevaluar cada trimestre: lo que ayer requería el modelo caro puede que hoy no.

Detrás de todo esto hay un límite físico que ninguna mejora de eficiencia elimina del todo. La Agencia Internacional de la Energía proyecta que el consumo eléctrico de los centros de datos pase de unos 485 TWh en 2025 a alrededor de 950 TWh en 2030, aproximadamente el doble, hasta suponer en torno al 3 % de la demanda eléctrica mundial. Hacia 2035 la previsión base ronda los 1.200 TWh. Los centros de datos orientados a IA crecen mucho más rápido que el conjunto: se triplican en ese periodo.

El crecimiento está además muy concentrado. Según la AIE, China y Estados Unidos concentran cerca del 80 % del aumento hasta 2030, con unos 240 TWh adicionales en Estados Unidos y unos 175 TWh en China.

Lo relevante para una empresa que compra IA no es la cifra en sí, sino lo que implica: la capacidad de cómputo es un recurso con restricciones físicas y de suministro. Ese cuello de botella puede manifestarse antes en forma de límites de uso, rate limits, disponibilidad de capacidad en determinadas regiones o restricciones operativas que en una subida lineal del precio por token. Conviene diseñar contando con esa posibilidad.

La conclusión operativa no es dejar de usar IA ni esperar a que los precios se estabilicen. Es tratar el gasto en inferencia como se trata cualquier otro coste de infraestructura: con métricas, límites y responsables. Es lo que empieza a llamarse FinOps para IA, y no requiere herramientas nuevas, solo decidir medirlo.

• Separa el gasto por API del gasto por asientos. El primero es medido y predecible; el segundo es el que tiene riesgo de subida y de recorte de funciones.
• Mide tokens por caso de uso, no por usuario. Saber que un asistente consume X tokens por conversación permite proyectar el coste al crecer; saber cuántas licencias tienes, no.
• Instrumenta desde el primer día: coste por operación, por caso de uso y por modelo, visible en un panel que alguien mire.
• Aplica routing de modelos y prompt caching antes de negociar descuentos. Suelen dar más ahorro que cualquier acuerdo comercial.
• Pon techos de gasto y alertas, no cuando llegue la primera factura sorpresa.
• No ancles la arquitectura a un modelo concreto. Con esta cadencia de lanzamientos y de bajadas de precio, poder cambiar de modelo o de proveedor sin reescribir la aplicación vale más que elegir bien hoy; en Java, esa capa de abstracción es justo lo que aportan Spring AI y LangChain4j.
• Para cargas agénticas, presupuesta por tarea y no por persona. Es la única unidad que se comporta de forma estable cuando el agente decide cuánto trabajo hace.