Suivi des dépenses API OpenAI par fonctionnalité : guide d'attribution des coûts

Votre facture OpenAI indique que vous avez dépensé 4 237 $ le mois dernier. Elle ne vous dit pas que 3 100 $ de ce montant provenaient d'un point de terminaison de résumé incontrôlé, 700 $ d'un client qui vous paie 50 $ par mois, et 437 $ d'une fonctionnalité que personne n'utilise. Le tableau de bord masque l'image dont vous avez besoin pour prendre toute décision de tarification, de capacité ou de feuille de route.

Ce guide vous montre comment attribuer correctement les coûts de l'API OpenAI : étiquetez chaque requête avec des métadonnées, agrégez les dépenses par fonctionnalité, route et client, définissez des plafonds budgétaires par clé, et concevez des invites pour que les coûts cessent d'être une ligne mystérieuse. Si vous livrez des fonctionnalités LLM, ce travail transforme l'IA d'une dépense incontrôlée en un coût de produit géré.

En bref

Étiquetez chaque appel d'API OpenAI avec des métadonnées structurées (fonctionnalité, route, customer_id, environnement), émettez une ligne de journal structurée par requête qui capture le nombre de jetons et le coût calculé, puis agrégez par étiquette dans votre entrepôt de données. Définissez des plafonds budgétaires par clé dans le tableau de bord OpenAI, alertez sur les anomalies de dépenses horaires, et validez le wrapper de bout en bout avec des tests de scénario Apidog avant de faire confiance aux chiffres.

Introduction

Vous livrez une nouvelle fonctionnalité IA le mardi. Le vendredi matin, votre directeur financier vous demande en message privé pourquoi la ligne OpenAI a bondi de 40 %. Vous ouvrez le tableau de bord. Il montre une augmentation des dépenses totales. Il ne montre pas quelle fonctionnalité, quel client, ou quelle route en est responsable. Vous commencez à deviner.

C'est la lacune que rencontre chaque équipe exécutant des charges de travail LLM en production. L'interface de facturation d'OpenAI est conçue pour la comptabilité fournisseurs, pas pour l'attribution technique. Vous voyez les totaux quotidiens, les détails du modèle, et c'est tout. Vous ne voyez pas la forme de la requête, le client qui l'a déclenchée ou la fonctionnalité qui a appelé le modèle.

La solution est simple en concept et impitoyable en exécution. Vous encapsulez chaque appel d'API avec une couche de métadonnées. Vous enregistrez chaque requête dans un stockage structuré. Vous agrégez par étiquette. Vous définissez des plafonds. Vous alertez sur les écarts. À la fin de cet article, vous aurez un modèle de données concret, deux exemples de code fonctionnels, un flux de travail de vérification avec Apidog, et une comparaison d'outils afin que vous puissiez décider de construire, d'acheter ou d'utiliser directement l'API d'utilisation d'OpenAI.

Pour le contexte de tarification qui motive votre calcul des coûts, consultez la répartition des prix de GPT-5.5. Pour un problème d'attribution de facturation connexe du côté des outils de développement, consultez la facturation de l'utilisation de GitHub Copilot pour les équipes API. Pour les bases de l'API OpenAI, consultez la référence officielle de l'API OpenAI.

Pourquoi le tableau de bord de facturation d'OpenAI n'est pas suffisant

Ouvrez la page de facturation OpenAI dès maintenant. Vous y verrez un graphique des dépenses quotidiennes, une ventilation par modèle et une limite d'utilisation. C'est l'intégralité de l'interface. Cela fonctionne bien si vous avez une seule application, un seul client et une seule fonctionnalité. Dès que vous avez l'un des éléments suivants : plusieurs fonctionnalités dans le même produit, plusieurs clients, plusieurs environnements ou plusieurs développeurs, le tableau de bord cesse d'être utile.

Voici ce qui manque.

