El precio de un creador de aplicaciones con IA depende de lo que cuenta como trabajo

El plan más barato para 100 iteraciones de prompts por semana suele ser el que contabiliza menos trabajo alrededor de cada prompt. El precio mensual publicado casi no dice nada hasta saber si un reintento, una fase de planificación, una prueba, un despliegue y un agente que trabaja en segundo plano usan el mismo medidor.

He visto equipos comparar planes dividiendo el precio de una suscripción entre 100 prompts. La cuenta es ordenada e incorrecta. Un prompt que cambia el texto de un botón y otro que reestructura una base de datos cuentan como un mensaje para quien escribe, pero pueden generar facturas muy distintas. Una comparación honesta empieza con un registro de carga de trabajo y después aplica las reglas de facturación de cada proveedor a ese mismo registro.

Este artículo usa un catálogo de precios hipotético, no los precios de ningún proveedor concreto. Su objetivo es ofrecerte un cálculo que puedas sustituir por las condiciones reales de los planes antes de comprar.

El mismo número de prompts puede ocultar tres facturas distintas

El número de mensajes de usuario mide la conversación, no el cómputo ni el trabajo terminado. Los planes por créditos suelen medir la actividad del modelo, los planes por tareas miden una unidad de trabajo definida por el proveedor y los planes planos venden acceso dentro de un límite. Esos límites producen totales distintos incluso cuando la aplicación y las 100 solicitudes semanales son idénticas.

Supongamos que una persona fundadora pide cada semana 70 pequeños cambios de interfaz, 20 cambios que afectan a varios archivos y 10 cambios de compilación o despliegue. El recuento visible es 100. Entre bastidores, el creador puede revisar el repositorio, elaborar un plan, llamar al modelo varias veces, ejecutar pruebas, reparar una edición fallida, recompilar la aplicación y mantener un agente activo después de que aparezca la respuesta del chat. Un plan puede cobrar cada llamada al modelo. Otro puede considerar toda la secuencia como una tarea. Una suscripción puede incluirla, limitarla o cobrar parte como excedente.

Esta es la diferencia que los compradores confunden con frecuencia: una iteración es un ciclo de decisión del usuario, mientras que un evento facturable es aquello que el proveedor haya decidido medir. Tratarlos como sinónimos favorece al plan con la página de precios más ambigua. También puede encarecer un plan que parecía barato cuando el equipo ya ha comprometido su aplicación con la plataforma.

Para comparar, usa un factor mensual de 4.33 semanas en vez de fingir que todos los meses tienen cuatro semanas. Cien iteraciones semanales se convierten en 433 iteraciones mensuales. Esa pequeña corrección añade 33 iteraciones antes de incluir un solo reintento o trabajo en segundo plano.

Una solicitud de presupuesto útil pide al proveedor que clasifique el trabajo, no que se limite a estimar un total. Pregunta: ¿qué inicia el medidor? ¿Cuándo se detiene? ¿Cuenta una ejecución fallida? ¿Cuenta un reintento automático? ¿Qué trabajo continúa después de que la interfaz indique que la respuesta está completa? ¿La capacidad no usada se acumula? Las respuestas determinan la factura.

Define una única carga de trabajo antes de abrir la calculadora

Crea una semana representativa con el trabajo que realmente esperas y mantenla fija antes de comparar planes. Si cambias la carga de trabajo para cada modelo de precios, estarás probando textos comerciales, no precios.

Para la comparación detallada, usaré esta carga semanal:

• 70 ediciones pequeñas de una unidad de crédito cada una
• 20 cambios en varios archivos de tres unidades de crédito cada uno
• 10 cambios de compilación o despliegue de cinco unidades de crédito cada uno
• 25 ejecuciones de reintento con una media de dos unidades de crédito
• 35 ejecuciones en segundo plano que consumen 45 unidades de crédito en total

Las 100 iteraciones solicitadas consumen 180 unidades de crédito hipotéticas en sus primeros intentos. Los reintentos añaden 50. La planificación, la indexación, las pruebas y el trabajo de despliegue añaden 45. El total semanal es 275 unidades, o 1,190.75 unidades en un mes medio.

