Cache de 12 heures dans l’API OpenAI : quand réduit-il le coût des longues requêtes ?

Pour un agent qui fait plusieurs appels à l’API au cours d’une journée de travail, la retransmission d’instructions longues a un coût. Le 20 octobre 2026, OpenAI a ajouté à l’API Responses une durée de mise en cache configurable de 12 heures : des instructions, des outils et du contexte communs peuvent rester réutilisables entre des requêtes espacées de plusieurs heures. OpenAI indique un tarif d’écriture 2,5 fois supérieur au prix ordinaire des jetons d’entrée ; il s’agit du tarif total d’écriture, et non d’un supplément qui s’y ajoute. Les économies dépendent de la réutilisation du préfixe et du prix de lecture des jetons mis en cache. L’annonce dans le journal des modifications d’OpenAI est datée du 20 octobre 2026.

Cette durée est conçue pour les processus de travail en plusieurs étapes : un agent peut, par exemple, analyser des documents le matin puis reprendre sa tâche plus tard avec les mêmes instructions et outils. Pour décider d’activer la durée de 12 heures, il faut comparer le coût de l’écriture aux dépenses liées aux lectures répétées et tenir compte du nombre de requêtes qui réutilisent réellement le même préfixe.

Ce qui est mis en cache

La mise en cache des prompts réutilise une partie initiale identique de l’entrée. Les requêtes suivantes doivent conserver cette partie à l’identique ; les données variables doivent être placées après la partie fixe. Le guide d’OpenAI sur la mise en cache des prompts indique que, pour GPT‑5.6 et les modèles ultérieurs, l’API Responses permet de définir un TTL de `30m` ou `12h`. Douze heures est la durée minimale pendant laquelle une écriture doit rester disponible pour une lecture depuis le cache ; cela ne garantit pas sa suppression exactement au bout de 12 heures. La disponibilité et les paramètres dépendent du modèle.

Les instructions système, les définitions des outils et les règles de traitement stables sont bien adaptées au préfixe fixe. La question actuelle, les identifiants de tâche et les données récentes doivent être ajoutés ensuite. Si les premières parties de la requête changent, le préfixe correspondant sera plus court et le nombre de jetons réutilisés pourra diminuer.

Évaluer la rentabilité

Supposons qu’un préfixe stable contienne P jetons, soit envoyé N fois, que le prix d’un jeton d’entrée ordinaire soit C et que le tarif de lecture depuis le cache du modèle choisi soit R. Avec une seule écriture et une correspondance dans le cache pour toutes les requêtes suivantes, le coût de ce préfixe sera d’environ 2,5PC + (N−1)PR. Sans cache, sa transmission coûterait NPC. Cette estimation ne porte que sur le préfixe stable : il faut comptabiliser séparément la partie variable de la requête, les défauts de cache et les écritures supplémentaires. Le tarif de lecture dépend du modèle ; la documentation indique, par exemple, 0,05 fois le prix ordinaire du jeton d’entrée pour GPT‑6.1 Sol, et 0,1 pour GPT‑5.6 et les modèles ultérieurs.

Dans ce modèle simplifié, le cache commence à faire économiser sur le préfixe réutilisé lorsque 2,5C + (N−1)R < NC. Le seuil de rentabilité réel dépend du taux de correspondance observé, des écritures répétées et du tarif applicable. Si les requêtes sont rares, si les instructions changent souvent ou si le préfixe est unique à chaque fois, le coût supplémentaire des écritures peut dépasser les économies réalisées sur les lectures.

Tester sur la charge de travail réelle

1. Définissez le scénario de référence. Prenez des requêtes types, la longueur du préfixe stable, les intervalles entre les appels et le coût sans TTL de 12 heures.
2. Séparez les éléments fixes et variables. Gardez les instructions communes et les schémas des outils au début, puis placez les données utilisateur et la tâche en cours après ceux-ci.
3. Comparez des requêtes comparables. Calculez les écritures, le volume de jetons d’entrée mis en cache et le coût total pour le modèle et la durée de conservation choisis.
4. Évaluez le cycle de travail complet. Tenez compte des défauts de cache, des nouvelles écritures après expiration et des cas où une modification du préfixe empêche sa réutilisation.

Les métriques de réponse de l’API permettent de vérifier le volume réel de jetons d’entrée mis en cache et d’écritures ; les informations rapportées varient selon le modèle. La durée configurable de 12 heures convient à un préfixe stable et volumineux, réutilisé à plusieurs heures d’intervalle. Pour les requêtes courtes ou rarement répétées, mesurez d’abord les écritures, les correspondances et le coût total sur votre propre trafic.