Aller au contenu principal

Budgets et quotas

Un plafond de coût et un plafond de jetons sur chaque exécution, réglés sur la version de l'agent. Ce qu'a coûté un appel est calculé à partir des jetons que déclare le fournisseur et du prix du modèle, jamais deviné.

Chaque appel de modèle passe par un seul endroit de la plateforme, le worker, qui consigne pour chaque appel les jetons déclarés par le fournisseur, le prix du modèle et le coût qui en résulte. Les plafonds, les écrans du Studio et les exports lisent tous ces enregistrements.

Les plafonds d'une exécution​

Une exécution a 2 plafonds, enregistrés avec la version de l'agent dans la carte Plafonds de dépense de l'onglet Guardrails de l'agent :

  • Plafond de coût d'un run : en dollars, de 0,01 à 1 000.
  • Plafond de jetons d'un run : de 1 000 à 50 millions de jetons.

Les deux comptent l'exécution entière, sous-agents compris. Le premier plafond atteint arrête l'exécution : elle se termine en échec, avec le plafond dépassé pour motif. Les plafonds sont figés à la création de l'exécution : une modification n'affecte pas les exécutions déjà en cours.

Quand l'agent ne fixe aucun plafond, les variables de projet BUDGET_MAX_LLM_COST_USD et BUDGET_MAX_LLM_TOKENS s'appliquent, puis le défaut de la surface d'où vient l'exécution, et en dernier un défaut de plateforme de 1 USD, sans plafond de jetons. Sur le widget, les défauts de la surface sont WIDGET_RUN_MAX_COST_USD (1 USD sauf si l'exploitant le change) et WIDGET_RUN_MAX_TOKENS (600 000 jetons).

Pourquoi aussi un plafond de jetons

Le coût d'un appel se calcule à partir du prix du modèle. Un modèle sans prix a un coût inconnu, compté à part et qui n'ajoute rien au total : un plafond de coût ne l'arrête donc jamais. Le plafond de jetons, si, parce que le fournisseur déclare les jetons à chaque appel.

Un plafond borne ce que Rikoo dépense pour votre compte chez un fournisseur. C'est un contrôle, pas une relation de facturation : ce que vous payez au fournisseur reste entre vous et lui.

Rikoo ne plafonne pas la dépense sur une période, ni par projet ni par organisation. Pour être prévenu quand la dépense dérive, l'écran Alertes propose 2 règles, désactivées par défaut : Coût très au-dessus d'une journée normale (avertissement à 2 fois, alerte à 4 fois le coût d'une journée normale) et Jetons transportés par run. Voir Alertes.

Quotas​

Les quotas du plan (agents, projets, membres, collections, outils, serveurs MCP, secrets, exécutions de production par mois, entre autres) ne s'appliquent que sur l'offre hébergée, selon le plan de l'organisation. Une instance auto-hébergée n'est plafonnée par aucun plan ; l'écran Usage & Coûts montre ce que détient l'organisation.

Lire les chiffres​

  • Traces, sous Surveillance, montre le coût de chaque exécution, réparti entre son coût propre et celui de ses sous-agents.
  • Usage & Coûts montre le coût par agent sur 30 jours et une projection, et compte à part les appels de coût inconnu au lieu de les ajouter comme des zéros. Les chiffres s'exportent en CSV.
  • Quand l'export des traces en OTLP est configuré, chaque span d'appel de modèle porte son coût (gen_ai.usage.cost) et chaque span d'exécution son total (rikoo.run.cost_usd). Les métriques collectées portent les jetons et les durées, pas le coût. Voir Observabilité.

Les modèles facturés à l'unité plutôt qu'au jeton (une seconde d'audio, un caractère, une image) sont comptés dans leur propre unité, avec le prix du registre des modèles : une facture n'est jamais doublée en additionnant deux choses différentes.

Le prix enregistré pour chaque modèle, dans l'unité où il est facturé. La métrologie lit ces chiffres, elle ne les estime pas.
Per-model prices and context windows under a provider, with a model the registry lists but the provider no longer serves switched off.