Los modelos pequeños deberían decidir qué ven los modelos grandes

Se está volviendo habitual dejar que un modelo de IA potente orqueste a otros más pequeños. El modelo grande planifica el trabajo y luego delega la clasificación, la extracción o las ediciones predecibles en modelos más rápidos y económicos.

Esto tiene sentido, pero solo optimiza quién realiza cada tarea.

Creo que existe una ganancia de eficiencia aún mayor: utilizar modelos pequeños no solo bajo el modelo grande, sino alrededor de él.

Podrían preparar su contexto antes de que razone, filtrar la salida de sus herramientas y preservar la información útil a medida que la sesión crece.

El modelo grande seguiría tomando las decisiones difíciles. Pero como es inteligente, lento y caro, cada token que procese debería ganar su lugar.

Preparar el contexto en lugar de acumularlo

Los agentes de programación crean un historial de trabajo extenso: mensajes, planes, salidas de comandos, archivos, errores y versiones superadas de la misma información. Cada elemento pudo haber sido útil en su momento, pero pocos siguen siéndolo para cada decisión posterior.

Los sistemas actuales suelen acumular este material hasta que limpian los resultados de las herramientas, guardan memorias o compactan la conversación. La documentación de Anthropic trata el contexto irrelevante como una amenaza para el enfoque del modelo, no solo para la capacidad de la ventana de contexto.

Un modelo pequeño podría seleccionar el contexto antes de cada paso de razonamiento importante. Su salida podría verse así:

{
  "include_messages": [2, 7, 11],
  "include_files": [
    { "path": "src/auth.ts", "lines": "48-126" },
    { "path": "tests/auth.test.ts", "match": "refresh token" }
  ],
  "include_tool_results": ["call_184"],
  "durable_notes": ["The user rejected cookie-based sessions."],
  "omit_reason": "Unrelated build logs and superseded files"
}

El modelo grande recibiría los pasajes seleccionados de la fuente, no un resumen vago de todo el historial. Se trata de una recuperación sobre el espacio de trabajo evolutivo del propio agente.

A la izquierda, un espacio de trabajo desordenado con archivos, pruebas fallidas, planes antiguos y notas rápidas. Un selector de contexto elige cuatro de ellos, que se muestran a la derecha como el contexto de trabajo entregado al modelo principal. — El espacio de trabajo lo guarda todo. Lo que llega al modelo es solo lo que necesita la siguiente decisión.

Filtrar las salidas de las herramientas antes de que el modelo principal las lea

Una API o un servidor MCP pueden devolver docenas de campos cuando el agente solo necesita tres. Los IDs, las marcas de tiempo, los metadatos de paginación y las descripciones repetidas permanecen en la transcripción y pueden procesarse de nuevo en turnos posteriores.

Un modelo pequeño podría situarse entre la respuesta de la herramienta y el modelo principal. Filtraría la salida bruta según el objetivo actual, devolvería un subconjunto tipado y preservaría una referencia al resultado intacto. Esto es especialmente valioso cuando el desarrollador del agente no puede modificar la herramienta externa.

Esta misma capa podría clasificar archivos, localizar secciones relevantes y excluir contenido generado antes de que el modelo grande los lea.

Una respuesta bruta extensa de una herramienta pasa por un filtro de carga, que entrega una lista corta de campos útiles al modelo principal mientras la respuesta bruta se archiva como evidencia recuperable. — El filtro reduce lo que llega al modelo y la respuesta bruta permanece recuperable.

Comprimir la información mientras está fresca

La compactación suele ser reactiva: una vez que el contexto alcanza un umbral, un historial extenso se convierte en un resumen corto. Para entonces, es posible que el modelo principal ya haya releído contenido verboso muchas veces. Un resumen tardío también debe preservar detalles de varias etapas cuya relevancia futura es difícil de predecir.

El historial de un agente tiene dos lectores con necesidades diferentes. Los humanos necesitan los mensajes completos y el lenguaje natural para comprender y auditar lo ocurrido. Los modelos de IA necesitan los mismos hechos en la menor cantidad de tokens fiables.

Un modelo pequeño podría mantener ambas versiones a medida que llega la información: la transcripción completa legible por humanos y una representación compacta legible por máquina cargada en el contexto activo. Cada elemento comprimido estaría vinculado a su original.

La versión para máquina no necesitaría una prosa pulida. Podría adoptar la tendencia reciente “Caveman” en agentes de programación: enunciados telegráficos que eliminan artículos, cortesías, matices y rellenos conectores, preservando el detalle técnico. El objetivo no es que los humanos hablen así, sino dejar de pagar a modelos grandes para que relean lenguaje escrito para humanos.

Un registro de pruebas de 2.000 tokens podría convertirse en:

14 tests passed. refreshes expired token failed because expiresAt was undefined at auth.test.ts:88. Full output: artifact test-run-184.

El resultado, el fallo, el valor relevante, la ubicación y la ruta hacia la evidencia sobreviven. El ruido no.

Esto es un mantenimiento continuo en lugar de una compactación de emergencia.

