Por qué una API barata de IA puede costar más en programación intensiva

Una IA puede ser barata por token y cara por desarrollador al mismo tiempo. No es una contradicción: se están comparando dos productos distintos. Una API de pago por uso cobra cada token consumido; una suscripción de programación acota el gasto del usuario mientras este se mantenga dentro de las reglas de uso del plan.

Para un agente autónomo que recorre repositorios una y otra vez, conserva contextos largos y genera mucho código, pruebas y explicaciones, la pregunta no es solo «¿qué modelo tiene el token más barato?». La pregunta decisiva es: ¿cuándo deja de crecer mi coste marginal y qué volumen de trabajo soporta el plan de forma fiable?

Una tarifa baja por token sigue creciendo sin límite

GLM-5.2 figura con un precio de 1,40 dólares por millón de tokens de entrada, 0,26 dólares por millón de tokens de entrada recuperados de caché y 4,40 dólares por millón de tokens de salida. 1 Son tarifas competitivas para usos habituales de API, pero a gran escala la aritmética cambia deprisa:

• 1.000 millones de tokens de entrada sin caché: 1.400 dólares
• 1.000 millones de tokens de entrada desde caché: 260 dólares
• 1.000 millones de tokens de salida: 4.400 dólares

El último dato es especialmente relevante en programación asistida por IA. Un agente no solo lee código y documentación: también emite planes, modificaciones, resultados de pruebas, explicaciones, llamadas a herramientas e iteraciones. Si la carga de salida es significativa, el coste puede superar con creces lo que sugiere el titular sobre el precio de la entrada.

La caché puede modificar sustancialmente el resultado. El contexto reutilizado se factura a un precio mucho menor, pero la factura final sigue dependiendo de la mezcla real de entrada sin caché, entrada en caché y salida. 1

La comparación viral de coste diario necesita contexto

Se ha difundido una comparación que sitúa el uso de la API de GLM-5.2 cerca de 7.800 yuanes diarios frente a un coste semanal fijo muy inferior de una suscripción a Codex. Ilustra una diferencia real entre facturación por consumo y una asignación incluida en una suscripción, pero el volumen de tokens citado requiere matices.

Con las tarifas publicadas de GLM-5.2, decenas de miles de millones de tokens de entrada sin caché, por sí solos, costarían decenas de miles de dólares al día; una salida de esa escala costaría bastante más. 1 Una factura de 7.800 yuanes diarios podría corresponder, en cambio, a un volumen facturable efectivo menor, una alta proporción de entrada en caché, una mezcla concreta de entrada y salida, precios descontados u otra base de cálculo.

La lección práctica es simple: el total de tokens no basta. Para comparar un flujo de trabajo de programación conviene medir:

1. los tokens de entrada sin caché;
2. los tokens de entrada desde caché;
3. los tokens de salida;
4. las ventanas de reinicio y los límites del plan; y
5. si el exceso de uso pasa a facturación adicional.

La suscripción limita el gasto del usuario, no necesariamente el uso

Una suscripción no hace que la inferencia sea gratuita. Lo que hace es cambiar quién absorbe la variabilidad del coste.

Con un plan mensual fijo, un usuario intensivo autorizado puede recibir un volumen equivalente de API superior al que compraría al precio de lista. El usuario obtiene un presupuesto más previsible; el proveedor gestiona el riesgo mediante ventanas móviles, límites de velocidad, prioridades, créditos y otras reglas de uso razonable.

Por eso una API más cara puede coexistir con una suscripción de programación aparentemente más atractiva. El precio de API es un precio marginal directo del cómputo. La suscripción es un paquete con límites: pueden ser aceptables para muchos usuarios, pero no garantizan un rendimiento ilimitado.

Los planes de programación chinos también pueden estar muy medidos

La división importante no es «modelos chinos frente a extranjeros». Es si el producto de programación funciona como un contador abierto de tokens, una cartera de créditos o una asignación suficientemente amplia que se reinicia de forma periódica.