Dépenses totales sans contexte. Le tableau de bord vous indique que vous avez dépensé 312 $ hier sur GPT-5.5. Il ne vous dit pas si cela provient d'un client qui a sollicité votre point de terminaison de chat de support 50 000 fois ou d'une tâche en arrière-plan qui a résumé toute votre base de connaissances parce que quelqu'un a laissé un drapeau activé. Les deux sont identiques sur le graphique.

Pas de ventilation par fonctionnalité. OpenAI étiquette les requêtes par clé d'API et par modèle. Il ne les étiquette pas par votre fonctionnalité, votre route, votre ID client ou votre environnement. Si vous voulez l'un de ces éléments, vous devez le construire vous-même. Il n'y a pas de dimension native pour l'analyse de produit dans le tableau de bord.

Délai de reporting. Les données d'utilisation apparaissent avec un délai de plusieurs dizaines de minutes à quelques heures. Au moment où une boucle incontrôlée apparaît dans votre tableau de bord, elle a déjà brûlé une carte de crédit. Vous avez besoin d'un suivi en temps réel, pas d'un graphique historique.

Pas de primitives d'alerte. OpenAI vous donne un plafond budgétaire par organisation et un e-mail de notification souple. Il n'y a pas d'alerte par clé, pas de seuil par fonctionnalité, pas de détection d'anomalies. Si vous voulez "me pager si le point de terminaison de chat dépasse 50 $ en une heure", vous devez le construire vous-même.

Pas d'attribution client. Si vous vendez du SaaS B2B avec une fonctionnalité IA, vous devez savoir quel client a généré quelles dépenses afin de pouvoir tarifer, réguler ou vendre. Le tableau de bord ne peut pas répondre à la question "combien le client X me coûte ce mois-ci". Votre équipe financière a besoin de ce chiffre pour calculer la marge brute par client. Sans cela, vos économies unitaires sont des conjectures.

Les comptes de service et les clés de niveau projet aident, mais seulement partiellement. Les clés de projet d'OpenAI vous permettent de diviser l'utilisation par projet. Cela vous donne un niveau d'attribution. Cela ne vous donne pas d'attribution par fonctionnalité, par client ou par route. Vous avez toujours besoin de métadonnées au niveau de l'application pour répondre aux questions importantes. L'API d'utilisation d'OpenAI renvoie des données agrégées par projet, pas par requête.

Le schéma se répète dans chaque équipe qui déploie des fonctionnalités LLM à grande échelle. Le fil de discussion Dev.to "OpenAI Tells You What You Spent. Not Where. So I Built a Dashboard" est devenu viral parce qu'il a exprimé clairement le problème : on ne peut pas gérer ce qu'on ne peut pas mesurer. Le tableau de bord natif répond à une question financière. Vous devez répondre à une question produit.

Le modèle de données d'attribution des coûts

L'attribution des coûts commence par une décision : chaque requête OpenAI génère un événement étiqueté écrit dans votre entrepôt de données. Cet événement est votre unité d'analyse. Si le schéma est correct, le reste du travail – tableaux de bord, alertes, plafonds – devient une requête SQL.

Voici le schéma minimal dont vous avez besoin.

Calculez le coût au moment de l'écriture, pas au moment de la requête. Les prix changent ; vous voulez un chiffre figé qui reflète le taux que vous avez payé le jour où la requête a eu lieu. La logique de calcul pour GPT-5.5 ressemble à ceci :

PRICING = {  # USD par 1M de jetons, en mai 2026
    "gpt-5.5":      {"input": 5.00,  "cached": 2.50,  "output": 30.00},
    "gpt-5.5-pro":  {"input": 30.00, "cached": 15.00, "output": 180.00},
    "gpt-5.4":      {"input": 2.50,  "cached": 1.25,  "output": 15.00},
    "gpt-5.4-mini": {"input": 0.25,  "cached": 0.125, "output": 2.00},
}

def compute_cost_usd(model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens):
    rates = PRICING[model]
    uncached = max(0, prompt_tokens - cached_tokens)
    input_cost  = (uncached      * rates["input"])  / 1_000_000
    cache_cost  = (cached_tokens * rates["cached"]) / 1_000_000
    output_cost = ((completion_tokens + reasoning_tokens) * rates["output"]) / 1_000_000
    return round(input_cost + cache_cost + output_cost, 6)

