Codex se paie de deux façons courantes : acheter un abonnement ChatGPT incluant un quota Codex, ou utiliser sa propre clé API facturée au token. Beaucoup demandent directement « quelle option est la moins chère », mais il n'existe pas de réponse universelle : la structure de consommation d'un agent de programmation diffère totalement de celle d'un chat ordinaire.
Cet article n'inscrit pas de prix unitaires voués à expirer ; il fournit une méthode que vous pouvez appliquer vous-même : examiner les deux modes de facturation, puis identifier où partent les tokens, et enfin plafonner le risque par un budget maximal.
Remarque : OpenAI, Codex et ChatGPT sont des marques d'OpenAI. Cet article est purement technique et sans lien d'affiliation ni de représentation avec OpenAI. Les quotas d'abonnement, prix unitaires et règles de facturation évoluent ; référez-vous aux pages de l'éditeur et à la page tarifs des modèles du site.
1. Distinguer les deux modes de facturation
L'abonnement repose sur « forfait mensuel + quota ». Plusieurs offres ChatGPT incluent un quota Codex ; plus l'offre est élevée, plus le quota, le choix de modèles et la concurrence sont généralement larges. Une fois le quota épuisé, il faut attendre sa réinitialisation, acheter des crédits ou changer d'offre. Avantage : une facture prévisible. Inconvénient : quotas et règles de limitation sont ajustés par la plateforme, et ventiler précisément le coût par projet est difficile.
L'API à l'usage suit le principe « payer ce que l'on consomme ». Tokens d'entrée, tokens de sortie et lectures/écritures de cache sont facturés séparément ; on change de modèle selon la tâche et on peut séparer plusieurs projets par clé via une passerelle. Avantages : souplesse et auditabilité. Inconvénient : dès qu'un agent boucle ou relit de gros fichiers, la facture dépasse les prévisions.
| Dimension | Abonnement (offre ChatGPT) | Clé API à l'usage |
|---|---|---|
| Unité de facturation | Mensualité plus quota ou crédits inclus | Facturation au token |
| Prévisibilité de la facture | Plutôt élevée | Moyenne à faible selon l'usage |
| Choix des modèles | Dans le périmètre de l'offre | Selon les modèles accessibles à la clé |
| Ventilation multi-projets | Limitée | Forte, par clé ou par projet |
| Public adapté | Particuliers, usage quotidien stable | Équipes, automatisation, usage variable |
2. Pourquoi un agent de programmation consomme tant de tokens
Un chat ordinaire est un échange question-réponse ; un agent de programmation suit une boucle « lire le dépôt, appeler des outils, modifier des fichiers, lancer les tests, corriger ». Pour une même tâche, la structure des tokens diffère fortement :
- Le prompt système, les définitions d'outils et la description du projet entrent dans le contexte à chaque tour.
- La lecture de fichiers, la recherche de code et les sorties de commandes s'accumulent comme résultats d'outils.
- Les appels d'outils multi-tours allongent l'historique : chaque tour d'entrée paie pour le contenu précédent.
- Les tentatives échouées, la compression de contexte et les résumés génèrent une consommation supplémentaire.
- Les tokens de sortie sont souvent moins nombreux que ceux d'entrée, mais à un prix unitaire plus élevé.
Évaluer le prix de Codex ne consiste donc pas à se demander « combien coûte une question », mais « combien de tours prend une tâche complète et quel contexte chaque tour transporte ». C'est aussi pourquoi l'abonnement et la facturation à l'usage donnent des expériences si différentes : les tâches légères sont avantageuses en abonnement, les tâches lourdes peuvent coûter plus cher en API — ou moins, si le changement de modèle est bien exploité.
3. Estimer la facturation à l'usage
La formule suivante permet un calcul approximatif. Lisez les prix unitaires sur la page de tarifs actuelle ; n'utilisez pas d'anciens chiffres extérieurs à cet exemple.
Coût par tour ≈
tokens d'entrée × prix entrée
+ tokens lus en cache × prix cache
+ tokens de sortie × prix sortie
+ coût d'écriture du cache (si facturé séparément)
Coût mensuel ≈
coût par tour × tours par jour × jours ouvrés
+ requêtes en échec et nouvelles tentatives
+ compression de contexte et résumés
En pratique, la méthode la plus fiable consiste à choisir une tâche représentative, à relever dans les journaux d'usage de la passerelle ses tokens réels d'entrée, de sortie et de cache, puis à multiplier par le nombre de tâches similaires par jour. Ne devinez pas à partir du « nombre de mots d'une page de chat » : l'entrée d'un agent représente souvent plusieurs fois à plusieurs dizaines de fois celle d'un chat.
4. Trois scénarios typiques
Usage personnel stable. Modification quotidienne de code, écriture de tests, lecture de documentation : l'usage est régulier et l'abonnement simplifie généralement la gestion. Augmentez d'offre seulement si le quota manque, sans viser d'emblée le niveau le plus élevé.
Petite équipe multi-projets. Préférez l'API avec une passerelle : clés par personne et par projet, facturation ventilable, modèles répartis selon les tâches. Inconvénient : il faut fixer un plafond, sinon une boucle d'Agent peut consommer le budget d'un mois.
Automatisation et tâches ponctuelles. Les robots de CI, les refactorisations par lots et les scans nocturnes conviennent mieux à la facturation à l'usage : la tâche a un début et une fin clairs, et un coût maîtrisé avec limites de concurrence et de tentatives.
Beaucoup d'équipes finissent en mode hybride : abonnement pour les personnes, API pour l'automatisation et les outils partagés. Les deux modes ne s'excluent pas ; l'essentiel est de ne pas laisser une même personne consommer deux quotas sans tenue de registre.
5. Cache et contexte : les deux variables les plus sous-estimées
Le cache réduit les coûts, mais suppose une condition. Il exige généralement un préfixe de requête stable : même prompt système, mêmes définitions d'outils, mêmes extraits de fichiers. Insérer un contenu variable au milieu peut invalider le cache suivant. Placez les contenus stables — description du projet, conventions de code — en tête, et les questions temporaires à la fin : le taux de succès est généralement meilleur.
La taille du contexte a un effet plus direct. Plus le dépôt est grand, plus vous lisez de fichiers et plus la conversation est longue, plus chaque tour d'entrée coûte. Méthodes de contrôle : exclure les artefacts de build et les dépendances, ne lire que les modules concernés, ouvrir une nouvelle session au bon moment, demander à l'Agent de chercher avant de lire. Un modèle à fenêtre de contexte plus large n'est pas plus économique : il permet simplement d'insérer plus de contenu, et la facturation reste au token réel.
6. Plafond budgétaire et liste de contrôle
- Créez des clés distinctes par personne, projet et environnement ; évitez une clé commune à toute l'équipe.
- Dans la console de la passerelle, fixez plafond et alerte de solde ; commencez bas et ajustez après une semaine.
- Limitez la concurrence et le nombre de tentatives automatiques pour éviter la facturation répétée des échecs.
- Excluez de la configuration du projet les répertoires de build, dépendances, journaux et fichiers de clés.
- Répartissez les modèles : modèle puissant pour les tâches difficiles, modèle économique pour renommer, commenter ou générer du code standard.
- Consultez chaque semaine le rapport d'usage par projet et par modèle ; en cas d'anomalie, coupez la clé immédiatement.
- Donnez un budget séparé aux tâches automatisées, sans le mélanger à celui des personnes.
Ces mesures sont plus efficaces que la recherche d'un prix unitaire plus bas. La plupart des dépassements viennent d'un contexte incontrôlé, de tentatives incontrôlées ou de clés incontrôlées, pas d'un prix unitaire élevé.
7. Décider avec deux semaines de données
Ne migrez pas d'un coup. La première semaine, conservez l'abonnement existant tout en exécutant un ensemble de tâches représentatives avec une clé API ; notez pour chaque type de tâche le nombre de tours, les tokens d'entrée, les tokens de sortie et les succès de cache. La deuxième semaine, rejouez les mêmes tâches avec un autre niveau de modèle et comparez qualité d'achèvement et coût.
Au bout de deux semaines, vous obtenez trois chiffres : coût moyen par tâche, volume mensuel de tâches par personne et part des tentatives échouées. Multipliez les deux premiers, ajoutez le surcoût du troisième : vous obtenez la base réelle de la facturation à l'usage. Comparez cette base à la mensualité et au quota de l'abonnement : la conclusion est généralement plus fiable que n'importe quelle « réponse universelle ». Pour un point d'entrée et des rapports d'usage unifiés, commencez par créer un compte ZSQH AI Gateway ; les modèles et la facturation sont détaillés sur la page tarifs des modèles.
Questions fréquentes
Peut-on utiliser l'abonnement Codex et une clé API en même temps ?
Oui. Codex CLI accepte la connexion au compte comme une clé API personnalisée ou une passerelle compatible. La pratique courante en équipe est l'abonnement pour les personnes et l'API pour l'automatisation, à condition de tenir un registre interne pour éviter double paiement et mélange de quotas.
Pourquoi ma facture API dépasse-t-elle largement les prévisions ?
Vérifiez trois choses : contexte trop volumineux, tentatives fréquentes, tâches concurrentes superflues. Les tokens d'entrée d'un agent de programmation représentent souvent l'essentiel du coût ; la lecture de fichiers hors sujet et les longues conversations inutiles sont les causes les plus fréquentes.
Le cache fait-il toujours économiser ?
Pas nécessairement. Il faut un préfixe de requête stable pour que le cache soit utilisé, et certains fournisseurs facturent séparément l'écriture du cache. Si les prompts changent souvent ou si le modèle change fréquemment, le gain diminue nettement. Vérifiez d'abord le taux de succès dans les journaux d'usage.
Faut-il une clé par personne dans une équipe ?
Évitez une clé commune, mais aussi une multiplication de clés sans registre. Une clé par personne avec des sous-quotas par projet permet de localiser les anomalies et de révoquer un départ individuellement. La clé se place dans une variable d'environnement ou un service de gestion de secrets, jamais dans le dépôt.
Ces prix vont-ils changer ?
Oui. Quotas d'abonnement, prix unitaires, règles de cache et mécanismes de crédits peuvent évoluer. Cet article ne décrit qu'une méthode de calcul et ne promet aucun prix fixe. Pour un budget, utilisez les informations actuelles des pages de l'éditeur et de la page tarifs des modèles, et recalculez régulièrement.
Pour aller plus loin
Savoir si le prix de Codex est avantageux ne dépend pas de la mémorisation d'un prix unitaire, mais de la connaissance de votre structure de tâches : nombre de tours par tâche, contexte par tour, part des tentatives échouées. Une fois ces trois points quantifiés, le choix entre abonnement et API devient clair. Pour une gestion unifiée des clés, des plafonds et de la ventilation par projet, vous pouvez créer un compte ZSQH AI Gateway ; le périmètre des modèles et la facturation figurent sur la page tarifs des modèles.
Lectures associées :
