Console de requête TokenLab : déboguez vos appels d'API d'IA depuis un tableau de bord unique

Un appel d'API IA qui échoue ne se signale que rarement de manière explicite. Vous recevez un code d'état, peut-être une chaîne d'erreur, et un canal de support où quelqu'un vous demande « quel était l'ID de la requête ? ». Si vous ne l'avez pas sous la main, l'enquête piétine avant même d'avoir commencé. Nous avons conçu la console de requêtes TokenLab pour combler cette lacune en regroupant les détails au niveau de la requête dans une vue de tableau de bord unique. Elle affiche le modèle, la clé, l'état du cache, l'état de facturation, le timing et un aperçu de la charge utile (payload) expurgé. Dans notre pipeline, nous traitons l'ID de requête comme la clé de recherche principale.

Points clés à retenir

• La console de requêtes TokenLab est une interface de débogage au niveau de la requête située dans le tableau de bord de l'API TokenLab, et non un rapport de facturation.
• Chaque requête possède un ID que vous pouvez rechercher directement. Vous pouvez créer un lien direct vers une requête spécifique avec requestId dans l'URL.
• La console affiche le routage, l'état de facturation, l'état du cache, le contexte du modèle/clé et des aperçus de la charge utile expurgés pour les requêtes récentes.
• L'accès est limité à votre organisation et régi par les autorisations d'adhésion au tableau de bord — les membres de l'équipe voient ce que leur rôle leur permet de voir.
• Pour le débogage d'un incident unique, utilisez la console. Pour une revue des coûts par lots sur des plages temporelles, utilisez plutôt les exports d'utilisation.

Qu'est-ce que la console de requêtes TokenLab ?

Vous y accédez via /dashboard/api?tab=requestConsole, dans la section API du tableau de bord TokenLab. Le tableau de bord de l'API lui-même se trouve à /dashboard/api. La console repose sur un principe simple : lorsqu'une requête échoue, la résolution la plus rapide consiste à avoir son contexte complet sous les yeux, plutôt que de faire des suppositions basées uniquement sur un message d'erreur.

La description du tableau de bord présente la console comme un inspecteur pour les requêtes récentes, couvrant le routage, la facturation, le corps de la requête/réponse et le contexte du fournisseur de modèle. Nous pouvons la diviser en quelques sections de travail.

Vue Liste. Un tableau filtrable des requêtes récentes. C'est là que vous commencez lorsque vous n'avez pas encore d'ID de requête spécifique. Vous scannez les appels échoués ou inhabituels.

Panneau Inspecteur. Une fois que vous sélectionnez une requête, l'inspecteur s'ouvre avec tous les détails : quel modèle a servi la requête, quelle clé API a été utilisée, si elle a atteint le cache et quel était le statut final.

Contexte d'erreur. Si la requête a échoué, la console affiche les informations d'erreur liées à cet appel spécifique. Vous n'avez pas besoin de croiser les données avec un journal d'erreurs séparé.

État du routage et de la facturation. Indique comment la requête a été routée et si elle a été facturée, est en attente, a été remboursée ou a échoué. Ces quatre états sont cruciaux lorsqu'un client demande « ai-je été facturé pour cette erreur ? ».

Aperçu de la charge utile (payload). Les corps des requêtes et des réponses sont affichés sous forme d'aperçus expurgés lorsqu'ils sont disponibles, vous donnant la forme et la structure sans exposer de données sensibles brutes.

Contexte du fournisseur de modèle et de la clé de modèle. Quel fournisseur et quel modèle spécifique ont traité l'appel. C'est utile lorsque vous exécutez plusieurs modèles derrière une seule intégration et que vous devez confirmer que le bon a été invoqué.

Rien de tout cela ne nécessite de construire votre propre pipeline de journalisation par-dessus l'API. Tout est déjà exposé par organisation, filtré par les autorisations d'adhésion au tableau de bord, afin que les membres de l'équipe ayant les accès appropriés voient les mêmes données de requête que vous.

Que vérifier en premier ?

Lorsqu'un appel d'API échoue, il existe un ordre logique pour vérifier les choses. Sauter directement à « le modèle est-il en panne » avant de confirmer que la requête a bien atteint le bon point de terminaison est une perte de temps.

Le triage en cinq champs

Vérification	Ce qu'elle vous indique
ID de requête	Confirme que vous regardez l'appel exact en question, et non un appel similaire
Statut	Facturé, en attente, remboursé ou échoué — vous indique s'il s'agit d'une question de coût ou d'un problème technique
Modèle	Quel modèle a réellement servi la requête (utile si vous routez vers plusieurs modèles)
État du cache	Si un hit ou un miss du cache de prompt a modifié le coût ou la latence
Source de la clé	Quelle clé API a été utilisée, utile lorsque plusieurs clés ou environnements partagent une intégration

