El precio por token cae, pero el costo de IA sube

Una empresa puede reducir el precio por token y aun así aumentar su costo de IA. La keyword costo de IA solo se vuelve inteligible cuando la cuenta deja de mirar la tarifa aislada y pasa a acompañar el workload, la tarea concluida, la ruta y el valor efectivamente desembolsado.

El precio de una unidad cayó. La cesta comprada cambió.

El costo de IA es una multiplicación con pésimo sentido del humor: precio por token multiplicado por tokens consumidos, más el trabajo que la arquitectura esconde hasta el cierre. Una request más barata puede estimular más requests, contextos más grandes, nuevas funciones e intentos automáticos. El precio por token no necesita subir para que la factura crezca.

El análisis AI Token Price Collapse, But AI Costs Are Rising, publicado por GTM Newsletter, sirve como fuente secundaria y punto de partida. No sirve como prueba primaria de cada número. La tesis de este artículo es más estrecha: CTOs y CFOs deben administrar costo efectivo por workload, con volumen, calidad de la ruta, contexto, reintentos, operación, moneda y contrato en el mismo cuadro.

¿Por qué el precio por token puede caer mientras el costo de IA sube?

El costo de IA sube cuando la reducción del precio por token es menor que el aumento del trabajo enviado al sistema o que los costos necesarios para concluir ese trabajo. La relación no es una ley universal. Aparece cuando el producto amplía el uso, la aplicación carga más contexto, la operación repite requests o el contrato añade gastos fuera de la tabla.

El precio por token responde a una pregunta estrecha: cuánto cuesta procesar una unidad en esa ruta, en ese contrato y en esa moneda. La factura responde a otra: cuánto trabajo la empresa envió, cuántas veces lo envió y cuántos intentos fueron necesarios.

La diferencia deja de ser académica cuando una función de resumen pasa a ejecutarse en todas las interacciones. El contexto crece. Un segundo intento se habilita para requests lentas. Cada decisión puede tener sentido aisladamente, pero la cuenta observa el conjunto.

La vieja ironía de la eficiencia aparece de nuevo: cuando el peaje se abarata, más gente toma la carretera.

El precio por token más bajo reduce la factura si el volumen, el comportamiento del producto, la ruta y el contrato permanecen estables. Esa es la condición. Sin medición, la empresa llama economía a lo que tal vez sea solo una expansión de compra.

¿Qué es lo que el precio por token no muestra sobre el costo de IA?

El precio por token no muestra el volumen efectivo, la composición entre entrada y salida, el tamaño del contexto, las requests repetidas, la operación o la contratación en moneda extranjera. Para comparar workloads, la unidad útil es el costo por tarea concluida. Precio por token es una dimensión de la cuenta, no la cuenta entera.

Un equipo puede celebrar tokens de entrada más baratos e ignorar que cada request ahora carga el historial completo de la conversación. Otro puede elevar el límite de salida para evitar respuestas cortadas. La tarifa cayó. El paquete se hizo más grande.

El presupuesto necesita separar cinco capas:

1. Precio por token: tarifa contratada para tokens de entrada y salida.
2. Volumen: requests, tokens y tareas concluidas en el período.
3. Calidad de la request: éxito, reintentos, fallback y requests descartadas.
4. Operación: observabilidad, caché, colas, procesamiento de contexto e incidentes.
5. Costo efectivo: contratación, tipo de cambio, tributos aplicables, tasas y créditos capturados o perdidos.

La tercera capa suele ser silenciosa. Una request que falla y se repite aparece como consumo. El dashboard no pregunta si la primera respuesta sirvió al usuario. El presupuesto debería preguntarlo.

El benchmark de LLMs orientado a CFOs pone el score técnico y la economía en la misma conversación. Este artículo avanza por otra senda: la mejor tarifa falla cuando el sistema no mide el trabajo desperdiciado a su alrededor.

La tabla es un antídoto contra la planilla que contiene solo la columna "precio por millón".

¿Cuándo la caída del precio por token expande el uso?

La caída del precio por token expande el uso cuando reduce el costo percibido de una tarea y libera a producto, ingeniería u operaciones para enviar más trabajo al modelo. El efecto depende de la demanda reprimida, del diseño de la aplicación y del comportamiento de los usuarios. Debe medirse como hipótesis, nunca tratarse como destino.

Un producto que usaba IA solo en el cierre de un ticket puede pasar a usar IA en la clasificación, en la búsqueda, en el borrador y en la auditoría. La tarifa sigue siendo menor. Los puntos de consumo se multiplican.

