Limites et crédits

Un point d’accès /v1 pour tous les fournisseurs. Pointez votre client OpenAI vers une autre URL et une clé, avec vos clés et 0 % de majoration.

Limites de débit

Le débit de requêtes est calculé sur l’achat cumulatif plutôt que sur le solde courant : une recharge relève donc votre plafond, et dépenser ne l’abaisse pas en pleine charge de travail. Les limites sont partagées entre les instances : le nombre est le même qu’un seul processus appelle ou vingt.

Les limites de débit de votre propre fournisseur s’appliquent aussi, et sont souvent la contrainte déterminante — vous êtes son client.

Une clé d’inférence peut aussi porter ses propres débits, en plus de ceux du compte : rpm_limit (requêtes par minute) et tpm_limit (jetons de la requête et de la réponse par minute), fixés sur POST /v1/keys ou PATCH /v1/keys/:hash, ou depuis la page Clés API ; null en retire un. Les deux se comptent par minute civile. Au-delà de l’un ou l’autre, une requête reçoit 429 rate_limited avant qu’aucun fournisseur ne soit sollicité, avec x-ratelimit-limit-requests, x-ratelimit-remaining-requests et x-ratelimit-reset-requests (et leurs équivalents -tokens) ainsi que retry-after. Les jetons sont comptés à la fin de chaque réponse : les requêtes déjà en cours quand le budget est atteint peuvent donc le dépasser pour la minute.

Plafonds de dépenses

Fixez une limite par clé et par espace de travail. La limite d’une clé couvre une période — daily, weekly, monthly ou lifetime — et a un mode. Une limite stricte, par défaut, refuse une requête dès que la clé l’atteint, avec 403 budget_exceeded, avant qu’aucun fournisseur ne soit sollicité. Le refus est consigné et apparaît dans Activité avec sa raison : vous voyez ce qui a été arrêté, pas seulement ce qui s’est exécuté. Une limite souple sert la requête et ajoute un en-tête x-autonomous-relay-limit-warning portant la même phrase.

Ce que compte un plafond. Chaque requête passe par votre propre clé de fournisseur, donc un plafond compte ce que ces requêtes coûtent au prix catalogue du fournisseur — ce que votre fournisseur vous facture — et un plafond mensuel de 50 $ arrête la clé à 50 $ de ces dépenses. C’est le comportement par défaut pour les plafonds de clé, les budgets de garde-fou et les budgets d’espace de travail ; mettez include_byok_in_limit (ou include_byok_in_budgets, include_byok) à false pour ne compter que les dépenses sur la capacité de la plateforme, qui n’en a aucune aujourd’hui.

GET /v1/keys renvoie, pour chaque clé plafonnée, son usage sur la période en cours, limit_remaining et limit_resets_at, mesurés exactement comme la limite est appliquée. Une limite peut être modifiée sur une clé active sans la réémettre.

PATCH/v1/keys/:hash
curl
curl -X PATCH https://autonomousrelay.com/v1/keys/$KEY_HASH \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY" \
  -H 'content-type: application/json' \
  -d '{"limit": 50, "limit_reset": "monthly", "limit_mode": "hard"}'
GET/v1/workspaces/:id/budgets
PUT/v1/workspaces/:id/budgets/:interval

Clients (espaces de travail)

Gardez un espace de travail par client. Chacun a ses propres clés, ses propres budgets et ses propres dépenses, sous votre compte et votre solde uniques. Un budget d’espace de travail borne les seules dépenses de cet espace : un client qui consomme beaucoup n’arrête jamais les autres. Créez une clé dans un espace avec workspace_id sur POST /v1/keys, ou déplacez-en une avec PATCH /v1/keys/:hash.

GET/v1/workspaces
POST/v1/workspaces
PATCH/v1/workspaces/:id
DELETE/v1/workspaces/:id

Pour refacturer un client, exportez son mois en CSV : une ligne par requête, avec billed_usd (ce qui vous a été facturé) et list_price_usd (les jetons au prix catalogue, ce que mesurent les budgets). /v1/activity et /v1/activity/summary acceptent le même filtre workspace.

GET/v1/activity/export.csv?month=YYYY-MM&workspace=:id

Rapports clients

