El presupuesto de tu agente

3.1El problema

Magallanes, tu deep-research agent, tiene un system prompt de una página y 3 tools. Nada más. Lo lanzas sobre un encargo de verdad: investiga un tema, lee documentos, escribe un informe por secciones. Empieza fino.

Al turno 20, mides su contexto. Pesa 85K tokens.

Te quedas mirando el número. ¿De dónde salen? El prompt no ha cambiado: sigue siendo una página. Las tools son las mismas 3. El usuario solo mandó un encargo corto al principio. Y aun así, el contexto se ha multiplicado sin que nadie escribiera 85K tokens a mano.

Esa pregunta —"¿quién se está comiendo mi presupuesto?"— es la lección. Hasta que no la sepas contestar con números, no puedes priorizar nada. No sabes si recortar el prompt, podar tools, comprimir el historial o limpiar los tool results. Todas suenan razonables. Solo una mueve la aguja.

Recordando L1: el proveedor anuncia 200K de ventana y tú usas 85K. "Cabe de sobra" — y Magallanes ya repite búsquedas y se contradice. El problema no es que no quepa. Es que cada uno de esos 85K tokens cobra renta sobre la atención del modelo. Esta lección te dice de dónde sale cada token.

3.2Qué vas a poder hacer

Al terminar podrás:

• Descomponer el contexto de cualquier agente en sus cuatro partidas: system prompt, definiciones de tools, historial y tool results.
• Medir cada partida con la API de token counting de Anthropic, separando el coste fijo del crecimiento por turno.
• Leer la pendiente de una tabla de crecimiento y nombrar qué partida la domina.
• Decidir qué recortar primero ante un desglose dado, y qué palanca (de las cuatro del curso) le corresponde.

Necesitas saber antes: la taxonomía de fallos de N0·L2 (poisoning, distraction, confusion, clash) y el esqueleto de Magallanes del índice del nivel. Python básico (listas, bucles, diccionarios). Si la taxonomía no está sólida, repásala: aquí la usarás para conectar cada partida inflada con el modo de fallo que provoca.

3.3Recupera

Antes de leer, responde de memoria. En N0·L2 clasificaste los fallos de Magallanes en cuatro modos.

1. Si las tools inflan el contexto —muchas definiciones, varias parecidas— ¿qué modo de fallo esperas que aparezca primero?
2. Si lo que infla el contexto es el historial que el agente arrastra de sus propios turnos, ¿qué modo esperas?
3. ¿Por qué un contexto que "cabe de sobra" en la ventana puede aun así degradar la calidad?

Pista para la 1: cuando el catálogo crece, el modelo elige la tool equivocada — eso es context confusion. Para la 2: cuando el contexto largo hace que el modelo repita su historial en vez de sintetizar, es context distraction. Para la 3: cada token gasta presupuesto de atención, lo viste en L1. Esta lección conecta cada partida del presupuesto con el modo que dispara.

3.4El concepto

Las cuatro partidas del contexto

Empecemos por lo concreto: abre el contexto de Magallanes en un turno cualquiera y mira qué hay dentro. No es un bloque opaco. Son cuatro cosas distintas, cada una con su propio comportamiento.

El presupuesto del agente es la suma de las cuatro partidas en un turno dado. La analogía: es como el presupuesto mensual de una casa. Dos partidas son gastos fijos (el alquiler: prompt y tools); dos crecen con el uso (las facturas: historial y tool results). Límite de la analogía: el dinero de una partida no estorba al de otra; los tokens sí. Un tool result enorme entierra el system prompt en mitad del contexto, donde el modelo lo lee peor (lo viste en L1).

Las dos primeras partidas son coste fijo: están ahí desde antes del primer turno y no se mueven. Las dos últimas son coste variable: crecen a medida que el agente trabaja. Esa distinción es el eje de toda la lección. El miedo no está en el valor inicial; está en la pendiente.

El loop ReAct append-only: por qué el contexto solo crece

¿Por qué crecen el historial y los tool results, y por qué no bajan nunca? Por cómo está construido el loop del agente.

Magallanes corre un loop ReAct: razona, llama una tool, recibe el resultado, razona otra vez, llama otra tool. El resultado de cada paso se añade a la lista de mensajes. El de N0 es deliberadamente ingenuo: nadie quita nada. Es append-only —solo se agrega, nunca se descarta—.