Lo mismo ocurre dentro de una request. Contextos más grandes reducen el preprocesamiento fuera del modelo, pero transfieren el trabajo a la inferencia. El equipo puede aceptar ese intercambio cuando la precisión o la velocidad de desarrollo justifican el gasto. El presupuesto necesita registrar la elección.

La expansión suele aparecer en cuatro señales: requests por usuario, tokens por request, requests automáticos y usuarios o casos de uso. Ninguna señal prueba causalidad por sí sola.

La atribución exige una línea de base con fecha, ruta, workload y volumen antes del cambio. Sin esa línea, "el consumo creció" es observación, no explicación.

La figura técnica de este artículo organiza esa atribución sin inventar valores de mercado: baseline, clasificación, ruta, contexto, reintentos, operación y costo efectivo aparecen como etapas de la misma cuenta.

¿Dónde los reintentos, el contexto y el enrutamiento devoran el presupuesto?

Reintentos, contexto y enrutamiento elevan el costo cuando la empresa paga por trabajo que no mejora la tarea concluida. Un reintento puede recuperar disponibilidad. Un contexto más grande puede mejorar la respuesta. Una ruta más barata puede fallar en el workload equivocado. El diagnóstico depende del resultado, no de la tarifa aislada.

Los reintentos son el caso más fácil de subestimar. Una política de repetición protege contra fallas transitorias, pero necesita límite, clasificación y telemetría. Sin eso, un timeout puede generar dos o tres cobros, según la política de reintento y el comportamiento de facturación del proveedor.

El fallback también tiene costo. Migrar una request a otra ruta puede preservar el servicio, pero la empresa necesita registrar cuántas requests siguieron el camino secundario, por qué motivo y con qué resultado. El failover es una póliza. Las pólizas necesitan siniestro contabilizado.

El contexto es otra forma de inflación invisible. Instrucciones, historial y documentos pueden reenviarse en requests sucesivas porque la aplicación no definió compactación, caché o selección de fragmentos. El usuario ve una respuesta. La empresa paga la biblioteca entera.

El enrutamiento por precio puede producir falsa economía. Cuando una request sensible a la latencia sigue una ruta lenta, surgen timeouts, reintentos y abandono. La ruta de menor tarifa fue elegida; la tarea más cara fue fabricada.

La página del Nexforce Router describe enrutamiento por costo, performance y latencia, fallback automático, límites de presupuesto, analytics y pago local. El punto aquí no es atribuir al producto una promesa de economía automática. Es volver la decisión de ruta observable y auditable.

¿Por qué el costo efectivo exige una condición brasileña?

En modo CLIENTE, la contratación directa de un proveedor extranjero es una hipótesis de análisis, no una alícuota lista. La calificación de la operación, la separación contractual, la jurisdicción del beneficiario, el municipio y el régimen del comprador definen qué líneas entran en el costo efectivo. El modo distribuidor o reventa sigue otra lógica, y sus entendimientos no migran al cliente final.

La tarifa en moneda extranjera no es una tasa universal de salida de caja. En Brasil, el comprador directo necesita clasificar la operación antes de calcular cualquier tributo. En la Solución de Consulta Cosit nº 191, de 23 de marzo de 2017, la Receita Federal trató, con base en los hechos presentados por el interesado, de autorizaciones de uso y acceso a SaaS y clasificó aquella operación específica como servicio técnico a efectos de IRRF y CIDE. Esto no transforma todo SaaS en una categoría fiscal automática. Una licencia pura, segregada y sin transferencia de tecnología sigue la excepción prevista en el art. 2º, §1º-A, de la Ley 10.168/2000. La clasificación vence al atajo.

Clasificación primero.

Para el modo CLIENTE, el mapa de validación comienza en el RIR/2018, arts. 767 y 786, para IRRF y gross-up; en la Ley 10.168/2000, art. 2º, §§1º-A y 2º, para CIDE; en la Ley 10.865/2004, arts. 7º y 8º, para PIS/COFINS-Importación; en la LC 116/2003, arts. 1º, §1º, y 6º, §2º, I, para ISS; y en el Decreto 6.306/2007, art. 15-B, XXIV, para IOF-cambio. La aplicación depende del contrato y de la norma vigente.

Este recorte describe el régimen vigente al 8 de agosto de 2026. La transición de la Ley Complementaria 214/2025 extingue PIS/COFINS en 2027 y sustituye su incidencia por la CBS; el ISS se reduce gradualmente de 2029 a 2032 y deja de existir en 2033. La alícuota plena de CBS/IBS todavía depende de la definición aplicable. Cualquier porcentaje futuro debe identificarse como premisa de planificación, no como alícuota vigente.