Chaque client (espace de travail) dispose d’un rapport mensuel imprimable — requêtes, jetons et valeur d’utilisation par modèle, agent et jour — sous votre nom, votre logo et votre pied de page plutôt que les nôtres. Réglez l’image de marque une fois ; le logo est un PNG ou JPEG de moins de 150 Ko, vérifié par ses octets et jamais récupéré depuis une URL. La valeur d’utilisation est le prix catalogue des jetons utilisés : un rapport d’utilisation, pas une facture.

GET/v1/workspaces/:id/report?month=YYYY-MM
PUT/v1/branding

Membres et rôles

Plusieurs personnes peuvent partager une organisation, chacune avec un rôle. Propriétaire : tout, y compris inviter et retirer des personnes. Développeur : clés, clés de fournisseur, limites, clients, alertes et agents ; lit la facturation. Finance : activité, exports, crédits et achat de crédits ; ne modifie rien d’autre. Une requête qu’un rôle n’autorise pas est refusée avec 403 permission_denied. Une clé de gestion sans personne derrière elle a tous les droits. Les invitations sont des liens à usage unique valables sept jours ; une personne peut appartenir à plusieurs organisations et passer de l’une à l’autre.

GET/v1/members
POST/v1/invitations
POST/v1/auth/switch

Agents

Nommez l’agent sur chaque requête avec X-Autonomous-Relay-Agent (1 à 64 lettres, chiffres, . _ : -). Ses dépenses sont suivies sur toutes les clés qu’il utilise, et un budget sur lui refuse ses requêtes avec 403 budget_exceeded une fois atteint — sans toucher les autres agents de la même clé. Un budget soft sert la requête et ajoute un en-tête x-autonomous-relay-limit-warning. Dans les deux cas, le franchissement de 50 %, 80 % et 100 % d’un budget est annoncé sur vos canaux d’alerte comme agent_limit.threshold. Un budget peut aussi être limité à un espace client avec workspace_id : il ne lie alors que les requêtes des clés de cet espace, et un budget pour toute l’organisation sur le même agent s’applique en parallèle. Un nom mal formé est un 400 avant toute dépense.

GET/v1/agents
PUT/v1/agents/:agent/budgets/:interval
DELETE/v1/agents/:agent/budgets/:interval

Alertes de consommation

Ajoutez un canal Slack, webhook ou e-mail, et chaque clé plafonnée est annoncée quand elle franchit 50 %, 80 % et 100 % de son plafond — ou les seuils de votre choix — une fois par seuil et par période. Une clé qui franchit plusieurs seuils en une requête n’est annoncée qu’une fois, au plus haut. Chaque tentative est consignée avec son résultat.

POST/v1/alerts/channels
POST/v1/alerts/channels/:id/test
GET/v1/alerts/deliveries

Les dépenses qui s’emballent sont signalées sans aucune limite : toutes les cinq minutes, une clé ou un agent dont les 15 dernières minutes ont coûté au moins 3× ses 15 minutes habituelles (et au moins 5 $), ou fait au moins 5× ses requêtes habituelles (et au moins 300), est signalé une fois pour l’heure et envoyé à tous les canaux comme un événement spend.runaway. « Habituel » désigne ses propres 24 heures précédentes. Par défaut, rien n’est suspendu : c’est vous qui décidez. Réglez runaway_action sur pause et la clé signalée est aussi suspendue : elle répond 403 key_paused jusqu’à ce que vous la repreniez avec PATCH /v1/keys/:hash {"paused": false} ou depuis la page Alertes. Un agent n’est jamais suspendu : une étiquette n’est pas un identifiant.

Une exécution dont les propres limites d’emballement sont atteintes (max_cost_per_minute_usd ou max_tool_calls_without_progress) est suspendue et annoncée une fois, aux mêmes canaux, comme un événement run.paused qui nomme l’exécution, la raison et ce qu’elle a dépensé. Reprenez-la avec POST /v1/runs/:id/resume ou depuis la page Exécutions.

GET/v1/alerts/runaways
GET/v1/alerts/settings
PUT/v1/alerts/settings

