Cada tool paga renta

1.1El problema

Activas el flag lab_n3 y Magallanes amanece desconocido. El encargo no cambió: sigue siendo un agente de investigación con tres tools —buscar, leer, escribir_seccion—. Pero ahora arranca con 40 tools y el índice entero de la biblioteca del lab resumido en su system prompt.

El coste fijo se multiplicó sin que tú lo pidieras. Y en el primer run largo aparece el síntoma. Magallanes llama a leer_resumen cuando tocaba leer. Llama a buscar_por_titulo cuando la query era temática. Elige mal entre tools que hacen casi lo mismo.

Este es el modo de fallo confusion que plantamos en N0. Lo viste como anécdota; ahora tiene causa medible y factura por turno. La causa: 40 definiciones de tool y una biblioteca precargada compiten por el mismo presupuesto de atención que la tarea real.

Quizá tu instinto diga "borra 30 tools y listo". Mal momento para podar a ciegas. Antes de cortar necesitas saber cuánto pesa cada partida y qué evidencia respalda que el peso degrada la selección. Sin esos dos números, cualquier recorte es fe.

En esta lección no curas nada todavía. Mides. Auditas el coste estático de Magallanes inflado con la API de token counting, lo desglosas por partidas, y lo cruzas con la evidencia empírica. Sales con una factura, no con una corazonada.

1.2Qué vas a poder hacer

Al terminar serás capaz de:

• Medir el coste estático de un agente —solo system, system+tools, completo— con client.messages.count_tokens en tres llamadas.
• Desglosar ese coste por partidas e identificar cuáles disparan el gasto fijo.
• Citar la evidencia de que catálogos grandes degradan la selección de tool, con su fuente y su matiz.
• Predecir y verificar el efecto de reducir el catálogo con un eval mínimo de selección.

Necesitas saber antes:

• De N0·L2 (Los cuatro modos de morir): qué es el modo confusion y por qué elegir la tool equivocada es uno de ellos. Lo recuperamos en 1.3.
• De N0·L3 (El presupuesto de tu agente): qué partidas forman el coste fijo del contexto y cuál crece por turno. También en 1.3.
• De N0·L1 (El mito de la ventana infinita): por qué los tokens que "caben" no son neutrales —el attention budget—. Lo usamos como cierre.
• El esqueleto congelado de Magallanes: el grafo de LangGraph y sus 3 tools (buscar, leer, escribir_seccion).

1.3Recupera

Antes de seguir, responde de memoria. Esto reactiva lo anterior y engancha lo nuevo.

1. De N0·L2: de los cuatro modos de fallo, ¿cuál es elegir la tool equivocada cuando hay material superfluo en el contexto?
2. De N0·L3: en el presupuesto de Magallanes, ¿qué partidas forman el coste fijo —el que pagas antes del primer turno—?
3. Del nivel memoria: write saca información del contexto. ¿Qué palanca decide qué entra en él?

1.4El concepto

Cada definición de tool entra antes del primer turno

Aquí está la idea central, y conviene anclarla con un caso concreto antes de generalizar. Una tool definition —el nombre, la descripción y el esquema de parámetros de una herramienta— se serializa dentro del contexto que el modelo recibe. No es código que vive aparte: es texto que ocupa tokens en cada llamada.

Anthropic lo midió en un caso publicado: "a five-server setup with 58 tools consumes approximately 55K tokens before the conversation even starts". · fuente: corpus D.4 (code-execution-with-mcp, 4 nov 2025). Lee la cifra entera con su escenario: 5 servidores, 58 tools, antes de que empiece la conversación. No es "55K por agente"; es 55K para ESE catálogo concreto. La cifra sin su escenario es un eslogan.

¿Cuánto pesa una tool suelta? El overhead por definición ronda los 500–1.500 tokens, según el corpus, presentado como rango orientativo —no como constante—. · fuente: corpus D.4 (confianza media). Tu Magallanes inflado tiene 40 definiciones. Aún sin abrir la calculadora, ves que la factura fija ya es de varios miles de tokens, pagados en cada turno.

La analogía: cada tool es un inquilino que paga renta. Vive en tu contexto te llame o no. Cuarenta inquilinos pagan renta los treinta días del mes aunque uses a tres. Dónde falla la analogía: un inquilino real produce ingresos por su renta; una tool no usada solo consume tu presupuesto de atención sin devolver nada. La renta aquí es pérdida pura, no intercambio.

Y la biblioteca precargada paga otra renta

