Note de l’auteur : vous ne voyez pas l’utilisation du contexte dans la zone de saisie de Codex ? Elle se trouve dans /status. Cet article explique comment calculer, en 5 étapes et à partir des journaux d’invocation d’APIYI, les tokens consommés et le coût de chaque tour dans Codex. Il propose aussi un tableau pour choisir entre compresser le contexte et démarrer une nouvelle session.
Vous utilisez Codex avec APIYI et travaillez depuis plusieurs heures dans une même conversation. Sous la zone de saisie, seuls le mode d’autorisation et le modèle sont affichés. Impossible de voir combien de contexte est utilisé, et vous ne savez pas si vous devriez ouvrir une nouvelle session.
La réponse en bref : Codex permet toujours de consulter l’utilisation du contexte, mais l’information se trouve désormais dans /status ; les données nécessaires pour calculer le coût sont dans les journaux d’invocation d’APIYI / apiyi.com. Cet article explique en cinq étapes comment consulter la consommation de tokens de chaque tour Codex dans les journaux d’invocation d’APIYI : quoi regarder, comment faire le total et quand compresser le contexte ou démarrer une nouvelle session.
Ce n’est pas un énième article théorique. Chaque étape décrit ce qui apparaît à l’écran, où cliquer et comment vérifier que tout est bon.
Pourquoi Codex n’affiche pas la consommation de tokens à chaque tour
On entend souvent dire que Codex a supprimé l’affichage du contexte. En réalité, ces informations sont réparties entre trois endroits, qui ne donnent pas tous accès aux mêmes données.
- Application de bureau / extension IDE : le champ de saisie affiche uniquement le mode d’autorisation et le modèle. Saisissez
/statuspour voir l’identifiant de la conversation, la proportion de contexte utilisée et la marge restante avant les limites de débit. - CLI :
/statusaffiche le modèle actuel, la politique d’approbation, les répertoires accessibles en écriture et l’utilisation actuelle des tokens. Le pied de page de la CLI affiche déjà une indication sur le contexte. Avec/statusline, vous pouvez y ajouter les statistiques de contexte et les compteurs de tokens. Votre sélection est enregistrée danstui.status_line, dans le fichierconfig.toml. codex exec --json: en exécution non interactive, Codex émet une ligne d’événement JSON à chaque changement d’état. L’événementturn.completedcontientusage, avec cinq champs :input_tokens,cached_input_tokens,cache_write_input_tokens,output_tokensetreasoning_output_tokens.
Par ailleurs, /usage permet uniquement de consulter l’activité des tokens à l’échelle du compte, à condition d’être connecté avec le compte officiel. Si vous utilisez une clé tierce, cette commande ne fonctionne pas.
Comparaison des trois façons de suivre la consommation de tokens dans Codex
| Méthode | Scénarios couverts | Ce qu’on peut voir | Ce qu’on ne peut pas voir |
|---|---|---|---|
| Journaux d’appels APIYI | Application de bureau, IDE et CLI | Entrées, sorties, lectures et écritures en cache, montant de chaque requête | Contenu des conversations ; une ligne correspond à une requête, il faut additionner les requêtes d’un tour |
Codex /status |
Interfaces interactives de l’application de bureau et de la CLI | Utilisation du contexte, marge avant les limites de débit, utilisation actuelle des tokens | Montant |
codex exec --json |
Exécution non interactive uniquement | Tokens d’entrée, de lecture et d’écriture en cache, de sortie et de raisonnement pour chaque tour | Données de la TUI interactive et de l’application de bureau |
Parmi ces trois méthodes, seuls les journaux permettent de voir le montant. Encore faut-il que le service utilisé fournisse des journaux et des données d’utilisation détaillées : l’abonnement officiel ne permet pas de consulter le détail de chaque requête.
Première étape : définir comment compter les tokens consommés par Codex
Avant de commencer, retenez ceci : une requête ne correspond pas à un tour de conversation.
Une requête est un appel que Codex envoie au modèle. Un tour comprend tout le processus qui commence lorsque vous envoyez un message et se termine lorsque Codex vous répond après avoir fait le travail. Au cours d’un tour, Codex lit des fichiers, exécute des commandes et modifie du code. Après chaque appel à un outil, il doit renvoyer le résultat au modèle avec l’historique complet. Un tour de conversation correspond donc généralement à plusieurs lignes dans les journaux, voire à plusieurs dizaines pour une tâche complexe.
Autre point à garder en tête : le modèle ne se souvient pas lui-même des échanges précédents. L’entrée du tour N ≈ tout le contenu des N-1 tours précédents + le nouveau contenu du tour en cours. C’est pourquoi les longues conversations coûtent de plus en plus cher.
À vérifier : face à plusieurs lignes de requêtes dans les journaux, vous savez reconnaître qu’elles appartiennent à un même tour, sans compter chaque ligne comme un tour distinct.
Deuxième étape : créer un jeton dédié à Codex
Pour que les statistiques soient exploitables, il faut pouvoir isoler les requêtes de Codex dans les journaux. Si Codex partage une clé avec des scripts ou d’autres outils, vous ne pourrez plus les filtrer par jeton.
- Dans la console APIYI, ouvrez la page des jetons et cliquez sur « Ajouter un jeton ». Donnez-lui un nom facile à reconnaître, par exemple avec « codex ».
- Ouvrez le fichier
config.tomlde Codex et ajoutez un fournisseur sousmodel_providers, avecbase_url = "https://api.apiyi.com/v1". Utilisezenv_keypour indiquer la variable d’environnement contenant ce jeton. - Faites pointer
model_providervers ce fournisseur. L’application de bureau, l’IDE et la CLI utilisent le même fichier de configuration : une seule modification suffit. - Utilisez une autre clé pour tous les autres outils ; ne réutilisez pas celle-ci.
🎯 Conseil technique : un jeton dédié, le filtrage des journaux par jeton et l’export sont les trois outils proposés par la console APIYI / apiyi.com pour établir vos statistiques. L’abonnement officiel ne donne pas accès au détail de chaque requête. Avec un jeton dédié, vous pouvez calculer séparément les coûts de Codex.
Vérification : sur la page des journaux, cliquez sur « Développer », puis sélectionnez cette clé dans le filtre avancé « Jeton ». La liste ne doit plus afficher que les requêtes envoyées par Codex.
Troisième étape : comprendre une requête dans les journaux d’appels
Ouvrez api.apiyi.com/log, accessible via « Journaux » dans le menu de gauche. Chaque ligne de la liste correspond à une requête API.
En haut de la page, vous pouvez filtrer par période, type, modèle et état du cache. L’aide associée à l’état du cache précise : « Hit = lecture du cache, miss = création du cache ». En cliquant sur « Développer », vous pouvez affiner les filtres par jeton, mode streaming, plage de tokens d’invite ou de complétion, délai jusqu’au premier octet, etc.
Signification des colonnes du journal
| Colonne | Ce que vous voyez | Comment l’interpréter |
|---|---|---|
| Heure | Heure de fin de la requête | UTC+0 par défaut, soit 8 heures de décalage avec l’heure de Pékin |
| Modèle | Par exemple, gpt-5.6-terra | Le cache n’est pas partagé entre les modèles |
| Informations | Streaming ou non, délai jusqu’au premier octet, tokens d’invite et de complétion, montant | Un résumé de la requête dans une seule cellule |
| Invite / Complétion | Deux nombres | Invite = tokens d’entrée, complétion = tokens de sortie ; les tokens de raisonnement sont généralement comptés dans la complétion |
| Coût | Montant en dollars | Montant avant remise, coefficient de groupe déjà inclus |
| Détails | Différents coefficients, tokens écrits dans le cache, tokens lus depuis le cache | Les lectures et écritures du cache sont indiquées séparément : pas besoin de deviner |
Pour les requêtes utilisant le cache, la colonne « Informations » affiche à la fois les chiffres de lecture et d’écriture. Les lignes sans détail de cache affichent uniquement une combinaison du type « Sans streaming, premier octet : N secondes, invite/complétion, montant ». Les modèles d’image et de vidéo facturés à l’appel affichent aussi des valeurs d’invite et de complétion, mais leur coût n’est pas calculé par token : n’y appliquez pas la méthode de calcul de cet article.
Vérification : choisissez une ligne au hasard. Vous devez pouvoir indiquer le nombre de tokens d’entrée et de sortie, le nombre de tokens lus depuis le cache et le coût de la requête.
Quatrième étape : additionner les lignes de journal pour calculer la consommation de tokens d’un tour Codex
Une ligne ne représente qu’une seule requête. Pour connaître la consommation d’un tour de conversation, il faut les additionner.
Règle de calcul : additionnez toutes les requêtes associées au même jeton et au même modèle dans une fenêtre d’environ 5 minutes après l’envoi de votre instruction. Ajustez cette fenêtre selon votre usage.
- Consulter directement la page : filtrez par jeton, modèle et plage horaire, puis examinez les tokens d’invite et de complétion ligne par ligne. Pratique pour une vérification occasionnelle.
- Exporter et recalculer : cliquez sur « Exporter » en haut à droite de la liste, récupérez le fichier Excel ou CSV, puis regroupez les données par plage horaire pour calculer les sommes.
- Utiliser l’API de consultation des journaux : appelez
GET /api/log/selfavec un jeton d’accès personnel pour l’authentification (il commence parnap_; une clé API commençant parsk_renverra une erreur 401). Transmettez les paramètrestype=2(consommation uniquement),token_name,start_timestampetend_timestamp(en secondes Unix). Attention : le paramètre de pagination s’écrit en camelCase,pageSize; si vous écrivezpage_size, il sera ignoré sans avertissement. - Convertir en montant :
quota ÷ 500 000 = montant en dollars. Le champotherest une chaîne JSON qu’il faut analyser une seconde fois pour accéder aux détails commeusage.
Lorsque vous utilisez l’API de consultation, indiquez toujours une plage horaire, idéalement d’une journée maximum. Sans plage horaire, l’API remonte tout l’historique, ce qui peut provoquer un délai d’attente dépassé pour les comptes qui contiennent beaucoup de données. La consultation des journaux ne consomme pas de quota.
Calculer le coût d’un tour Codex
| Modèle | Entrée | Lecture du cache | Sortie | Contexte | Exemple : total par tour |
|---|---|---|---|---|---|
| gpt-5.6-sol | $4 | $0.4 | $20 | 1,000,000 | Environ $0.214 |
| gpt-5.6-terra | $2 | $0.2 | $12 | 1,000,000 | Environ $0.107 |
| gpt-5.6-luna | $0.2 | $0.02 | $1.2 | 1,000,000 | Environ $0.011 |
Les tarifs sont indiqués par million de tokens et ont été consultés le 28 octobre 2026. Au-delà de 272 000 tokens en entrée dans une seule requête, le tarif d’entrée double.
💰 À propos des tarifs : consultez la liste des modèles sur APIYI / apiyi.com pour connaître les modèles et tarifs applicables. L’exemple du tableau suppose un tour avec 120 000 tokens en entrée, dont 96 000 trouvés dans le cache, et 4 000 tokens en sortie. Pour sol : 24 000 hors cache × $4 + 96 000 en cache × $0.4 + 4 000 en sortie × $20, le tout divisé par un million, soit environ $0.214.
Ces chiffres montrent deux choses. D’abord, les 96 000 tokens trouvés dans le cache ne coûtent qu’environ $0.038 : le cache est donc déterminant pour maîtriser le coût des longues conversations. Ensuite, en passant à luna pour le même tour, le coût représente près d’un vingtième de celui de sol. La page officielle de luna précise toutefois que ses performances sont moins bonnes avec un contexte très long, au-delà de 256K.
Validation : vous pouvez calculer le nombre de tokens d’entrée supplémentaires par rapport au tour précédent et indiquer combien de ces tokens supplémentaires ont été trouvés dans le cache.
Étape 5 : utiliser les données de tokens Codex pour décider entre compresser et ouvrir une nouvelle fenêtre
Avec les données de chaque tour, vous pouvez prendre une décision en vous appuyant sur des chiffres. Surveillez surtout trois signaux :
- Croissance des entrées : si le nombre de tokens d’entrée ajoutés à chaque tour augmente, les sorties d’outils et l’historique s’accumulent rapidement.
- Part des lectures en cache : si leur proportion dans les entrées baisse nettement dans la colonne d’explication, le préfixe a changé et la plupart des nouvelles entrées sont facturées au plein tarif.
- Entrée par requête : à l’approche de 272 000 tokens, la requête suivante risque de franchir le palier tarifaire.
Tableau de décision : compresser ou ouvrir une nouvelle fenêtre
| Ce que vous voyez dans les logs | Action recommandée | Pourquoi |
|---|---|---|
| L’entrée d’une requête approche 272 000 tokens et la tâche n’est pas terminée | Lancez d’abord /compact manuellement |
Éviter que le prix des entrées double après le franchissement du palier |
| L’entrée d’une requête approche 272 000 tokens et la tâche est à une étape de transition | Ouvrez une nouvelle fenêtre | Repartir à zéro est plus propre que compresser |
| La part des lectures en cache baisse plusieurs tours de suite | Ouvrez une nouvelle fenêtre pour changer de sujet | Le cache n’est plus utilisé ; la suite de la conversation sera en grande partie facturée au plein tarif |
| L’augmentation des entrées par tour s’accélère soudainement | Vérifiez les sorties d’outils et, si nécessaire, réduisez tool_output_token_limit |
De longues sorties de commandes ont été ajoutées à l’historique |
| Les entrées sont stables et la part des lectures en cache est élevée | Poursuivez la conversation actuelle | C’est dans cette situation qu’une longue conversation offre le meilleur rapport coût-efficacité |
| Vous venez de compresser et la fenêtre est déjà presque pleine | Ouvrez une nouvelle fenêtre | Les compressions successives rendent le résumé de plus en plus approximatif |
Comment configurer la compression du contexte dans Codex
La compression consiste à remplacer les premiers échanges de la conversation par un résumé concis pour libérer de l’espace dans la fenêtre de contexte. Codex propose deux méthodes : manuelle et automatique.
- Compression manuelle : saisissez
/compactdans l’application de bureau ou dans la CLI. - Compression automatique : définissez le seuil de déclenchement avec
model_auto_compact_token_limit. Si vous ne le renseignez pas, la valeur par défaut du modèle est utilisée. - Périmètre de calcul du seuil :
model_auto_compact_token_limit_scopeacceptetotal(calcul sur l’ensemble du contexte actif) oubody_after_prefix(calcul limité à la partie ajoutée après le préfixe conservé). - Avec une base_url tierce : si le nom du modèle ne figure pas dans la table intégrée de Codex, mieux vaut renseigner manuellement
model_context_windowet le seuil de compression automatique. Pour déclencher la compression avant de franchir un palier tarifaire, vous pouvez fixer le seuil sous 272 000. - N’activez pas
remote_compactionsans vérification : la valeurv2exige que le fournisseur en amont prenne en charge le protocole de compression côté Responses. Il est plus prudent de conserverunsupportedet d’utiliser la compression locale.
Le coût de la compression
La compression n’est pas gratuite. Elle réécrit le préfixe de l’historique, ce qui invalide le cache. Les tokens d’entrée de la requête qui suit sont donc facturés presque au tarif plein. Une fois la compression terminée, mieux vaut passer directement à un nouveau sujet plutôt que de reprendre une ancienne tâche. La compression entraîne aussi une perte de détails : rien ne garantit que le résumé conservera toutes les informations.
Questions fréquentes (FAQ)
Q1 : Une requête n’apparaît pas dans les journaux. A-t-elle été oubliée ?
Les journaux ne recensent que les appels facturés. Les requêtes qui échouent lors des étapes réseau, d’authentification ou de validation des paramètres n’atteignent pas le service en amont : elles ne sont donc ni facturées ni consignées. À l’inverse, une entrée dans les journaux indique que la requête a bien généré une consommation. Vérifiez aussi que le filtre de jeton et la période sélectionnée sont corrects.
Q2 : Pourquoi le montant est-il inférieur à mon estimation basée sur les tokens ?
La cause la plus fréquente est le cache. Le canal OpenAI utilise un cache automatique des préfixes : lorsque le préfixe reste identique et contient au moins 1 024 tokens, il peut être servi depuis le cache. La partie mise en cache est facturée à 10 % du tarif des tokens d’entrée. Dans la colonne des détails des journaux APIYI / apiyi.com, vous pouvez voir le nombre de tokens lus depuis le cache. Par ailleurs, les journaux affichent le montant avant remise : coût réel ≈ montant du journal ÷ (1 + taux de bonus).
Q3 : Pourquoi l’heure des journaux ne correspond-elle pas à celle de mes actions ?
Par défaut, les journaux affichent les heures en UTC+0. L’heure de Pékin est en UTC+8, soit 8 heures de décalage. Si vous filtrez « la session de 15 h » en utilisant l’heure de Pékin, vous risquez donc de croire qu’il manque des données. Convertissez simplement l’heure avant de filtrer.
Q4 : Combien de temps les journaux sont-ils conservés ?
Prévoyez de pouvoir consulter environ les 30 derniers jours. La durée réelle peut être plus longue, mais la plateforme ne le garantit pas et sa politique de nettoyage peut évoluer. Si vous avez besoin de rapprocher vos comptes sur une plus longue période, utilisez régulièrement la fonction « Exporter » ou l’API de consultation des journaux pour conserver vos propres données.
Q5 : Les journaux permettent-ils de voir les fichiers lus par Codex et le contenu envoyé ?
Non. Les journaux ne conservent que les informations de base nécessaires à la facturation, comme le nombre de tokens, le montant et les coefficients appliqués. Ils n’enregistrent pas le contenu des entrées et des sorties. Pour savoir ce qui s’est passé lors d’un échange, il faut consulter la conversation Codex elle-même.
Q6 : Existe-t-il un moyen simple d’enregistrer automatiquement la consommation de chaque échange ?
Pour une exécution par script, vous pouvez utiliser `codex exec –json` et lire les données d’utilisation dans l’événement `turn.completed`. En mode interactif, vous pouvez utiliser l’API de consultation des journaux pour récupérer et agréger régulièrement les données, en filtrant par jeton dédié et par période. Les nouveaux utilisateurs peuvent d’abord obtenir un crédit d’essai gratuit sur APIYI / apiyi.com pour tester l’ensemble du processus.
Consommation de tokens par tour dans Codex : l’essentiel
- L’accès existe toujours : consultez l’utilisation du contexte avec
/status. Dans le CLI,/statuslinepermet aussi de l’afficher en pied de page. - Requête ≠ tour : un tour de conversation peut comprendre plusieurs appels d’outils et correspondre à plusieurs lignes dans les journaux. Il faut les additionner sur la période concernée.
- Clé dédiée : créez une clé API réservée à Codex pour filtrer facilement ses entrées dans les journaux.
- Consultez la colonne des détails : les lectures et écritures de cache sont indiquées séparément. Les tokens trouvés dans le cache sont facturés à 10 % du tarif normal.
- Palier de 272 K : si une requête dépasse 272 000 tokens en entrée, le tarif d’entrée double.
- La compression a un coût : après compression, le cache devient invalide et les tokens en entrée de la requête concernée sont presque entièrement facturés au tarif normal. C’est donc un bon moment pour passer à un nouveau sujet.
En résumé
Si vous ne voyez pas l’utilisation du contexte dans Codex, ce n’est pas parce que la fonctionnalité a disparu : elle a simplement changé de place. /status vous indique le contexte restant, tandis que les journaux d’appels vous montrent le coût de chaque tour. En combinant les deux, vous pouvez décider sur la base de chiffres s’il est temps d’ouvrir une nouvelle fenêtre.
Vous pouvez essayer dès aujourd’hui : créez une clé dédiée à Codex, puis ouvrez la page des journaux d’APIYI / apiyi.com. Choisissez un tour de conversation récent et additionnez les quelques requêtes qui le composent.
📚 Références
- Dépôt officiel OpenAI Codex : code source de la CLI et définitions des événements
- Lien :
github.com/openai/codex -
Détail : le champ
usagedeturn.completedest défini danscodex-rs/exec/src/exec_events.rs -
Documentation officielle de Codex : commandes slash et références de configuration
- Lien :
developers.openai.com/codex -
Détail : présentation de
/status,/compact,/statuslineet des paramètres liés à la compression -
Documentation d’aide d’APIYI : journaux d’appels, facturation du cache et API de consultation des journaux
- Lien :
docs.apiyi.com - Détail : définition des champs des journaux, tarif du cache à 10 % du tarif standard et méthode de conversion de
quota
Auteur : équipe technique d’APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site officiel d’APIYI. Vous trouverez davantage de détails sur la configuration dans le centre de documentation.