Commencez par l'ID de requête. Si vous l'avez obtenu à partir d'un journal côté client, d'un ticket de support ou d'un rapport d'erreur, utilisez le modèle de lien direct :

/dashboard/api?tab=requestConsole&requestId=%3Crequest_id>

Cela ouvre l'inspecteur directement sur la requête en question, en ignorant complètement la vue liste. C'est le chemin le plus rapide lorsqu'une personne vous donne un ID et demande « que s'est-il passé ici ? ».

Si vous n'avez pas encore d'ID de requête, les filtres de la console vous permettent de restreindre la recherche par modèle, plage horaire, état du cache de prompt, source de la clé et statut. Par exemple, lorsqu'une requête échoue, filtrez par statut « échoué » au cours de la dernière heure, puis scannez la liste pour trouver l'appel spécifique sur lequel un utilisateur s'interroge.

Lire correctement le champ de statut

Les quatre états — facturé, en attente, remboursé, échoué — répondent à des questions différentes :

• Facturé signifie que l'appel a été complété et a consommé des crédits. Si un utilisateur signale une erreur mais que la requête apparaît comme facturée, cela mérite d'être signalé séparément. Cela suggère que l'échec s'est produit côté client après une réponse réussie.
• En attente signifie que la requête est toujours en cours ou en attente de règlement. Ne considérez pas cela comme un échec prématurément.
• Remboursé signifie que TokenLab a annulé la charge, généralement lié à un échec du côté du fournisseur ou du routage.
• Échoué signifie que l'appel ne s'est pas terminé avec succès et n'a pas été facturé.

Savoir lequel de ces états s'applique avant d'escalader le problème vous évite des allers-retours inutiles avec le support.

Confirmer le modèle et l'état du cache

Si vous exécutez des requêtes sur des modèles comme Claude Sonnet 5, DeepSeek V4 Pro ou Gemini 3.5 Flash via une intégration partagée, confirmez que la console affiche le modèle attendu. Un client mal configuré, une variable d'environnement obsolète ou une surcharge de routage peut envoyer du trafic vers le mauvais modèle sans erreur évidente côté client.

L'état du cache est important pour deux raisons : le coût et la latence. Un miss du cache alors que vous attendiez un hit signifie généralement que le préfixe du prompt a changé, même subtilement. Recherchez un horodatage, un champ réordonné ou un caractère d'espacement supplémentaire. Le filtre d'état du cache de la console vous permet de comparer les requêtes « hit » et « miss » côte à côte.

Comment la console de requêtes TokenLab fonctionne avec les exports d'utilisation

La console de requêtes et les exports d'utilisation résolvent des problèmes différents, il est donc utile d'être explicite sur la limite. La console est conçue pour l'investigation d'une requête unique : un appel, une erreur, une question de facturation, résolus dans le panneau de l'inspecteur. C'est ce que vous ouvrez lorsqu'une requête spécifique échoue et que vous avez besoin de savoir pourquoi, immédiatement.

Les exports d'utilisation sont conçus pour une revue globale : dépenses sur une plage temporelle, ventilations par modèle ou par clé, et le type de rapport que vous remettriez à un responsable financier ou utiliseriez pour un rapprochement mensuel. Si vous voulez répondre à « combien avons-nous dépensé pour DeepSeek V4 Pro la semaine dernière », c'est une question d'export, pas une question de console. Consultez le guide des exports d'utilisation du tableau de bord TokenLab pour ce flux de travail.

En résumé : la console pour les incidents, les exports pour les totaux. Certaines équipes utilisent les deux en séquence. Un export révèle une anomalie dans les dépenses globales, et la console est l'endroit où vous creusez les requêtes spécifiques qui l'ont causée.

Une routine de débogage pratique

Le débogage ad hoc se transforme en conjectures sous la pression. Une routine répétable empêche les incidents de durer plus longtemps que nécessaire.

Checklist : lorsqu'une requête échoue

