Kimi K3, un millón de tokens y la trampa del contexto: más memoria no es más arquitectura
Kimi K3 y K2.8 llevan los coding agents a contextos enormes. Es útil, pero cargar un repositorio entero no sustituye retrieval, herramientas, tests ni un buen harness.
- kimi
- coding agents
- llm
- ingeniería de software
- context window
Lo que realmente cambia un millón de tokens
Kimi se convirtió en uno de los productos que más me hicieron repensar la relación entre contexto e ingeniería de coding agents.
En septiembre de 2026, la documentación de Kimi Code presenta K3 como su modelo flagship de 2,8 billones de parámetros, con contexto de hasta un millón de tokens en planes compatibles. K2.8 Preview, desplegado el 11 de septiembre, también llega a 1M y se posiciona cerca de K3 con razonamiento más eficiente. Kimi Code además ya tiene cliente desktop y el 23 de septiembre la CLI llegó a la versión 2.1.0.
Es mucha capacidad dentro de una herramienta que puede leer archivos, editar código y ejecutar comandos.
La reacción natural es: perfecto, ahora puedo meter el repositorio entero en contexto.
Creo que esa es justamente la trampa.
1M de contexto resuelve un problema real
Primero, el lado positivo.
Un contexto grande es realmente útil en tareas como:
- refactors que atraviesan muchos módulos;
- migraciones de APIs internas;
- comprensión de convenciones dispersas;
- análisis de bases legacy sin documentación centralizada;
- cambios en monorepos;
- comparación de implementaciones distantes;
- sesiones largas donde el agente necesita mantener decisiones anteriores.
Quien ya usó un coding agent en una base grande conoce el síntoma contrario: el modelo entiende el archivo actual y pierde la arquitectura que existe alrededor.
Una ventana mayor reduce ese problema.
Pero reducir un problema no convierte "más contexto" en una estrategia universal.
Una context window no es working memory perfecta
Un millón de tokens es capacidad de entrada. No garantiza atención homogénea, recuperación perfecta ni razonamiento proporcionalmente mejor.
Cuando entra demasiada información aparecen otros costos:
- relevancia diluida — lo importante compite con cientos de archivos irrelevantes;
- latencia — llenar contexto cuesta tiempo;
- costo o cuota — contextos gigantes no son gratis;
- staleness — contenido cargado al inicio puede quedar viejo después de muchos cambios;
- conflicto — pueden coexistir patrones antiguos y nuevos;
- observabilidad — se vuelve más difícil entender qué influyó en una decisión.
Prefiero pensar el contexto como una cache cara, no como un disco infinito.
Un buen agente no "lo sabe todo"; sabe encontrar
La arquitectura que me parece más robusta combina tres capas.
1. Contexto estable
Poca información, pero de alto valor:
AGENTS.mdo equivalente;- convenciones del proyecto;
- comandos de tests;
- reglas de seguridad;
- un mapa corto de arquitectura.
2. Retrieval bajo demanda
El agente usa herramientas para buscar lo que necesita:
find symbol → read file → inspect imports → search tests → inspect schema
Trae al contexto lo relevante cuando se vuelve relevante.
3. Contexto largo como margen, no como excusa
Cuando una tarea realmente atraviesa decenas de archivos, una ventana grande permite mantener esos detalles sin compactar agresivamente.
La diferencia es sutil: usar 1M porque la tarea lo exige frente a usar 1M porque no quiero seleccionar contexto.
Un ejemplo: agregar autorización a una feature
Imagina que el agente necesita agregar un permiso nuevo.
El enfoque ingenuo sería cargar src/** y preguntar qué hacer.
Yo prefiero un loop instrumental:
1. localizar feature
2. localizar patrón actual de autorización
3. encontrar una feature similar
4. encontrar tests de esa política
5. identificar la capa responsable
6. implementar
7. ejecutar tests específicos
8. ejecutar checks globales
El agente no necesita tener todo el proyecto en la cabeza desde el principio. Necesita un camino confiable para adquirir contexto.
Ese principio sigue valiendo incluso con modelos mejores.
Kimi Code es interesante también por el harness
Otra cosa que destaca en Kimi Code actual es que la historia no es solo el modelo.
La herramienta cubre varias partes del harness:
- CLI;
- cliente desktop;
- edición y ejecución de comandos;
- modos de permisos;
- subagentes;
- plugins;
- MCP;
- sesiones largas;
- modos de plan y goal;
- control remoto;
- integración con herramientas de terceros.
Eso refuerza una tendencia de 2026: comparar solo benchmarks de modelos dice cada vez menos sobre la experiencia real de ingeniería.
Un coding agent es aproximadamente:
modelo
+ gestión de contexto
+ herramientas
+ política de permisos
+ entorno de ejecución
+ memoria/sesión
+ tests
+ observabilidad
+ UX de revisión
Cambiar el modelo modifica una pieza. A veces es la más importante; muchas veces no es el único cuello de botella.
La compatibilidad de protocolos también importa
Kimi Code documenta endpoints compatibles con protocolos OpenAI y Anthropic e integración con herramientas como Claude Code, OpenCode, Codex y Hermes.
Para mí eso es estratégicamente interesante porque reduce el acoplamiento entre modelo y harness.
Si puedo probar K3 dentro de un flujo que ya uso, la comparación se vuelve mucho más honesta. No estoy cambiando IDE, memoria, tools y modelo al mismo tiempo.
Cambio una variable.
Esa portabilidad es una característica de producto más importante de lo que parece.
Cómo evaluaría Kimi en un proyecto real
No empezaría por HumanEval ni por una demo de "construye una app completa".
Tomaría una muestra de tareas reales del repositorio:
| Tipo de tarea | Qué medir |
|---|---|
| Bug pequeño | tiempo hasta patch correcto |
| Refactor | regresiones y consistencia |
| Feature multiarchivo | completitud de la implementación |
| Investigación | calidad de la causa raíz |
| Tests | cobertura del comportamiento importante |
| Migración | número de intervenciones humanas |
Después registraría algo así:
type AgentRun = {
taskId: string
model: string
contextTokens: number
durationMs: number
cost?: number
attempts: number
testsPassed: boolean
humanEditsAfterAgent: number
accepted: boolean
}
Sin telemetría, "este modelo parece mejor" es solo memoria selectiva.
Lo que K2.8 dice sobre la carrera actual
K2.8 Preview es interesante porque Moonshot destaca explícitamente la eficiencia de reasoning, no solo capacidad máxima.
Eso apunta a un cambio saludable: después de años preguntando "¿cuánto puede razonar el modelo?", empezamos a preguntar "¿cuánto razonamiento necesita realmente esta tarea?".
Tener niveles low, high y max convierte el esfuerzo de reasoning en un parámetro de ingeniería.
Puedo imaginar un routing como este:
const effort = task.risk === 'high'
? 'max'
: task.files <= 2
? 'low'
: 'high'
No tiene que ser literalmente este código. La idea útil es que calidad, latencia y costo dejan de ser una sola configuración global.
Long context cambia el límite, no los fundamentos
Lo que más me gusta de Kimi K3 no es simplemente "ahora cabe 1M".
Es que un límite mayor permite construir agentes que no tengan que compactar todo constantemente.
Los fundamentos siguen siendo los mismos:
- contexto relevante gana a contexto bruto;
- tests ganan a confianza subjetiva;
- herramientas ganan a memoria estática;
- permiso explícito gana a autonomía irrestricta;
- un diff verificable gana a un resumen convincente;
- la arquitectura del harness gana a un benchmark aislado.
Un modelo con contexto enorme puede ser un gran motor.
Pero un motor no es un coche.