Facturation et limitation de débit

Cette page décrit le processus de facturation d’une requête, de son envoi à son règlement, ainsi que la facturation en cas d’erreur, d’annulation ou de limitation. Pour le prix unitaire et le mode de facturation de chaque type de modèle, voir Tarification des modèles.

Quand la facturation a lieu

Chaque requête passe par deux étapes : « pré-réservation → règlement » :

Pré-réservation : avant de transmettre la requête en amont, un montant estimé est prélevé sur le quota de la clé et le solde du compte. Si l’un des deux est insuffisant, la requête est rejetée immédiatement et n’est pas envoyée en amont.
Règlement : une fois la requête terminée, le coût réel est calculé à partir de l’usage réel renvoyé par l’amont. Le surplus réservé est restitué et le manque est débité.

Méthode d’estimation du coût :

Type de modèle	Méthode d’estimation
Facturation au token	Tokens d’entrée plus `max_tokens` de la requête, estimés au prix unitaire du modèle
Modèles à tarifs par palier	Estimés au prix du palier le plus élevé, puis facturés au palier réel lors du règlement
Facturation par appel ou par image	Prix à l’unité pré-réservé directement
Tâches asynchrones (vidéo, musique, etc.)	Montant estimé réservé à la soumission, réglé à la fin de la tâche

Les erreurs sont-elles facturées ?

Le principe : sans usage facturable, pas de facturation ; le montant pré-réservé est intégralement restitué.

Scénario	Facturation
Clé invalide ou expirée, solde ou quota de la clé insuffisant	Non facturé, la requête n’est pas envoyée en amont
Paramètres de requête invalides, modèle indisponible, aucun canal disponible	Non facturé
Limitation de débit (`429`)	Non facturé
Erreur renvoyée par l’amont (4xx / 5xx)	Non facturé, le montant pré-réservé est intégralement restitué
Succès en amont mais usage nul	Non facturé
Interruption ou délai dépassé en amont pendant un flux	Facturé selon le contenu déjà généré
Échec ou expiration d’une tâche asynchrone (non terminée sous 24 heures)	Non facturé, le montant pré-réservé est intégralement restitué

Nouvelles tentatives et bascules

En cas d’erreur en amont, RouteAPI relance automatiquement la requête ou bascule vers un autre canal. L’ensemble du processus ne comporte qu’une pré-réservation et qu’un règlement ; les tentatives échouées ne sont pas facturées, vous ne payez que la tentative finalement réussie. Si la requête est finalement servie par un modèle de repli, elle est facturée au prix du modèle qui l’a réellement servie.

Une fois qu’un flux a commencé à vous envoyer du contenu, il n’est plus relancé. Si l’amont est alors interrompu, la partie déjà générée est facturée.

Une annulation manuelle est-elle facturée ?

Scénario	Facturation
Requête non streaming, connexion coupée avant réception de la réponse	Non facturé, le montant pré-réservé est intégralement restitué
Requête streaming, connexion coupée en cours de route	Facturé, voir l’explication ci-dessous
Tâches asynchrones (vidéo, musique, Midjourney)	Aucune annulation possible après soumission

Lorsqu’une requête streaming est coupée en cours de route, l’amont est généralement déjà en train de générer et continue jusqu’à la fin. RouteAPI continue de lire la sortie en amont jusqu’à la fin de la génération et facture l’usage réellement généré, et pas seulement la partie que vous avez déjà reçue. Pour maîtriser ce coût, limitez la longueur de sortie avec max_tokens.

Limitation de débit

Pour préserver la stabilité de la plateforme et de l’amont, la plateforme peut limiter la fréquence des requêtes de modèle par compte. La limite est calculée par compte : toutes les clés API d’un même compte partagent le même quota.

En cas de limitation, la réponse renvoie 429 Too Many Requests, avec le même format de corps que les autres erreurs :

{
  "error": {
    "message": "... (request id: ...)",
    "type": "error",
    "code": ""
  }
}

Une requête limitée est rejetée avant la pré-réservation : elle n’est pas facturée.
Lorsque l’amont renvoie 429, RouteAPI bascule automatiquement vers un autre canal pour réessayer. Le 429 ne vous est renvoyé que si la limitation persiste après la nouvelle tentative.
La réponse ne contient pas d’en-tête Retry-After. Il est conseillé d’utiliser un backoff exponentiel côté client, par exemple 1 s, 2 s, 4 s, avec une gigue aléatoire.
Multiplier les clés API n’augmente pas la limite. Si vous avez besoin d’une fréquence plus élevée, contactez-nous.

L’API de la plateforme (/api/open/v1) a ses propres règles de limitation, voir Erreurs et limites de l’API de la plateforme.

Vérifier les débits

Le Journal d’utilisation permet de consulter le détail de chaque requête facturée :

Champ	Description
Heure	Heure de la requête
Clé	Nom de la clé API ayant émis la requête
Modèle	Modèle réellement facturé
Durée / premier token	Durée totale ; pour les requêtes streaming, affiche aussi la latence du premier token
Entrée	Nombre de tokens d’entrée ; en cas de cache, lecture et écriture du cache sont affichées séparément
Sortie	Nombre de tokens de sortie
Coût	Montant réellement débité
Détail	Prix unitaire, multiplicateur et déroulé de la facturation

Le champ usage de la réponse de l’API renvoie également l’usage de tokens de la requête :

Champ	Description
`prompt_tokens`	Tokens d’entrée
`completion_tokens`	Tokens de sortie ; les tokens de raisonnement des modèles de raisonnement y sont également inclus
`total_tokens`	Total entrée + sortie
`prompt_tokens_details.cached_tokens`	Tokens d’entrée ayant touché le cache

Si votre compte bénéficie d’une remise exclusive, le coût indiqué dans le journal est déjà le montant remisé.