Créditos

Hay dos formas de pagar la inferencia en Helmcode, y funcionan juntas en lugar de sustituirse.

Un plan mensual compra una cuota plana en nuestros propios modelos: ilimitada en los eficientes y con tope mensual en los más grandes. El crédito es un saldo prepago en euros que se gasta por token, a la tarifa publicada de cada modelo. Necesitas crédito para todo lo que un plan no cubre, y el caso más claro son los modelos de frontera que revendemos de OpenAI, Anthropic y Google, que ningún plan cubre en ningún nivel.

El saldo

Un saldo por organización, en euros. No caduca y no se reinicia: el crédito se gasta, no se renueva. Todo va en euros además: el saldo, el extracto, la lista de precios y las facturas, así que nunca lees tu saldo en una unidad distinta de la de tu factura.

Tres propiedades que conviene conocer, porque son las que hacen defendible la cifra:

• El saldo nunca baja de cero. Cuando una petición cuesta más de lo que queda, cobramos lo que había y absorbemos la diferencia. Tu extracto muestra las dos cifras, lo que costó la petición y lo que cobramos de verdad, así que la diferencia se ve en lugar de quedar sin explicar.
• Cada movimiento es una fila. Compras, consumo, recargas automáticas, devoluciones y ajustes se añaden a un libro que nunca se reescribe, y cada cargo referencia la petición que lo generó. Eso es lo que permite responder meses después a una pregunta sobre una sola petición.
• Los importes son exactos. El saldo se guarda internamente en micro-euros enteros y no como número en coma flotante, así que una serie larga de cargos pequeños sigue cuadrando al céntimo.

Qué paga el crédito, y en qué orden

Para una petición cualquiera, el orden es fijo:

Son, por tanto, dos contadores separados que nunca se suman y de los que solo uno se reinicia: la cuota del plan se mide en tokens y se reinicia el día 1, el crédito se mide en euros y no se reinicia nunca.

Dos consecuencias de ese orden:

• Una organización con crédito y sin ninguna suscripción puede usar toda la plataforma pagando por token.
• Una organización suscrita nunca paga con crédito algo que su plan ya cubre. La cuota del plan se consume siempre primero, así que no hay doble cobro.

Comprar crédito

Las compras son puntuales, se hacen desde la sección de créditos de la consola y se pagan con Stripe Checkout. El importe tiene que estar entre 5 € y 5.000 €.

El techo es una protección contra errores de teclado, no una política: si necesitas más de 5.000 € de una vez, habla con nosotros. El suelo existe por la comisión.

La comisión al comprar

La comisión es max(5% del importe, 0,80 €), se cobra encima del crédito que compras y se muestra antes de pagar. Compra 100 € de crédito y se te cobran 105 €, de los cuales 100 € entran en el saldo. Compra 10 € y se te cobran 10,80 €. Por debajo de unos 16 € lo que manda es el suelo de 0,80 €; por encima toma el relevo el 5%.

Por qué una comisión al comprar y no un margen sobre la inferencia: nuestro precio por token publicado es exactamente el que se cobra, tanto en nuestros modelos como en los revendidos. Esa es la propiedad que te permite multiplicar cantidades por tarifas y llegar al importe que cobramos, y un margen escondido en la tarifa por token la destruiría. Así que el coste de aceptar un pago con tarjeta se cobra donde se produce: en la compra. El procesamiento de tarjeta tiene un coste fijo por transacción, y por eso la comisión tiene un suelo en lugar de ser un porcentaje plano hasta el céntimo.

Una compra genera una factura con los datos fiscales de tu organización, y el crédito entra en el saldo en cuanto el pago se completa.

Recarga automática

Opcional. Fijas un umbral y un importe, y cuando el saldo baja del umbral compramos ese importe con la tarjeta guardada.