La misma actividad tiene otra forma bajo la facturación por tareas. Genera 100 inicios de tareas solicitados por usuarios, 25 inicios por reintentos y 35 inicios de tareas en segundo plano cada semana. Son 160 eventos semanales y 692.8 eventos mensuales. Que los 692.8 sean facturables depende de cómo el contrato defina una tarea.

Registra por separado el trabajo completado y el fallido. Una tasa de fallos basada solo en mensajes de error visibles no detecta reparaciones silenciosas, alternativas automáticas del modelo ni repeticiones de pruebas. La exportación de uso de la plataforma, si existe, es mejor evidencia que el historial de chat porque el chat puede agrupar varias ejecuciones de agentes en una sola respuesta.

Usa una semana que incluya los problemas habituales: un prompt poco claro, un conflicto de dependencias, una prueba que falla por un motivo ajeno y una reparación de despliegue. Una semana de demostración impecable produce un presupuesto que dura solo hasta que empieza el desarrollo real.

No infles la carga de trabajo para protegerte. Añade un margen de variación por separado después de calcular el nivel base observado. Mantener separados el nivel base y el margen te permite ver si un plan es caro por el trabajo normal o porque compraste un seguro para un mes intenso.

Los paquetes de créditos cobran por el movimiento dentro del creador

Los paquetes de créditos cuestan menos cuando los precios por unidad de la plataforma son bajos, los créditos sin usar duran lo suficiente para emplearlos y el creador necesita pocas rondas de reparación. Cuestan más cuando una solicitud sencilla se ramifica en varias llamadas al modelo que el usuario no puede ver.

Un crédito no es una unidad estándar. Puede representar tokens, llamadas al modelo, pasos de agentes, segundos o una combinación ponderada. Un proveedor también puede cobrar cantidades de crédito distintas por un modelo rápido y por otro más potente. Comparar el número de créditos de dos paquetes no sirve de nada salvo que ambas plataformas definan el consumo de la misma forma, algo poco habitual.

Calcula el precio de la carga hipotética con un paquete de 500 unidades por $30. La demanda mensual es de 1,190.75 unidades. Como los paquetes no se pueden dividir, el comprador necesita tres y paga $90. La cuenta termina el mes con 309.25 unidades si los créditos no caducan. El coste efectivo del trabajo consumido es de unos 7.56 centavos por unidad, aunque el paquete anuncie 6 centavos, porque hubo que comprar capacidad sin usar.

La acumulación cambia el resultado. Si las 309.25 unidades restantes se conservan, la compra del mes siguiente puede ser de dos paquetes en vez de tres. En varios meses estables, el coste medio se acerca a la tarifa anunciada. Si los créditos caducan cada mes, el saldo desperdiciado forma parte del precio. No lo omitas nunca del modelo.

La selección de modelo puede cambiar el consumo sin alterar el número de prompts. Si la plataforma dirige las ediciones complejas a un modelo con un multiplicador de cuatro unidades, las diez solicitudes más difíciles pueden dominar la factura. Pregunta si ese enrutamiento es automático, si puedes verlo después y si puedes fijar un límite. Un modelo más barato que falla y se reintenta dos veces puede costar más que un modelo potente que acierta una vez.

Los paquetes de créditos funcionan bien para proyectos irregulares porque pagas cuando ocurre el trabajo, siempre que los créditos tengan una vida útil razonable. Resultan más difíciles de presupuestar para un equipo que experimenta libremente. El medidor puede cambiar la conducta: la gente agrupa solicitudes inconexas en prompts enormes, evita pruebas o acepta resultados flojos para ahorrar créditos. Esas decisiones reducen la factura a costa de perjudicar la aplicación.

La pregunta incómoda es si el trabajo en segundo plano debe consumir créditos. Consume recursos, así que cobrarlo es defendible. El problema aparece cuando el comprador no puede predecirlo ni detenerlo. Una evaluación justa comprueba si la interfaz muestra cada cargo en segundo plano y si un límite de gasto detiene el trabajo nuevo antes de que el saldo llegue a cero.

La facturación por tareas depende de dónde empieza y termina una tarea