Esto tiene una consecuencia estructural. Cada documento que leer() devuelve se queda en el contexto para siempre, aunque el agente ya lo haya resumido y no lo vuelva a necesitar. Cada razonamiento intermedio se queda. El contexto es un cajón al que solo entran cosas.

El corpus lo confirma como patrón conocido, no como rareza de tu código. El loop ReAct acumula interacciones en un contexto append-only y satura en tareas de largo horizonte: "unbounded context growth… prohibitive inference memory costs and reasoning degradation" (ACON, arXiv:2510.00615, Microsoft Research, oct 2025). El mismo paper, con su mecanismo de compresión, reduce el pico de tokens un 26–54% preservando el éxito de la tarea. La señal: el crecimiento sin límite es el problema; comprimirlo es la cura.

Esto explica el spoiler del problema. En Magallanes, la partida que se dispara no es el historial de razonamientos —son los tool results—, porque cada leer() mete un documento completo. Esa tool se diseñó así a propósito: infla el contexto para que lo veas.

El coste fijo: lo que pagas antes de hablar

Antes de que el usuario diga una palabra, ya estás pagando. El system prompt y las definiciones de tools ocupan tokens desde el arranque. En Magallanes son modestos: una página y 3 tools. Pero la cifra se vuelve seria rápido.

El dato del corpus, con su escenario exacto: "a five-server setup with 58 tools consumes approximately 55K tokens before the conversation even starts" (Anthropic, Code execution with MCP, nov 2025). Un montaje de 5 servidores MCP con 58 tools gasta ~55K tokens antes de que la conversación empiece siquiera. Eso es coste fijo puro: 55K tokens que pagas en cada turno, hagas lo que hagas, solo por tener las tools conectadas.