Les jetons de raisonnement comptent comme sortie. L'API OpenAI les renvoie dans usage.completion_tokens_details.reasoning_tokens, mais ils sont facturés au taux de sortie. Manquez cela et vous sous-estimerez le coût de chaque appel en mode pensée. Pour le calcul complet des prix, consultez la répartition des prix de GPT-5.5.

Maintenant, encapsulez le client OpenAI. Chaque appel passe par une fonction. Cette fonction prend des métadonnées, effectue la requête et écrit l'événement.

import time, uuid, json, logging
from openai import OpenAI

client = OpenAI()
logger = logging.getLogger("llm.cost")

def call_with_attribution(
    *, feature, route, customer_id, environment,
    model, messages, **openai_kwargs
):
    request_id = str(uuid.uuid4())
    started = time.time()
    error_code = None
    response = None

    try:
        response = client.chat.completions.create(
            model=model, messages=messages, **openai_kwargs
        )
    except Exception as e:
        error_code = getattr(e, "code", "unknown_error")
        raise
    finally:
        latency_ms = int((time.time() - started) * 1000)
        u = response.usage if response else None
        prompt_tokens     = getattr(u, "prompt_tokens", 0)
        completion_tokens = getattr(u, "completion_tokens", 0)
        cached_tokens     = getattr(getattr(u, "prompt_tokens_details", None), "cached_tokens", 0) or 0
        reasoning_tokens  = getattr(getattr(u, "completion_tokens_details", None), "reasoning_tokens", 0) or 0
        cost_usd = compute_cost_usd(model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens)

        logger.info(json.dumps({
            "event": "openai.request",
            "request_id": request_id,
            "feature": feature,
            "route": route,
            "customer_id": customer_id,
            "environment": environment,
            "model": model,
            "prompt_tokens": prompt_tokens,
            "completion_tokens": completion_tokens,
            "reasoning_tokens": reasoning_tokens,
            "cached_tokens": cached_tokens,
            "latency_ms": latency_ms,
            "cost_usd": cost_usd,
            "error_code": error_code,
        }))

    return response

Ce wrapper unique est votre surface d'attribution des coûts. Chaque fonctionnalité de votre produit l'appelle. La ligne de journal structurée est votre entrée d'entrepôt de données. À partir de là, envoyez les journaux à BigQuery, ClickHouse, Snowflake ou Postgres via votre pipeline de journaux existant (Vector, Fluent Bit, Logstash, collecteur OTLP). Pas de deuxième pipeline. Pas de service supplémentaire.

Pour les équipes Node.js, la forme est identique. Encapsulez le SDK OpenAI dans une fonction qui prend des métadonnées, capture `response.usage`, calcule le coût et écrit une ligne JSON. Si votre plateforme exécute déjà un bus d'événements (Kafka, NATS, Pub/Sub), publiez l'événement là-bas au lieu de la sortie standard et laissez les consommateurs en aval le répartir vers votre entrepôt et votre système d'alerte.

Connectez le suivi des coûts et testez-le avec Apidog

Vous avez le schéma et le wrapper. Transformez-les maintenant en quelque chose d'opérationnel. Six étapes.

1. Remplacez les appels OpenAI directs par le wrapper. Cherchez dans votre codebase `OpenAI(` et `client.chat.completions.create`. Chaque occurrence devient un appel `call_with_attribution(...)`. Rendez `feature` et `route` des arguments obligatoires. Passez-les au moment de l'appel, pas depuis une globale. Si vous oubliez de les passer, la fonction doit déclencher une erreur, et non se baser sur une valeur par défaut "unknown".

2. Émettez des journaux structurés. Journalisez vers la sortie standard en JSON, une ligne par événement. Définissez le niveau du journal sur INFO spécifiquement pour ces événements. Ne les mélangez pas avec le bruit de débogage. Si vous utilisez déjà un logger structuré (structlog, pino, winston), connectez-le à celui-ci.

