STU, cuotas y gasto

Shara mide el consumo en una única unidad, la STU (Shara Token Units), independiente del modelo que se use por debajo. A eso se suman cuotas claras por plan, excedentes previsibles, rollover y cortes de gasto automáticos: la idea es que nunca tengas una factura sorpresa a fin de mes.

La STU es la unidad única de consumo del cliente, independiente del modelo usado por debajo. La regla es directa: 1 STU = 1 token ponderado. Cada vez que un agente lee o escribe, Shara cuenta los tokens reales (entrada más salida), les aplica el peso del modelo que atendió la petición y eso es el STU. No hay divisor ni escala oculta entre medias.

Los pesos hacen dos cosas. La salida pesa más que la entrada, porque cuesta más de generar. Y los modelos más capaces pesan más por token, así que la misma frase resuelta por Symphony gasta más STU que resuelta por Prelude. El peso del modelo es proporcional a lo que cuesta de verdad, de modo que gastar la cuota entera en el modelo más caro no te da menos trabajo del que pagaste.

La conversión es determinista: para un mismo modelo y un mismo volumen de tokens, el gasto en STU es siempre el mismo. No hay tarifas ocultas ni redondeos opacos.

Tier	Alias	Peso por token
Ágil	Prelude	El más bajo de los tres cloud
Producción	Sonata	La referencia: entrada 1, salida 2,5
Alta capacidad	Symphony	El más alto
Local	Concerto	0 · corre en tu hardware, no consume cuota

En números redondos: una tarea de 8.000 tokens de entrada y 1.200 de salida sale por unos 3.500 STU con Prelude, unos 11.000 con Sonata y unos 36.750 con Symphony. Sirve para hacerte una idea del orden de magnitud, no como tarifa.

Como Amadeus delega cada tarea al modelo más adecuado, tu consumo baja de forma natural: las tareas rutinarias caen en Prelude o Sonata, y solo el razonamiento complejo llega a Symphony. No pagas capacidad de más para trabajo sencillo.

Cada intercambio con un agente descuenta STU de tu cuota mensual. El consumo de una interacción depende de tres cosas:

• El tamaño de la entrada: el mensaje, más el contexto que el agente necesita (su IDENTITY.md, la memoria relevante, el correo o documento que está leyendo).
• El tamaño de la salida: lo que el agente redacta o razona para responder.
• El modelo que atiende: cuanto mayor es el tier (Prelude, Sonata, Symphony), más STU pesa cada token.

Una tarea puede implicar varias llamadas encadenadas. Si Amadeus recibe una petición y la delega a un agente departamental, y este a su vez consulta una herramienta y elabora un borrador, cada paso suma su parte al total de la interacción. El dashboard desglosa ese recorrido para que veas exactamente en qué se gastó.

Las cuotas están dimensionadas para un uso de empresa real, no para gastarlas en una tarde. Como referencia orientativa (el consumo exacto depende del modelo, del contexto y de la longitud de cada respuesta):

• Una tarea corta (clasificar un correo, extraer datos de un mensaje, redactar una respuesta breve) es de bajo consumo, sobre todo cuando la atiende Prelude o Sonata.
• Una tarea media (redactar una propuesta, resumir un hilo largo, preparar un informe con datos) consume más, porque crece el contexto y la salida.
• Una tarea compleja (analizar un contrato cláusula a cláusula, un análisis estratégico, una investigación profunda) es la que más pesa, y normalmente la resuelve Symphony.

Traducido a capacidad mensual, cada plan da para el orden de miles de interacciones. Es una guía de dimensionado, no una promesa exacta: lo fiable es mirar tu consumo real en el dashboard durante las primeras semanas y ajustar el plan a partir de ahí.

Plan	STU / mes	Perfil de uso que cubre
First	50 M	Un equipo esencial automatizando su día a día
Pro	140 M	Uso diario intensivo con más departamentos
Max	280 M	Operación intensiva multi-departamento
Max ×5	1.150 M	Equipos grandes con alta concurrencia
Max ×20	4.000 M	Volumen alto de empresa mediana

Plan	Precio	STU / mes
First	129 €/mes	50 M
Pro	349 €/mes	140 M
Max	690 €/mes	280 M
Max ×5	2.900 €/mes	1.150 M
Max ×20	9.900 €/mes	4.000 M
Concerto Local	999 €/mes	60 M en la nube (componente híbrido opcional)
Agente adicional	+99 €/mes	+15 M

Existe descuento anual del 10 %. Concerto Local (999 €/mes) despliega Shara en tu propia infraestructura, con todo incluido. Trae además 60 M STU/mes para el componente Amadeus en la nube del modo híbrido, que enciendes o apagas tú: apagado no consume nada, y no genera excedente en ningún caso. Detalle completo de cada plan en Planes y precios.

Si superas tu cuota mensual, la conversación en curso no se corta: pasa a excedente, que se factura como tarifa plana. El excedente se acumula durante el periodo y se suma a tu siguiente factura.

Plan	Excedente
Todos los planes de pago	5 €/M STU
Concerto Local	Sin excedente

La tarifa es plana e idéntica en todos los planes de pago: 5 € por cada millón de STU que gastes por encima de tu cuota. Concerto Local no aplica: su bolsa en la nube es fija y, si se agota, se resuelve con soporte en vez de facturarse.

