Esa ventana de contexto de 128K puede ser una suposición — Hermes ahora lo dice


Pruebas un modelo nuevo en Bedrock y Hermes muestra ctx 128K en la barra de estado. Actúas en consecuencia: una pregunta que cruza archivos en un repositorio de treinta mil tokens. A mitad de la respuesta, empieza a comprimir el historial. Revisas después la tarjeta del modelo del proveedor y la ventana es de 1.050.000 tokens — ocho veces lo que te dijeron.

Peor aún, la etiqueta junto a ese número decía “detectado”. Parecía un hecho. Era un valor por defecto.

Un número decide tres cosas

Una ventana de contexto no es decoración. Decide cuándo se comprime el historial, cuánto material cabe en un prompt y cómo se comporta la recuperación de desbordamiento. Si te quedas corto, la compresión salta demasiado pronto y las tareas largas pierden su memoria a mitad de vuelo. Si te pasas, el proveedor rechaza la petición sin más.

Así que “este número se detectó o se adivinó” no es una cuestión académica. Explica dos síntomas completamente distintos.

De dónde sale el número

El resolver prueba fuentes en orden y se detiene en el primer acierto:

  1. Sondear al proveedor y tomar el valor exacto.
  2. La tabla estática del proveedor — en Bedrock, la tabla de modelos.
  3. La ventana del catálogo para la misma familia — lo que el catálogo de modelos de Hermes dice de esa familia.
  4. Un valor por defecto estático — 128K en Bedrock, 256K en la ruta genérica.

El paso 3 es lo que añade este cambio. Antes de él, un modelo de Bedrock ausente de la tabla estática caía directo del paso 2 al valor por defecto de 128K del paso 4, incluso cuando el catálogo de modelos ya conocía la ventana de la familia.

Ese paso solo aplica a modelos de Anthropic, OpenAI y xAI: IDs pelados, IDs con prefijo geo o global, e IDs dentro de un ARN de foundation-model o de inference-profile. La siguiente sección explica por qué se detiene ahí.

Qué afirma realmente “fallback”

El marcador hace exactamente una afirmación: ninguna fuente local reportó este número; es el valor de fallback.

Lo verás en la línea de sesión del gateway (con el texto “fallback, not a detected limit”), en /usage, en la barra de estado ancha, en el banner de bienvenida y en el resumen del cambio de /model; arreglos posteriores extendieron la misma etiqueta a /status y /context. En la barra de estado aparece como un sufijo corto.

Conviene no confundirlo con el otro sufijo: pinned significa que fijaste tú el valor, fallback significa que el sistema puso el valor por defecto. Ninguno de los dos significa que lo haya dicho el proveedor.

El marcador solo hace lecturas locales, falla abierto y nunca sondea, así que no puede ralentizar la barra de estado. Registra por profile home, modelo y URL base — lo que fue uno de los arreglos posteriores: la primera implementación usaba una memo de 60 segundos indexada sin el profile home, así que el veredicto de un perfil podía etiquetar la ventana de otro.

Un caso real: nueve días de GPT-6.1 Terra como 128K

El día que salió Terra (26 de octubre), el catálogo de modelos aprendió su ventana: 1.050.000. La tabla de Bedrock no cambió, y el resolver de Bedrock nunca consulta el catálogo. Así que v0.22.6, v0.22.7 y main resolvían Terra en Bedrock a 128K — y la compresión arranca al 75% de la ventana, es decir, a 96K.

Después del arreglo, un modelo de Bedrock de Anthropic, OpenAI o xAI que la tabla estática aún no lista toma la ventana de su familia del catálogo antes de que aplique el valor por defecto de 128K. Terra recupera 1.050.000, y GPT-5.4 también. El ID pelado de Terra además ganó enrutado: su tarjeta de modelo lista Mantle como el único endpoint para esa forma.

¿Por qué solo esos tres proveedores? Porque sus filas de catálogo coinciden de cerca con sus tarjetas de Bedrock: de 34 tarjetas, 27 son iguales, 6 están por debajo y 1 por encima. La única fila por encima es GPT-6.1 Sol (1.050.000 en el catálogo frente a una tarjeta de 1M), y tiene su propia fila en la tabla, que gana.

Otros proveedores no se pueden tomar prestados así. Sus filas de catálogo son ventanas directas del proveedor que pueden exceder lo que sirve Bedrock: Llama 3 8B tiene tarjeta de 8K mientras la fila llama dice 131.072; Qwen3 32B tiene tarjeta de 32K mientras la fila qwen dice 131.072. Tomarlas prestadas cambiaría una compresión temprana por una petición que el proveedor rechaza.

Por qué el valor por defecto no se sube sin más a un millón

La sugerencia aparece: los modelos nuevos son enormes, así que sube el suelo a 1M. La respuesta está en cien tarjetas de modelos de texto de Bedrock: 32 son de 1M o más, pero 36 son de 128K o menos y 8 quedan por debajo de eso (Llama 3 8B/70B a 8K; Mistral 7B, Mixtral, Small y Large 2402 a 32K; Qwen3 32B a 32K; Palmyra Vision a 4K).

Un suelo de 1M mandaría a esos modelos peticiones de 8 a 250 veces demasiado grandes. La respuesta de Bedrock a una carga sobredimensionada no ayuda: un InternalServerException opaco, o “Input is too long for requested model.” La recuperación de desbordamiento solo adopta un límite que el error cite de verdad, así que sin un número en el mensaje no hay nada que corregir — el turno comprime y vuelve a fallar en cada petición.

Así que el valor por defecto se queda en 128K y la ventana por familia se encarga de los modelos nuevos: los modelos que de verdad tocan el default son lanzamientos frontier recientes, y esos llegan primero al catálogo.

Aquí está todo el conjunto de tarjetas comprobado antes y después:

igual que la tarjeta por debajo de la tarjeta por encima de la tarjeta
antes 55 37 8
después 77 15 8

Las 8 filas “por encima” son todas tarjetas por debajo de 128K que tocan el default; este cambio las deja igual.

Configurarlo tú mismo

No hay clave de config nueva — los overrides son los mismos de antes. Fija uno global:

model:
  context_length: 200000

O haz override por proveedor y modelo:

model_overrides:
  bedrock:
    us.openai.gpt-6.1-terra:
      context_window: 1050000

La forma genérica es la misma: bajo model_overrides, primero el proveedor, luego el modelo, luego context_window.

Un valor fijado manda sobre un fallback y se muestra como pinned en vez de fallback. Si cambias de modelo o de ruta en el gateway, el pin configurado se descarta primero, para que el número de una ventana vieja nunca quede junto al nombre de un modelo nuevo.

Cómo saber si tu número es fiable

Una comprobación en cuatro pasos:

  1. Busca fallback después del número en /usage, /status o /context.
  2. Si está, mira la tarjeta del modelo o la documentación del proveedor para la ventana real.
  3. Fíjala con model_overrides cuando lo sepas.
  4. Confirma la dirección con los síntomas: compresión mucho antes de lo esperado significa que el número es demasiado pequeño; peticiones rechazadas que mencionan la longitud de la entrada significan que es demasiado grande.

Esto llegó a main el 4 de noviembre, después del punto de release v0.22.7, así que a día de hoy no está en una release — la próxima versión lo recoge.

Para bajar una capa más, el post sobre uso de contexto y anclas cubre cómo mantener la información correcta a través de la compresión, la guía de compresión lean-tail cubre cómo abaratar el historial que conservas, y el post sobre los valores por defecto de la ventana de contexto en Codex es el mismo mecanismo visto desde otro punto de entrada.