Es común pensar que las tools son baratas "porque solo es metadata". No lo son cuando se acumulan. Cada definición de tool cuesta del orden de 500 a 1.500 tokens (issue modelcontextprotocol#2808, ~1.000 por tool — confianza media). Multiplica por 58 y entiendes los 55K.

Que el problema existe lo demuestra que hubo que ponerle un límite. Claude Code limita las respuestas de tools a 25.000 tokens por defecto (Anthropic, Writing tools for agents, sep 2025). Si una sola respuesta de tool pudiera ser ilimitada, un leer() desafortunado entierra el resto del contexto de un golpe. El límite existe porque el riesgo es real.

Por qué cada partida dispara un modo de fallo distinto

Aquí conectas con la taxonomía de L2. Cada partida que se infla no degrada "en general": dispara un modo concreto.

• El historial que crece sin gestión → distraction: el modelo se sobre-enfoca en su propio pasado y repite acciones en vez de sintetizar.
• Los tool results enormes → contexto largo que distrae y, si arrastran un dato erróneo de un documento mal leído, poisoning.
• Las definiciones de tools cuando son muchas o parecidas → confusion: el modelo elige la tool equivocada (esto lo ataca N3).

Esto convierte el desglose en algo accionable. No mides tokens por contabilidad. Mides para saber qué enfermedad estás incubando y, por tanto, qué tratamiento aplicar.

3.5Míralo funcionar

Vamos a contestar la pregunta del problema con números reales. Construiremos un script de auditoría que mide el coste fijo de Magallanes y cómo crece su contexto turno a turno.

La herramienta es la API de token counting de Anthropic. Cuenta los tokens exactos de un contexto sin generar respuesta: es una llamada de medición, no de inferencia. Su uso no consume tu presupuesto de generación, aunque tiene sus propios rate limits. La firma, del corpus:

1client.messages.count_tokens(model=..., system=..., messages=[...], tools=[...])
2# devuelve: {"input_tokens": N}

Le pasas las mismas piezas que pasarías a una llamada real —el system prompt, la lista de mensajes, las definiciones de tools— y te devuelve cuántos tokens ocupa todo junto. Esa es toda la API que necesitas.

Antes de leer el código línea a línea: la idea es contar dos veces. Una con el contexto vacío (solo prompt y tools) para el coste fijo. Otra después de cada turno, acumulando los mensajes, para ver la pendiente. Lee el bloque entero, luego volvemos sobre los puntos clave.

1import anthropic
2
3client = anthropic.Anthropic()
4MODEL = "claude-..."   # el modelo que use tu Magallanes
5
6# El system prompt de una página y las definiciones de las 3 tools de Magallanes.
7SYSTEM = "..."                    # las instrucciones de una página
8TOOLS = [
9    {"name": "buscar", "description": "...", "input_schema": {...}},
10    {"name": "leer", "description": "...", "input_schema": {...}},
11    {"name": "escribir_seccion", "description": "...", "input_schema": {...}},
12]
13
14def contar(messages: list[dict]) -> int:
15    """Tokens de entrada de un contexto = prompt + tools + estos mensajes."""
16    resultado = client.messages.count_tokens(
17        model=MODEL,
18        system=SYSTEM,
19        messages=messages,
20        tools=TOOLS,
21    )
22    return resultado.input_tokens
23
24# 1. COSTE FIJO: el contexto antes de que el agente diga nada (sin mensajes).
25coste_fijo = contar(messages=[])
26print(f"Coste fijo (system + tools): {coste_fijo} tokens")
27
28# run_de_magallanes: lista de listas — cada sublista, los mensajes de un turno.
29# Es la salida de tu loop ReAct: [[msg_t1a, msg_t1b], [msg_t2a], ...]
30run_de_magallanes = ...  # ← conecta aquí la salida de tu Magallanes
31
32# 2. CRECIMIENTO: parte de un run real de Magallanes ya ejecutado.
33#    'historial' es la lista de mensajes que el loop ReAct fue acumulando,
34#    turno a turno (encargo, razonamientos, tool calls, tool results).
35historial = []          # se irá llenando con los mensajes de cada turno
36for turno, mensajes_del_turno in enumerate(run_de_magallanes, start=1):
37    historial += mensajes_del_turno          # append-only: nunca se quita nada
38    total = contar(messages=historial)
39    print(f"Turno {turno:>2}: {total:>6} tokens")

Tres puntos merecen self-explanation. Respóndelos antes de seguir.

• ¿Por qué contar(messages=[]) da el coste fijo? Porque con la lista de mensajes vacía, lo único que queda en el contexto es el system prompt y las definiciones de tools. Las dos partidas fijas, aisladas. Es el suelo: por debajo de eso no bajas mientras tengas esas tools conectadas.
• ¿Por qué historial += mensajes_del_turno y nunca historial = ...? Porque así reproduces el loop append-only de N0. Cada turno suma sus mensajes a los anteriores; ninguno se descarta. El código es la causa estructural del crecimiento, hecha visible.
• ¿Por qué contar después de cada turno y no solo al final? Porque el número final (85K) no te dice si la subida fue suave o un salto brusco. La forma de la curva —dónde pega el salto— es lo que delata qué partida manda. Un valor te da el síntoma; la serie te da el diagnóstico.

La tabla y la pendiente

Esto es lo que produce el script sobre un run de Magallanes que lee documentos grandes. Cifras ilustrativas del comportamiento append-only, no medidas de un run concreto del corpus:

Lee la columna de tokens como una pendiente, no como puntos sueltos. Del turno 1 al 2, subió 2.500. Del 2 al 5, en cuanto entra el primer leer(), los saltos se agrandan. Cada leer() es un escalón de miles de tokens que no vuelve a bajar nunca.

El coste fijo (2.000) es ruido frente a lo que viene. Esa es la lección del problema: el valor inicial no asusta; la pendiente sí. El número que tienes que vigilar no es "cuánto pesa ahora" sino "cuánto sube por turno y por qué". Y el "por qué" tiene nombre: los tool results de leer(), cada uno un documento completo que el loop no descarta.

3.6Hazlo tú

Práctica con andamiaje decreciente. Vas a auditar una variante de Magallanes y comparar su pendiente con la del run base.

La variante cambia una sola cosa: en vez de devolver documentos completos, leer() devuelve snippets (extractos cortos del documento). El resto es idéntico: mismo encargo, mismas 3 tools, mismo loop append-only.

Parte A — guiada (predice antes de medir)

Antes de tocar código, responde esta elaborative interrogation: ¿por qué cambiar documentos completos por snippets cambia la pendiente, pero no el coste fijo?

Luego, reutilizando el script de 3.5, corre la auditoría sobre la variante y rellena los huecos:

• Coste fijo de la variante: ________ (compáralo con los 2.000 del base — ¿igual o distinto?).
• Pendiente: ¿el salto del turno 5 (primer leer()) es mayor, menor o igual que en el base?

Parte B — autónoma

Tienes las dos tablas: base (documentos) y variante (snippets). Escribe 3-4 frases que respondan: ¿cuál de las dos versiones de Magallanes esperas que falle antes en un run largo, y qué modo de fallo de L2 esperas en cada una?

Pista honesta: la variante tiene un precio en calidad. Un snippet puede no traer el dato que el agente necesitaba, y entonces tendrá que volver a leer. Mide la pendiente, pero no olvides que recortar tokens puede mover el problema, no eliminarlo.

3.7Comprueba

Sin pistas. Te dan un desglose de presupuesto de un agente al turno 30. Decide qué recortarías primero y qué palanca le corresponde. Apruebas si justificas la partida con el número y nombras la palanca correcta.

Desglose del agente "Atlas" al turno 30 (total: 120K tokens):

*Porcentajes redondeados al entero; los tokens absolutos son la fuente de verdad.

Las cuatro palancas del curso (de Lance Martin / LangChain, adelanto): write (sacar tokens fuera del contexto), select (traer solo lo necesario), compress (retener solo los tokens requeridos), isolate (separar en contextos distintos).

Responde: (a) qué partida recortas primero y por qué; (b) qué palanca aplicas; (c) qué partida atacarías en segundo lugar.

3.8Conecta

Acabas de convertir un número opaco —85K tokens— en un desglose accionable. Ya no preguntas "¿por qué pesa tanto?". Sabes que el coste fijo es el suelo, que el historial y los tool results son la pendiente, y que en Magallanes los tool results de leer() son los que mandan.

Este desglose es la dimensión 4 de la rúbrica del checkpoint C0: tu diagnóstico de Magallanes tendrá que traer el presupuesto desglosado con números reales, no una impresión. Lo que mediste aquí es una pieza de ese informe.

Y marca el mapa del resto del curso. Cada partida tiene su nivel:

• El historial sin gestión lo ataca N1 (compresión, trimming, summarization).
• Las tools y los tool results los ataca N3 (catálogo bajo demanda, just-in-time, limpieza de resultados).

En tu trabajo: la próxima vez que un agente "vaya lento y falle", no debatas a ciegas. Cuenta. Saca el coste fijo y la pendiente por turno con count_tokens. El desglose te dice qué recortar primero y deja de ser una opinión.

3.9Reflexiona

Tómate un minuto, en serio. La metacognición es lo que convierte una lección leída en una capacidad tuya.

• Contar tokens parece contabilidad aburrida. ¿Cambió algo cuando viste que la pendiente —no el total— delata la partida culpable?
• En el problema, casi todo el mundo apuesta por el system prompt como culpable de los 85K ("es lo que escribí yo"). El verdadero culpable eran los tool results, que nadie escribió a mano. ¿Por qué es tan fácil mirar la partida equivocada?
• Recortar la partida que domina baja los tokens, pero la práctica B mostró que puede mover el problema (snippets que no traen el dato). ¿Cómo decidirías si un recorte mejoró el agente o solo le quitó tokens?

Esto requiere práctica. La intuición de "qué partida manda" se afina auditando agentes reales y viendo la pendiente con tus propios ojos. Es exactamente lo que harás en el sweep de L4 y en el diagnóstico de L5.

Referencia rápida

Las cuatro partidas del contexto:

• Coste fijo (no crece): system prompt · definiciones de tools.
• Coste variable (crece, append-only): historial · tool results.

Causa estructural del crecimiento: loop ReAct append-only — todo tool result se acumula y nunca se descarta (ACON, arXiv:2510.00615, oct 2025; reduce el pico 26–54% al comprimirlo).

Coste fijo de referencia: un montaje de 5 servidores MCP con 58 tools gasta ~55K tokens antes de que la conversación empiece (Anthropic, Code execution with MCP, nov 2025). Claude Code limita las respuestas de tools a 25.000 tokens por defecto (Anthropic, Writing tools for agents, sep 2025).

Medir: client.messages.count_tokens(model=..., system=..., messages=[...], tools=[...]) → {"input_tokens": N}. Sin coste de generación, con rate limits propios. Cuenta messages=[] para el coste fijo; acumula mensajes por turno para la pendiente.

Partida inflada → modo de fallo (L2): historial → distraction · tool results → distraction/poisoning · tools → confusion.

Partida → palanca: la que domina la pendiente, primero. Tool results → compress/write · catálogo de tools → select · historial → compress.

Fuentes del corpus: Anthropic (Code execution with MCP · Writing tools for agents) · ACON (arXiv:2510.00615) · Anthropic Python SDK (count_tokens) · marco write/select/compress/isolate (Lance Martin / LangChain).