3. Agrègez par fonctionnalité dans votre entrepôt de données. Une fois les événements arrivés dans BigQuery ou ClickHouse, les requêtes s'écrivent d'elles-mêmes :

SELECT
  feature,
  DATE_TRUNC(timestamp, DAY) AS day,
  COUNT(*) AS requests,
  SUM(cost_usd) AS spend_usd,
  SUM(prompt_tokens + completion_tokens) AS tokens,
  AVG(latency_ms) AS avg_latency_ms,
  SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate
FROM openai_events
WHERE environment = 'prod'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY feature, day
ORDER BY day DESC, spend_usd DESC;

4. Représentez graphiquement les dépenses par route. Pointez Grafana, Metabase, Looker ou Superset vers la table. Construisez trois vues : les dépenses par fonctionnalité au fil du temps, les dépenses par client au fil du temps, et un tableau des 20 routes les plus coûteuses trié par les dépenses d'hier. C'est votre tableau de bord opérationnel quotidien.

5. Testez le wrapper avec Apidog avant de le déployer. C'est l'étape que la plupart des équipes ignorent et regrettent. Votre wrapper écrit des journaux structurés. Si le schéma est incorrect, votre entrepôt de données est silencieusement incorrect, et les tableaux de bord mentent. Utilisez Apidog pour effectuer des tests de bout en bout sur votre service :

• Créez un scénario dans Apidog qui envoie une requête à votre point de terminaison IA avec un `customer_id` et une `feature` connus.
• Capturez la réponse et l'émission du journal du canal secondaire (stdout, OTLP, votre point de terminaison de journal).
• Utilisez les assertions de réponse d'Apidog pour vérifier que la charge utile du journal contient les `feature`, `route`, `customer_id` attendus, et que `cost_usd > 0` et `prompt_tokens > 0`.
• Exécutez le même scénario dans les environnements de staging et de production en utilisant les variables d'environnement Apidog.
• Rejouez les requêtes étiquetées et assurez-vous que les appels réessayés ne comptent pas deux fois le coût (votre wrapper devrait réutiliser le `request_id` lors de la nouvelle tentative).

Pour des approches de test d'API plus larges qui s'intègrent à cette étape de vérification, consultez les outils de test d'API pour les ingénieurs QA. Pour l'approche "contract-first" qui s'associe à la couverture d'attribution des coûts, consultez le développement d'API "contract-first".

6. Définissez des plafonds budgétaires par clé et des alertes. OpenAI vous permet de créer une clé de projet par environnement ou par fonctionnalité. Utilisez-la. Créez une clé `prod-support-chat`, une clé `prod-summarization`, une clé `staging-all`. Définissez des plafonds stricts dans le tableau de bord OpenAI afin qu'une boucle incontrôlée sur une fonctionnalité ne puisse pas épuiser l'intégralité du budget de l'organisation. Superposez votre propre système d'alerte : une requête SQL qui s'exécute toutes les 10 minutes et vous avertit si une fonctionnalité dépasse 3 fois sa dépense horaire moyenne sur 7 jours. PagerDuty, Opsgenie ou un webhook Slack fonctionnent tous ; le déclencheur provient de votre entrepôt de données, pas d'OpenAI.

La combinaison des plafonds de clés natifs et des alertes basées sur l'entrepôt de données vous offre deux couches de défense. Les plafonds natifs sont un filet de sécurité contre les dépenses catastrophiques. Les alertes de l'entrepôt de données détectent la dérive lente avant que le plafond ne soit atteint.

Techniques avancées et conseils de pro

Une fois le pipeline de base opérationnel, les optimisations suivent.

