Suscripción o pago por token tiene un cruce claro

Una suscripción sale más barata que el pago por token cuando su coste mensual por intento útil baja del coste medido de producir el mismo trabajo aceptado. El error habitual es usar el número de prompts como unidad. Ese número dice muy poco. El equipo paga por funciones aceptadas, y entre un prompt y una función terminada aparecen reintentos, contexto creciente, ramas descartadas y mínimos de usuarios.

La cuenta empieza con una función, no con un mensaje. Hay que estimar sus intentos, cómo crecen los tokens tras cada fallo y qué parte de la capacidad pagada no produce código aprovechable. Después se amplía el modelo al mes y se aplican los límites reales del plan. El cruce es un intervalo, no un porcentaje universal, porque el tamaño de la función y la política de contexto suelen moverlo más que el precio anunciado.

La unidad correcta es una función aceptada

Una función aceptada es la pieza mínima que el equipo considera terminada: una pantalla de acceso conectada a una API, un webhook de facturación con pruebas o un formulario móvil que guarda bien. Usa el límite que ya maneje el equipo al planificar. Un primer borrador vistoso no cuenta si alguien todavía debe reparar el modelo de datos o rehacer las pruebas.

Para cada función, registra intentos hasta la aceptación. Un intento empieza cuando el modelo recibe contexto suficiente para proponer una implementación sustancial y termina al aceptarla, rechazarla o cambiar de dirección. Las preguntas pequeñas pueden asignarse al intento que las rodea. La coherencia importa más que una clasificación perfecta.

El coste medido básico es:

metered_feature_cost = sum(attempt_input_tokens * input_rate
                         + attempt_output_tokens * output_rate
                         + tool_charges)

Usa las tarifas de la factura. Si la entrada en caché, los tokens de razonamiento, las imágenes o las herramientas tienen otros precios, déjalos en términos separados. Un precio combinado solo sirve después de calcularlo con tu mezcla real.

La suscripción necesita el mismo límite:

subscription_feature_cost = allocated_monthly_subscription_cost
                            / accepted_features_within_plan

Dividir el plan por todos los chats lo hace parecer barato porque los fallos inflan el denominador. Dividir la factura de tokens solo por prompts exitosos oculta esos fallos. Ambos lados deben dividirse por funciones aceptadas.

Mide aparte el tiempo humano de reparación. Pertenece a una decisión más amplia, pero añadir salarios a un solo lado estropea la comparación. Primero compara gasto de plataforma para resultados equivalentes; después añade trabajo si una opción cambia de forma constante la revisión o reparación.

La tasa de reintento no cambia de forma lineal

La tasa debe ser la probabilidad de que un intento falle y exija otro, no el porcentaje de funciones que tuvieron algún reintento. Si cada intento tiene probabilidad independiente r, el número esperado es:

expected_attempts = 1 / (1 - r)

Un 20% produce 1,25 intentos esperados, un 50% produce 2 y un 80% produce 5. La curva se acelera porque cada reintento también puede fallar. 1 + r solo cuenta uno y subestima el trabajo difícil.

La independencia es aproximada. Los fallos se agrupan alrededor de requisitos ambiguos, entornos desconocidos o una mala arquitectura que sigue en el contexto. Conviene medir una muestra:

observed_attempts_per_feature = total_material_attempts / accepted_features
observed_retry_rate = (total_material_attempts - accepted_features)
                      / total_material_attempts

Si 40 funciones aceptadas necesitaron 68 intentos sustanciales, hay 1,7 intentos por función y cerca de un 41% de reintento. La relación ya incluye fallos repetidos y resulta más segura que la memoria.

No llames fallo a cada revisión. Una secuencia prevista de esquema, API e interfaz contiene etapas exitosas. Cuenta reintento cuando el nuevo intento sustituye o repara trabajo que debía superar la aceptación. Iterar es un método de producción; reintentar es rehacer. Confundirlos penaliza una buena descomposición.

Presupuesta al menos dos bandas. Las funciones rutinarias se acercan a la mediana; migraciones, integraciones nuevas y peticiones vagas ocupan una banda alta. Un promedio único esconde la cola que suele agotar el plan.

El contexto creciente puede costar más que el reintento

Los intentos rara vez tienen igual tamaño. El primero puede llevar una especificación breve y pocos archivos. El cuarto suma la petición original, código generado, errores, pruebas y correcciones. Con pago medido, cada entrada repetida vuelve a cobrarse salvo que exista una tarifa reducida de caché.

Modela el crecimiento con datos o un multiplicador:

input_tokens_on_attempt_n = initial_input_tokens * growth_factor^(n - 1)
output_tokens_on_attempt_n = initial_output_tokens * output_factor^(n - 1)

Con 30.000 tokens de entrada iniciales, 4.000 de salida y crecimiento de entrada del 35%, el cuarto intento ronda 73.800 tokens de entrada. Cinco burbujas parecidas no generan cinco cargos iguales.

El crecimiento exponencial sirve para pruebas de tensión, pero algunas herramientas recortan, resumen, almacenan o cargan contexto de forma selectiva. Mide el comportamiento real. Exporta tokens o registra una semana. Si la interfaz los oculta, estima por tamaño de archivos e historial y prueba factores bajos y altos.

