L’observabilité de l’API d’IA est ce qui permet à une équipe d’ingénierie de reconstituer un incident de routage d’un modèle sans deviner. Un utilisateur signale un timeout, un modèle de secours répond différemment, un fournisseur renvoie 429, ou les dépenses augmentent après un changement en amont. L’analyse d’incident nécessite plus qu’un simple prompt brut et un code d’état. Elle a besoin d’un enregistrement de journal qui montre la requête, la route, la chaîne de nouvelles tentatives, le modèle sélectionné, le profil de latence, l’utilisation, le coût et les contrôles de confidentialité autour de ce qui a été stocké.
Ce guide est une liste de contrôle au niveau des champs pour les journaux d’observabilité de l’API d’IA dans les incidents de routage. Il est rédigé pour les équipes utilisant une passerelle IA, un routeur multi-fournisseurs ou une couche de compatibilité, où une requête applicative peut passer par plusieurs chemins amont possibles. L’objectif n’est pas de stocker indéfiniment chaque prompt. L’objectif est de conserver suffisamment de métadonnées pour prouver ce qui s’est passé tout en gardant sous contrôle les entrées sensibles, les sorties, les arguments des outils et les identifiants clients.
Flatkey convient à ce problème parce que sa communication produit publique se concentre sur une clé API unique, une URL de base compatible avec OpenAI à https://router.flatkey.ai/v1, une facturation unifiée et un tableau de bord unique pour les clés, l’utilisation et le routage. Flatkey évoque aussi le basculement automatique et l’équilibrage de charge entre les comptes amont. Ce sont des fonctionnalités de fiabilité utiles uniquement lorsque les journaux peuvent répondre à une question de routage a posteriori.
L’observabilité des API d’IA commence par les questions d’incident
Avant de choisir des champs, définissez les questions auxquelles le responsable d’incident doit répondre. Pour le routage des modèles, l’observabilité des API d’IA devrait permettre de répondre à ces questions à partir d’un seul enregistrement de requête ou d’une trace corrélée :
- Quelle application, quel environnement, quelle équipe, quelle clé, quel workflow et quel responsable sûr pour les clients a envoyé la requête ?
- Quelle famille d’endpoint, quel modèle demandé, quelle politique de routage et quelle règle de secours s’appliquaient au moment de la requête ?
- Quel fournisseur, quel modèle, quel compte amont ou quel itinéraire a réellement servi la réponse ?
- La requête a-t-elle été retentée, basculée, limitée, mise en file d’attente, bloquée ou abandonnée ?
- Quel code de statut, quelle classe d’erreur du fournisseur, quel en-tête de limitation de débit, quel délai d’attente ou quel événement de flux a modifié le résultat ?
- Combien de jetons d’entrée, de sortie, mis en cache et de raisonnement ont été comptabilisés, et combien a coûté l’itinéraire ?
- Les contrôles de confidentialité ont-ils stocké les charges utiles brutes, les charges utiles masquées, uniquement les métadonnées ou aucune entrée de journal ?
Si un journal ne peut pas répondre à ces questions, l’équipe comblera l’écart avec la mémoire de Slack, des captures d’écran et des tickets d’assistance du fournisseur. Cela ralentit la résolution et rend les futurs changements d’itinéraire plus difficiles à fiabiliser.
La liste de contrôle du journal d’incident de routage de modèle
Le tableau ci-dessous est l’élément central d’observabilité de l’API d’IA pour cet article. Utilisez-le comme liste de contrôle d’implémentation pour les journaux d’API LLM, les journaux de passerelle ou les événements de l’entrepôt de données.
| Groupe de champs | Champs à capturer | Pourquoi c’est important lors d’un incident de routage | Remarque sur la confidentialité |
|---|---|---|---|
| Identifiants de corrélation | ID de requête d’application, X-Client-Request-Id, x-request-id du fournisseur, traceparent W3C, ID du journal de passerelle, ID d’événement. |
Relie l’erreur visible par l’utilisateur, la décision de la passerelle, la requête du fournisseur, le span de trace et le ticket d’assistance. | Utilisez des ID opaques. N’encodez pas l’e-mail, l’IP, le nom du locataire ou le texte du prompt dans les champs de trace. |
| Locataire et propriétaire | Projet, environnement, ID ou hachage de clé API, équipe, workflow, ID de compte sécurisé pour le client, centre de coûts. | Indique qui a été affecté et qui est propriétaire du quota, du coût et de la remédiation. | Privilégiez des ID internes stables plutôt que les noms bruts des clients ou les e-mails des utilisateurs. |
| Route demandée | Famille de point de terminaison, modèle demandé, préférence de fournisseur, politique de routage, politique de repli, version de l’alias du modèle, version du catalogue/tarification. | Reconstitue ce que le client a demandé et ce que le routeur était autorisé à faire à ce moment-là. | Gardez les prompts hors de l’objet de routage, sauf si un mode de débogage approuvé séparément est actif. |
| Route sélectionnée | Fournisseur final, modèle final, compte ou canal en amont, région le cas échéant, raison de la décision de routage, ID de règle de politique. | Prouve si le modèle principal a servi la réponse ou si un chemin de repli a modifié le comportement ou le coût. | Les identifiants de compte doivent être des références internes, pas des secrets du fournisseur ni des identifiants complets. |
| Chaîne de retry et de repli | Index de tentative, nombre de retries, fournisseur/modèle précédent, classe d’échec, code d’état, cible de repli, résultat final. | Empêche les retries à l’aveugle et montre si l’échelle de basculement a fonctionné comme prévu. | Stockez la classe d’erreur et des extraits sûrs. Évitez de stocker les corps d’erreur complets du fournisseur s’ils peuvent refléter le contenu du prompt. |
| Latence et streaming | Heure de début de la requête, durée de la passerelle, durée du fournisseur, délai jusqu’au premier token/fragment, stream démarré, stream terminé, raison de l’abandon, déconnexion du client. | Sépare la latence du fournisseur, le temps de routage de la passerelle, le blocage du streaming et l’annulation côté client. | Les fragments de streaming sont du contenu. Journalisez les métadonnées de timing par défaut et le contenu uniquement sous un mode de débogage régi. |
| Utilisation et coût | Tokens d’entrée, tokens de sortie, tokens mis en cache, tokens de raisonnement, unités image/vidéo le cas échéant, nombre de requêtes, ligne de poste, coût estimé ou final. | Explique l’impact budgétaire lorsque le repli transfère le trafic vers un autre fournisseur, modèle ou niveau de service. | Agrégez par clé, workflow et équipe pour les tableaux de bord normaux ; restreignez les vues par utilisateur. |
| Forme de la réponse | Raison de fin, ID/noms d’appel d’outil, type de sortie, statut de réponse, détails de troncature ou d’incomplétude, niveau de service. | Montre si le modèle s’est arrêté normalement, a appelé un outil, a atteint une limite ou a renvoyé une réponse incomplète. | Les arguments d’outil et les résultats d’outil peuvent contenir des données sensibles. Stockez les ID et les noms par défaut. |
| Erreurs et limites de débit | Statut HTTP, code d’erreur du fournisseur, classe de délai d’attente, retry-after, en-têtes de requête restants/limite/réinitialisation, en-têtes de jetons restants/limite/réinitialisation. | Distingue les mauvaises requêtes, les échecs d’authentification, les incidents fournisseur, l’épuisement du quota et les tempêtes de limitation de débit. | Normalisez les erreurs du fournisseur en classes sûres avant de les placer dans des outils d’analytique larges. |
| Gouvernance et conservation | Action DLP, ID de politique, mode de journalisation du contenu, indicateur de redaction, hachage de charge utile, classe de conservation, éligibilité à la suppression. | Permet à la sécurité et à la conformité de vérifier pourquoi le contenu a été stocké, masqué, bloqué ou exclu. | Par défaut, privilégiez des journaux contenant uniquement les métadonnées lorsque le contenu brut n’est pas requis pour un workflow défini d’assistance ou d’audit. |
Capturez les ID avant de déboguer le fournisseur
La première mission de l’observabilité de l’API d’IA est la corrélation. La documentation de référence de l’API d’OpenAI recommande de consigner les ID de requête en production et documente à la fois les valeurs x-request-id générées par le fournisseur et les valeurs X-Client-Request-Id fournies par l’appelant. Ce dernier point est important lorsqu’un délai d’attente ou une panne réseau empêche votre client de recevoir les en-têtes de réponse du fournisseur.
Pour une passerelle, ajoutez une couche supplémentaire : un ID de requête de passerelle qui survit aux réessais internes et aux mécanismes de secours. Si une requête d’utilisateur tente d’abord le fournisseur A, puis le fournisseur B, et enfin un modèle de secours, l’ID de passerelle doit relier tous les essais entre eux. L’ID de requête du fournisseur doit rester spécifique à chaque tentative. L’ID de trace doit relier cet appel d’IA au reste de la requête de l’application.
W3C Trace Context définit traceparent et tracestate pour propager le contexte de trace distribué entre les services. Utilisez ces en-têtes pour la corrélation des traces, et non pour l’identité du client. La section sur la confidentialité du W3C est explicite : les champs de traçage ne doivent pas contenir d’informations personnellement identifiables ni d’autres informations sensibles.
Consignez séparément la route demandée et la route sélectionnée
Une erreur courante dans la surveillance des passerelles IA consiste à ne journaliser que le fournisseur et le modèle finaux. Cela fait perdre la preuve de routage la plus importante : ce que le client a demandé et ce que la politique a autorisé avant que la passerelle ne prenne une décision.
Conservez ces deux objets séparés :
- Route demandée : famille de point de terminaison, modèle ou alias demandé, politique de routage, préférence de fournisseur, politique de repli, version du catalogue, version des prix et mode de requête tel que streaming ou batch.
- Route sélectionnée : fournisseur final, modèle final, compte ou canal amont, région le cas échéant, raison de la décision de routage et ID de règle de politique.
Cette séparation compte lorsqu’une réponse de repli est valide mais surprenante. Si la route demandée était chat/completions avec le streaming activé, et que la route sélectionnée a basculé vers un autre modèle après un délai d’attente, l’analyse de l’incident peut voir à la fois le chemin prévu et le chemin réellement emprunté. Elle aide aussi les équipes financières à comprendre pourquoi l’utilisation est apparue sous un modèle ou une ligne budgétaire différente.
Les acheteurs de Flatkey devraient appliquer le même schéma d’évaluation. Commencez par la liste de contrôle des exigences d’une passerelle API IA, puis utilisez le guide de playbook sur l’équilibrage de charge et le basculement pour définir quelles modifications de route sont autorisées avant d’examiner les journaux.
Enregistrer la chaîne de retry et de repli
Les retries sont l’endroit où des journaux incomplets deviennent coûteux. Si les seuls champs stockés sont le statut final et le modèle final, l’équipe ne peut pas savoir si une requête a abouti au premier essai, après un retry, ou après cinq tentatives sur plusieurs fournisseurs. Une observabilité des API IA de niveau incident traite le retry et le fallback comme une chaîne.
Chaque tentative devrait inclure :
- Indice de tentative et ID de requête parent du gateway.
- Fournisseur, modèle, compte amont et famille d’endpoint pour cette tentative.
- Heure de début, durée, classe de timeout et état du streaming.
- Code de statut, classe d’erreur du fournisseur, ID de requête du fournisseur et métadonnées de limite de débit.
- Cible de repli et raison de la décision lorsque la tentative ne met pas fin à la chaîne.
Cette chaîne empêche le gateway de masquer les véritables modes de défaillance. Une requête mal formée doit échouer de manière fermée, sans passer d’un fournisseur à l’autre. Une erreur 500 du fournisseur peut justifier un retry. Une limite de quota peut basculer vers un compte amont approuvé. Une incompatibilité de modèle visible par le client peut nécessiter une erreur contrôlée plutôt qu’un repli silencieux.
Mesurer la latence pour les flux, pas seulement pour les appels terminés
Les réponses en streaming nécessitent plus que la durée totale. La documentation d’observabilité de Vercel AI Gateway souligne le time to first token, la durée de la requête, le nombre de tokens et les dépenses comme métriques de passerelle. Les conventions sémantiques GenAI d’OpenTelemetry incluent gen_ai.response.time_to_first_chunk et gen_ai.request.stream. Ces champs sont utiles parce que de nombreux incidents de routage sont des incidents de streaming : le fournisseur a accepté la requête, le premier chunk est arrivé en retard, le flux s’est bloqué ou le client s’est déconnecté.
Au minimum, consignez l’heure de début de la requête, la durée de la passerelle, la durée du fournisseur, le time to first token ou chunk, l’indicateur de début de flux, l’indicateur de flux terminé, la raison de l’abandon et l’état de déconnexion du client. Pour les réponses non diffusées en streaming, les mêmes champs peuvent rester nuls ou faux. Cela permet de conserver un seul schéma pour Chat Completions, Responses et les familles d’API spécifiques aux fournisseurs.
Ne stockez pas les chunks du flux par défaut. Les chunks du flux sont du contenu de réponse, et le contenu de réponse peut inclure des données utilisateur, du contexte récupéré, des résultats d’outils ou des informations réglementées. Pour une observabilité d’API IA normale, les métadonnées de timing suffisent généralement à diagnostiquer un blocage.
Connecter l’usage et le coût à la décision de routage
L’usage et le coût relèvent des incidents, pas seulement des équipes financières. Les exemples de l’API Responses d’OpenAI incluent l’usage des jetons d’entrée, de sortie, mis en cache, de raisonnement et total. Le point de terminaison d’usage de l’organisation d’OpenAI prend en charge le regroupement par projet, utilisateur, clé API, modèle, lot et niveau de service ; le point de terminaison des coûts prend en charge le regroupement par projet, ligne de facturation et clé API. La documentation de l’AI Gateway de Vercel décrit de la même manière des résumés de requêtes par projet et clé API, les décomptes de jetons, la durée P75, le TTFT P75 et le coût.
Pour l’observabilité des API d’IA, capturez l’usage et le coût au niveau de la tentative lorsque c’est possible, et toujours au niveau de la requête finale. Un repli peut être opérationnellement correct et financièrement surprenant. Sans le modèle, la route, l’usage et le coût dans le même événement, la finance peut constater une hausse des dépenses avant que l’ingénierie ne puisse l’expliquer.
La tarification publique de Flatkey et le texte de sa page d’accueil mettent en avant une tarification claire, une facturation unifiée, des analyses d’usage et un tableau de bord pour les clés, l’usage et le routage. Un instantané de tarification du 18 juin 2026 enregistré pour cette tâche a renvoyé 638 lignes de modèles, 23 fournisseurs et des familles de points de terminaison incluant OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, Gemini generateContent, la génération d’images et OpenAI video. Considérez ces chiffres comme des preuves datées, puis vérifiez la page de tarification en direct et les enregistrements du tableau de bord pour les modèles spécifiques de votre flux de travail.
Utiliser l’enregistrement en métadonnées uniquement par défaut
Les invites et réponses brutes sont de puissants outils de débogage, mais ce sont aussi des journaux risqués. La documentation de journalisation d’AI Gateway de Cloudflare constitue un modèle de référence utile : elle décrit des journaux de requêtes avec l’invite, la réponse, le fournisseur, l’horodatage, le statut, l’utilisation des jetons, le coût, la durée et l’agent utilisateur, et elle documente également un en-tête qui peut empêcher le stockage du contenu brut des requêtes et des réponses tout en conservant des métadonnées telles que le nombre de jetons, le modèle, le fournisseur, le code de statut, le coût et la durée.
C’est la bonne posture par défaut pour les journaux d’API LLM : collecter les métadonnées par défaut, puis exiger un mode de débogage explicite ou un processus de support avant que le contenu brut ne soit stocké. Les conventions sémantiques OpenTelemetry GenAI indiquent les messages d’entrée, les messages de sortie, les instructions système, les arguments d’appel d’outil et les résultats d’appel d’outil comme des champs pouvant contenir des informations sensibles. Votre politique de journalisation doit en tenir compte.
Une politique pratique comporte quatre modes :
- Pas de journal : utilisé pour les requêtes qui ne doivent pas être conservées au-delà du traitement transitoire.
- Métadonnées uniquement : route, identifiants, latence, statut, utilisation, coût et indicateurs de masquage.
- Charge utile masquée : champs de requête/réponse sélectionnés après suppression des données personnelles et des secrets.
- Charge utile brute : capture de débogage de courte durée, contrôlée par des accès, pour un incident spécifique ou un cas de support approuvé par le client.
Exemple d’événement de journal de routage
Ce modèle est intentionnellement axé d’abord sur les métadonnées. Adaptez les noms à votre système de journalisation, mais conservez la séparation entre le route demandée, la route sélectionnée, les tentatives, l’utilisation, le coût et les contrôles de confidentialité.
{
"gateway_request_id": "gw_01jz_route_abc",
"app_request_id": "req_9a7c",
"traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
"client_request_id": "7c2c1b3a-4b55-4e36-bd47-8d1c2e2f2e11",
"owner": {
"project": "checkout-ai",
"environment": "production",
"api_key_id": "key_hash_6f12",
"team": "platform",
"workflow": "customer-chat"
},
"requested_route": {
"endpoint_family": "chat_completions",
"model": "primary-chat-model",
"stream": true,
"route_policy_id": "chat-prod-v8",
"fallback_policy_id": "chat-prod-safe-fallback-v3",
"catalog_version": "2026-06-18"
},
"selected_route": {
"provider": "provider_b",
"model": "backup-chat-model",
"upstream_account": "acct_pool_2",
"decision_reason": "primary_timeout",
"policy_rule_id": "fallback_on_timeout_once"
},
"attempts": [
{
"index": 1,
"provider": "provider_a",
"model": "primary-chat-model",
"provider_request_id": "req_provider_a_123",
"status_code": 504,
"error_class": "timeout",
"duration_ms": 12000,
"fallback_target": "provider_b"
},
{
"index": 2,
"provider": "provider_b",
"model": "backup-chat-model",
"provider_request_id": "req_provider_b_456",
"status_code": 200,
"duration_ms": 2400,
"time_to_first_chunk_ms": 620,
"finish_reason": "stop"
}
],
"usage": {
"input_tokens": 1284,
"output_tokens": 312,
"cached_input_tokens": 0,
"reasoning_output_tokens": 0
},
"cost": {
"currency": "usd",
"estimated_amount": 0.0048,
"line_item": "backup-chat-model"
},
"privacy": {
"content_logging_mode": "metadata_only",
"payload_redacted": true,
"retention_class": "30_day_incident_metadata"
}
}Les noms de champs sont des exemples, et non un contrat d’API Flatkey. Utilisez-les pour tester si votre passerelle, votre entrepôt de données et vos outils d’incident peuvent répondre aux questions de routage sans avoir besoin du contenu brut.
Un flux de triage en 10 minutes
Lorsqu’un incident de routage de modèle commence, le flux de observabilité de l’API IA doit être suffisamment court pour que l’ingénieur d’astreinte puisse l’exécuter sous pression :
- Trouver la requête corrélée : rechercher par ID de requête d’application, ID de requête de passerelle, ID d’erreur visible par l’utilisateur, ID de requête du fournisseur ou ID de trace.
- Comparer les routes demandées et sélectionnées : confirmer le modèle demandé, la politique de routage, la règle de repli, le fournisseur final et le modèle final.
- Lire la chaîne des tentatives : identifier la première défaillance, le nombre de nouvelles tentatives, la cible de repli et le résultat final.
- Vérifier le contexte de limite de débit et de quota : inspecter les en-têtes de reste, de limite et de réinitialisation lorsque les fournisseurs renvoient un 429 ou une pression sur les jetons.
- Séparer la latence du streaming : comparer la durée de la passerelle, la durée du fournisseur, le temps jusqu’au premier bloc, la fin du flux et la déconnexion du client.
- Réconcilier l’utilisation et le coût : examiner les décomptes de jetons, le niveau de service, la ligne de coût et la propriété de l’équipe/de la clé.
- Examiner le mode de confidentialité : confirmer si le journal est limité aux métadonnées, caviardé, brut ou intentionnellement omis.
- Décider de l’action de routage : revenir en arrière sur la politique, désactiver une route, réduire le poids du trafic, augmenter le quota, mettre le travail en arrière-plan en file d’attente ou échouer de manière fermée.
Après l’incident, transformez les mêmes étapes en vue tableau de bord. Les révisions les plus rapides se produisent lorsque l’ingénierie, le support et la finance peuvent inspecter la même forme d’événement.
Comment Flatkey s’intègre à l’observabilité des API IA
Flatkey est conçu pour les équipes qui veulent une seule clé API, un seul endpoint de routage compatible, une tarification claire, une facturation unifiée et un seul tableau de bord pour les clés, l’utilisation et le routage. Pour cet article, le chemin de preuve pertinent est pratique : pointez un client de staging vers https://router.flatkey.ai/v1, envoyez des requêtes via une clé hors production, déclenchez une défaillance contrôlée lorsque c’est possible, et vérifiez quelles données d’utilisation, de routage, d’erreur et de coût apparaissent dans le tableau de bord.
Utilisez le suivi de l’utilisation de l’IA par clé pour séparer le trafic de staging, de production, des clients et des workflows. Utilisez la gestion des quotas des API IA pour éviter que le basculement n’épuise le budget partagé. Utilisez l’attribution des coûts des API IA par équipe lorsque les changements de routage nécessitent un responsable financier.
L’appel à l’action est simple : si votre équipe souhaite tester l’observabilité des API IA derrière une seule clé, obtenez une clé, exécutez une route de staging via Flatkey, et vérifiez si les journaux répondent aux questions de l’incident ci-dessus avant de vous appuyer sur le basculement automatique en production.
Questions fréquentes
Qu’est-ce que l’observabilité d’une API IA ?
L’observabilité d’une API IA est la capacité d’inspecter le trafic des API de modèles à travers les identifiants de requête, les traces, les modèles, les fournisseurs, les décisions de routage, les tentatives de पुनessai, les mécanismes de repli, l’utilisation, le coût, la latence, les erreurs et les contrôles de confidentialité. Pour les incidents de routage, elle doit expliquer à la fois ce que le client a demandé et ce que la passerelle a réellement sélectionné.
Que doivent capturer les journaux d’une API LLM ?
Les journaux d’API LLM doivent capturer les identifiants de corrélation, les métadonnées du propriétaire, la route demandée, la route sélectionnée, la chaîne de tentatives, la latence, l’état du streaming, l’utilisation des jetons, le coût, la raison de fin, la classe d’erreur, le contexte de limitation de débit et le mode de journalisation du contenu. Les prompts et les sorties bruts doivent être facultatifs, soumis à contrôle d’accès et expurgés lorsque c’est possible.
Pourquoi enregistrer séparément le modèle demandé et le modèle de réponse ?
Le modèle demandé montre l’intention du client. Le modèle de réponse montre ce qui a réellement servi la requête. Lors d’un incident de repli, ces éléments peuvent différer. Enregistrer les deux est essentiel pour l’examen de la qualité, la réconciliation des coûts et la communication avec le support.
Comment les identifiants de requête aident-ils le support du fournisseur ?
Les identifiants de requête du fournisseur identifient l’appel API en amont. Un identifiant de requête fourni par l’appelant peut aider lorsqu’un timeout empêche l’en-tête de réponse d’atteindre votre client. Conservez les deux identifiants dans l’enregistrement de l’incident, ainsi que l’identifiant de requête de la passerelle et l’identifiant de trace.
La surveillance de la passerelle IA doit-elle stocker les prompts bruts ?
Pas par défaut. La surveillance de la passerelle IA a généralement besoin d’abord de métadonnées : route, modèle, statut, durée, utilisation, coût et mode de confidentialité. Ne stockez les prompts ou réponses bruts que dans le cadre d’un flux de travail défini de débogage, de support ou d’audit, avec des règles de rétention et des contrôles d’accès.
Sources utilisées
- Vue d’ensemble de l’API OpenAI : débogage des requêtes et des identifiants de requête
- Référence de l’API Chat Completions d’OpenAI et référence de l’API Responses
- Référence de l’API OpenAI sur l’utilisation et les coûts de l’organisation
- Documentation de journalisation de Cloudflare AI Gateway
- Documentation d’observabilité de Vercel AI Gateway
- Recommandation W3C Trace Context
- Attributs de convention sémantique GenAI d’OpenTelemetry
Vérification finale avant de modifier le routage
Avant de faire confiance au basculement automatique, faites de l’observabilité des API d’IA une partie du jalon de mise en production. Confirmez la politique de routage, la hiérarchie de retry, les champs de jetons et de coûts, les en-têtes de limitation de débit, les horodatages de flux, les ID de requête du fournisseur, le mode de confidentialité et la classe de conservation. Lancez ensuite un incident contrôlé en préproduction et vérifiez que les journaux peuvent expliquer le résultat sans accès brut aux prompts.
Flatkey réduit la surface d’intégration à une seule clé et une seule URL de base compatible. Pour évaluer cette couche de fiabilité avec votre propre trafic, obtenez une clé, exécutez un workflow de préproduction et examinez les enregistrements de routage, d’utilisation, de coût et d’erreur dont votre équipe aura besoin lors d’un incident réel.