Dos líneas temporales. En la primera, los mensajes brutos se acumulan hasta que aparece una señal de advertencia y luego colapsan en un único resumen compacto. En la segunda, un gestor de memoria comprime cada mensaje al llegar, produciendo un registro compacto en todo momento. — Con la compactación tardía, pagas por los mismos tokens en cada turno hasta alcanzar el umbral. Comprimir sobre la marcha significa pagar una sola vez.

La economía es plausible

La inferencia extra vale la pena solo si ahorra más de lo que cuesta en dinero, latencia y errores. Un modelo sencillo demuestra que el umbral financiero puede ser bajo.

Consideremos una sesión de programación ilustrativa de 20 pasos. El modelo grande recibe 1,45 millones de tokens de entrada en total. Un modelo de contexto lee el mismo historial, emite 10.000 tokens de instrucciones de selección y reduce la entrada del modelo grande a 560.000 tokens. Ambas versiones producen 40.000 tokens de salida del modelo grande.

Dos columnas. A la izquierda, una pila alta de documentos va directa al modelo principal, que genera una etiqueta de coste roja y grande. A la derecha, un filtro pequeño adelgaza la pila primero por una fracción del precio, y la etiqueta de coste del modelo principal es mucho más pequeña. — El modelo pequeño se paga dos veces si lo que elimina cuesta más leerlo que ejecutarlo.

Utilizando los precios estándar de la API publicados el 4 de julio de 2026, combinar Gemini 3.1 Flash-Lite (0,25 $ de entrada y 1,50 $ de salida por millón de tokens) con Claude Fable 5 (10 $ de entrada y 50 $ de salida) resulta en:

	Sin filtrado	Con filtrado
Entrada modelo grande	1,45M tokens	0,56M tokens
Coste modelo grande	16,50 $	7,60 $
Coste modelo contexto	ninguno	0,38 $
Total	16,50 $	7,98 $

Coste total de una sesión de 20 pasos

Sin filtrado$16.50

Con filtrado$7.98

La última fila de la tabla, a escala. El ahorro es de 8,52 $, o el 51,7%.

El filtrado se amortiza tras eliminar 37.750 tokens de entrada de Fable, que es el 2,6% de la entrada bruta.

El filtro puede fallar

Eliminar contexto puede eliminar la pista que resuelve la tarea. Un modelo pequeño puede descartar una línea de registro inusual, distorsionar una restricción del usuario o omitir un identificador necesario para la siguiente llamada a una herramienta.

Por lo tanto, la arquitectura necesita algunas reglas estrictas:

mantener las entradas brutas recuperables;
hacer que las decisiones de filtrado sean estructuradas y auditables;
nunca comprimir instrucciones de usuario ni restricciones de seguridad;
incluir información incierta;
permitir que el modelo principal solicite la evidencia original;
medir el éxito de la tarea, no solo el ahorro de tokens.

Los modelos pequeños deben gestionar el acceso a la evidencia, no convertirse en una fuente de verdad invisible.

El experimento importa más que la estimación

La idea debe probarse frente a tres alternativas: contexto acumulado bruto, compactación basada en umbrales y filtrado semántico continuo.

Cada sistema debe ejecutar las mismas tareas de programación. La evaluación debe medir el coste total de tokens, la latencia, la utilización de la caché y el éxito de la tarea. También debe registrar cada caso en el que el filtrado elimine evidencia que el modelo principal necesite más adelante.

1Un conjunto de tareasEl mismo trabajo de programación para cada uno
2Tres sistemasBruto, compactación por umbral, filtrado continuo
3Cuatro medidasCoste, latencia, aciertos de caché, éxito
4Un veredictoLo más barato solo cuenta si sigue funcionando

El ahorro de tokens por sí solo declararía ganador al filtro más agresivo, por eso la calidad de la ejecución es la medida decisiva y no una nota a pie de página.

La arquitectura gana solo si reduce el coste sin reducir la calidad de la ejecución. Hasta que exista tal prueba, la economía es una razón para experimentar, no una prueba de que el sistema funcione.

Un nuevo rol para los modelos pequeños

El enrutamiento de modelos pregunta: ¿qué modelo debe realizar esta tarea?

Esta arquitectura pregunta: ¿qué merece la atención del mejor modelo?

Enrutamiento de modelosQuién hace el trabajo

Lee la tarea, elige un modelo
El modelo barato hace los trabajos fáciles
El contexto es lo que sea que se haya acumulado

Modelos pequeños alrededor del grandeSobre qué se hace el trabajo

El mejor modelo se reserva las decisiones difíciles
Los modelos pequeños eligen qué lee
El contexto se selecciona antes de cada paso

Ambos no son alternativas. El enrutamiento decide quién responde; esto decide en qué se basa la respuesta.

Los modelos pequeños podrían convertirse en bibliotecarios de contexto, editores de carga y mantenedores de memoria. Prepararían el espacio de trabajo antes de que el modelo principal razone y luego preservarían los resultados útiles después de que actúe.

La idea es más relevante para los agentes de programación porque generan mucho material intermedio. También se aplica a la investigación, el soporte y otros flujos de trabajo prolongados que combinan conversación, herramientas y datos externos.

El modelo más capaz no debería leer cada línea simplemente porque el sistema puede enviársela.

Cada token debería estar ahí por una razón.