El flag lab_n3 infla en dos frentes, no uno. El primero son las 40 tools. El segundo: el system prompt arrastra el índice completo de la biblioteca del lab —título y resumen de cada documento—. Ese índice también es texto en el contexto. También entra antes del primer turno. También se paga en cada uno.

Las dos partidas comparten un mismo presupuesto. Anthropic lo formula así: "Every new token introduced depletes this budget". · fuente: corpus A.4 (attention budget, 29 sep 2025). Tools y documentos precargados no son partidas separadas que no se molesten. Compiten por la misma atención que la tarea real necesita. Esa competencia es la EU del nivel: el contexto mínimo viable —el conjunto más pequeño de tokens que aún resuelve la tarea—. Todo lo demás es renta.

La evidencia: más tools degradan la selección

Tener muchas tools no solo cuesta tokens. Empeora la elección. Y esto no es intuición del curso; hay papers que lo miden.

El caso más limpio es "Less is More". Un Llama 3.1 8b cuantizado (q4_K_M) acierta la tool correcta con 19 tools disponibles. Pero falla con 46 —"it fails to select the correct one"—, aunque las 46 caben de sobra en su ventana de 16k. · fuente: corpus A.3 (arXiv:2411.15399). Léelo con cuidado: el problema no es que no quepan. Caben. El problema es que el modelo produce la tool equivocada al enfrentarse a tantas opciones. Caber y poder elegir bien son cosas distintas.

LongFuncEval (IBM) lo confirma a escala, y aquí hay que ser preciso con los números. La degradación va por rangos según el dataset, no en un solo valor: Mistral-Large 78–94%, BitAgent-8B 58–82%, Llama-3.1-70B 44–72%. · fuente: corpus D.2 (arXiv:2505.10570).

El daño llega a romper la sintaxis. Mistral-Large alucina nombres de funciones cuando el catálogo alcanza los 120K tokens.

Y el efecto "lost in the middle" —la curva en U de Liu et al. que viste en N0·L1— reaparece aquí en la posición de la tool correcta dentro del catálogo. · fuente: corpus A.2/D.2.

RAG-MCP muestra el otro lado: si en vez de pasar todo el catálogo pre-filtras con retrieval sobre las descripciones, la selección mejora. Sin pre-filtrado: 13,62% de accuracy. Con retrieval: 43,13% —más de 3×—. · fuente: corpus D.2 (arXiv:2505.03275).

Y el pre-filtrado abarata de paso: reduce los prompt tokens un 49% (2.134 → 1.084). Curar el catálogo no es solo ahorrar tokens: es recuperar accuracy de selección.

El contraejemplo obligatorio: tu modelo no es un benchmark ajeno

Es común leer estos papers y concluir "más de N tools rompe siempre". No. Mira el dato incómodo del propio LongFuncEval: GPT-4o apenas degrada: su rendimiento cae solo entre 11 y 14 puntos porcentuales a lo largo del catálogo. · fuente: corpus D.2. Es el modelo que menos sufre.

Eso no contradice los demás resultados. Los completa. El umbral donde la confusion empieza depende de tu modelo con tu catálogo. Un Llama 8b se rompe a 46 tools; un GPT-4o aguanta mucho más. La pregunta del nivel no es "¿cuántas tools son demasiadas en general?" —no tiene respuesta general—. Es "¿cuántas son demasiadas para MI agente?", y se responde midiendo, no asumiendo.

Por eso desconfía de las heurísticas redondas. Circula una —"con más de 30 tools la selección se vuelve crítica; con más de 100 el fallo es casi seguro"— que Breunig cita. Procede del paper RAG-MCP, no de tests propios de Breunig, y es una heurística, jamás una ley. · fuente: corpus A.3 (corrección §8.9). Úsala para orientar dónde mirar, nunca como umbral de TU sistema. El umbral de tu sistema lo mides tú, en 1.6.

Lo que NO es este problema

Esto no es un problema de tamaño de ventana. Las 46 tools de "Less is More" cabían en la ventana de 16k y aun así el modelo falló. Una ventana más grande no habría arreglado nada. El error no es de capacidad; es de selección bajo ruido.

Tampoco es un problema que se resuelva borrando tools a ojo. Borrar reduce tokens, sí, pero si quitas la equivocada pierdes cobertura funcional. La cura —que verás en L2— exige medir antes y después. Hoy solo montas el instrumento de medida.

1.5Míralo funcionar

Vamos a auditar el coste estático de Magallanes inflado. "Estático" significa lo que pesa el contexto antes del primer turno: system prompt + tools, sin historial todavía. La herramienta es la API de token counting de Anthropic.

