Facturation et gestion des coûts

Comprendre ce que vous payez

La facturation de la Responses API a une particularité importante : dans une conversation chaînée, vous êtes facturé pour l’intégralité de l’historique, même si vous ne le renvoyez pas explicitement. Comprendre ce mécanisme est essentiel pour maîtriser vos coûts en production.

Le piège de l’historique cumulé

Avec previous_response_id, le serveur reconstruit automatiquement le contexte complet. C’est pratique pour le développeur, mais cela signifie que les tokens s’accumulent :

La croissance est quadratique. Au 10e tour d’une conversation, les tokens d’entrée peuvent être 10 à 50 fois supérieurs à votre message initial.

Lire les coûts dans la réponse

Chaque réponse inclut un objet usage avec le coût exact :

{
  "usage": {
    "input_tokens": 450,
    "output_tokens": 280,
    "total_tokens": 730,
    "output_tokens_details": {
      "reasoning_tokens": 200
    },
    "cost_in_nano_usd": 1500000
  }
}

cost_in_nano_usd

Le champ cost_in_nano_usd donne le coût en nano-dollars :

1 000 000 000 nano-USD = 1 USD

Pour convertir :

cost_usd = response.usage.cost_in_nano_usd / 1_000_000_000
print(f"Coût de cette requête : ${cost_usd:.6f}")

Tokens de raisonnement

Les reasoning_tokens dans output_tokens_details sont facturés au tarif des tokens de sortie. Ils peuvent représenter 50 à 80% des tokens de sortie sur les modèles de raisonnement.

Stratégies d’optimisation

Limiter la longueur des conversations

Plutôt que de chaîner indéfiniment, résumez périodiquement :

# Au bout de N tours, résumer et repartir
if turn_count > 5:
    summary = client.responses.create(
        model="grok-4.20-reasoning",
        input="Résume cette conversation en 3 points essentiels.",
        previous_response_id=last_id
    )
    # Repartir avec le résumé comme nouveau contexte
    new_start = client.responses.create(
        model="grok-4.20-reasoning",
        instructions=f"Contexte précédent : {summary.output[0].content[0].text}",
        input=user_message
    )

Choisir le bon modèle

Tous les modèles n’ont pas le même coût. Pour des tâches simples, utilisez un modèle moins puissant (et moins cher). Réservez les modèles de raisonnement aux problèmes complexes.

Contrôler max_output_tokens

Limitez la sortie quand vous n’avez pas besoin de longues réponses :

{
  "model": "grok-4.20-reasoning",
  "input": "Réponds en une phrase : quelle est la capitale du Japon ?",
  "max_output_tokens": 100
}

Utiliser store: false quand possible

Les réponses non stockées ne sont pas conservées côté serveur. Cela ne réduit pas le coût direct mais évite l’accumulation de données inutiles.

Suivi des coûts en production

Implémentez un suivi systématique :

import json
from datetime import datetime

def log_usage(response, user_id, feature):
    log_entry = {
        "timestamp": datetime.now().isoformat(),
        "user_id": user_id,
        "feature": feature,
        "response_id": response.id,
        "model": response.model,
        "input_tokens": response.usage.input_tokens,
        "output_tokens": response.usage.output_tokens,
        "reasoning_tokens": response.usage.output_tokens_details.reasoning_tokens,
        "cost_nano_usd": response.usage.cost_in_nano_usd,
        "cost_usd": response.usage.cost_in_nano_usd / 1e9
    }
    # Sauvegarder dans votre système de logs
    save_to_db(log_entry)

Alertes de coût

Mettez en place des seuils d’alerte :

MAX_COST_PER_REQUEST = 0.05  # 5 centimes USD

cost = response.usage.cost_in_nano_usd / 1e9
if cost > MAX_COST_PER_REQUEST:
    alert(f"Requête coûteuse détectée : ${cost:.4f} (user: {user_id})")

Points clés à retenir

• Les conversations chaînées facturent tout l’historique à chaque tour — croissance quadratique
• cost_in_nano_usd / 1 milliard = coût en USD
• Les tokens de raisonnement sont facturés mais invisibles dans la réponse
• Résumez les longues conversations pour contenir les coûts
• Implémentez un suivi systématique des coûts par utilisateur et par fonctionnalité