• Solo tarjeta. Nuestra cuenta de Stripe es española, así que la alternativa sería domiciliación SEPA, que tarda días en liquidar, y una recarga que llega tres días después de que el saldo llegase a cero no es una recarga. Si tu método de pago por defecto no es una tarjeta, el control se ve y está desactivado indicando el motivo, nunca desaparecido sin más.
• Un rechazo la suspende en lugar de reintentar. Te avisamos, apagamos la función y dejamos que el saldo baje y rechace limpiamente. Volver a guardar el ajuste es la única forma de rearmarla, y es deliberado: cualquier cosa automática ahí sería el bucle de reintentos que estamos evitando.

Cuando el crédito se agota

• Antes de cero. Por debajo de tu umbral de saldo bajo (2 € por defecto, y configurable) te enviamos un correo.
• En cero. Una petición que necesita crédito se rechaza con 402 y el código credits_exhausted, distinto de subscription_required y de monthly_cap_reached para que tu cliente pueda diferenciar los tres y reaccionar distinto a cada uno.
• Qué sigue funcionando. Todo lo que cubre tu plan. Solo rechaza la parte que se paga con crédito, así que una organización suscrita que se quede sin crédito conserva el acceso completo a su tarifa plana.

Nota: recibir credits_exhausted en un modelo de frontera mientras tus modelos propios siguen respondiendo es el comportamiento previsto, no un fallo. Un rechazo en un modelo no es una caída. Mira Modelos.

Dónde se ve el desglose

La sección de créditos de la consola tiene dos pestañas. La segunda aparece cuando el crédito está activado para tu organización.

Balance. El saldo, tus umbrales, los ajustes de recarga y los movimientos más recientes. Cada fila de consumo lleva el modelo, el importe cobrado, el saldo resultante y las cantidades medidas: tokens de entrada, tokens de entrada en caché, escrituras de caché y tokens de salida. Las filas de compra llevan además la comisión y el porcentaje del que sale. Las filas de consumo no llevan comisión alguna, porque no hay margen sobre el consumo.

Private models. La tarifa vigente de cada uno de los nueve modelos de frontera, que es la que manda, y lo que te ha costado cada uno en una ventana declarada. La ventana se devuelve para que leas el periodo que has obtenido de verdad y no el que pediste, y se calcula sobre un agregado diario en lugar de sobre los últimos movimientos. Eso importa a medida que creces: un número fijo de filas recientes es un mes en una cuenta tranquila y cinco minutos en una con tráfico, así que una cifra sacada de ahí se encoge justo cuando empieza a interesar. Esta vista es tu consumo medido completo de la ventana, no una muestra de actividad reciente, y separa además nuestros modelos de los revendidos.

Reconciliar

Las facturas y el extracto responden preguntas distintas, y mezclarlos es la fuente habitual de confusión.

• Una factura se emite cuando compras crédito: el importe, la comisión y los impuestos. El consumo no se factura nunca: baja el saldo.
• El extracto es el registro de ese consumo. Para comprobar un cargo, multiplica cada cantidad medida por la tarifa publicada de su clase y suma las cuatro. Ese total es lo que se cobró.

Dos detalles hacen que la cuenta salga:

• Se listan las cuatro clases de token, escrituras de caché incluidas. En los modelos de Anthropic una escritura de caché se cobra a su propia tarifa, por encima de la de entrada, así que una comprobación que la ignore queda por debajo de lo cobrado sin nada visible que explique la diferencia. Mira por qué Anthropic cobra las escrituras de caché por separado.
• Cada cargo pertenece a la versión de precio que lo generó. Cuando reajustamos un precio, la tarifa antigua se cierra y se abre una sucesora, y los cargos históricos no se recalculan nunca a la tarifa nueva. Un extracto de hace dos meses sigue cuadrando con la tarifa que estaba vigente entonces, mientras que la tarifa que te cobra hoy es siempre la de la consola.

Ver también

• Modelos para los modelos de frontera que solo se pagan con crédito, y sus tarifas.
• Rate limits para los límites por clave y las cuotas mensuales del plan, que son independientes del crédito.
• Precios para los planes mensuales.