El registro de sesión de DeepSeek Harness como registro de costes
Updated August 16, 2026 · first published August 16, 2026
La mayoría de stacks de agentes atornillan el seguimiento de coste a posteriori: un wrapper alrededor de la llamada al modelo que escribe tokens en un sistema aparte que, con el tiempo, se separa de la realidad. DeepSeek Harness lo hace al revés. El registro de sesión es el artefacto primario y el uso de tokens vive dentro de él.
La sesión es un log de eventos append-only
Una sesión es una secuencia ordenada y solo-anexable de entradas SessionEvent tipadas. Cada evento lleva cuatro campos:
| Campo | Qué significa |
|---|---|
type | La clase de evento, por ejemplo assistant/message |
seq | Número de secuencia monótono dentro de la sesión |
time | Marca de tiempo |
data | La carga útil específica del tipo |
Los eventos de superficie (lo que una interfaz muestra) añaden dos campos más: sourceEventSeqs, que apunta de vuelta a los eventos crudos de los que se derivaron, y surfaceOp. Esos punteros son la razón por la que una cifra de coste puede rastrearse hasta exactamente los eventos que la produjeron.
Los eventos que le importan a un modelo de coste
turn/startyturn/end: el corchete exterior de una petición de usuario.turn/endlleva unTurnEndReasonque dice si el turno se completó, se abortó o se truncó.step/startystep/end: un paso es una petición al modelo más las llamadas a herramientas que provoca. Es la unidad natural de facturación.assistant/message: salida del modelo, conTokenUsageopcional.assistant/chunk: salida en streaming, incluidos los chunks de uso.tool/callytool/result: ejecución de herramientas; el resultado puede llevarmeta.request/headeryrequest/context: elEpochHeadery el contexto de petición con proveedor, modelo y ventana de contexto. Ese par es lo que asigna un precio a una cifra de uso.
La regla rectora de la documentación es: lo visible para el modelo queda registrado. Todo lo que entra en el contexto del modelo deja un evento. Eso hace el log completo por construcción, en vez de completo mientras nadie olvide instrumentarlo.
El uso viaja con la salida
El uso de tokens no se escribe en un canal lateral: viaja con la salida a la que pertenece. Prefiera los chunks de uso (assistant/chunk con { type: 'usage' }) porque están lo más cerca posible de lo que el proveedor facturó realmente; recurra a assistant/message.usage cuando no haya chunk. Un modelo de coste que lea así nunca puede atribuir una cifra a un paso que no la generó.
Historia derivada, no duplicada
El historial de mensajes que ve el modelo se proyecta desde el log de eventos en vez de mantenerse al lado como una segunda verdad. Esa es la diferencia entre un sistema cuyas cifras de coste concuerdan con su ejecución y uno donde ambas divergen y nadie puede decir cuál tiene razón.
«Lo visible para el modelo queda registrado» es la única regla que hace posible reconstruir el coste. Sin ella, toda cifra de atribución es una estimación con una barra de error desconocida.
Qué construir encima
- Una
step/startconstep/endpara formar spans de paso: la unidad contra la que reportará coste. - Adjunte
request/context(proveedor, modelo, ventana de contexto) y el precio a partir del uso del chunk a cada span. - Cuente el fan-out de
tool/callpor paso: la ramificación de herramientas es la razón habitual de que un turno cueste de pronto diez veces más. - Vigile la distribución de
TurnEndReason. Los turnos abortados y truncados son trabajo pagado sin resultado, y son la primera métrica que no tiene sin un log.
Related
- ¿Qué es DeepSeek Harness? Guía completa
- Todo es un plugin: la arquitectura (EN)
- Dónde poner los límites de gasto (EN)
- Convenciones GenAI de OpenTelemetry (EN)
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 →