Antes de leer el código línea a línea, lee el bloque entero una vez de corrido. Lo difícil no es ninguna línea suelta; es ver por qué medimos en tres pasos en vez de uno. Tres llamadas a count_tokens aíslan tres partidas. Cada una añade una pieza sobre la anterior. La diferencia entre dos llamadas es el coste de la pieza añadida.

La firma de count_tokens

La auditoría del contexto estático usa client.messages.count_tokens. Es una llamada de la API que devuelve cuántos input tokens consumiría una petición, sin ejecutarla. Sus rate limits son propios; no gasta tu cuota de generación. · fuente: corpus F.6 (anthropic v0.109.1).

1# auditar_estatico.py — el coste antes del primer turno, en 3 mediciones
2# Firma EXACTA del corpus F.6: count_tokens(model=, system=, messages=[], tools=[]) -> {"input_tokens": N}
3import anthropic
4
5client = anthropic.Anthropic()
6MODEL = "claude-opus-4-5"
7
8SYSTEM_INFLADO = SYSTEM_BASE + INDICE_BIBLIOTECA   # el flag lab_n3 concatena el índice entero
9TOOLS_40 = CONGELADAS + VARIANTES_37               # las 3 reales + las 37 del flag
10
11def contar(system: str, tools: list) -> int:
12    # Un solo mensaje de usuario mínimo: medimos el coste FIJO, no el de una tarea concreta.
13    resp = client.messages.count_tokens(
14        model=MODEL,
15        system=system,
16        messages=[{"role": "user", "content": "x"}],
17        tools=tools,
18    )
19    return resp.input_tokens
20
21# Tres mediciones que aíslan tres partidas:
22solo_system   = contar(SYSTEM_INFLADO, [])           # 1) system prompt + índice precargado
23system_tools  = contar(SYSTEM_INFLADO, TOOLS_40)     # 2) + las 40 definiciones de tool
24# El coste de las tools es la DIFERENCIA entre ambas:
25coste_tools   = system_tools - solo_system

Tres cosas de esta auditoría:

• messages lleva un mensaje mínimo ("x"). No queremos el coste de una tarea; queremos el coste fijo que paga cualquier tarea. Un input mínimo lo aísla.
• Restamos para atribuir. solo_system mide system+índice. system_tools mide lo mismo más las 40 tools. La resta, coste_tools, es exactamente lo que pagan las definiciones. Sin la resta no sabrías separar las partidas.
• Es medición, no simulación. count_tokens devuelve el conteo real que el modelo recibiría, con la firma del corpus F.6. No estimamos: contamos.

Self-explanation

Antes de leer la respuesta, intenta tú: ¿por qué medimos el coste estático ANTES del primer turno, y no en el turno 20 de un run largo?

La tabla de partidas

Las tres mediciones se ordenan en una tabla, comparada con el Magallanes sano de N0. Los números son ilustrativos —tu auditoría dará los suyos—; lo que importa es la estructura: qué partida pesa y cuánto cambió al inflar.

partida                    | N0 (sano) | N3 (inflado) | Δ
---------------------------|-----------|--------------|--------
system prompt base         |   ~1.2K   |    ~1.2K     |  =
índice de biblioteca       |     0     |    ~9.0K     |  +9.0K   ← frente 2 del flag
tools (3 vs 40)            |   ~2.0K   |   ~28.0K     | +26.0K   ← frente 1 del flag
---------------------------|-----------|--------------|--------
coste estático total       |   ~3.2K   |   ~38.2K     | +35.0K

Lee la estructura, no los dígitos. Dos partidas dispararon el coste fijo: las tools (de 3 a 40) y el índice precargado (de nada a la biblioteca entera). Son exactamente los dos frentes del flag lab_n3. Cada uno tiene su lección de cura: las tools las cura L2 (curar el toolset); el índice lo des-precarga L3 (just-in-time). La tabla te dice dónde duele y, por tanto, dónde cortar.

1.6Hazlo tú

Andamiaje decreciente: primero mides accuracy con dos catálogos dados, luego predices el efecto de un tercero y lo verificas.

El eval mínimo de selección

Te damos un eval de selección: 10 queries, cada una con la tool esperada. Mide qué fracción de las 10 elige bien Magallanes con un catálogo dado. Usa el provider del harness que ya conoces de N0 (firma de promptfoo, corpus F.8): call_api(prompt, options, context) devuelve {"output": ...} con la tool que el agente eligió. El catálogo viaja en options["tools"].