El rollover premia el uso constante trasladando al mes siguiente los STU que no consumiste. Solo aplica en los planes cloud (la bolsa de Concerto Local es fija y no rueda) y funciona con tres reglas:

1. Se activa si consumes al menos el 80 % de tu cuota base en el mes. Es un incentivo al uso real, no a acumular cuota sin usarla.
2. Tiene un techo del 20 % de la cuota base. Aunque te sobre más, al mes siguiente arrastras como mucho ese 20 %.
3. Caduca a los 2 meses. El rollover no consumido dentro de ese plazo se pierde.

En el mes nuevo, Shara gasta primero el rollover y luego la cuota del mes. Solo cuando ambos se agotan entra el excedente. Con esto, un mes flojo no penaliza al siguiente y el margen que dejaste sin usar sigue estando disponible durante un tiempo.

Ejemplo con Pro (140 M STU/mes): si en un mes consumes 120 M (por encima del 80 %) y te sobran 20 M, arrastras hasta 28 M (el 20 % de 140 M), así que pasan los 20 M completos. El mes siguiente empiezas gastando esos 20 M de rollover y, cuando se agotan, sigues con la cuota base.

Para que no te pille por sorpresa, Shara avisa a medida que te acercas al límite de tu cuota. Los umbrales de aviso son tres:

• 75 %: primer aviso informativo. Vas por buen ritmo de consumo; es buen momento para revisar si el mes viene cargado.
• 90 %: aviso de proximidad al límite. Conviene decidir si activar medidas de ahorro o prever excedente.
• 100 %: has agotado la cuota del mes. A partir de aquí el servicio sigue, pero el consumo entra en excedente (5 €/M) salvo que tengas rollover disponible.

Los avisos llegan al administrador de la cuenta y quedan visibles en el dashboard, junto con el desglose de consumo por agente y por día. Cómo se cobra el excedente y cuándo aparece en la factura, en Facturación y excedentes.

Fuera del horario laboral que configuras (tenants.business_hours), Shara fuerza el bajo consumo automáticamente. La idea es que el trabajo nocturno o de fin de semana (cron, monitorización, alertas) siga funcionando sin disparar coste.

• Downgrade automático de modelo: Symphony pasa a Sonata y Sonata pasa a Prelude, de modo que la misma tarea consume menos STU.
• Límite de salida en Prelude: se acota a 500 tokens para respuestas más contenidas fuera de horario.
• Sin cortar el servicio: se mantienen cron, monitorización y alertas; solo se rebaja el gasto.

En la práctica, el modo de bajo gasto reduce de forma notable el coste fuera de horario sin que dejes de estar cubierto. El horario laboral se define por tenant, así que se adapta a tu jornada real.

Los kill-switches son cortes automáticos por límite duro. Funcionan en tres niveles y cada uno actúa antes de que el siguiente entre en juego. Los importes son billable, es decir, lo que verías en factura.

Nivel	Umbral por defecto	En STU (a 5 €/M)	Qué hace
Por ejecución	5 € en un run	1 M STU	Corta el run y pausa la inferencia de la empresa.
Por hora	50 € en la última hora	10 M STU	Pausa la inferencia y avisa al administrador.
Por día	400 € en las últimas 24 h	80 M STU	Pausa la inferencia mientras la ventana siga por encima.

Las ventanas de hora y día son rodantes, no del reloj: se miran los últimos 60 minutos y las últimas 24 horas desde ahora mismo. La columna en STU es la que ve la app, que trabaja en STU y no en euros; sale de dividir el umbral en euros entre la tarifa de excedente.

Al dispararse un corte se emite el webhook kill_switch.triggered y aparece un banner en el panel. Los cortes por hora y por día se levantan solos cuando su ventana baja del umbral, y el de ejecución al cabo de una hora; un administrador puede levantarlos antes desde el panel, y también dejar una pausa manual que no se levanta sola. En Concerto Local no aplican en modo solo-local: no hay coste en la nube que medir.

Entre la cuota, el rollover, los avisos, el modo de bajo gasto y los kill-switches tienes varias palancas para tener el consumo bajo control. En orden práctico:

• Dimensiona el plan por tu consumo real. Mira el dashboard las primeras semanas y sube o baja de plan según los STU que gastes de verdad, no por estimación.
• Configura bien el horario laboral para que el modo de bajo gasto cubra las horas en las que no necesitas los modelos premium.
• Vigila los avisos de 75 % y 90 % para decidir a tiempo si prevés excedente o ajustas el uso.
• Aprovecha el rollover: mantener un consumo por encima del 80 % hace que el margen sobrante no se pierda del todo.
• Trata cualquier corte de gasto como una señal, no como ruido. Los umbrales son fijos y no se tocan desde el panel: si uno salta, algo se ha desbocado y merece que mires qué.
• Usa el excedente como colchón, no como norma. A 5 €/M es previsible para picos puntuales; si es recurrente, sale a cuenta subir de plan.

Para elegir plan y ver precios completos, ve a Planes y precios. El motor de facturación mide cada llamada por su coste real; el STU que ves tú es el medidor, y no cambia según el plan que tengas: el mismo trabajo cuesta los mismos STU en First que en Max.