Mise en cache des invites. GPT-5.5 facture 50 % du taux d'entrée pour les jetons mis en cache. Structurez votre invite système comme un préfixe stable et placez les variables par requête à la fin. Les taux d'accès au cache supérieurs à 70 % sur les charges de travail de chat sont normaux une fois que vous faites cela. Suivez le `cache_hit_rate` par fonctionnalité dans votre tableau de bord afin de pouvoir voir quand une modification d'invite fait chuter votre taux d'accès. La documentation officielle d'OpenAI sur la mise en cache des invites couvre les règles d'éligibilité.

API de traitement par lots pour le travail hors ligne. Tout ce qui n'a pas besoin d'une réponse synchrone passe par l'API Batch pour une réduction de 50 %. Résumé nocturne, exécutions d'évaluation, re-remplissage d'embeddings, re-traitement de documents. Le wrapper de coût s'applique toujours ; appelez le point de terminaison Batch et étiquetez les événements avec `batch_job_id` afin de pouvoir les attribuer à la charge de travail source.

Réglage de l'effort de raisonnement. GPT-5.5 Thinking est le même modèle avec un `reasoning.effort` plus élevé. Chaque niveau d'effort multiplie les jetons de sortie. Auditez vos fonctionnalités : exécutez-vous `medium` là où `low` passerait les barres de qualité ? Exécutez un test A/B, suivez la qualité et le coût, choisissez l'option la moins chère si la qualité se maintient. Pour des calculs plus approfondis, consultez comment utiliser l'API GPT-5.5.

Discipline de la fenêtre de contexte. Les invites longues sont coûteuses. RAG avec un budget de récupération strict est plus efficace que de remplir toute la base de connaissances dans la fenêtre de contexte. Suivez les `prompt_tokens` moyens par fonctionnalité ; si cela augmente de semaine en semaine sans changement de fonctionnalité, votre invite grossit.

Surveillez la limite des 272 000 jetons de GPT-5.5. OpenAI applique un multiplicateur d'entrée de 2x et un multiplicateur de sortie de 1,5x pour les requêtes dépassant 272 000 jetons. Ajoutez une garde dans votre wrapper qui enregistre un avertissement lorsque `prompt_tokens > 250000` afin de pouvoir détecter les invites qui sont sur le point d'atteindre cette limite. Pour les détails de tarification, consultez l'article sur la tarification de GPT-5.5.

Plafonds de dépenses par client. Si vous vendez du B2B et que votre contrat inclut une fonctionnalité basée sur un LLM, vous avez besoin d'un plafond par client. Calculez les dépenses glissantes par `customer_id` à partir de votre entrepôt de données et faites en sorte que votre application le vérifie avant chaque appel. Si le plafond est atteint, renvoyez un 429 avec un message "quota AI mensuel dépassé" et un CTA de facturation. C'est ce qui transforme les fonctionnalités d'IA d'un risque de marge en un produit à marge.

Erreurs courantes à éviter.

• Compter les jetons de raisonnement comme entrée. Ce sont des sorties. Facturez-les au taux de sortie.
• Faire confiance au tableau de bord OpenAI pour les décisions en temps réel. Il y a un décalage. Utilisez votre propre entrepôt de données.
• Étiqueter au niveau du SDK plutôt qu'au site d'appel. Les étiquettes appartiennent à la fonctionnalité, pas au client.
• Oublier d'étiqueter les tâches en arrière-plan. Les tâches Cron, les workers de file d'attente et les webhooks effectuent les mêmes appels OpenAI ; étiquetez-les avec une `route` synthétique comme `cron:nightly-summarize` ou `queue:image-caption`.
• Échantillonnage. N'échantillonnez pas. Enregistrez chaque requête. Le volume de données est trivial ; la précision de l'attribution ne l'est pas.
• Laisser `customer_id` être nul. Si vous ne connaissez pas le client, enregistrez `internal` ou `system`, jamais nul. Nul devient un trou noir d'attribution.

Alternatives et outils

Vous n'avez pas à construire cela vous-même. Voici une comparaison honnête.