La facturación basada en tareas puede ser el modelo más barato cuando un precio cubre todo el intento, incluida la planificación, las llamadas al modelo, las pruebas y las reparaciones. Se vuelve el más caro cuando cada acción interna se convierte en una tarea nueva.

Aplica una tarifa hipotética de $0.14 a cada evento iniciado del registro. Con 692.8 eventos mensuales, el coste es de $96.99 tras redondear a centavos. Es más que el resultado de $90 de los paquetes de créditos, aunque catorce centavos suenen poco en una página de precios.

Ahora cambia una frase del contrato: cobra solo por las 433 iteraciones solicitadas por usuarios e incluye los reintentos y el trabajo en segundo plano dentro de cada tarea. El coste mensual baja a $60.62. No ha cambiado nada de la aplicación. Ha cambiado el límite de la tarea, y ese límite mueve $36.37.

La facturación por tarea completada necesita otra definición. Si una ejecución cambia archivos pero falla el despliegue, ¿ha completado la plataforma la tarea? Si el usuario rechaza el resultado y pide una corrección, ¿es una tarea nueva o una continuación? Los proveedores necesitan reglas para evitar trabajo ilimitado por una sola tarifa, pero los compradores necesitan reglas que puedan reproducir desde un registro de actividad.

La recomendación habitual de comparar el coste por prompt exitoso es errónea cuando el éxito se declara por cuenta propia. Los usuarios aceptan resultados parciales, dividen solicitudes grandes y corrigen resultados manualmente. Un coste bajo por éxito registrado puede ocultar horas de limpieza. Compara en su lugar el coste por cambio aceptado, usando el punto en el que el equipo fusionaría, desplegaría o conservaría el resultado.

Los precios por tareas tienen una ventaja presupuestaria cuando la unidad corresponde a algo que una persona reconoce. Un equipo puede estimar 400 cambios aceptados con más confianza que millones de tokens. Esa ventaja desaparece si el producto etiqueta la indexación, la planificación, las pruebas y el despliegue como tareas separadas. Lee los nombres de los eventos en una factura real o en una exportación de uso antes de considerar estable la unidad.

Pregunta también cómo funciona la concurrencia. Dos agentes a la vez pueden reducir el tiempo transcurrido y duplicar los inicios de tareas. Una reparación en segundo plano que activa un agente de pruebas puede contar una vez, dos veces o no contar. La factura sigue al medidor, no al reloj.

Las suscripciones planas ganan solo dentro de su límite incluido

Una suscripción plana cuesta menos para esta carga de trabajo cuando la cuota mensual incluye las 433 iteraciones de usuario, los 108.25 inicios por reintento y los 151.55 inicios en segundo plano. Si alguna categoría queda fuera de la suscripción, añádela antes de declarar más barato el plan plano.

Usa un plan hipotético de $79 al mes que incluye hasta 600 ejecuciones interactivas y de reintento, además de 200 ejecuciones en segundo plano. El ejemplo genera 541.25 ejecuciones interactivas y de reintento, y 151.55 ejecuciones en segundo plano al mes. Ambos totales encajan, así que el coste se mantiene en $79. Bajo estas hipótesis, el precio plano supera a los paquetes de créditos de $90 y al plan de tareas iniciadas de $96.99.

La palabra «ilimitado» no merece ningún valor en una hoja de cálculo. Sustitúyela por el umbral real de uso razonable, el límite de concurrencia, la restricción de modelo o la regla de ralentización. Si el proveedor no indica un límite, modela un caso bajo y uno alto. Un plan que solo parece barato bajo una interpretación sin límites no te ha dado un precio fiable.

Los planes planos también generan costes por escalones. Con 599 ejecuciones incluidas, una más puede no costar nada. Con 600, la siguiente puede activar un excedente u obligar a subir de nivel. Representa al menos tres niveles de carga: un mes tranquilo, el mes esperado y un mes de lanzamientos. El caso esperado por sí solo oculta el punto en que la suscripción salta.

