For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Observabilité et consommation de tokens

Suivez la progression en temps réel, examinez le travail effectué et consultez la consommation de tokens enregistrée.

Suivez l’activité des agents en temps réel, examinez le travail effectué et consultez les traces détaillées de chaque tour :

  1. Consultez les journaux de session dans le tableau de bord de la plateforme.
  2. Suivez la session à partir de ses événements et de son historique enregistré.
  3. Examinez les tours pour repérer les commandes dont l’exécution a été déléguée.
  4. Consultez la consommation de tokens enregistrée pour les tours de l’agent racine et des sous-agents.

Consulter la session dans le tableau de bord

Accédez à platform.openai.com/logs?api=agents et ouvrez l’onglet Agents.

Recherchez une session par son identifiant pour examiner ses tours, ses appels d’outils et ses sous-agents.

Consultez le guide de traçage pour examiner dans le tableau de bord les enregistrements des réponses du modèle, des appels d’outils et de l’activité des sous-agents, ou exportez les traces de session au format JSON OTLP via l’API publique.

Suivre les événements et consulter l’historique de session

Chaque session fournit un flux d’événements qui indique ce que fait l’agent en temps réel. Définissez OPENAI_API_KEY et remplacez l’identifiant de session donné dans ces exemples par celui que vous avez enregistré :

Suivre les événements de session en temps réel
// Replace the illustrative IDs and URLs below with your own resource values.
import OpenAI from "openai";

const client = new OpenAI();
const events = await client.beta.agents.sessions.events.stream("sess_123");
try {
  for await (const event of events) {
    if (
      [
        "agent.session.turn.failed",
        "agent.session.turn.cancelled",
        "agent.session.failed",
        "agent.session.environment.failed",
        "error",
      ].includes(event.type)
    ) {
      throw new Error(`Agent lifecycle failure: ${event.type}`);
    }
    console.log(JSON.stringify(event));
  }
} finally {
  events.controller.abort();
}

Le flux reste ouvert même lorsque la session signale qu’elle est inactive, ce qui vous permet de suivre les tâches en attente. Appuyez sur Ctrl+C pour arrêter le suivi.

Au cours de la session, vous verrez des événements tels que :

agent.session.environment.connected
agent.session.turn.created
agent.session.turn.in_progress
agent.session.turn.item.added
agent.session.turn.output_text.delta
agent.session.turn.completed
agent.session.idle

Pour examiner le travail déjà effectué, récupérez les éléments enregistrés de la session :

Examiner les éléments enregistrés de la session
// Replace the illustrative IDs and URLs below with your own resource values.
import OpenAI from "openai";
const client = new OpenAI();

const sessionId = "sess_123";
const items = await client.beta.agents.sessions.items.list(sessionId, {
  order: "asc",
  limit: 100,
});
console.log(items.data);

Examiner les tours et repérer les commandes déléguées

L’API publique donne accès aux tours de session. Utilisez le turn_id d’un élément de commande avec l’identifiant de session que vous avez enregistré. L’exemple en Go parcourt les tours de l’agent racine et des sous-agents grâce à la pagination intégrée au SDK, puis récupère le tour correspondant auprès de l’agent auquel il appartient. Remplacez les identifiants donnés en exemple par ceux de votre session. L’exemple cURL nécessite jq :

Identifier l’agent qui a exécuté une commande déléguée
// Replace the illustrative session and turn IDs with values from your command item.
import OpenAI from "openai";
const client = new OpenAI();

async function findTurn(sessionId, turnId) {
  for await (const turn of client.beta.agents.sessions.turns.list(sessionId, {
    limit: 100,
  })) {
    if (turn.id === turnId) {
      return client.beta.agents.sessions.turns.retrieve(turnId, {
        session_id: sessionId,
      });
    }
  }
  for await (const subagent of client.beta.agents.sessions.subagents.list(
    sessionId,
    { limit: 100 }
  )) {
    for await (const turn of client.beta.agents.sessions.subagents.turns.list(
      subagent.id,
      { session_id: sessionId, limit: 100 }
    )) {
      if (turn.id === turnId) {
        return client.beta.agents.sessions.subagents.turns.retrieve(turnId, {
          session_id: sessionId,
          subagent_id: subagent.id,
        });
      }
    }
  }
  throw new Error(`Turn ${turnId} not found in session ${sessionId}`);
}

const turn = await findTurn("sess_123", "turn_123");
console.log(turn.subagent_id || "main agent");

Pour paginer manuellement, utilisez le last_id renvoyé comme valeur de after pour la page suivante lorsque has_more vaut true. L’exemple en Go parcourt ces pages automatiquement.

Chaque élément de commande contient un turn_id. Récupérez le tour correspondant et consultez son subagent_id pour identifier le sous-agent qui a exécuté la commande. Si l’identifiant du sous-agent vaut null, c’est l’agent racine qui a exécuté la commande. L’API ne signale pas si la sortie de la commande a été tronquée.

Examiner la trace d’un tour

Dans le tableau de bord de la plateforme, examinez un tour terminé et l’activité des agents pendant ce tour. Pour récupérer les traces enregistrées via l’API publique, utilisez le point de terminaison d’exportation des traces de session avec une clé API de projet. Les points de terminaison de traçage du tableau de bord sont distincts de ceux de l’API prise en charge pour les clients.

