Réduire ses coûts LLM de 60% avec le prompt caching — guide pratique

Note — scénario illustratif. L'exemple chiffré ci-dessous est un cas type, pas la facture d'un client nommé. Les montants et pourcentages sont des estimations et ordres de grandeur indicatifs, fournis à titre pédagogique. Ils ne constituent pas une garantie de résultat.

Imaginons un projet qui dépense 840€/mois en tokens Claude. Après implémentation du prompt caching : 320€/mois environ. Gain : ~62%. Temps d'implémentation : 4 heures.

Ce guide vous montre exactement comment reproduire ce résultat.

Comment fonctionne le prompt caching

Anthropic facture le prompt caching en deux modes :

• Cache write : 25% plus cher que le prix normal (on crée le cache)
• Cache read : 90% moins cher que le prix normal (on réutilise le cache)

Le break-even : Si vous réutilisez un bloc de texte plus de 1,25 fois, vous économisez de l'argent.

Pour un system prompt de 10 000 tokens utilisé 100 fois par jour :

• Sans cache : 100 × 10 000 × 0.003€/1K = 3€/jour
• Avec cache (1 write + 99 reads) : 0.00375€ + 99 × 0.0003€ = 0.034€/jour

Économie : 98.8% sur cette partie du coût.

Quand utiliser le caching

✅ Cas idéaux :

• System prompts longs (> 1000 tokens)
• Documents de référence inclus dans chaque requête
• Règles métier / guidelines répétées
• Exemples few-shot

❌ À éviter :

• Blocs qui changent à chaque requête
• Contexts très courts (< 500 tokens)
• Données utilisateur dynamiques

Implémentation avec le SDK Anthropic

import anthropic

client = anthropic.Anthropic()

# System prompt long (règles métier, contexte produit, etc.)
SYSTEM_PROMPT = """
Tu es un assistant commercial expert pour [Entreprise].

RÈGLES IMPÉRATIVES :
[... 2000 tokens de règles métier ...]

CATALOGUE PRODUITS :
[... 5000 tokens de données produits ...]

PROCESS COMMERCIAL :
[... 1000 tokens de process ...]
"""

def analyze_lead(lead_data: str) -> str:
    response = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"}  # ← La clé
            }
        ],
        messages=[
            {
                "role": "user",
                "content": f"Analyse ce lead : {lead_data}"
            }
        ]
    )
    return response.content[0].text

Important : Le cache expire après 5 minutes d'inactivité. Si vous avez des pics, gardez une requête de "warm-up" active.

Les 3 patterns les plus efficaces

Pattern 1 : Document RAG mis en cache

Au lieu de re-injecter toute votre base de connaissances à chaque requête :

# Avant (coûteux)
messages=[{"role": "user", "content": f"Documentation: {all_docs}\n\nQuestion: {question}"}]

# Après (avec cache)
system=[{"type": "text", "text": all_docs, "cache_control": {"type": "ephemeral"}}]
messages=[{"role": "user", "content": question}]

Pattern 2 : Few-shot examples en cache

system=[
    {
        "type": "text",
        "text": f"Voici 20 exemples de classification...\n{examples}",
        "cache_control": {"type": "ephemeral"}
    },
    {
        "type": "text",
        "text": "Classifie le texte suivant selon les exemples ci-dessus."
    }
]

Pattern 3 : Cache multi-tour

Pour les conversations longues, cachez l'historique :

messages = [
    {"role": "user", "content": [
        {"type": "text", "text": long_history, "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": new_message}
    ]}
]

Monitoring du cache hit rate

Vérifiez vos économies réelles via l'API :

response = client.messages.create(...)

# Dans la réponse
cache_creation_input_tokens = response.usage.cache_creation_input_tokens
cache_read_input_tokens = response.usage.cache_read_input_tokens

hit_rate = cache_read_input_tokens / (cache_creation_input_tokens + cache_read_input_tokens)
print(f"Cache hit rate: {hit_rate:.1%}")

Visez un hit rate > 80% pour un ROI significatif.

Les autres optimisations à combiner

Le caching est la plus rapide à implémenter, mais pas la seule levier :

1. Choix du modèle : Haiku pour les tâches simples, Sonnet pour les complexes. Haiku coûte 25× moins cher que Opus.

2. Batching : Regroupez les requêtes non-urgentes. L'API Batch d'Anthropic offre 50% de réduction.

3. Output trimming : Limitez max_tokens au strict nécessaire. Beaucoup de code génère 2000 tokens quand 400 suffisent.

4. Prompt optimization : Des prompts bien écrits obtiennent le même résultat en moins de tokens.

Le vrai takeaway

Le caching n'est pas une optimisation avancée réservée aux gros volumes. À partir de 50 requêtes/jour avec un system prompt > 1000 tokens, l'économie est significative.

Implémentez-le dès le départ — c'est 4h de travail une fois, et c'est payé en quelques semaines.