GLM Coding Plan aplica expresamente dos restricciones: una asignación móvil de puntos cada cinco horas y otra semanal. Los límites publicados incluyen 12.000 puntos cada cinco horas y 60.000 puntos semanales en Pro, y 28.000 y 140.000, respectivamente, en Max. El consumo se calcula a partir de tokens de entrada, entrada en caché y salida mediante coeficientes específicos de cada modelo. 2

Qoder es aún más explícito sobre su esquema de créditos. Sus planes de pago ofrecen 2.000, 6.000 o 20.000 créditos mensuales para modelos premium; cuando se agotan, Qoder cambia al usuario a un modelo base con mensajes limitados. La compañía también indica que los recursos premium incluidos equivalen al valor de la suscripción más los recursos promocionales adicionales. 17

Para quien ejecuta con frecuencia tareas largas y autónomas con agentes, estas estructuras pueden sentirse menos como una tarifa plana y más como consumo prepago presentado bajo una cuota mensual.

Los multiplicadores en horas punta hacen visible la capacidad disponible

Los límites de uso no son la única restricción. Los proveedores también pueden modificar la velocidad a la que se consume una asignación en momentos de mayor demanda.

La documentación actual de Z.ai indica que GLM-5.3 consume cuota con un multiplicador de 1× fuera de las horas punta y de 3× durante las horas punta; para GLM-5.3-Flash, las cifras indicadas son 0,4× y 1,2×. 4 La documentación general de GLM Coding Plan identifica como franja punta los días laborables, de 14:00 a 18:00 en UTC+8. 2

Es un mecanismo de gestión de capacidad: el precio monetario de la suscripción no cambia, pero el trabajo cubierto por la asignación puede reducirse durante las horas de mayor demanda. No debe extrapolarse automáticamente a cualquier plan o periodo de GLM-5.2 sin revisar sus condiciones vigentes.

Qué prueban —y qué no prueban— las fuentes sobre problemas de acceso

Los reportes sobre cupos diarios agotados, menor disponibilidad de GLM-5.2, retención breve de caché, agrupación deficiente de solicitudes entre usuarios o escasez de inferencia específica de un proveedor pueden ser plausibles, pero no todos quedan demostrados por el material revisado.

La documentación primaria disponible sí respalda la existencia de techos de cuota, contabilidad de puntos ponderada por tokens y multiplicadores según la hora. 24 Por sí sola, no verifica una explicación concreta del proveedor para cada incidencia de acceso que se haya comentado. Para decidir una compra, conviene tratar los reportes informales como señales que hay que probar, no como hechos concluyentes.

Una evaluación útil debe incluir una prueba con la carga real de trabajo y en las horas en que opera el equipo: tamaño del repositorio, comportamiento de la caché, longitud de las respuestas, número de agentes simultáneos, colas y comportamiento de respaldo del plan importan más que una tarifa aislada por token.

La regla de compra para equipos con uso intensivo de IA

Las APIs chinas de bajo coste siguen siendo atractivas para inferencia ligera o predecible, especialmente cuando el flujo de trabajo reutiliza contexto en caché. 1 También pueden ser una buena opción para equipos que necesitan control directo sobre la API y pueden gestionar estrictamente su presupuesto de tokens.

Pero la programación con IA de alta intensidad es otro problema de compra. Si un agente consume grandes volúmenes de forma sostenida, suele ganar la opción que combine:

• un techo mensual predecible;
• una asignación que aguante jornadas normales de trabajo;
• reglas claras de reinicio y de exceso de uso;
• acceso estable en horas punta; y
• capacidad suficiente para tareas paralelas.

En resumen: hay que comparar el trabajo útil realmente disponible al mes, no solo el precio de lista de la API. Un modelo medido y barato gana cuando el consumo está controlado. Una suscripción gana únicamente si sus límites son transparentes y suficientemente amplios para la carga real de los agentes del desarrollador.