Les ressources de tour comprennent un champ usage renseigné selon les données disponibles et un champ subagent_id qui permet d’identifier le travail délégué. Si la consommation est inconnue, sa valeur peut être null. La valeur enregistrée peut évoluer. Consultez la section Consulter la consommation de tokens des sous-agents.

Pour identifier l’agent qui a exécuté une commande shell, récupérez le tour indiqué par le champ turn_id de l’élément de commande, puis consultez turn.subagent_id. L’API destinée aux clients n’indique pas si la sortie de la commande a été tronquée.

Erreurs et reprise

Consultez la section Erreurs et reprise pour analyser un échec, choisir une méthode de reprise et relancer l’opération en toute sécurité.

Utilisation du modèle et coût

Un agent peut appeler le modèle plusieurs fois pour accomplir une tâche. Comme dans l’API Responses, chaque appel est soumis à la tarification des tokens et aux règles de mise en cache des prompts du modèle. Pour estimer le coût d’une tâche, tenez compte de tous les appels nécessaires à son exécution.

Quels éléments entrent dans le calcul du coût ?

Chaque appel au modèle peut consommer les catégories de tokens suivantes :

  • Tokens d’entrée : instructions de l’agent, définitions d’outils, historique de conversation, saisie de l’utilisateur, fichiers ou images et résultats des outils.
  • Tokens d’entrée mis en cache : tokens réutilisés lorsque le préfixe du prompt correspond à celui d’un appel précédent. Ils sont facturés au tarif du modèle pour les entrées mises en cache.
  • Tokens de sortie : texte généré, arguments des appels d’outils et raisonnement.

Les tokens de raisonnement sont facturés comme des tokens de sortie.

Les sous-agents peuvent eux aussi appeler le modèle. Pour analyser les coûts du modèle, consultez leur consommation enregistrée par tour en plus de celle de l’agent racine.

Tenez compte du travail de l’agent racine et des sous-agents, y compris des nouvelles tentatives. Ajoutez les frais éventuels liés aux outils, aux ressources de calcul du bac à sable et aux services tiers. Certains modèles facturent également l’écriture des données d’entrée dans le cache. Les champs de consommation de l’API Agents décrits ci-dessous ne fournissent pas de décompte distinct des tokens écrits dans le cache. Ils ne permettent donc pas de déterminer le montant exact facturé pour le modèle lorsque ce tarif s’applique.

Mise en cache des prompts

Les agents conservent le contexte d’un tour à l’autre au sein d’une session. Lorsque des appels successifs au modèle partagent le même préfixe de prompt, la mise en cache des prompts permet de réutiliser le résultat du traitement de ce préfixe. Le modèle génère une nouvelle réponse à chaque appel, même lorsqu’il utilise le cache. Garder une session ouverte ne garantit pas que le cache sera utilisé. La réutilisation dépend de la correspondance des préfixes ainsi que des règles du modèle concernant l’admissibilité à la mise en cache et la durée de conservation.

Dans la mesure du possible, conservez les mêmes instructions initiales et définitions d’outils, et précisez les nouveaux détails de la tâche dans les messages suivants. Avec la recherche d’outils, les définitions des outils trouvés sont ajoutées à la fin de la conversation. Le contenu précédent reste ainsi disponible pour une réutilisation depuis le cache. Consultez la section Mise en cache des prompts pour connaître les règles propres à chaque modèle.

Une proportion élevée de tokens d’entrée mis en cache ne permet pas de mesurer les économies réalisées sur le coût total de la tâche. Les entrées mises en cache restent facturées et les appels successifs peuvent traiter un historique volumineux. Comparez les coûts d’exécution d’une même tâche pour la qualité et la latence requises par votre application.

Comprendre la consommation de tokens

Les ressources de session et de tour fournissent un champ usage, renseigné selon les données disponibles. Sa valeur peut être null lorsque la consommation est inconnue, et les décomptes enregistrés peuvent évoluer à mesure que les données de consommation sont comptabilisées. L’absence de données ne signifie pas que la consommation est nulle. Ces décomptes ne constituent pas une facture définitive.

Un objet de consommation enregistré contient les catégories de tokens suivantes :

{
  "input_tokens": 5000,
  "input_tokens_details": {
    "cached_tokens": 1500
  },
  "output_tokens": 900,
  "output_tokens_details": {
    "reasoning_tokens": 200
  },
  "total_tokens": 5900
}

Dans cet exemple, l’agent a traité 5 000 tokens d’entrée et généré 900 tokens de sortie. Parmi les tokens d’entrée, 1 500 étaient mis en cache. Parmi les tokens de sortie, 200 étaient des tokens de raisonnement.

Les tokens mis en cache sont inclus dans input_tokens et les tokens de raisonnement dans output_tokens.

Consulter la consommation de tokens des sous-agents

Listez ou récupérez les tours de session et consultez le champ usage de chaque tour. Le champ subagent_id identifie le sous-agent. Il vaut null pour les tours de l’agent racine. Lorsque has_more vaut true, passez last_id comme valeur de after en conservant la même valeur de order pour lire les tours restants.

La consommation est enregistrée selon les données disponibles. Sa valeur peut être null lorsqu’elle est inconnue, et les valeurs enregistrées peuvent évoluer. Vous pouvez également consulter la consommation enregistrée pour chaque agent dans le tableau de bord de traçage.