Quick answer: La plupart des stacks d'agents boulonnent le suivi des coûts après coup : un wrapper autour de l'appel modèle qui écrit des tokens dans un système séparé, lequel finit par diverger de la réalité....

Le journal de session de DeepSeek Harness comme registre de coûts

Updated August 16, 2026 · first published August 16, 2026

La plupart des stacks d'agents boulonnent le suivi des coûts après coup : un wrapper autour de l'appel modèle qui écrit des tokens dans un système séparé, lequel finit par diverger de la réalité. DeepSeek Harness procède à l'inverse. Le journal de session est l'artefact primaire, et l'usage de tokens vit dedans.

La session est un journal d'événements append-only

Une session est une suite ordonnée et seulement extensible d'entrées SessionEvent typées. Chaque événement porte quatre champs :

ChampSignification
typeLe genre d'événement, par exemple assistant/message
seqNuméro de séquence monotone dans la session
timeHorodatage
dataLa charge utile propre au type

Les événements de surface (ce qu'une interface affiche) ajoutent deux champs : sourceEventSeqs, qui renvoie aux événements bruts dont ils dérivent, et surfaceOp. Ces renvois sont la raison pour laquelle un chiffre de coût peut être remonté jusqu'aux événements exacts qui l'ont produit.

Les événements qui comptent pour un modèle de coût

La règle directrice de la documentation est : ce qui est visible du modèle est journalisé. Tout ce qui entre dans le contexte du modèle laisse un événement. Le journal est donc complet par construction, et non complet tant que personne n'oublie de l'instrumenter.

L'usage voyage avec la sortie

L'usage de tokens n'est pas écrit dans un canal latéral : il voyage avec la sortie à laquelle il appartient. Préférez les chunks d'usage (assistant/chunk avec { type: 'usage' }) car ils collent au plus près de ce que le fournisseur a réellement facturé ; repliez-vous sur assistant/message.usage en l'absence de chunk. Un modèle de coût qui lit ainsi ne peut jamais attribuer un chiffre à une étape qui ne l'a pas produit.

Historique dérivé, pas dupliqué

L'historique de messages que voit le modèle est projeté depuis le journal d'événements plutôt que maintenu à côté comme une seconde vérité. C'est la différence entre un système dont les chiffres de coût concordent avec son exécution et un système où les deux divergent sans qu'on puisse dire lequel a raison.

« Visible du modèle veut dire journalisé » est la seule règle qui rende possible une reconstruction des coûts. Sans elle, tout chiffre d'attribution est une estimation dont la marge d'erreur est inconnue.

Ce qu'il faut bâtir dessus

  1. Joignez step/start et step/end pour former des spans d'étape : l'unité sur laquelle vous rapporterez les coûts.
  2. Attachez request/context (fournisseur, modèle, fenêtre de contexte) et le prix issu de l'usage du chunk à chaque span.
  3. Comptez l'éventail de tool/call par étape : la démultiplication d'outils est la raison habituelle pour laquelle un tour coûte soudain dix fois plus.
  4. Surveillez la distribution des TurnEndReason. Les tours interrompus et tronqués sont du travail payé sans résultat, et c'est la première métrique dont vous êtes privé sans journal.

Related


Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research