Facturation et limites

Quand les crédits partent, et quand ils reviennent.

Principe de facturation

Les appels API et l’usage dans le navigateur partagent la même comptabilité : même compte, même grille tarifaire, un historique unique dans « Portefeuille », avec l’origine identifiable.

• Images : tarif unitaire × quantité. Le tarif vient du palier choisi, ou du modèle s’il n’en a pas.
• Vidéo : crédits par seconde × durée. Plus la résolution est élevée, plus la seconde coûte cher — voir specs dans /v1/models.
• Chat textuel : au jeton, avec des tarifs distincts en entrée et en sortie, arrondi au supérieur, minimum 1 crédit par appel.
• Pour l’image et la vidéo, le débit a lieu à la soumission et non à la fin, si bien que des envois simultanés ne peuvent pas mettre le solde à découvert. Le texte ne peut être compté qu’une fois les jetons produits : il est donc débité après coup (un seuil de solde filtre l’appel en amont).

Ce qui est remboursé

• Refusée par le moteur de rendu à la soumission : remboursement immédiat.
• Échouée pendant le rendu : remboursement dès que la tâche passe à failed.
• Abandonnée sans que personne n’interroge : le service d’arrière-plan la clôture et rembourse.
• Résultat qui ne plaît pas : pas de remboursement. Comme dans le studio, le rendu a coûté de l’argent réel.

Limite d’appels

Chaque clé autorise 120 appels par minute ; au-delà, 429 rate_limit_exceeded. Ce seuil sert à stopper les scripts emballés, pas le trafic réel : interrogez aux intervalles conseillés plutôt qu’en boucle serrée.

S’y ajoutent des limites de parallélisme et de volume quotidien au niveau du compte, fixées par votre formule, qui apparaissent en 429 concurrency_limit_reached.