Tokens y contexto

Cómo se convierte el input en tokens, qué ocupa la ventana de contexto y qué ocurre cuando una sesión crece.

Actualizado 28 ago 2026

Tokens y tokenización

Un token es una unidad de la representación que procesa el modelo. Puede ser una palabra completa, parte de una palabra, puntuación o espacios. La división depende del tokenizer asociado al modelo.

La tokenización transforma el texto en tokens y después en identificadores del vocabulario. En el ejemplo documentado de BERT base cased que aparece debajo, Transformer se divide en los subwords transform y ##er; el visual también muestra el ID de vocabulario de cada token.

BERT base cased divide Using a Transformer network is simple en Using, a, transform, ##er, network, is y simple, y los convierte en los IDs 7993, 170, 11303, 1200, 2443, 1110 y 3014. — Figura 1. La misma frase pasa de texto a tokens y después a los IDs que procesa el modelo.

Muchos tokenizers utilizan subwords. Una palabra frecuente puede ocupar un token, mientras otra se divide en varias piezas conocidas. Esto permite representar palabras nuevas sin guardar cada palabra posible en el vocabulario.

El mismo texto no ocupa necesariamente lo mismo en dos modelos. Idioma, código, números y puntuación pueden cambiar el recuento. Cuando el límite o el coste importan, conviene utilizar el contador del modelo real en lugar de una regla aproximada de palabras por token.

Input y output

Los input tokens son los que recibe la inferencia. Los output tokens son los que genera el modelo.

En una request de chat, el input no es solo el último mensaje del usuario. También puede incluir instrucciones, historial, definiciones de tools y contenido recuperado. Una respuesta corta puede haber requerido procesar mucho input.

Las APIs suelen utilizar estos recuentos para mostrar usage y calcular precio. Algunas añaden categorías como cached input o detalles de reasoning, pero no son divisiones universales que todas las APIs representen igual.

Contexto

El contexto es la información disponible para el modelo durante una inferencia concreta. Lo que queda fuera no influye en esa llamada hasta que la aplicación lo recupera y lo introduce de nuevo.

Una sesión de coding agent puede enviar:

Las reglas de AGENTS.md.
La conversación necesaria para mantener la tarea.
Los schemas de read_file, shell y otras tools.
El resultado del último test y el fichero que se está modificando.

Todo eso consume contexto aunque la interfaz muestre principalmente la conversación. Un resultado de shell con miles de líneas puede ocupar más que muchos turnos de chat.

Una context window se divide en instrucciones, definiciones de tools, conversación, información recuperada, resultados de tools, input actual y capacidad restante. — Figura 2. Instrucciones, historial, tools, resultados e input actual comparten la misma capacidad disponible.

Ventana de contexto

La context window o ventana de contexto limita cuántos tokens puede manejar el modelo en una inferencia. En muchas APIs, input y nueva generación comparten esa capacidad.

Esto significa que una ventana casi llena deja poco margen para responder. Si una aplicación introduce 126K tokens en una ventana de 128K, no debería esperar una respuesta de 8K sin reducir antes el input.

Una ventana mayor permite enviar más material, pero no convierte todo ese contenido en información útil. Duplicados, decisiones antiguas y resultados irrelevantes siguen gastando tokens y pueden dificultar encontrar lo que importa.

En agentes, el límite lógico que gestiona el cliente y el límite físico cargado en el runtime pueden ser distintos. En el experimento de Qwen3.8-27B con OpenCode, OpenCode gestionaba la sesión como 64K mientras LM Studio cargaba alrededor de 81K para dejar margen frente a pequeños overflows.

Crecimiento de una sesión

En una API que reenvía el historial, cada turno puede procesar de nuevo buena parte de lo anterior. Una conversación que termina con 16K tokens no implica que el proveedor haya procesado solo 16K durante toda la sesión.

Los agentes hacen crecer el contexto con más tipos de información: cada tool call produce un resultado, los ficheros leídos pueden volver en turnos posteriores y las instrucciones suelen repetirse. Filtrar un log o leer solo un rango de líneas puede ser más importante que disponer de una ventana enorme.

Ingeniería de contexto desarrolla cómo elegir esa información.

Compactación

La compactación sustituye parte del historial acumulado por una representación menor para poder continuar. No aumenta el límite del modelo; reduce el contexto utilizado.

Antes de compactar, la conversación antigua y un resultado grande ocupan casi toda la ventana. Después, el estado anterior queda resumido y aumenta la capacidad disponible. — Figura 3. La compactación resume parte del contexto anterior y recupera espacio para continuar la tarea.

Un resumen puede conservar el objetivo, los cambios hechos y los problemas pendientes. También puede perder detalle. Por ejemplo, puede recordar que un test sigue fallando pero omitir una línea exacta del stack trace.

Si ese detalle puede volver a ser necesario, el log completo debería permanecer en un fichero recuperable. La compactación sirve para continuar la conversación; no sustituye a conservar evidencia exacta fuera del contexto.

Truncar es más simple: se elimina contenido antiguo para cumplir el límite. Compactar intenta preservar su significado útil. En ambos casos, la aplicación debe asumir que parte del contexto original ya no está disponible directamente.