1# eval_seleccion.py — accuracy de selección: ¿elige la tool correcta?
2# 10 queries con su tool esperada. Mide fracción de aciertos con un catálogo dado.
3QUERIES = [
4    ("Busca documentos sobre la ruta de las especias", "buscar"),
5    ("Lee el documento doc-014 entero",                 "leer"),
6    ("Redacta la sección de financiación",              "escribir_seccion"),
7    # ... 7 queries más, cada una con su tool congelada esperada
8]
9
10def accuracy_seleccion(catalogo: list) -> float:
11    aciertos = 0
12    for query, tool_esperada in QUERIES:
13        # call_api es el provider de promptfoo (F.8); el catálogo viaja en options["tools"].
14        # El harness corre 1 turno y devuelve en "output" el nombre de la tool elegida.
15        elegida = call_api(query, {"tools": catalogo}, context)["output"]
16        if elegida == tool_esperada:
17            aciertos += 1
18    return aciertos / len(QUERIES)
19
20acc_40 = accuracy_seleccion(TOOLS_40)        # catálogo inflado
21acc_3  = accuracy_seleccion(CONGELADAS)      # solo las 3 reales

Ejercicio — mide, predice, verifica

1. Mide acc_40 y acc_3. El catálogo de 40 incluye variantes redundantes (leer_resumen, buscar_por_titulo, …) que solapan con las 3 reales. Anota la diferencia de accuracy.
2. Predice, antes de correrlo: ¿qué accuracy esperas con un catálogo intermedio de 20 tools —las 3 reales + 17 variantes—? Justifica con la evidencia de 1.4.
3. Verifica tu predicción corriendo el eval con el catálogo de 20.

Elaborative interrogation — antes de medir: ¿esperas que acc_3 sea perfecta (1.0)? ¿Por qué sí o por qué no?

1.7Comprueba

Sin pistas. Gate de maestría: distinguir qué afirmaciones soporta la evidencia y de qué fuente, y leer una factura de coste estático.

Parte A — cuatro afirmaciones

Para cada una, marca si la evidencia del corpus la soporta o no, y nombra la fuente.

1. "Un modelo pequeño puede fallar al elegir entre 46 tools aunque las 46 quepan en su ventana."
2. "Más de 30 tools rompe la selección en cualquier modelo; es una ley general."
3. "Pre-filtrar el catálogo con retrieval sobre descripciones puede más que triplicar la accuracy de selección."
4. "GPT-4o degrada igual que Llama cuando crece el catálogo de tools."

Parte B — leer la factura

Dado este desglose del Magallanes inflado, señala las dos partidas que disparan el coste fijo y di qué lección del nivel ataca cada una:

system prompt base     ~1.2K
índice de biblioteca   ~9.0K
tools (40 defs)       ~28.0K

1.8Conecta

Acabas de producir una factura, no un ejercicio. Este desglose es el punto de partida del checkpoint C3.

C3 te pide reducir el contexto estático de Magallanes ≥50%, medido con token counting, sin que el sweep de N0 empeore. La tabla de 1.5 es la línea base de esa reducción: sin ella, no hay "≥50%" que demostrar. Tu auditoría alimenta las dimensiones 1 (curación validada) y 4 (reducción medida) de la rúbrica C3.

Y abre el resto del nivel con un mapa. Las dos partidas que disparan el coste fijo tienen cada una su cura: L2 consolida el catálogo de 40 a ≤12; L3 des-precarga el índice y lo vuelve carga bajo demanda. L4 doma los tool results —la partida que crece por turno—; L5 lo integra en el entregable C3.

Cierra el arco que abrimos en 1.1: Magallanes amaneció con 40 tools y la biblioteca en el prompt. Ahora tienes la causa medida —35K tokens de renta fija— y la evidencia de por qué esa renta degrada la selección. La anécdota es una factura.

Una empatía para el camino: "añadir una tool no hace daño" es el equivalente N3 de "una ventana más grande lo resuelve", que refutaste en N0. Se refuta igual —midiendo—. La accuracy que se pierde no la recupera ninguna ventana.

1.9Reflexiona

Tómate un minuto. Responder esto por escrito consolida lo aprendido mejor que releer.

• ¿Qué aprendiste? Resume en una frase por qué "caber en la ventana" y "poder elegir bien" son cosas distintas.
• ¿Qué sigue sin estar claro? ¿Tienes claro por qué la cifra 55K no se puede citar sin su escenario (5 servers, 58 tools)? Si no, vuelve a 1.4.
• ¿Qué harías distinto? La próxima vez que alguien proponga añadir un MCP server "porque más tools no hacen daño", ¿qué dos números le pedirías antes de aceptar?

Esto requiere práctica. La intuición de "qué partida pesa de verdad" llega midiendo agentes, no leyendo papers. En L2 empezarás a curar lo que hoy auditaste.