1. Obtenez l'ID de la requête. Depuis vos journaux client, la réponse d'erreur ou un rapport d'utilisateur. Si vous ne journalisez pas les ID de requête de votre côté aujourd'hui, commencez maintenant. C'est la clé de recherche la plus rapide dont vous disposez.
2. Ouvrez la console avec le lien direct. Utilisez le paramètre de requête requestId pour accéder directement à l'inspecteur.
3. Vérifiez d'abord le champ de statut. Facturé, en attente, remboursé ou échoué. Cela cadre le reste de l'investigation.
4. Confirmez le modèle qui a réellement servi la requête. Comparez-le avec ce que vous pensiez envoyer.
5. Vérifiez l'état du cache. Un miss du cache alors que vous attendiez un hit peut expliquer une latence ou un coût inattendu.
6. Vérifiez la source de la clé. Confirmez que la bonne clé API et le bon environnement étaient utilisés, surtout dans les configurations staging-vs-production.
7. Lisez le contexte de l'erreur et les informations de routage. C'est généralement là que la cause profonde devient visible.
8. Examinez l'aperçu de la charge utile expurgé. Confirmez que la forme de la requête correspond à ce que votre client a envoyé. Les paramètres mal formés apparaissent souvent ici avant d'apparaître ailleurs.
9. Croisez avec la référence de l'API si nécessaire. La référence de l'API de complétion de chat TokenLab sur https://docs.tokenlab.sh/api-reference/chat/create-completion documente les formes de requête et de réponse attendues. Utilisez-la pour confirmer si une charge utile était mal formée côté client.
10. S'il s'agit d'un modèle (répétition) et non d'un cas isolé, passez aux exports d'utilisation. Une seule requête échouée est un problème de console. Dix requêtes échouées sur une heure constituent un modèle qui mérite d'être exporté et examiné globalement.

Suivre cet ordre — ID, statut, modèle, cache, clé, erreur, charge utile — vous évite de passer à côté du champ qui explique réellement l'échec.

FAQ

Comment trouver une requête échouée sans ID de requête ?

Utilisez les filtres de la vue liste dans la console de requêtes TokenLab. Restreignez par modèle, plage horaire, état du cache de prompt, source de la clé et statut. Par exemple, filtrez par statut « échoué » au cours de la dernière heure, puis scannez l'appel sur lequel un utilisateur s'interroge. Une fois trouvé, ouvrez l'inspecteur et copiez l'ID de requête pour les futurs journaux.

Pourquoi une requête apparaît-elle comme facturée alors que le client signale une erreur ?

Facturé signifie que l'appel a été complété et a consommé des crédits. Si un utilisateur signale une erreur mais que la requête apparaît comme facturée, l'échec s'est probablement produit côté client après une réponse réussie. Signalez ce cas séparément car il pointe vers un chemin de correction différent de celui d'une requête échouée ou remboursée.

Que m'indique un miss du cache dans l'inspecteur ?

Un miss du cache signifie que la requête n'a pas atteint le cache de prompt. Cela compte pour le coût et la latence. Un miss alors que vous attendiez un hit signifie généralement que le préfixe du prompt a changé, même subtilement. Vérifiez s'il y a un horodatage, un champ réordonné ou un caractère d'espacement supplémentaire.

Puis-je partager un lien de requête avec un membre de l'équipe ?

Oui, si ses autorisations d'adhésion au tableau de bord le permettent. Les données de requête sont limitées à votre organisation. Utilisez le format de lien direct /dashboard/api?tab=requestConsole&requestId=<request_id> pour ouvrir directement l'inspecteur. Les membres de l'équipe voient ce que leur rôle leur permet de voir.

Quand dois-je passer de la console aux exports d'utilisation ?

Passez-y lorsque le problème est un modèle (répétition), pas un cas isolé. Une seule requête échouée est un problème de console. Dix requêtes échouées sur une heure constituent un modèle qui mérite d'être exporté et examiné globalement. Utilisez les exports pour les dépenses sur une plage temporelle, les ventilations par modèle ou par clé, et le rapprochement mensuel.

Sources et fraîcheur

• Console de requêtes TokenLab — /dashboard/api?tab=requestConsole — observé le 09/07/2026
• Référence de l'API de complétion de chat TokenLab — https://docs.tokenlab.sh/api-reference/chat/create-completion — observé le 09/07/2026
• Exports d'utilisation du tableau de bord TokenLab — /blog/tokenlab-dashboard-usage-exports — observé le 09/07/2026
• Répertoire public des modèles TokenLab — /models — observé le 09/07/2026
• Tableau de bord des clés API TokenLab — /dashboard/api — observé le 09/07/2026

Les exemples de modèles référencés (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) reflètent la SSOT (Source unique de vérité) actuelle des modèles au 19/09/2026. L'instantané source pour cette note de console a été observé le 09/07/2026 ; la date originale de la SSOT des modèles dans la source était le 07/07/2026.

Étapes suivantes

Si vous déboguez actuellement les échecs d'API IA en cherchant dans les journaux côté client et en croisant avec un tableau de bord de facturation séparé, la console de requêtes supprime une étape de cette boucle. La console se trouve à /dashboard/api?tab=requestConsole. Le tableau de bord des clés API est à tokenlab.sh/dashboard/api. La forme de requête/réponse des complétions de chat est documentée à https://docs.tokenlab.sh/api-reference/chat/create-completion. Pour une revue des dépenses globales, utilisez les exports d'utilisation. Pour les détails sur la tarification des modèles et les fenêtres de contexte, consultez le répertoire des modèles. Ouvrez la console et localisez une requête échouée récente par son ID.