Dónde poner los límites de gasto en DeepSeek Harness
Updated August 16, 2026 · first published August 16, 2026
Un agente que descubre su presupuesto en la factura mensual no tiene presupuesto: tiene un post-mortem. La pregunta útil sobre cualquier harness es dónde puede uno plantarse dentro del bucle y decir que no, y DeepSeek Harness la responde con dos puntos de extensión en cascada con nombre propio.
Primero, la forma del bucle
El harness usa un modelo de turno y paso. Un paso es una petición al modelo más las llamadas a herramientas que produce. Un turno contiene cero o más pasos. El flujo de un turno es, a grandes rasgos: reclamo de entrada, ensamblado del prompt, agent/pre-step, stream del LLM, ejecución de herramientas, cierre del paso y cierre del turno.
Dos flujos de eventos corren en paralelo. session/event lleva hechos duraderos de replay: chunks, mensajes, llamadas a herramientas, resultados. agent/* lleva señales vivas de coordinación: estado, buzón, interceptación de peticiones. Los límites pertenecen al segundo; la contabilidad, al primero.
Punto de intercepción 1: agent/pre-step
Es el control previo a que salga la petición al modelo. La documentación afirma que la decisión devuelta por agent/pre-step es autoritativa y que los listeners que envuelven next() preservan los mensajes aguas abajo salvo que la sustitución sea intencionada. Esa es la propiedad que lo hace utilizable como puerta de presupuesto: un listener puede rechazar un paso propuesto, o modificarlo, y la decisión se mantiene.
Lo que corresponde aquí:
- Topes de pasos por turno. El modo de fallo del agente descontrolado es un turno que nunca converge. Un techo duro de pasos convierte una factura ilimitada en una acotada.
- Presupuestos acumulados de tokens. Sume el uso registrado hasta ahora en el log de sesión y rechace el siguiente paso pasado el umbral.
- Bajada de modelo. Reescriba el paso hacia una ruta más barata cuando el turno haya superado un umbral blando, en vez de rechazarlo sin más.
- Límites de tamaño de contexto. El prompt se ensambla antes de este hook, así que la petición ya montada es visible y medible aquí.
Punto de intercepción 2: tools/pre-execute
La ejecución de herramientas es una tubería de tres fases. Primero corre la cascada tools/pre-execute, después los guardas monótonos y solo entonces el cuerpo de la herramienta, en sandbox y con control de acceso al sistema de archivos. Luego una cascada post-execute puede aceptar, bloquear, sustituir o añadir contexto al resultado, y ToolDefinition.finalizeContent impone invariantes de contenido de forma síncrona.
La capa de permisos es deliberadamente asimétrica. Los guardas monótonos registrados deniegan o se abstienen, con identidad protegida: nunca conceden. Si un guarda deniega, o si el prompt de un solo uso de ctx.approval falta o resulta incontestable, el resultado es denegación y el cuerpo de la herramienta se omite. Falla cerrado, no abierto.
Las mutaciones del sistema de archivos se controlan aparte: solo pasan las mutaciones fs/write-intent o fs/edit-intent. Escribir no es un efecto colateral incidental de ejecutar una herramienta.
Dos propiedades hacen fiable esta tubería como punto de control: los guardas solo pueden denegar, y un prompt de aprobación incontestable deniega. La mayoría de capas caseras de política para agentes fallan en abierto cuando falta el canal de aprobación, que es justo cuando las necesitaba.
Qué registra la tubería
Tres eventos de sesión le dan el rastro de auditoría: tool/call antes de ejecutar, tool/code-dispatch para subllamadas y tool/result como resultado final autoritativo. Que las subllamadas se registren aparte importa: una única llamada a herramienta visible para el modelo que se ramifica internamente no esconde su ramificación.
Un conjunto práctico de límites
| Control | Hook | Frena |
|---|---|---|
| Máximo de pasos por turno | agent/pre-step | Bucles que no convergen |
| Techo acumulado de tokens | agent/pre-step | Sobregasto a fuego lento |
| Bajada de ruta pasado el umbral | agent/pre-step | Precios de frontera para trabajo barato |
| Lista blanca de herramientas por clase de coste | Guarda monótono | Herramientas caras en contextos baratos |
| Denegación de subprocesos y red | Política de ctx.sandbox | Salida de red sin medir |
| Control de write-intent | Costura ctx.fs | Mutaciones sin revisar |
La salvedad
DeepSeek Harness está en developer preview y su propio README advierte de cambios que rompen compatibilidad. Estos nombres y semánticas de hooks son los documentados hoy; trate los plugins de límites construidos sobre ellos como código que revisitará, y fije la versión contra la que construyó.
Related
- ¿Qué es DeepSeek Harness? Guía completa
- El registro de sesión como registro de costes (EN)
- Todo es un plugin: la arquitectura (EN)
- Límites de gasto para agentes (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 →