Este artículo no fija alícuotas ni presume que una contratación de IA tenga un tratamiento fiscal único. La naturaleza de la operación, el contrato, el proveedor y la entidad contratante deben examinarse antes de cualquier cálculo de costo efectivo. La fuente oficial citada en las referencias sirve para consulta normativa, no sustituye el análisis del caso concreto.

La cuenta brasileña debe registrar entidad, proveedor, naturaleza del servicio, contrato, moneda, fecha de cambio, eventual retención y tratamiento fiscal validado. Ninguna factura debe recibir un multiplicador fijo por atajo editorial. El encuadre depende de las premisas de la operación, y las referencias internas de producto no sustituyen la fuente pública ni la validación fiscal del contrato concreto.

¿Qué matriz mide el costo de IA real?

La matriz correcta acompaña cada workload desde la request hasta la tarea concluida. Registra consumo, ruta, calidad y costo de contratación en el mismo identificador. Así, la empresa separa crecimiento de uso, degradación de ruta, desperdicio operacional y efecto cambiario, en lugar de atribuir toda alza al precio del modelo.

La operación puede comenzar con una unidad simple: proyecto, clave, workload o período. Lo importante es mantener la unidad lo bastante estable para comparar antes y después.

Comience por la tarea concluida.

La regla debe ser estable antes del próximo cambio de precio por token. Sin eso, el equipo mide ruido y llama al ruido economía. Cuando la definición incluye éxito, ruta, contexto, reintentos y moneda, la comparación deja de premiar la tarifa nominal y pasa a mostrar el costo que realmente acompaña al workload.

1. Definir la tarea concluida. Una respuesta generada no es necesariamente una tarea resuelta.
2. Registrar la ruta. Modelo, proveedor, región, versión de la política y motivo del fallback entran en el mismo evento.
3. Separar entrada y salida. Tokens de contexto y de respuesta tienen comportamientos diferentes.
4. Contar reintentos. Intento inicial, repetición, timeout, error y resultado final quedan visibles.
5. Agregar la operación. Caché, observabilidad, colas y procesamiento auxiliar reciben centro de costo o estimación rastreable.
6. Convertir a costo efectivo. La moneda de contratación y la moneda de reporte aparecen juntas, con fecha y premisas.
7. Comparar por workload. Precio por token es una dimensión. Costo por tarea concluida es la decisión.

La matriz no necesita comenzar perfecta. Necesita comenzar antes del próximo cambio de precio por token.

¿Qué resuelve el enrutamiento y qué no resuelve?

El enrutamiento resuelve la falta de control sobre qué request sigue a qué modelo, bajo qué reglas y con qué resultado. No transforma volumen desperdiciado en eficiencia ni corrige una mala definición de éxito. Su papel es volver costo, performance, disponibilidad y límites decisiones operacionales observables.

El enrutamiento importa.

Un gateway de LLM puede distribuir requests y elegir rutas por costo, latencia o performance. También puede aplicar límites de gasto, registrar requests y activar failover, cuando esas capacidades están documentadas en la solución adoptada. El valor económico aparece cuando la política es explícita y la empresa puede comparar el resultado de la ruta con la tarea concluida.

Requests de baja complejidad no necesitan consumir la misma ruta que una tarea que exige contexto amplio. Un camino sensible a la latencia no debe optimizarse por precio nominal si el retraso provoca repetición. Un proyecto que alcanzó su límite debe parar, alertar o cambiar de política.

El Router no debe usarse como excusa para borrar la complejidad. Límite de gasto sin medición de tarea puede cortar un workload crítico. Failover sin análisis de calidad puede preservar disponibilidad mientras degrada la respuesta.

La arquitectura madura trata el enrutamiento como política económica aplicada en tiempo real. La pregunta deja de ser "¿qué modelo es más barato?" y pasa a ser "¿qué ruta entrega esta tarea dentro del presupuesto y del nivel de servicio aceptados?"

¿El argumento a favor del precio por token está equivocado?

El mejor argumento contrario dice que, si el precio por token cae y el workload permanece igual, el costo total cae. Bajo esas premisas, el argumento es correcto. La divergencia comienza cuando "workload igual" es solo una hipótesis, sin línea de base para volumen, contexto, reintentos, ruta, distribución de entrada y salida y condición contractual.

El steelman merece ser preservado. Una operación con volumen fijo, misma tasa de éxito, mismo contexto y misma contratación captura la caída del precio por token. Negarlo transforma una buena tesis en hinchada.