Compromis à garder à l'esprit. Un proxy (Helicone) ajoute un saut dans votre chemin critique ; le coût de latence est faible mais réel, et vous dépendez de sa disponibilité. Une pile d'observabilité auto-hébergée (Langfuse) vous donne un contrôle total mais vous l'opérez. Le chemin de l'entrepôt de données personnalisé est ce que la plupart des grandes équipes finissent par adopter ; il s'intègre au reste de votre pile de données, mais vous écrivez vous-même les requêtes et les alertes. L'API d'utilisation native est acceptable si vos besoins sont simples, inutile dès qu'ils ne le sont plus.

Pour une lecture plus approfondie sur ce à quoi ressemble une bonne observabilité des coûts LLM en pratique, le guide de l'équipe Helicone sur le suivi des coûts LLM explique l'approche basée sur proxy. La documentation de Langfuse sur le suivi des coûts couvre la voie open-source.

Si vous exploitez cela à l'échelle de la plateforme, les modèles se généralisent. Voir les plateformes API pour l'architecture de microservices pour savoir comment les wrappers d'attribution des coûts s'intègrent dans une stratégie de maillage de services.

Cas d'utilisation réels

SaaS B2B avec des dépenses LLM par client. Une entreprise vend un produit d'intelligence commerciale. Chaque client déclenche des appels GPT-5.5 lorsqu'il demande un résumé. Sans attribution, l'entreprise sait qu'elle dépense 80 000 $ par mois en OpenAI. Avec une attribution par client, elle apprend que 12 % des clients génèrent 71 % des dépenses. Elle introduit une tarification échelonnée, des quotas souples sur le niveau le plus bas et des frais de dépassement par siège. La marge brute sur la fonctionnalité IA passe de 41 % à 73 % en un trimestre.

Suivi des outils de développement internes. Une organisation d'ingénierie donne à chaque développeur l'accès à un assistant de chat privé GPT-5.5. Grâce à des balises par développeur (`customer_id` devient `dev_email`), l'ingénierie de plateforme constate que trois développeurs représentent 50 % des dépenses internes. Deux d'entre eux exécutent des boucles d'agents automatisées qu'ils ont oublié d'éteindre. Les désactiver permet d'économiser 1 800 $ par mois. Le troisième effectue un travail légitime ; les données justifient un quota à l'échelle de l'organisation plus élevé pour eux.

Prévision des dépenses pour les fonctionnalités d'IA. Une équipe produit souhaite lancer une nouvelle fonctionnalité de résumé. Le chef de produit ne sait pas comment prévoir les coûts. Avec des données historiques par fonctionnalité, l'équipe construit un modèle : jetons d'invite moyens par appel, jetons de sortie moyens, appels attendus par utilisateur actif, utilisateurs actifs attendus. La prévision indique : 0,04 $ par utilisateur actif par jour, soit 1,20 $ par mois. L'équipe de tarification fixe le prix de la fonctionnalité à 5 $ par utilisateur par mois. Les finances donnent leur accord car l'économie unitaire est visible.

Conclusion

Vous ne pouvez pas gérer ce que vous ne pouvez pas mesurer. Le tableau de bord de facturation d'OpenAI répond à une question financière. L'attribution par fonctionnalité, par client, par route répond à la question du produit. Construisez le wrapper, enregistrez l'événement, interrogez l'entrepôt de données, et votre ligne AI cessera d'être un mystère.

Cinq points à retenir :

• Étiquetez chaque requête avec la fonctionnalité, la route, l'ID client et l'environnement. Rendez les étiquettes obligatoires au site d'appel.
• Calculez le coût au moment de l'écriture afin que les données historiques reflètent le taux que vous avez payé ce jour-là.
• Utilisez une clé de projet par environnement et définissez des plafonds stricts dans le tableau de bord OpenAI comme filet de sécurité.
• Superposez des alertes basées sur l'entrepôt de données aux plafonds natifs pour détecter les dérives lentes avant que le plafond ne soit atteint.
• Testez le wrapper avec Apidog avant de le déployer ; de mauvaises étiquettes signifient des erreurs d'attribution silencieuses.
• Auditez trimestriellement l'effort de raisonnement et la taille des invites ; l'optimisation la moins chère est celle qui maintient la qualité constante.
• Suivez le taux d'accès au cache par fonctionnalité afin qu'un changement d'invite ne double pas silencieusement votre coût d'entrée.