Tras dos fallos, abrir una conversación limpia puede quitar contexto contaminado. Reduce entrada repetida, pero añade preparación y puede perder decisiones. Trátalo como un intento inicial más un coste fijo:

reset_cost = repository_context + specification + accepted_decisions

Así la higiene del contexto adquiere precio. Mantener todo puede consumir más tokens; reiniciar siempre repite el mapa y la especificación. El punto económico depende del crecimiento y de si la caché sobrevive entre conversaciones.

En una suscripción el contexto también consume capacidad, aunque no aparezca como línea de tokens. Puede acelerar límites, provocar restricciones o reducir funciones mensuales. El uso incluido es capacidad, no tokens infinitos.

Una ecuación encuentra el cruce

Usa funciones aceptadas al mes como resultado común. Define:

• S: coste mensual total, incluidos usuarios obligatorios.
• F: funciones aceptadas por mes.
• A: intentos esperados por función aceptada.
• C(A): coste medido de tokens y herramientas con crecimiento de contexto.
• L: funciones máximas antes de límites o recargos.

Dentro de la capacidad, gana la suscripción cuando:

S / F < C(A), provided F <= L

El cruce mensual es:

F_crossover = S / C(A)

Por encima de F_crossover, la suscripción es más barata si el plan aguanta. Por debajo, gana el pago medido. Con tamaños distintos, suma el coste de la mezcla real.

Para despejar la tasa, sustituye A = 1 / (1 - r). Si cada intento cuesta c:

S / F = c / (1 - r)
r_crossover = 1 - (c * F / S)

La abreviatura solo funciona con intentos parecidos. Si crece el contexto, calcula C(A) para varias tasas y busca la primera cuyo coste mensual supera S. Una hoja con tasas en filas y funciones en columnas es más clara. Cada celda muestra metered_monthly_cost - subscription_monthly_cost; marca también los límites, porque un cruce barato pero bloqueado no sirve.

Un ejemplo descubre las variables ocultas

Imagina cuatro personas y una suscripción de 120 dólares por usuario y mes: 480 dólares para 24 funciones medianas. Es un ejemplo, no el precio de un servicio citado.

La mezcla real produce tarifas de 0,000006 dólares por token de entrada y 0,000018 por salida. El primer intento usa 40.000 de entrada y 5.000 de salida; la entrada crece un 30% por reintento.

Sin reintentos:

40,000 * $0.000006 + 5,000 * $0.000018 = $0.33

Las 24 funciones cuestan 7,92 dólares. Con un 50% de reintento se esperan dos intentos:

attempt 1: 40,000 input + 5,000 output = $0.33
attempt 2: 52,000 input + 5,000 output = $0.402
feature total: $0.732
monthly total: $17.568

La suscripción aún pierde por mucho. Incluso cinco intentos cuestan unos 2,42 dólares por función, cerca de 58 al mes. Una tasa alta no vuelve rentable un plan de 480 dólares si la función inicial es pequeña.

Cambia ahora el tamaño. Una refactorización de todo el repositorio empieza con 900.000 tokens de entrada y 35.000 de salida, con crecimiento del 25%. El primer intento cuesta 6,03 dólares y cinco cuestan 41,88. Para 24 funciones, el total ronda 1.005 dólares. La suscripción podría ganar, si tiene capacidad.

La fórmula simple con $S = 480, $F = 24 y $c = 6.03 da:

r_crossover = 1 - (6.03 * 24 / 480)
            = 0.6985

El cruce aproximado es 69,85%. El contexto creciente lo reduce. Conviene dar un intervalo entre tasas probadas y no fingir precisión decimal. El salto de 40.000 a 900.000 tokens mueve más la decisión que un cambio pequeño de fallos. Copia el método, no el porcentaje ajeno.

Los usuarios pueden borrar una ventaja aparente

La suscripción cobra acceso; el modelo medido cobra consumo. Diez personas ocasionales pueden requerir diez plazas aunque dos concentren el uso. Calcula:

S = required_seats * seat_price + fixed_plan_fees

Incluye a quienes necesitan acceso directo para pedir o revisar. No inventes plazas para quien solo lee resultados exportados si el contrato lo permite. La colaboración real decide.

Mide también:

seat_utilization = active_prompting_days / available_workdays

Una utilización baja no siempre es despilfarro; alguien puede usarlo solo en la semana de lanzamiento y evitar un traspaso caro. Pero compara el plan completo con una cuenta medida y controles adecuados, no con el gasto de los dos usuarios más activos.

El crecimiento del equipo crea escalones: una contratación añade una plaza completa y al principio solo parte del resultado. Ejecuta el modelo con la plantilla actual y la prevista. Para descuentos anuales, compara coste y trabajo anuales, incluidos vacaciones, vacantes y meses tranquilos.

Los límites crean un segundo cruce

Una suscripción puede ser barata en papel y no soportar la carga. El primer cruce es financiero; el segundo es operativo. Expresa el límite en su unidad real: mensajes, peticiones ponderadas, créditos, tokens o ventana móvil. Después conviértelo:

feature_capacity = usable_monthly_units
                   / expected_units_per_accepted_feature

Usa unidades aprovechables y reserva margen para investigación, planificación y cadenas graves. Si todo cabe solo con el intento mediano, el plan ya va justo.

Al cruzar el límite, el trabajo espera, se ralentiza, paga exceso o sube de nivel. Para recargos:

hybrid_cost = subscription_cost + max(0, usage - included_usage) * overage_rate

Un tope duro vuelve inviable el plan si bloquea la entrega. Informa de la falta de capacidad junto al precio. Prueba también el día y la semana de más uso, pues una tarde de lanzamiento puede alcanzar una ventana móvil.

Koder.ai ofrece niveles free, pro, business y enterprise; hay que comparar el nivel cuyas plazas y capacidad encajan. Su modo de planificación, snapshots y rollback pueden cambiar los reintentos observados, por lo que conviene medir un piloto propio.

Un piloto debe evitar el autoengaño

El piloto necesita suficiente detalle para repetir la decisión. Dos semanas pueden bastar en un equipo constante si incluyen tareas rutinarias y difíciles, no solo demos pulidas.

Registra una fila por intento sustancial con:

• identificador y banda de tamaño de la función;
• número de intento y aceptación o rechazo;
• tokens de entrada, caché y salida o unidades del plan;
• reinicio, cargos de herramientas y ventana temporal;
• usuario que inició el intento.

Mantén idéntica la regla de aceptación. Una revisión visual en un lado y pruebas en el otro no producen trabajo equivalente. Escribe la regla antes.

Separa causas: cambio de requisito, fallo del modelo, contexto contaminado, herramienta y error de usuario. Algunas cambian con la interfaz; un requisito modificado tres veces consume capacidad en todas. Un snapshot reduce el coste de una mala rama, pero no arregla requisitos vagos.

Calcula la función mediana, la banda de muchos reintentos y la mezcla mensual real. Ejecuta sensibilidad cambiando funciones, tasa, crecimiento y plazas de uno en uno. Si un 10% cambia la elección, busca un compromiso corto o más datos. Si todos los casos razonables coinciden, la decisión es estable.

Elige según la forma de la carga

El pago por token suele encajar con uso escaso, contextos pequeños, experimentos y trabajo que puede esperar. Una cuenta sin uso casi no genera inferencia. El riesgo son contextos largos y fallos repetidos, sobre todo con agentes que añaden peticiones invisibles.

Una suscripción encaja con flujo estable, funciones caras y plazas bien utilizadas dentro del límite. La previsibilidad tiene precio. Si cuesta 200 dólares más pero finanzas exige una factura fija, registra esos 200 como coste de previsibilidad.

Cambiar de plan porque los reintentos se sienten frecuentes es mala recomendación. Recordamos la función dolorosa de cinco intentos y olvidamos doce éxitos baratos. La factura pondera tokens; la memoria, frustración. Un mes de datos corrige esa diferencia.

No elijas solo por modelos nuevos. Uno más capaz puede reducir intentos y costar más por token. Divide el piloto por tamaño y usa el modelo que elegiría un operador competente. Un prompt visible también puede activar agentes de planificación, implementación y revisión; compara la función completa, no la burbuja.

Guarda valores bajo, esperado y alto para cada dato incierto, tomados de la variación observada. Identifica cuál cambia la decisión. La duración del contrato exige margen: un mes admite probar cerca del cruce, un año necesita espacio para periodos tranquilos y plazas vacías.

Aplica impuestos, divisas y créditos de forma coherente. Los créditos que caducan solo ahorran si se convierten en trabajo aceptado. Asigna una persona a actualizar el modelo cuando cambien precios, plantilla, funciones o intentos.

El denominador también depende de especificaciones y revisores. Si el equipo solo puede aceptar 18 funciones, usar 30 abarata la suscripción sobre el papel sin producir más. Prueba además una mezcla: suscripción para usuarios intensivos y pago medido para ocasionales, calculando cada grupo por separado.

Contratación puede pedir una sola tasa. Entrega un intervalo con supuestos y el punto donde falla la capacidad. Distingue decisiones de uso inmediato de renovaciones: el coste ya pagado no afecta al próximo contrato, aunque la capacidad incluida que queda pueda tener coste marginal cero hoy.

Seguridad, ubicación de datos, exportación de código, despliegue y rollback pueden filtrar opciones antes del precio. No inventes equivalentes monetarios para requisitos obligatorios.

Registra también funciones canceladas. Sus tokens y capacidad consumida no vuelven; asígnalos a una categoría de abandono y al área que los causó. Tal vez el supuesto problema de precios sea un problema de especificación.

Conserva toda la precisión dentro de la hoja, pero presenta la tasa como intervalo o porcentaje entero. Un 62,437% promete una exactitud inexistente.

Escribe dos números juntos: coste por función aceptada y capacidad de funciones en la ventana más intensa. El primero muestra dónde se cruzan suscripción y pago por token. El segundo confirma si ese cruce existe en la práctica. Sin ambos, la hoja describe un precio, no tu producción.