La cuenta baja.

La conclusión cambia cuando la cesta comprada cambia: el equipo puede abrir una función antes bloqueada por el presupuesto, cambiar una request por tres etapas o anexar más contexto para reducir recuperación, mientras el equipo financiero sigue comparando solo el precio por token nominal publicado en la tabla del proveedor.

Quien logra probar estabilidad debe capturar la reducción. Quien no logra probar estabilidad debe tratar la caída como oportunidad de investigar el workload. El argumento contrario vence en el entorno controlado; pierde cuando la empresa confunde precio por token con cantidad de trabajo comprado.

Preguntas frecuentes sobre precio por token y costo de IA

La respuesta corta es que el precio por token informa la tarifa, mientras que el costo de IA mide el trabajo concluido y todo lo que fue necesario para concluirlo. La diferencia incluye volumen, contexto, reintentos, ruta, operación, moneda y contrato. La empresa que no mide esas capas conoce el precio de tabla, pero no conoce su gasto real.

¿Un token barato siempre reduce la factura?

No. El precio por token reduce la tarifa de la request cuando la ruta y el contrato son los mismos. La factura sube cuando volumen, contexto, respuestas, reintentos o cantidad de tareas crecen más rápido que la reducción de precio. La única forma de confirmar economía es comparar la línea de base con el workload posterior.

¿Qué métrica debe entrar en el presupuesto?

La métrica principal debe ser el costo efectivo por workload o por tarea concluida. El precio por token sigue siendo útil para negociar, simular y comparar rutas, pero no muestra requests repetidas, contexto excesivo, operación, moneda o condiciones contractuales. El presupuesto debe mantener esas dimensiones separadas antes de agregarlas.

¿La expansión de uso ocurre en toda caída de precio?

No. La expansión depende de la demanda reprimida, del producto, de los usuarios y de las decisiones de ingeniería. El análisis debe comparar requests por usuario, tokens por request, tareas, funcionalidades y tasa de éxito antes y después del cambio. Sin una línea de base, el crecimiento puede tener otra causa.

¿Los reintentos son siempre desperdicio?

No. Los reintentos pueden recuperar una falla transitoria y preservar una tarea importante. El desperdicio aparece cuando no existe límite, clasificación o telemetría para distinguir el intento que resolvió el problema de la repetición que solo generó otro cobro. La métrica correcta combina número de reintentos, motivo, resultado y costo.

¿El tipo de cambio altera el precio por token?

El tipo de cambio no altera el precio por token contratado en moneda extranjera, pero altera el costo efectivo para quien reporta en moneda local. El impacto depende del contrato, fecha de liquidación, spread y, en modo CLIENTE, de la calificación tributaria de la operación y del régimen del comprador. Una referencia brasileña no debe aplicarse automáticamente a otra operación.

¿Cuándo ayuda el enrutamiento de verdad?

El enrutamiento ayuda cuando la empresa tiene workloads diferentes, reglas de costo o performance, necesidad de failover y poca visibilidad sobre las requests. Vuelve la política explícita y auditable. No sustituye la definición de tarea concluida, la línea de base, la medición de calidad ni la validación del contrato.

Referencias y Lectura Complementaria

• AI Token Price Collapse, But AI Costs Are Rising
• Nexforce Router
• Benchmark de LLMs para CFOs: costo, no score técnico
• Comparación de costos de LLMs en 2026: enrutamiento inteligente
• Solución de Consulta Cosit nº 191/2017, Receita Federal: clasificación, en el caso consultado, de autorizaciones de uso y acceso a SaaS como servicio técnico a efectos de IRRF y CIDE
• Ley 10.168/2000, CIDE
• Ley 10.865/2004, PIS/COFINS-Importación
• Ley Complementaria 116/2003, ISS
• Decreto 6.306/2007, IOF
• Decreto 9.580/2018, RIR/2018

La cuenta que sobrevive al precio

El presupuesto de IA necesita sobrevivir a un precio por token que cambia. Exige medir el workload, registrar la ruta, contar reintentos y separar el precio por token del costo efectivo. Esa disciplina muestra cuándo la reducción se volvió expansión de consumo, cuándo una falla produjo requests extras y cuándo la contratación en moneda extranjera alteró el desembolso local.

La empresa que mide solo el token pregunta cuánto cuesta una pieza. La empresa que mide el workload descubre cuánto cuesta la máquina entera, incluido el tornillo que cae al suelo cada vez que un reintento se dispara.

Precio por token es negociación. Costo efectivo es gestión.