Un envoi webhook est du JSON avec un en-tête x-autonomous-relay-signature: t=<unix>,v1=<hex>. Vérifiez-le avec le signing_secret renvoyé une seule fois à la création du canal : v1 est le HMAC-SHA256 de <t>.<corps brut>. Les destinations doivent être des URL https publiques ; une destination Slack doit être un webhook entrant hooks.slack.com.

Crédits

GET/v1/credits
GET/v1/credits/history

Le solde, ainsi que ce qui est réservé en cours. Une réservation est posée avant l’acheminement et le reliquat inutilisé est rendu au règlement ; des requêtes simultanées ne peuvent donc pas dépasser collectivement un solde qui paraissait suffisant à chacune prise isolément.

Une requête est refusée lorsqu’elle ferait passer le solde sous zéro — ou sous credit_line, si une entente Entreprise en a fixé un. Il s’agit d’un contrôle à l’admission, non d’une garantie sur le solde : le règlement se fonde sur l’utilisation déclarée par le fournisseur, qui peut dépasser ce qui avait été réservé, et un flux déjà en cours ne peut pas être interrompu en plein milieu. Un solde peut donc devenir négatif ; tant qu’il l’est, toutes les requêtes sont refusées — y compris pour les modèles gratuits — jusqu’à une recharge.

Utilisation

GET/v1/activity

Métadonnées par requête : modèle, fournisseur, jetons, latence, coût, résultat. Paginé par curseur. Jamais le contenu de vos requêtes : ce point d’accès ne le retourne sous aucun réglage, et il n’est pas conservé du tout à moins que votre organisation n’active la journalisation des requêtes — désactivée par défaut et pas encore activable.

Chaque ligne porte aussi sa latence de routage : le temps total de la requête moins le temps passé chez les fournisseurs, c’est-à-dire la latence ajoutée par la passerelle elle-même.

GET/v1/activity/summary

Les totaux de la période, avec la période précédente de même durée à côté : dépenses, requêtes, volume de jetons, taux de succès du cache et coût mixte par million. Le volume de jetons est le total_tokens que chaque réponse a rapporté — les jetons mis en cache et de raisonnement sont comptés une seule fois, dans les chiffres d’entrée et de sortie.

Le taux de succès du cache et le coût mixte sont nuls au sens de « non mesurés », et non de zéro, lorsqu’il n’y a rien à diviser. Un taux de zéro et une absence totale de trafic sont deux réponses différentes.

GET/v1/activity/upstream

Une ligne par envoi à un fournisseur. Une requête qui a basculé apparaît une fois par tentative ; un réessai se lit donc comme les deux requêtes en amont qu’il a réellement été. Indiquez un identifiant de requête pour voir les tentatives d’une seule génération, dans l’ordre de la cascade.

GET/v1/activity/sessions

Les générations regroupées par session_id, les plus récemment actives d’abord, avec chaque modèle ayant servi la conversation. Plus d’un signifie qu’elle a changé de modèle en cours de route, ce qui fait perdre le cache de contexte.

Prometheus

GET/v1/metrics

Le trafic de votre organisation au format texte de Prometheus, pour le Prometheus ou le Grafana que vous utilisez déjà. Authentifiez-vous avec une clé de gestion. Les compteurs sont autonomousrelay_requests_total (par model, provider, status), autonomousrelay_tokens_total (par model, provider, type : prompt ou completion) et autonomousrelay_spend_usd_total ; à côté, l’histogramme autonomousrelay_request_duration_seconds et la jauge autonomousrelay_active_keys.

Les compteurs comptent les requêtes terminées depuis le début du mois UTC en cours et repartent de zéro au changement de mois, ce que rate() et increase() traitent comme une remise à zéro ordinaire. Les 25 modèles les plus utilisés gardent leur propre étiquette ; les autres sont additionnés sous other. Les chiffres sont recalculés au plus toutes les 15 secondes : une collecte plus fréquente lit les mêmes valeurs.

yaml
scrape_configs:
  - job_name: autonomousrelay
    scheme: https
    metrics_path: /v1/metrics
    scrape_interval: 60s
    authorization:
      type: Bearer
      # A management key. Keep it out of the file: render this config with
      # envsubst, or point credentials_file at a mounted secret instead.
      credentials: ${AUTONOMOUSRELAY_MANAGEMENT_KEY}
    static_configs:
      - targets: ['autonomousrelay.com']