Las plazas importan cuando la facturación depende de los usuarios y no del trabajo. Un plan de $79 para una persona cuesta $316 para cuatro plazas necesarias, aunque el equipo comparta las mismas 433 iteraciones. No supongas que está permitido compartir cuentas. Calcula el precio de las personas que deben revisar prompts, aprobar despliegues o inspeccionar el uso.

Una cuota plana puede fomentar la experimentación saludable porque cada idea fallida no genera un microcargo visible. También puede ocultar desperdicio hasta que la plataforma limite la cuenta. La visibilidad de uso sigue siendo importante. Necesitas saber si los agentes entran en bucles y si un mes de lanzamientos cruzará el límite incluido.

Los descuentos anuales deben entrar al cálculo al final. Primero encuentra el modelo más barato en condiciones mensuales. Después aplica el descuento y el coste del compromiso. Pagar diez meses por una herramienta que abandonas a los tres no es un ahorro.

Los reintentos pertenecen al nivel base, no a una nota al pie

Los reintentos son trabajo normal de desarrollo, así que una comparación de precios que suponga resultados perfectos al primer intento no sirve para comprar. La cifra útil es la amplificación de reintentos: intentos totales divididos entre iteraciones solicitadas.

El ejemplo tiene 125 intentos interactivos para 100 iteraciones solicitadas, lo que da una amplificación de reintentos de 1.25. Eso no significa que el 25 por ciento de los prompts simplemente falle. Algunas solicitudes necesitan aclaración, algunas ediciones pasan las comprobaciones de código pero no cumplen la intención y algunos fallos proceden de herramientas o dependencias. El efecto en la facturación es el mismo cuando el plan mide otro intento.

Mide los reintentos con una regla que dos personas puedan aplicar de forma consistente. Cuenta un reintento cuando el usuario repite el mismo resultado deseado después de rechazar o reparar el resultado anterior. No cuentes como reintento un requisito genuinamente nuevo. Etiqueta por separado los reintentos automáticos porque el usuario quizá nunca los vea.

Una prueba piloto pequeña debe incluir las tareas que esperas que sean difíciles. Si solo pruebas textos y cambios de color en una página de destino, la tasa de reintentos dice poco sobre migraciones de bases de datos, autenticación, gestión de estado o compilaciones móviles. Somete al menos un cambio arriesgado a cada candidato e inspecciona el registro de actividad.

Los reintentos afectan a los modelos de forma distinta:

• La facturación por créditos suele cobrar los recursos consumidos en cada intento.
• La facturación por tareas iniciadas suele cobrar cada intento si el reintento crea un evento.
• La facturación por finalización puede absorber los intentos fallidos, según su regla de finalización.
• La facturación plana absorbe los reintentos hasta que alcanzan un límite incluido o un control de uso razonable.

No aceptes los reintentos gratuitos como una respuesta completa. Pregunta si el reintento usa el mismo modelo, si una alternativa automática consume una asignación independiente y cuánto tiempo permanece abierta la ventana de reintento gratuito. Una corrección enviada a la mañana siguiente puede convertirse en una tarea nueva aunque el trabajo sea claramente el mismo.

También existe un coste humano de los reintentos. Un plan puede ser barato en dinero y caro en atención si los usuarios deben supervisar cada reparación. Durante la prueba piloto, registra los minutos de revisión por cambio aceptado. No fuerces ese tiempo dentro de la factura de la plataforma, pero muéstralo junto a la factura para que un precio bajo no oculte un mal flujo de trabajo.

Los agentes en segundo plano son el multiplicador invisible

El trabajo de los agentes en segundo plano debe aparecer en su propia fila porque puede continuar después de que el usuario vea una respuesta. La indexación del repositorio, la planificación, las comprobaciones de dependencias, las pruebas, la supervisión de compilaciones, el despliegue y los agentes de reparación pueden consumir presupuesto sin añadir otro mensaje de chat.

Nuestro ejemplo asigna 35 ejecuciones en segundo plano y 45 unidades de crédito cada semana. Esas cifras son hipótesis deliberadamente visibles. Sustitúyelas por registros de uso de una prueba piloto. Si un proveedor muestra solo un total combinado, ejecuta el mismo prompt una vez con la automatización opcional desactivada y otra con ella activada. La diferencia es una estimación, no una prueba, pero es mejor que tratar el trabajo como gratuito.