Téléchargez Apidog et utilisez-le pour vérifier de bout en bout votre wrapper d'attribution des coûts. Pilotez vos points de terminaison d'IA avec des requêtes étiquetées, affirmez la forme de la charge utile des journaux et rejouez les scénarios dans différents environnements afin que les données auxquelles votre entrepôt de données fait confiance soient les données que vos ingénieurs ont écrites.

Pour des lectures connexes sur la gestion des coûts, consultez la répartition des prix de GPT-5.5 et la facturation de l'utilisation de GitHub Copilot pour les équipes API.

FAQ

Les jetons de raisonnement comptent-ils comme entrée ou sortie pour la facturation ?Les jetons de raisonnement sont facturés au taux de sortie. L'API OpenAI les renvoie sous `usage.completion_tokens_details.reasoning_tokens`. Ajoutez-les aux `completion_tokens` lorsque vous calculez le coût. Pour les multiplicateurs par effort, consultez la répartition des prix de GPT-5.5.

Quelle est la précision de `response.usage` par rapport au tableau de bord OpenAI ?Le nombre de jetons dans `response.usage` correspond au tableau de bord au jeton près. Les changements de prix peuvent entraîner une légère dérive si vous calculez le coût à partir d'une table de taux obsolète ; épinglez le taux par modèle et mettez-le à jour le jour où OpenAI modifie un prix.

Puis-je faire de l'attribution uniquement avec les clés de projet OpenAI ?Les clés de projet vous donnent une dimension d'attribution : par projet. Elles ne vous donnent pas d'attribution par fonctionnalité, par client ou par route. Utilisez les clés de projet pour les divisions par environnement et les plafonds budgétaires ; utilisez les métadonnées au niveau de l'application pour tout le reste.

Qu'en est-il des réessais et des erreurs de limite de débit ? Comptent-ils doublement le coût ?Une requête qui échoue avant l'exécution du modèle (4xx, erreur réseau avant la complétion) ne renvoie pas d'objet `usage`, donc aucun coût n'est enregistré. Une requête qui réussit et est ensuite réessayée au niveau de l'application sera enregistrée deux fois à moins que vous ne réutilisiez le `request_id`. Les réessais idempotents doivent passer le même `request_id` et votre wrapper doit dédupliquer à l'écriture.

À quelle vitesse l'API d'utilisation d'OpenAI renvoie-t-elle les données ?L'API d'utilisation a un décalage de plusieurs dizaines de minutes. Pour les décisions en temps réel (alertes, coupe-circuits), utilisez votre propre entrepôt de données. Pour la réconciliation mensuelle, l'API d'utilisation est adéquate et correspond à votre facture.

Dois-je échantillonner les requêtes pour réduire le volume des journaux ?Non. Le volume de données est faible (une ligne JSON par requête), et l'échantillonnage compromet l'attribution par client et par route. Enregistrez chaque requête.

Puis-je utiliser cette approche pour d'autres fournisseurs de LLM ?Oui. Le schéma se généralise. Ajoutez une colonne `provider` (`openai`, `anthropic`, `google`, `deepseek`) et une table de prix par fournisseur. Le wrapper est spécifique au fournisseur ; l'entrepôt de données et les tableaux de bord ne le sont pas. Pour un point de comparaison, consultez la tarification de l'API DeepSeek V4.

Cela fonctionne-t-il aussi pour les appels d'embeddings et de génération d'images ?Oui, avec des calculs de coûts spécifiques au fournisseur. Les embeddings sont facturés par jeton d'entrée à un taux fixe ; les images sont facturées par image à un taux par résolution. Ajoutez `endpoint` (par exemple `chat`, `embeddings`, `image`) au schéma et branchez votre calcul de coût dessus.