> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Mise en cache des prompts GPT
> Mise en cache des prompts GPT : gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna, écriture en cache 1,25x, lecture 0,1x, prompt_cache_key et points de rupture.
La mise en cache des prompts (Prompt Caching) des modèles GPT (gpt-4o et suivants) s'applique automatiquement : lorsque le préfixe de la requête atteint 1 024 jetons et correspond mot pour mot à une requête récente, la partie en cache est facturée au tarif de lecture de cache, et la latence du premier jeton diminue. La série GPT-5.6 (`gpt-5.6-sol` / `gpt-5.6-terra` / `gpt-5.6-luna`) fait évoluer le mécanisme de cache : l'écriture en cache est désormais facturée séparément (1,25x le prix d'entrée), la lecture en cache est à 0,1x le prix d'entrée, le cache est conservé au moins 30 minutes, et de nouveaux paramètres sont introduits — `prompt_cache_key` pour une correspondance fiable et des points de rupture de cache explicites.
Aperçu du comportement du cache selon la génération :
| | Avant GPT-5.6 | GPT-5.6 et suivants |
| :--------------------------------- | :-------------------------------------------------------------- | :------------------------------------------------------------------------------------------ |
| Mode de mise en cache | Automatique | Automatique + points de rupture explicites |
| Longueur minimale de cache | 1 024 jetons | 1 024 jetons |
| Facturation de l'écriture en cache | Sans facturation supplémentaire | 1,25x le prix d'entrée de base |
| Facturation de la lecture en cache | Selon le tarif de lecture de cache du modèle | 0,1x le prix d'entrée de base |
| Durée de rétention du cache | Effacé après 5–10 minutes d'inactivité, 1 heure maximum | Conservé au moins 30 minutes |
| `prompt_cache_key` | Optionnel, pour améliorer le taux de hit | Requis par la documentation officielle pour activer une correspondance de cache plus fiable |
| Rétention étendue 24 heures | Prise en charge par certains modèles (`prompt_cache_retention`) | Remplacée par `prompt_cache_options.ttl`, seul `"30m"` est actuellement pris en charge |
## Démarrage rapide
La mise en cache des prompts ne nécessite aucune configuration supplémentaire : envoyez deux fois de suite une requête avec le même long préfixe ; si `usage.prompt_tokens_details.cached_tokens` de la deuxième réponse est supérieur à 0, le cache a été utilisé. Pour la série GPT-5.6, il est recommandé de définir également `prompt_cache_key` :
```shell Curl theme={null}
curl https://aihubmix.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $AIHUBMIX_API_KEY" \
-d '{
"model": "gpt-5.6-sol",
"prompt_cache_key": "my-app-report-assistant-v1",
"messages": [
{
"role": "system",
"content": "You are a meticulous assistant for analyzing quarterly financial reports... [placez ici de longues instructions fixes ou des documents de référence, ≥1024 jetons]"
},
{
"role": "user",
"content": "Summarize the key figures in one sentence."
}
]
}'
```
```py Python (OpenAI SDK) theme={null}
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["AIHUBMIX_API_KEY"], # clé lue depuis la variable d'environnement
base_url="https://aihubmix.com/v1",
)
long_context = "You are a meticulous assistant for analyzing quarterly financial reports... [longues instructions fixes ou documents de référence, ≥1024 jetons]"
# Envoyer deux fois de suite le même préfixe ; la deuxième requête utilise le cache
for i in range(2):
completion = client.chat.completions.create(
model="gpt-5.6-sol",
prompt_cache_key="my-app-report-assistant-v1",
messages=[
{"role": "system", "content": long_context},
{"role": "user", "content": "Summarize the key figures in one sentence."},
],
)
print(completion.usage.prompt_tokens_details)
```
Champ usage mesuré sur les deux appels (2026-07-10, `gpt-5.6-sol`) :
```json theme={null}
// 1er appel : aucun hit
"prompt_tokens_details": {"audio_tokens": 0, "cached_tokens": 0}
// 2e appel : le préfixe touche le cache
"prompt_tokens_details": {"audio_tokens": 0, "cached_tokens": 2816}
```
## Facturation du cache
Règles de facturation du cache pour la série GPT-5.6 :
| Élément facturé | Tarif |
| :------------------------- | :----------------------------- |
| Jetons d'entrée réguliers | Tarif plateforme |
| Jetons d'écriture en cache | 1,25x le prix d'entrée de base |
| Jetons de lecture en cache | 0,1x le prix d'entrée de base |
| Jetons de sortie | Tarif plateforme |
Formulation officielle d'OpenAI (extraite de l'[annonce de lancement de GPT-5.6](https://openai.com/index/gpt-5-6/)) : "For GPT‑5.6 and later models, cache writes are billed at 1.25x the model's uncached input rate, while cache reads continue to receive the 90% cached-input discount." Le [guide officiel de mise en cache des prompts](https://developers.openai.com/api/docs/guides/prompt-caching) décrit le périmètre d'application de ces taux comme "GPT-5.6 models and later model families". Les tarifs officiels de chaque modèle figurent sur [OpenAI Pricing](https://developers.openai.com/api/docs/pricing) ; les prix effectifs sur AIHubMix sont indiqués dans la [galerie de modèles](https://aihubmix.com/models).
Le point d'équilibre se calcule directement à partir des taux officiels : écrire un préfixe en cache coûte 0,25x le prix d'entrée de plus que sans cache, puis chaque hit économise 0,9x le prix d'entrée. Dès qu'un préfixe est réutilisé 1 fois, l'économie est nette ; plus il est réutilisé, plus l'économie augmente. Une requête unique dont le préfixe ne sera jamais réutilisé paie des frais d'écriture supplémentaires ; le mode explicit permet de désactiver le cache (voir « Paramètres de cache de GPT-5.6 » ci-dessous).
Pour les modèles antérieurs à GPT-5.6, l'écriture en cache est sans facturation supplémentaire et la lecture en cache est facturée au tarif de lecture de cache du modèle concerné ; les prix de chaque modèle sont indiqués dans la [galerie de modèles](https://aihubmix.com/models).
La série GPT-5.6 distingue deux paliers de contexte : lorsqu'une requête dépasse 272K jetons d'entrée, l'ensemble de la requête est facturé au palier de contexte long (entrée 2x, sortie 1,5x). Les taux d'écriture en cache 1,25x et de lecture 0,1x s'appliquent également au palier de contexte long, sur la base du prix d'entrée de ce palier.
## Comment le cache s'applique automatiquement
À l'envoi d'une requête, le système vérifie si le préfixe (dans l'ordre de sérialisation de messages, tools, etc.) correspond mot pour mot au préfixe d'une requête récente :
1. Si le préfixe atteint 1 024 jetons et qu'un préfixe en cache identique est trouvé, la partie correspondante est facturée au tarif de lecture de cache et la latence du premier jeton diminue ;
2. Sinon, la requête est traitée comme entrée régulière et le préfixe est écrit dans le cache (facturé 1,25x pour GPT-5.6 et suivants) ;
3. Un hit exige une correspondance octet par octet du préfixe ; toute modification en un point du préfixe invalide l'ensemble du cache situé après ce point.
Les scénarios suivants en bénéficient le plus :
* Longues instructions système fixes ou nombreux exemples few-shot
* Longs documents de référence cités de manière répétée dans les scénarios RAG
* Workflows d'agents transportant de nombreuses définitions d'outils (tools)
* Longues conversations multi-tours qui ajoutent uniquement des messages à la fin
Durée de rétention du cache : les modèles antérieurs à GPT-5.6 effacent le cache après 5–10 minutes d'inactivité, avec un maximum d'1 heure ; GPT-5.6 et suivants le conservent au moins 30 minutes, la durée effective pouvant être plus longue. Le cache n'est pas partagé entre organisations et n'a aucun effet sur le contenu de sortie.
## Paramètres de cache de GPT-5.6
La série GPT-5.6 ajoute trois paramètres liés au cache (communs à Chat Completions et à la Responses API) :
| Paramètre | Type / position | Valeurs | Défaut |
| :------------------------ | :--------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------- |
| `prompt_cache_key` | string, racine du corps de requête | Identifiant stable personnalisé, à répartir par activité ou par tenant ; le trafic total d'une même key doit rester autour de 15 requêtes/minute | Aucun |
| `prompt_cache_options` | object, racine du corps de requête | `mode` : `"implicit"` / `"explicit"` ; `ttl` : seul `"30m"` est pris en charge | `mode: "implicit"`, `ttl: "30m"` |
| `prompt_cache_breakpoint` | object, dans un bloc de contenu | `{"mode": "explicit"}`, marque la fin du préfixe mis en cache | Aucun point de rupture |
Les modèles antérieurs à GPT-5.6 ne prennent pas en charge `prompt_cache_options` ni `prompt_cache_breakpoint` ; la requête est rejetée. Le paramètre de rétention étendue 24 heures des anciens modèles, `prompt_cache_retention` (`"24h"` / `"in_memory"`), est remplacé à partir de GPT-5.6 par `prompt_cache_options.ttl`.
Relation entre les trois modes de contrôle du cache :
1. **Défaut (mode implicit)** : le cache est écrit automatiquement même sans aucun paramètre de cache — le système place automatiquement un point de rupture à la position du message le plus récent. Pour GPT-5.6 et suivants, les écritures en cache automatiques sont également facturées à 1,25x.
2. **Mode implicit + point de rupture explicite** : en plus du point de rupture automatique, `prompt_cache_breakpoint` peut être placé sur un bloc de contenu pour fixer la limite du cache à la fin du contenu stable ; les modifications situées après le point de rupture ne détruisent pas le cache du préfixe qui le précède.
3. **Mode explicit** : lorsque `prompt_cache_options.mode` vaut `"explicit"`, seuls les points de rupture manuels sont utilisés ; si aucun point de rupture n'est défini, la requête n'utilise pas le cache et ne génère pas de frais d'écriture. [Texte officiel](https://developers.openai.com/api/docs/guides/prompt-caching) : "If the conversation contains no explicit breakpoints, the request does not use prompt caching or incur cache-write charges."
Désactiver les frais d'écriture en cache d'une longue requête unique avec le mode explicit :
```json theme={null}
{
"model": "gpt-5.6-sol",
"prompt_cache_options": {"mode": "explicit"},
"messages": [
{"role": "user", "content": "[long contenu unique qui ne sera pas réutilisé]"}
]
}
```
Usage officiel du point de rupture explicite (placé à la fin du long bloc de contenu fixe) :
```json theme={null}
{
"model": "gpt-5.6-sol",
"prompt_cache_key": "my-app-report-assistant-v1",
"messages": [
{
"role": "system",
"content": [
{
"type": "text",
"text": "[longues instructions fixes ou documents de référence, ≥1024 jetons]",
"prompt_cache_breakpoint": {"mode": "explicit"}
}
]
},
{"role": "user", "content": "Summarize the key figures in one sentence."}
]
}
```
Contraintes strictes (formulation officielle) :
* Chaque requête crée au maximum 4 nouvelles écritures en cache ; en mode implicit, le point de rupture automatique en occupe 1 ;
* Le préfixe situé avant un point de rupture doit toujours atteindre 1 024 jetons pour être mis en cache ;
* À la lecture, le préfixe correspondant le plus long est retenu parmi les 50 derniers points de rupture ;
* Un point de rupture placé sur un bloc de contenu non pris en charge renvoie `400 invalid_request_error`. Chat Completions prend en charge les blocs `text` / `image_url` / `input_audio` / `file` / `refusal`, la Responses API les blocs `input_text` / `input_image` / `input_file`.
La prise en charge par AIHubMix des points de rupture `prompt_cache_breakpoint` au niveau des blocs de contenu et des hits de cache via la Responses API est en cours de finalisation. À ce stade, la voie recommandée est le cache automatique via Chat Completions avec `prompt_cache_key` (exemple du démarrage rapide de cette page, hit vérifié) ; le mode explicit de `prompt_cache_options` fonctionne normalement pour désactiver l'écriture en cache. Cette page sera mise à jour au fil de la prise en charge.
## Pourquoi le cache n'est pas touché
Un hit exige que tout le contenu situé avant le point de rupture soit identique octet par octet. Si `cached_tokens` reste à 0 lors de la deuxième requête, vérifiez la liste suivante :
* **Préfixe inférieur à 1 024 jetons** : les requêtes en dessous de la longueur minimale de cache sont traitées comme entrée régulière ;
* **Contenu variable mêlé au préfixe** : horodatages, identifiants de session, variables utilisateur doivent être placés après le contenu fixe ; toute modification dans le préfixe invalide le cache situé après ;
* **Définitions ou ordre des tools modifiés** : la liste d'outils participe au calcul du préfixe ; les définitions et leur ordre doivent être strictement identiques ;
* **Paramètre detail d'image incohérent** : `detail` influe sur la tokenisation des images et doit rester identique ;
* **Schéma de sortie structurée modifié** : le JSON Schema de `response_format` participe au cache en tant que préfixe du message système ; un changement de schéma change le préfixe ;
* **`reasoning_effort` modifié** : cité officiellement parmi les causes courantes d'une baisse du taux de hits ("Changes to reasoning effort") ;
* **Durée de rétention dépassée** : avant GPT-5.6, le cache est effacé après 5–10 minutes d'inactivité ; GPT-5.6 et suivants le conservent au moins 30 minutes ;
* **`prompt_cache_key` non défini (GPT-5.6)** : sans ce paramètre, un hit automatique reste possible, mais le mécanisme de correspondance plus fiable n'est pas utilisé.
## Bonnes pratiques
* Placez le contenu fixe (instructions système, exemples, documents de référence, définitions d'outils) au tout début de la requête, et le contenu variable à chaque tour à la fin ;
* Attribuez la même `prompt_cache_key` stable au trafic partageant le même préfixe ; maintenez le trafic total d'une key autour de 15 requêtes/minute et répartissez sur plusieurs keys par activité au-delà ;
* Dans les conversations multi-tours, ajoutez uniquement des messages à la fin, sans modifier les messages historiques ;
* Maintenez un trafic continu sur les requêtes partageant le même préfixe pour réduire l'effacement du cache ;
* Pour les longues requêtes uniques dont le préfixe ne sera pas réutilisé, utilisez le mode explicit pour éviter les frais d'écriture en cache (GPT-5.6 et suivants) ;
* Surveillez en continu les hits via `usage.prompt_tokens_details.cached_tokens`.
## Foire aux questions (FAQ)
### La mise en cache des prompts GPT doit-elle être activée manuellement ?
Aucune activation manuelle requise : dès que le préfixe atteint 1 024 jetons, il est automatiquement mis en cache. Pour GPT-5.6 et suivants, il est recommandé de définir également `prompt_cache_key` pour une correspondance de cache plus fiable.
### Comment sont calculés les frais d'écriture en cache de GPT-5.6 ? Comment éviter des frais d'écriture inutiles ?
L'écriture en cache est facturée à 1,25 fois le prix d'entrée de base, la lecture à 0,1 fois ; dès qu'un préfixe est réutilisé 1 fois, l'économie est nette. Pour une longue requête unique dont le préfixe ne sera pas réutilisé, réglez `prompt_cache_options.mode` sur `"explicit"` sans définir de point de rupture : la requête n'utilise alors pas le cache et ne génère pas de frais d'écriture.
### Combien de temps le cache est-il conservé ?
GPT-5.6 et suivants : au moins 30 minutes (`ttl` ne prend actuellement en charge que `"30m"`, la durée effective pouvant être plus longue) ; les modèles antérieurs à GPT-5.6 effacent le cache après 5–10 minutes d'inactivité, avec un maximum d'1 heure, et certains anciens modèles prennent en charge la rétention étendue `prompt_cache_retention: "24h"`.
### Quelle différence entre les points de rupture explicites de GPT-5.6 et le cache\_control de Claude ?
Les deux servent à fixer la limite du cache à la fin du contenu stable. Différences principales : GPT-5.6 met en cache automatiquement sans aucun paramètre, le point de rupture étant un contrôle fin optionnel ; Claude requiert l'activation du cache dans la requête (`cache_control` au niveau racine pour un point de rupture automatique, ou point de rupture explicite au niveau des blocs de contenu). GPT-5.6 conserve le cache au moins 30 minutes ; Claude, 5 minutes par défaut avec une option d'1 heure. La lecture en cache est facturée à 0,1x le prix d'entrée chez les deux. L'usage côté Claude est décrit dans [Mise en cache des prompts Claude](/fr/api/Claude-Cache).
### Le cache influe-t-il sur le contenu de sortie ?
Aucune influence. Formulation officielle : la mise en cache des prompts n'affecte que le traitement et la facturation côté entrée ; le modèle génère la sortie exactement de la même manière qu'en l'absence de cache.
## Références officielles
Les mécanismes, taux et paramètres de cette page proviennent des sources officielles OpenAI suivantes :
* [Annonce de lancement de GPT-5.6](https://openai.com/index/gpt-5-6/) : règle de facturation — écriture en cache 1,25x / lecture avec remise de 90 %
* [Guide de mise en cache des prompts](https://developers.openai.com/api/docs/guides/prompt-caching) : mécanisme, paramètres, champs usage et limites
* [OpenAI Pricing](https://developers.openai.com/api/docs/pricing) : tarifs officiels de chaque modèle
* [Documentation du modèle GPT-5.6](https://platform.openai.com/docs/models/gpt-5.6-sol) : fenêtre de contexte, seuil de facturation du contexte long
Les prix effectifs de chaque modèle sur AIHubMix sont indiqués dans la [galerie de modèles](https://aihubmix.com/models).
***
Dernière mise à jour : 2026-07-10