El modo de planificación merece atención especial. Un plan puede reducir implementaciones fallidas costosas al detectar conflictos pronto, o puede añadir un paso de pago antes de cada edición trivial. Pruébalo por separado con cambios pequeños y grandes. La política adecuada podría ser usar planificación para cambios de esquema y trabajo en varios archivos, y omitirla para ediciones de texto.

La indexación tiene otra forma de coste. El primer análisis de un repositorio puede ser caro, mientras que las actualizaciones incrementales posteriores cuestan poco. Una prueba piloto de una semana puede exagerar el coste en régimen estable si incluye la indexación inicial, o infravalorarlo si el repositorio de producción es mucho mayor. Separa el consumo de configuración del consumo recurrente.

Las pruebas y el despliegue no son desperdicio opcional. Desactivarlos para ajustarte a una asignación de créditos transfiere la detección de fallos a los usuarios. Calcula el precio del flujo de trabajo seguro que piensas ejecutar, incluidas las comprobaciones que lo protegen. Una comparación basada en pruebas desactivadas responde a la pregunta empresarial equivocada.

Koder.ai ofrece modo de planificación, despliegue y alojamiento, instantáneas y reversión, y exportación de código fuente, así que una prueba piloto puede observar estas partes del flujo de trabajo en vez de calcular solo los mensajes de chat. Los nombres y precios de los planes aún deben comprobarse en la interfaz actual del producto, porque el contexto del sitio establece niveles, no sus asignaciones actuales.

Fija un presupuesto de segundo plano si el producto lo permite, pero no confundas un límite con previsibilidad. Un límite evita gasto excesivo deteniendo el trabajo. La aplicación aún puede perder un lanzamiento mientras un agente espera más capacidad. Registra tanto el límite económico como la consecuencia operativa.

Somete a cada candidato al mismo registro

Un registro hace reproducible la comparación y deja al descubierto la ambigüedad contractual antes de que se convierta en una disputa por la factura. Cada fila debe describir un evento medido, con suficiente contexto para asignarlo a créditos, tareas y límites de suscripción.

Copia esta cabecera CSV y úsala durante una prueba piloto:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Mantén separados el tipo de evento y el resultado. Una prueba en segundo plano puede completarse correctamente mientras el cambio solicitado sigue sin ser aceptado. Si agrupas esos hechos en un solo estado, no podrás comprobar la regla del proveedor sobre tareas completadas.

Al final de la semana, calcula cuatro valores:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Después aplica las condiciones del plan sin cambiar las filas. Para el catálogo hipotético, el cálculo es:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Una hoja de cálculo también debe mostrar los créditos desperdiciados, la capacidad incluida restante y el siguiente límite de precio. El plan ganador del ejemplo conserva 58.75 ejecuciones interactivas y 48.45 ejecuciones en segundo plano. Ese margen no es suficiente para una semana de lanzamientos que duplique el trabajo de despliegue, así que el equipo debe calcular ese caso antes de comprometerse.

Pide al proveedor que revise una página anonimizada del registro. No preguntes qué plan es el más barato; pregunta cómo clasificaría cada fila. Una clasificación por escrito es más útil que una estimación comercial porque puedes compararla con la primera factura.

La variación importa más que el precio de etiqueta

El resultado del ejemplo es una suscripción plana de $79, paquetes de créditos de $90 y facturación por tareas iniciadas de $96.99. Esa clasificación solo se aplica al catálogo y la carga de trabajo indicados. Un pequeño cambio en el tratamiento de los reintentos o del trabajo incluido en segundo plano puede invertirla.

Calcula un punto de equilibrio para cada pareja. El plan plano de $79 supera a los paquetes de créditos de $30 cuando la demanda mensual exige tres o más paquetes, suponiendo que los créditos sin usar no tengan valor futuro. Si la acumulación permite al comprador usar todas las unidades, $79 equivale a unas 1,316.7 unidades de crédito a seis centavos cada una. Por debajo de ese uso, los créditos completamente utilizados cuestan menos.

