Une console unique pour le codage et les applications d'IA : ce qui a changé et comment l'utiliser

La console TokenLab a cessé de nous donner l'impression d'être un simple tableau de bord lorsque le mode assistant de codage et le mode application IA ont fusionné en une seule surface de travail. Dans notre pipeline, la requête, la réponse et l'état du compte associé sont désormais regroupés. Cela supprime un changement de contexte à chaque session et modifie notre façon de lire une réponse lente.

Points clés à retenir

• Le mode assistant de codage et le mode application IA cohabitent désormais dans la console TokenLab ; les deux anciens points d'entrée y ont été fusionnés.
• Les liens existants fonctionnent toujours et les conversations précédentes sont conservées. Il n'y a rien à migrer manuellement.
• Les réponses sont diffusées en streaming au fur et à mesure que le modèle les génère, au lieu d'apparaître uniquement à la fin. L'interface affiche le temps du premier token.
• La latence du premier token est un signal de requête enregistré (ttft_ms dans le journal des requêtes), et non une simple décoration de l'interface.
• Lorsque le solde devient faible au milieu d'une conversation, l'option de rechargement se trouve à côté de la conversation plutôt que sur une page de facturation séparée.
• Le choix du modèle dans la console suit le catalogue public ; consultez le répertoire des modèles pour connaître les options actuelles. Les exemples du catalogue actuel incluent Claude Sonnet 5 et DeepSeek V4 Pro.

Ce qui a changé dans la console TokenLab et ce qui n'a pas changé

Le changement a été déployé via deux entrées de journal des modifications. La convergence de la console (2026-08-04) a déplacé les deux anciens points d'entrée vers une console unique. Le streaming de chat dans la console (2026-08-18) a ajouté le streaming aux discussions. Ces deux changements ont eu lieu à un mois d'intervalle, de sorte que les équipes ayant manqué la première étape bénéficient automatiquement de la seconde.

Il s'agit d'un changement d'interface, pas de comportement. Les appels de modèles, les clés et la facturation restent inchangés. Les anciens liens continuent de fonctionner et les conversations existantes ont été préservées lors de la fusion. Aucune étape de migration manuelle n'est requise.

L'étape de convergence concerne les points d'entrée, et non l'accès aux modèles. L'étape de streaming concerne la manière dont une réponse apparaît, et non la facturation des tokens. C'est important, car un changement de surface produit peut parfois masquer un changement comportemental, ce qui n'est pas le cas ici. Le mode assistant de codage et le mode application IA partagent désormais un seul et même endroit ; la première décision lors d'une session ne consiste donc plus à choisir quel point d'entrée ouvrir.

Si votre équipe utilise des manuels opérationnels (runbooks) pointant vers les anciens points d'entrée, mettez à jour les libellés dès que possible. Les anciens liens fonctionnent toujours, donc le manuel ne sera pas rompu. La console est l'endroit à mettre en favori pour les nouveaux travaux. Lorsque vous choisissez un modèle dans l'un ou l'autre mode, le choix suit le catalogue public ; consultez donc le répertoire des modèles. Les exemples du catalogue actuel incluent Claude Sonnet 5 et DeepSeek V4 Pro.

Le streaming dans la console TokenLab change votre façon de lire une session

Le streaming modifie le moment où vous savez qu'une action est en cours. Dans notre pipeline, le client de la passerelle de la console construit les requêtes de chat en streaming, et la réponse s'affiche de manière incrémentale. L'interface affiche le temps du premier token, ce qui vous permet de voir quand le modèle commence à répondre. La console enregistre également ce signal sous le nom ttft_ms, une colonne optionnelle dans le journal des requêtes.

Le temps du premier token vous indique quand le premier token est arrivé, tandis que la latence totale vous indique quand la réponse complète est terminée. Ce sont des questions différentes ; par conséquent, si une réponse semble lente, vérifiez d'abord ttft_ms. Si le premier token est tardif, l'attente se situe avant la génération. Si le premier token est rapide mais que la réponse traîne, l'attente se situe dans le reste du flux.

Lorsque nous observons une session lente, nous comparons ttft_ms avec le reste des preuves de la requête au lieu de deviner à partir de l'indicateur de chargement. Les preuves au niveau de la requête sont limitées à l'organisation et couvrent le routage, l'état de la facturation, l'état du cache, ainsi que le contexte du modèle et de la clé derrière une requête. La console expose le même enregistrement de requête que celui que vous auriez dû extraire des journaux.

Un exemple concret de lecture du signal du premier token :

# Le journal des requêtes de la console expose `ttft_ms` comme colonne optionnelle.
# 1. Filtrez le journal des requêtes pour trouver la requête que vous vérifiez.
# 2. Lisez `ttft_ms`.
# 3. Comparez `ttft_ms` avec la latence totale de la requête sur la même ligne.

Pour connaître la forme exacte de la requête de streaming, utilisez la documentation actuelle de l'API TokenLab. Un exemple de requête copié avec des champs inventés serait moins utile que la page de documentation qui définit ces noms.

Le streaming ne change pas ce qui vous est facturé, car les mêmes tokens sont produits, mais ils sont visibles dès leur arrivée. Comme les réponses sont désormais diffusées en streaming, une session interrompue affiche toujours la réponse partielle au lieu de rien du tout. Cela change la façon dont vous diagnostiquez une défaillance en milieu de session. Pour les tâches de longue durée que le flux de chat ne couvre pas, consultez le guide des tâches de génération d'images asynchrones.

Comment vérifier une session lente sans deviner

