Passer au contenu principal
Un agent compromis ne s’arrête pas de lui-même. Une injection de prompt qui le piège dans une boucle de retry, ou une clé fuitée dans un log CI, continuera d’appeler des modèles jusqu’à ce que quelque chose dise stop. Sur OrcaRouter ce « quelque chose », ce sont deux champs sur la clé elle-même : un plafond de dépense et une expiration. Définissez-les une fois dans l’éditeur de clé et la passerelle applique les deux à chaque requête — aucun changement de code d’agent, aucun redéploiement. Cette page est la référence ciblée pour ces deux limites. Pour la liste complète des champs de clé, voir l’objet token ; pour le modèle d’identité autour d’eux, voir la vue d’ensemble des clés à portée limitée.

1. La limite de dépense de clé API : credit_limit_usd

credit_limit_usd est le plafond de dépense à vie pour une clé, exprimé en USD simple. Vous tapez un montant en dollars dans l’éditeur de clé ; OrcaRouter le convertit en quota de départ de la clé et mètre chaque appel contre lui.

Borné

credit_limit_usd: 25 frappe une clé avec 25 $ de dépense. Chaque appel débite son coût ; une fois que le solde restant atteint zéro, la clé cesse d’autoriser et chaque requête supplémentaire est rejetée.

Illimité

credit_limit_usd: 0 est la sentinelle pour aucun plafond — la clé tire sur le solde de votre espace de travail sans plafond par clé. Pratique, mais le pire rayon d’explosion si elle fuite.
0 ne signifie pas « zéro dollar » — il signifie illimité. Une clé que vous vouliez verrouiller à un budget minuscule doit porter un nombre positif. Pour exprimer « cette clé ne peut rien dépenser », désactivez-la ou supprimez-la, ne fixez pas le plafond à 0.

2. Comment le plafond est métré : remain_quota & used_quota

Le plafond en dollars que vous saisissez est la surface destinée à l’humain. En-dessous, la passerelle suit deux compteurs courants sur la clé :
ChampSignification
remain_quotaDépense restante avant que la clé cesse d’autoriser.
used_quotaDépense consommée jusqu’à présent sur la durée de vie de la clé.
Définir un credit_limit_usd positif amorce remain_quota à partir de ce montant en dollars ; chaque appel facturé déplace le coût de remain_quota vers used_quota. Une clé à plafond illimité porte plutôt unlimited_quota, et la vérification de solde est entièrement ignorée.
Un block guardrail ou firewall ne coûte rien contre le plafond lorsqu’il se déclenche avant l’exécution du modèle — un guardrail_blocked d’étape d’entrée et un firewall_blocked inbound se produisent tous deux avant le métrage, donc remain_quota est intact. Un block guardrail d’étape de sortie rembourse la requête. Voir guardrails et firewall.

3. Auto-expiration : expired_time

expired_time est une coupure absolue — un timestamp Unix epoch (secondes) après lequel la clé cesse d’autoriser, peu importe le budget restant.
  • Un timestamp futur fait expirer la clé à cet instant. La passerelle le compare à l’heure courante à chaque requête et rejette l’appel une fois qu’il est passé.
  • -1 est la sentinelle pour n’expire jamais.
Les deux limites sont indépendantes et doivent toutes deux passer. Une clé avec du budget restant mais un expired_time passé est morte ; une clé dans sa fenêtre de validité avec remain_quota à zéro est morte. La borne qui se déclenche en premier l’emporte. L’éditeur rejette une expiration fixée dans le passé, de sorte que vous ne pouvez pas frapper une clé née-expirée par accident.
Pour les clés à courte durée de vie frappées par exécution CI ou par agent éphémère, voir clés expirantes.

4. Une clé concrète plafonnée et expirante

Un job nocturne qui réconcilie les factures avec un seul modèle bon marché, tourne pour un pilote de deux semaines, et ne devrait jamais coûter plus de quelques dollars par nuit n’a presque besoin d’aucune agence. Configurez sa clé dans l’éditeur de clé de la console (/console/tokenDeveloper+) :
1

Définir le plafond de dépense

credit_limit_usd: 40 — tout le budget du pilote. Une boucle de retry emballée épuise la clé, pas le solde de votre espace de travail.
2

Définir l'expiration

expired_time : le timestamp Unix pour la fin de la fenêtre du pilote. La clé expire automatiquement et ne peut pas être réutilisée après la livraison du pilote.
3

Associer aux autres portées

Ajoutez model_limits pour qu’elle ne puisse pas escalader vers un modèle frontière, et allow_ips pour qu’une clé fuitée soit inutile hors de l’hôte du planificateur.
Si cet agent est détourné au troisième jour, les dégâts sont bornés à ce qu’il reste de ses 40 $, et toute la clé disparaît en onze jours quoi qu’il arrive. Le reste de l’espace de travail est intact.
Les deux champs sont du USD-et-du-temps sur la clé, pas une politique à l’échelle de l’espace de travail. Pour plafonner la dépense d’une seule exécution d’agent (plutôt que la durée de vie d’une clé), le verdict cap_cost du Firewall est le disjoncteur par exécution — voir règles du firewall. Les deux se composent : le plafond de la clé borne la durée de vie, cap_cost borne une seule exécution.

5. Qui peut les définir

Définir credit_limit_usd et expired_time fait partie de la création ou de la modification d’une clé, ce qui requiert le rôle Developer ou supérieur. N’importe quel membre de l’espace de travail peut lire l’enregistrement masqué d’une clé ; seul Developer+ peut changer ses limites. Les clés sont masquées à l’affichage — le plaintext est montré une fois à la création (voir masquage des clés).

6. Borné par défaut

Une clé avec credit_limit_usd: 0 et expired_time: -1 n’a aucun plafond de dépense et n’expire jamais — agence maximale, pire rayon d’explosion. Faites-en l’exception délibérée, pas le défaut.

Illimité vs borné

Quand une clé non plafonnée et non expirante est réellement le bon choix — et quand elle ne l’est pas.

Checklist de moindre agence

Faites passer chaque clé de production par la même passe de durcissement avant de la livrer.

7. Connexe

L'objet token

Chaque champ d’une clé, y compris les compteurs de quota.

Lier des politiques

Attacher un guardrail et une politique firewall à la même clé.

Agence excessive

La menace que les plafonds de dépense et l’expiration sont conçus pour contenir.
Un plafond de dépense et une expiration sont l’assurance la moins chère sur une clé : deux nombres qui transforment une credential ouverte en une clé qui échoue en sécurité — vide ou expirée — au lieu de tourner jusqu’à ce que votre facture le remarque.