OpenAI prolonge le cache des prompts. Douze heures ne garantissent pas une économie

Un assistant peut relire les mêmes consignes à chaque demande. Il peut aussi réutiliser une partie du travail déjà effectué. Le 20 octobre, OpenAI a ajouté une durée minimale de douze heures pour le cache des prompts dans son API Responses. L’objectif est de conserver un contexte commun entre des requêtes espacées. Mais cette durée s’accompagne d’un tarif d’écriture plus élevé.

Ce que le cache conserve vraiment

La nouveauté figure dans le journal officiel de l’API. Elle concerne les préfixes partagés entre plusieurs demandes. Un préfixe est la partie identique située au début du contexte envoyé au modèle. Il peut contenir des consignes et des définitions d’outils.

Le guide du cache précise que le service conserve des états intermédiaires du calcul. Il ne ressort pas une ancienne réponse déjà rédigée. Le modèle génère une nouvelle sortie à partir du contexte réutilisé et des informations ajoutées. Deux demandes identiques ne garantissent donc pas deux réponses identiques.

Cette fonction se distingue aussi de la mémoire d’un assistant. Elle optimise le traitement d’une entrée commune. Elle n’ajoute pas à elle seule une connaissance durable sur une personne ou une activité.

Douze heures coûtent davantage à l’écriture

Pour GPT-5.6 et les modèles suivants, OpenAI indique une durée minimale de trente minutes par défaut. Écrire des tokens dans ce cache coûte 1,25 fois leur tarif d’entrée ordinaire. Choisir douze heures porte ce coefficient à 2,5.

Ce tarif remplace le prix d’entrée applicable aux tokens écrits. Il ne s’ajoute pas à un premier paiement au tarif ordinaire. La lecture conserve son propre tarif réduit. Le guide indique un coefficient de 0,1 pour la plupart de ces modèles et de 0,05 pour GPT-6.1 Sol.

L’intérêt dépend donc des réutilisations effectives. Une matière de référence stable et rappelée plusieurs heures après sa première utilisation n’a pas le même profil qu’une demande isolée. Le coût de la génération des réponses reste également à compter. Un taux élevé de lecture du cache ne résume pas toute la facture.

Un réglage dépendant du modèle

Le paramètre `prompt_cache_options.ttl` accepte la valeur `12h` dans Responses pour les modèles concernés. Un développeur peut aussi choisir une durée différente à un point de rupture explicite. Ça permet de séparer un socle stable du contexte plus changeant d’une session.

Les modèles antérieurs utilisent un autre paramètre de conservation. Il faut donc vérifier la documentation du modèle appelé avant de reprendre ce réglage dans une application. La nouveauté du 20 octobre ne transforme pas uniformément tous les anciens caches.

Une durée minimale ne fixe pas une suppression

OpenAI précise que douze heures ne constituent pas une échéance d’effacement. Le service peut conserver les entrées plus longtemps dans les limites de sa politique de données. Le paramètre ne remplace pas les vérifications nécessaires sur cette politique et les exigences de l’organisation.

La durée minimale ne garantit pas non plus une baisse de latence à chaque appel. Les possibilités de réutilisation dépendent notamment du préfixe et du routage. Les changements de consignes ou d’outils peuvent réduire la partie qui correspond au cache.

Mesurer les lectures et la facture

Le bon point de départ reste un usage réel observé. Il faut suivre les tokens lus et écrits puis comparer le coût total sur une période représentative. Il faut aussi regarder les délais de réponse et la qualité des résultats. Ces mesures répondent à des questions différentes.

Cette distinction rejoint celle entre volume et valeur dans le rapport d’OpenAI sur les agents en Europe. Une métrique technique peut éclairer un usage sans démontrer son bénéfice final.

À mes yeux, le progrès utile est de pouvoir adapter la durée au rythme du travail. L’économie se constate ensuite dans les appels et la facture. Elle ne se déduit pas du seul mot cache.