Commencez par le journal des requêtes, pas par l'indicateur de chargement, car la colonne ttft_ms vous indique quand le premier token est arrivé. Si ce nombre est élevé, le modèle n'avait pas encore commencé à répondre. Si ce nombre est faible, le modèle a commencé tôt et le flux restant a pris du temps. Cette distinction vous évite d'incriminer la mauvaise partie du chemin.

L'enregistrement de la requête est limité à votre organisation. Il inclut la route qui a servi la requête, l'état de la facturation, l'état du cache, ainsi que le contexte du modèle et de la clé. Ces champs sont regroupés, ce qui vous permet de lire la session comme un événement unique plutôt que de devoir assembler des pages séparées. Le même enregistrement de requête est disponible dans le tableau de bord, ce qui aide à comparer la vue de la console avec les données au niveau du compte. Le guide de la console de requêtes explique où se trouvent ces preuves.

Par exemple, si le premier token est rapide et que la réponse traîne, ttft_ms n'est pas le signal principal, car c'est le reste du flux qui l'est. Vous pouvez examiner la route et l'état du cache dans le même enregistrement de requête. Vous pouvez vérifier si la requête a atteint un cache ou si elle a été envoyée au modèle. Vous pouvez voir quel contexte de clé et de modèle était attaché.

Rien de tout cela ne vous raconte toute l'histoire par soi-même, mais ensemble, ces éléments vous donnent une piste à suivre. Lorsque nous observons une session lente, le journal des requêtes contient les détails dont nous avons besoin. Nous comparons ttft_ms avec les autres preuves au niveau de la requête avant de tirer une conclusion.

Le même flux de travail aide lorsqu'une requête échoue ou se met en pause en raison du solde. L'enregistrement de la requête inclut l'état de la facturation, donc l'échec n'est pas un mystère. L'option de rechargement se trouve à côté de la conversation, donc la correction reste dans la même fenêtre. Vous n'avez pas besoin de quitter la session pour trouver l'étape suivante ; vous pouvez donc recharger votre solde puis continuer.

Si le solde est suffisant, vous pouvez passer au routage, à l'état du cache ou au choix du modèle. L'idée est de lire les preuves au niveau de la requête dans l'ordre. Demandez d'abord quand le premier token est arrivé, puis demandez quelle route l'a servi, et enfin demandez ce que l'enregistrement indique concernant la facturation, le cache, le modèle et le contexte de la clé. Cet ordre est simple et correspond à la manière dont la console présente les données.

Limitations

Le streaming montre la progression, pas le débit, car un flux peut démarrer rapidement et mettre longtemps à se terminer. Un premier token rapide ne prouve pas que l'ensemble de la requête est rapide. Le temps du premier token dépend également du modèle et de la route. Comparez au sein d'un même modèle plutôt qu'entre différents modèles.

Un changement dans ttft_ms peut refléter le routage, l'état du cache ou le choix du modèle, et pas seulement le prompt. Traitez ttft_ms comme un signal parmi d'autres dans le journal des requêtes. Associez-le aux autres preuves au niveau de la requête avant de tirer une conclusion. Il s'agit d'une surface pour lire une session, et non d'un benchmark pour classer les modèles.

La console ne transforme pas un flux de chat en un exécuteur de tâches. Si vous avez une tâche d'image de longue durée, utilisez le guide des tâches de génération d'images asynchrones au lieu de maintenir un flux de chat ouvert. La surface de streaming est destinée aux réponses qui arrivent token par token. Le guide asynchrone est destiné au travail qui s'exécute en dehors d'une réponse de chat.

N'oubliez pas non plus que les preuves au niveau de la requête sont limitées à l'organisation, ce qui lie une requête au contexte du compte qui l'entoure. Cela signifie également que vous ne devez pas traiter une requête comme un benchmark global. L'enregistrement couvre le routage, l'état de la facturation, l'état du cache, ainsi que le contexte du modèle et de la clé pour cette requête. C'est un excellent point de départ pour un diagnostic. Ce n'est pas un classement des fournisseurs ou des modèles. Lorsque nous comparons des sessions, nous comparons au sein du même modèle et de la même famille de routes, ce qui garantit l'honnêteté de la comparaison.

FAQ

Mes anciens liens de console fonctionnent-ils toujours ?

Oui. Les anciens liens continuent de fonctionner et les conversations existantes ont été préservées lors de la fusion. Il n'y a rien à migrer manuellement. Si vous avez mis une page de la console en favori, elle fonctionne toujours.

Que mesure réellement le temps du premier token ?

Il mesure le moment où le premier token arrive dans une réponse en streaming, et la console l'affiche dans l'interface et l'enregistre sous le nom ttft_ms, une colonne optionnelle dans le journal des requêtes. Il ne mesure pas la latence totale ni le débit.

Où puis-je recharger mon solde lorsqu'une conversation est épuisée ?

Utilisez l'option de rechargement à côté de la conversation, qui apparaît lorsque le solde devient faible en milieu de session, afin que vous puissiez gérer votre solde sans quitter la session. La page de facturation dans le tableau de bord reste l'endroit dédié aux opérations plus larges sur le compte.

Puis-je comparer le temps du premier token entre différents modèles ?

Non, pas comme une comparaison directe. Le temps du premier token dépend du modèle et de la route ; comparez donc au sein d'un même modèle plutôt qu'entre différents modèles. Utilisez ttft_ms comme un signal au niveau de la requête, et non comme un classement de modèles.

Créez une clé API et lancez une session dans la nouvelle console via le tableau de bord.