Envié las mismas tareas de programación a Kimi K2.7 Code y Claude Opus 4.8 a través de una sola API y medí lo que devolvían. En cuanto a corrección, quedaron empatados: ambos resolvieron sin fallos una trampa de precedencia de SemVer y un error oculto de fusión de intervalos. Pero Opus respondió de 3 a 9 veces más rápido y con una cuarta parte de los tokens de salida, mientras que Kimi costó aproximadamente un 46% menos por tarea al precio de lista. Así que la elección no tiene que ver con qué modelo es "más inteligente". Si estás ejecutando trabajo de programación sensible al coste o por lotes, Kimi K2.7 gana en precio. Si necesitas baja latencia, un contexto de 1M de tokens o un modelo de revisión final en el que confíes, Opus 4.8 merece la prima, y muchos equipos terminan enrutando entre los dos.
Práctico: ejecuté las mismas tareas de programación en ambos
Cómo lo probé: IDs de modelo kimi-k2.7-code y claude-opus-4-8, llamados a través de un único endpoint de gateway compatible con OpenAI el 2026-07-13, una sola ejecución por tarea con los parámetros predeterminados y sin caché de prompt. La latencia se mide como tiempo real del reloj del lado del cliente, así que incluye el tiempo de red y de cola, no solo la generación. Antes de puntuar, le pedí a cada modelo que se identificara como comprobación de cordura (Kimi respondió "made by Moonshot AI," Opus respondió Anthropic); eso es una comprobación de enrutamiento, no una prueba de versión. Esta es una muestra de dos tareas, no un benchmark. Muestra un comportamiento que se puede percibir; no puede medir el rendimiento agéntico de múltiples turnos.
Tarea 1 pidió a cada modelo implementar una función compare_semver() siguiendo la especificación SemVer 2.0.0, incluida la parte que la mayoría de las implementaciones hace mal: la precedencia de pre-lanzamiento, donde 1.0.0-alpha.1 < 1.0.0-alpha.beta, los identificadores numéricos tienen menor rango que los alfanuméricos, y beta.11 > beta.2 numéricamente en lugar de por orden alfabético. Califiqué cada respuesta contra una matriz de 72 comparaciones construida a partir del orden canónico de la especificación. Tarea 2 entregó una función defectuosa merge_intervals() cuyo verdadero error era last[1] = cur[1] en lugar de max(...), una línea que traga silenciosamente un intervalo completamente contenido como [1,10],[2,3]; califiqué contra 5 casos, incluido ese intervalo contenido.
Métrica | Kimi K2.7 Code | Claude Opus 4.8 |
|---|---|---|
Corrección de la tarea 1 (72 precedencia + casos límite) | 72/72 | 72/72 |
Corrección de la tarea 2 (5 casos incl. intervalo contenido) | 5/5 | 5/5 |
Latencia de la tarea 1 (lado del cliente) | 49.1s | 5.3s |
Latencia de la tarea 2 (lado del cliente) | 11.5s | 7.6s |
Tokens de la tarea 1 (entrada / salida) | 172 / 1,907 | 774 / 418 |
Costo de la tarea 1 (precio de lista nativo) | $0.0078 | $0.0143 |
El costo se calcula a partir de los conteos de tokens anteriores a los precios de lista nativos (Kimi $0.95/$4 por millón de entrada/salida, Opus $5/$25): Kimi = 172×$0.95/M + 1,907×$4/M ≈ $0.0078; Opus = 774×$5/M + 418×$25/M ≈ $0.0143. Los conteos de tokens de entrada difieren (172 frente a 774) porque el tokenizador de cada modelo y la contabilidad de la puerta de enlace cuentan el mismo prompt de manera diferente, no porque las tareas fueran distintas. Ambos modelos produjeron código completamente correcto en ambas tareas. La diferencia estuvo en cómo llegaron allí. Opus fue conciso y rápido, devolviendo 418 tokens en 5.3 segundos en la Tarea 1. Kimi tardó 49.1 segundos y emitió 1,907 tokens, gran parte de ellos una traza de razonamiento paso a paso que devolvió junto con el código. Sin embargo, como los tokens de Kimi son aproximadamente 6× más baratos, la ejecución más verbosa siguió costando menos.
Lo que el duelo demuestra y no demuestra
Demuestra que, en problemas de codificación acotados y bien especificados, Kimi K2.7 Code llega a la misma respuesta correcta que un modelo de frontera. No demuestra que Kimi iguale a Opus en sesiones agenticas largas de varios pasos, algo que dos tareas de un solo intento no pueden poner a prueba. La afirmación más sólida del propio Kimi está precisamente en ese terreno agentico, que los benchmarks de abajo abordan directamente.
Puntos de referencia: qué es de terceros frente a la propia tabla de Moonshot
Aquí está el desglose, con cada número etiquetado por fuente. La tabla autoinformada de Moonshot es donde Kimi parece más fuerte; la evaluación independiente es más limitada porque el modelo es reciente, y donde aún no existe ningún número K2.7 de terceros, la cifra publicada más cercana es la de K2.6 (marcada abajo).
Benchmark | Kimi K2.7 Code | Claude Opus 4.8 | Fuente |
|---|---|---|---|
MCPMark Verified (tool use) | 81.1 | 76.4 | Moonshot, auto-reportado |
SWE-bench Verified | 60.4% | no publicado en el mismo formato | Moonshot, auto-reportado |
Intelligence Index | 35 (K2.6 proxy) | 56 | Artificial Analysis, de terceros |
Output speed | ~45 tok/s (K2.6 proxy) | 59 tok/s | Artificial Analysis, de terceros |
La única cifra sobre la que se sostiene la comparación, MCPMark Verified 81.1 frente a 76.4, proviene de la propia tabla de Moonshot, no de un laboratorio independiente. Eso no es motivo para descartarla, ya que el uso de herramientas al estilo MCP es בדיוק donde Kimi fue ajustado. Pero lea el titular "Kimi beats Opus" como una afirmación del proveedor sobre una referencia optimizada por el proveedor. En la única comparación directa medida por un tercero, Artificial Analysis sitúa a Opus 4.8 claramente por delante en su Intelligence Index (56 frente a 35), aunque esa fila usa K2.6 como sustituto porque K2.7 no había sido puntuado de forma independiente al momento de escribir esto.
La brecha de la ventana de contexto que esconden los puntos de referencia
Opus 4.8 cuenta con una ventana de contexto de 1M tokens; Kimi K2.7 llega como máximo a 256K. Los puntajes de los benchmarks rara vez reflejan esto, pero es lo que decide el trabajo real. Una ventana de 256K puede contener cómodamente un repositorio de tamaño medio y una larga traza de agente, y está bien para la mayoría de las sesiones de codificación. Alcanzas el límite cuando estás introduciendo un monorepo grande completo, conjuntos extensos de documentos o transcripciones de agentes de varias horas en un solo prompt. Ahí, la ventana 4× más grande de Opus es la diferencia práctica, no un punto en una gráfica.
Precios: la brecha de 5–6× y la palanca de caché
En los precios de lista de la API nativa, Kimi K2.7 Code cuesta $0.95 por millón de tokens de entrada y $4.00 por millón de salida; Claude Opus 4.8 cuesta $5 y $25. Eso supone una diferencia de 5–6× en la salida, y es la razón principal por la que los equipos evalúan Kimi en absoluto.
La palanca que la mayoría de las tablas de precios pasa por alto es el caché. Kimi cobra $0.19 por millón de tokens en un acierto de caché, un descuento del 80% sobre la entrada que ya has enviado. En un bucle agéntico que vuelve a leer la misma base de código en cada paso, la entrada en caché domina la factura, así que el costo efectivo cae muy por debajo de la diferencia de etiqueta. Philip Kiely de Baseten informó de un ahorro de aproximadamente el 82% en una carga de trabajo de ejemplo después de cambiar de Opus 4.8 a Kimi 2.7 Code, el tipo de trabajo con mucho caché y mucha entrada donde los precios de Kimi se acumulan. Tu cifra variará según tu relación de entrada a salida, pero la dirección es consistente: cuanto más releas el contexto en relación con lo que generas, más gana Kimi en costo.
Opus recupera su precio en el lado de la salida. Generó una cuarta parte de los tokens que Kimi produjo en mi Tarea 1, así que en trabajos con mucha generación, como escribir archivos grandes o refactors extensos, la diferencia por token se reduce en el gasto real, y la velocidad de Opus recorta el tiempo de espera en tiempo real por el que estás pagando a un ingeniero.
La promesa de los pesos abiertos frente a la realidad de 577 GB
Kimi K2.7 se ofrece como open weights bajo una licencia MIT modificada, así que puedes alojarlo en tu propia infraestructura y ajustarlo. Opus 4.8 es solo API; tu código y los trazos de razonamiento van a Anthropic. En teoría, eso le da a Kimi una ventaja decisiva en privacidad y dependencia del proveedor. En la práctica, revisa primero el costo del hardware.
Kimi K2.7 es un modelo Mixture-of-Experts de 1 billón de parámetros (32B activos por token, 384 expertos). Revisores independientes sitúan una implementación completa INT4 en aproximadamente 577GB de VRAM una vez que se contabilizan los pesos, la caché KV y la sobrecarga en tiempo de ejecución, lo que coloca la configuración práctica mínima alrededor de 8× H100 80GB o una máquina de clase DGX Spark. Una sola RTX 4090 (24GB) no puede ejecutar el modelo completo con ajustes utilizables. Para todos menos un puñado de equipos bien financiados, "open weights" significa la libertad de enrutar a un proveedor de alojamiento o ajustar finamente en GPUs alquiladas, no un modelo que puedas desplegar internamente. Si tu motivo para elegir Kimi es el control de datos on-prem, cotiza el clúster antes de comprometerte; para la mayoría de los equipos, el autoalojamiento sigue siendo teórico.
Cuál deberías elegir
Adapta el modelo a la carga de trabajo en lugar de coronar a un ganador:
Elige Kimi K2.7 Code para coding sensible al costo, de alto volumen o agentic, cuando relees repetidamente una codebase, la latencia no es crítica y un contexto de 256K es suficiente. El descuento de caché se acumula a tu favor.
Elige Claude Opus 4.8 cuando necesites baja latencia, un contexto de 1M tokens para repos grandes o sesiones largas, una salida más concisa, o un modelo de revisión final en el que confiar para cambios de alto riesgo, donde su ventaja en puntuaciones de razonamiento independiente importa más.
La estrategia híbrida: borradores con un modelo barato, finalización con un modelo de vanguardia
El patrón más común entre los equipos que usan ambos no es elegir uno, sino enrutar. Deja que Kimi K2.7 se encargue de la generación y la iteración en volumen de forma económica, y luego pasa el resultado a Opus 4.8 para la revisión final o las partes que requieren juicio de frontera. Kimi habla el formato de OpenAI de forma nativa mientras que Opus usa la propia API de Anthropic, así que la forma práctica de enrutar entre ellos es una puerta de enlace que agrupe ambos detrás de un único endpoint compatible con OpenAI; en una plataforma como AIReiter, por ejemplo, ambos están bajo una sola clave, lo que hace que cambiar de Kimi a Opus sea un cambio de cadena de modelo y no una reintegración. El ahorro del 82% de arriba provino exactamente de este tipo de enrutamiento, no de eliminar Opus por completo.
Preguntas frecuentes
¿Es Kimi K2.7 mejor que Claude Opus 4.8 para programar?
En tareas acotadas y bien especificadas están igualados; en mi prueba, ambos devolvieron código completamente correcto. La ventaja de Kimi es el uso agéntico de herramientas (MCPMark 81.1 frente a 76.4, según Moonshot); Opus lidera en razonamiento general, velocidad y trabajo con contexto largo.
¿Cuánto más barato es Kimi K2.7 que Opus 4.8?
Aproximadamente 5–6× más barato en precio de lista ($0.95/$4 por millón frente a $5/$25). Con aciertos de caché ($0.19/M de entrada) en cargas de trabajo repetitivas, los ahorros en el mundo real pueden alcanzar el 80% o más.
¿Cuál es la ventana de contexto de Kimi K2.7 frente a Opus 4.8?
Kimi K2.7 maneja 256K tokens; Opus 4.8 maneja 1M, cuatro veces más grande.
¿Puedo ejecutar Kimi K2.7 localmente?
Solo con hardware serio. Se informa que una implementación completa en INT4 necesita unos 577 GB de VRAM (aproximadamente 8× H100 o un DGX Spark). Una sola GPU de consumo como una RTX 4090 no puede ejecutar el modelo completo.
¿Kimi K2.7 es de código abierto?
Se publica con pesos abiertos bajo una licencia MIT modificada, por lo que puedes alojarlo tú mismo y ajustarlo. Opus 4.8 es cerrado y solo está disponible vía API.
La conclusión
Si tu cuello de botella es el presupuesto, por defecto usa Kimi K2.7 Code y deja que el almacenamiento en caché haga el resto. Si es la latencia, la longitud del contexto o un cambio que no puedes permitirte hacer mal, paga por Opus 4.8. Considera la licencia de pesos abiertos como un extra que solo aprovecharás si posees las GPUs. Y si no estás seguro, conecta ambos y enruta por tarea en lugar de apostar el flujo de trabajo a una sola apuesta que luego tendrás que deshacer.