Frente a tareas iniciadas a $0.14, $79 equivale a unos 564.3 eventos. Los 692.8 eventos esperados superan ese punto. Sin embargo, si el plan por tareas cobra solo las 433 iteraciones solicitadas, cuesta $60.62 y gana. Una definición vuelve a importar más que la tarifa principal.

Ejecuta casos de sensibilidad en vez de fingir que la estimación es exacta. Para esta carga, cambia la amplificación de reintentos de 1.10 a 1.50, el trabajo en segundo plano de 20 a 60 eventos semanales y el consumo de las ediciones complejas con un multiplicador razonable indicado por el proveedor. No necesitas decenas de escenarios. Necesitas las pocas variables que pueden cambiar la decisión.

Considera por separado el flujo de caja y el compromiso respecto al coste unitario. Los paquetes pueden conservar flexibilidad. Una suscripción mensual crea un límite predecible mientras permanezcas dentro de su límite. Una suscripción anual cambia flexibilidad por descuento. La exportación de código fuente y las instantáneas pueden reducir el coste de abandonar un creador, pero no hacen gratuita la migración; la aplicación exportada aún necesita una compilación funcional, infraestructura y alguien que pueda mantenerla.

Una persona fundadora con un uso incierto debe preferir el modelo cuyo riesgo sea visible. Eso puede significar paquetes con acumulación prolongada, incluso cuando el total mensual esperado sea algo mayor. Un equipo con trabajo estable y medido puede comprar un plan plano cerca del centro de su rango incluido. Un plan por tareas encaja con trabajo que se asigna claramente a resultados aceptados e incluye la reparación dentro de la tarea.

No elijas basándote en el ganador del ejemplo. Elige después de sustituir cada tarifa y límite hipotético por condiciones que puedas señalar, y cada hipótesis de carga de trabajo por una observación de la prueba piloto.

Somete el modelo de facturación a una prueba de aceptación

Un modelo de precios está listo para decidir cuando otra persona puede reproducir el total mensual a partir del registro y de las condiciones del plan. Si el cálculo depende de que una persona de ventas interprete una tarea interna después de los hechos, el modelo no supera la prueba.

Usa esta lista compacta de aceptación:

1. Registra 100 iteraciones solicitadas representativas, o una muestra menor que incluya cada tipo principal de trabajo.
2. Etiqueta reintentos, reintentos automáticos, planes, pruebas, compilaciones, despliegues y otras ejecuciones en segundo plano.
3. Asigna cada evento a la regla del proveedor sobre créditos, tareas o capacidad incluida.
4. Calcula los totales esperados para un mes tranquilo y un mes de lanzamientos con el mismo factor de 4.33.
5. Guarda las condiciones del plan y compara la primera factura real con la previsión.

Fija una tolerancia antes de la prueba piloto. Por ejemplo, podrías investigar cualquier total que supere en más de un 10 por ciento la previsión. El porcentaje es una decisión de gestión, no un estándar del sector. Su propósito es obligar a revisar mientras todavía existe el historial de eventos.

Si el uso real supera la previsión, identifica la categoría de fila responsable. Más trabajo aceptado es distinto de más reintentos. Más ejecuciones de despliegue planificadas son distintas de un bucle de agente. La solución podría ser un plan mayor, una política de agentes más limitada, prompts más claros o una corrección de facturación. Un único total no puede indicarte cuál.

Mantén el registro junto a la factura durante los tres primeros ciclos de facturación, porque una prueba piloto tranquila puede no incluir trabajos por lotes, trabajo de lanzamientos y reparaciones automáticas. El modelo más barato para 100 iteraciones semanales depende, por tanto, de las condiciones, pero la decisión no tiene por qué ser imprecisa. En el ejemplo explícito, gana la suscripción plana de $79. Con facturación por tareas limitada al éxito, el mismo trabajo cuesta $60.62 y gana la facturación por tareas. Los paquetes de créditos ganan con un consumo menor o irregular cuando la acumulación evita desperdicios. Anota qué cuenta, mide el trabajo oculto y deja que la factura demuestre la promesa.