Kimi K3 en la práctica: experiencia práctica y una comparación con Claude Code

Cómo salió el experimento del autor#

Kimi K3 se lanzó el 16 de julio de 2026. Tiene 2,8 billones de parámetros, una ventana de contexto de un millón de tokens, pesos abiertos y el primer puesto en una comparación a ciegas de frontend. Reuní todos los detalles sobre su arquitectura, benchmarks y precios en la reseña completa de Kimi K3 frente a Claude Code, así que no los repetiré aquí.

Al final de aquella reseña escribí: el riesgo es perder un día con la configuración; la recompensa es una factura que baja a partir de la segunda semana. Hice el experimento con mis propias tareas.

Las primeras horas son realmente emocionantes. El modelo se pone enseguida con una tarea, genera un trabajo de frontend coherente y no duda ante archivos grandes. Por eso publiqué en el canal que me había sorprendido gratamente. Los problemas aparecieron en sesiones largas, con varios agentes, tras rondas repetidas de cambios y, por la tarde, en la terminal.

Al final, di marcha atrás. Esto es lo que me llevó a esa decisión, con cifras y enlaces a fuentes primarias para que puedas comprobarlo todo por tu cuenta.

¿Por qué los benchmarks muestran que Kimi K3 supera a Claude?#

Estos son los benchmarks en los que Kimi K3 supera a Claude Fable 5:

llm-stats recopiló los benchmarks; cada fila compara el modelo con Claude Fable 5.

Las cifras son reales. En los 35 benchmarks de la misma recopilación, Claude Fable 5 gana 22, Kimi K3 gana doce y hay un empate.

Lo más interesante es dónde se queda corto Kimi K3. Su desventaja en los benchmarks de programación es modesta, de 4–5 puntos. Se queda atrás en conocimiento y razonamiento: en HLE, Claude le saca casi 10 puntos. Ahí es exactamente donde una tarea larga se atasca: primero hay que entender y solo después se puede escribir.

Moonshot lo expresa así en la sección principal de su publicación de lanzamiento:

¿Por qué Kimi K3 parece el doble de lento en la práctica?#

La comparación usa Claude Opus 4.8, la versión de Claude con una medición completa de velocidad.

Kimi K3 responde antes, así que subjetivamente parece más rápido en una conversación breve. En el trabajo importa otra cosa: lo que tarda en llegar la respuesta completa. En esto pierde por casi la mitad, y en una respuesta larga la diferencia suma minutos.

Kimi Code anuncia entre 180 y 260 tokens por segundo, una cifra que parece convincente frente a mis 34,7. Se refiere a la versión rápida de la generación anterior, K2.7 Code HighSpeed. Kimi K3 no tiene ninguna versión de ese tipo, y el benchmark independiente mide el propio Kimi K3.

Una sesión que se interrumpe al séptimo error y consume tokens con llamadas repetidas revela un fallo de Context Engineering; aquí, la elección del modelo es secundaria.

¿Adónde van los tokens si no se puede desactivar el razonamiento?#

Puedes bajar el nivel de esfuerzo; la documentación enumera tres: bajo, alto y máximo. Pero el razonamiento no se puede desactivar por completo: se indica explícitamente que tanto el razonamiento como el almacenamiento de su historial están siempre activados en Kimi K3. Con llamadas directas a la API, el nivel máximo viene establecido de forma predeterminada, y la mayoría de los programas wrapper no lo cambian.

Cada turno añade miles de tokens de salida a $15 por millón. Además, Moonshot exige que devuelvas el mensaje completo del asistente, incluido su historial de razonamiento, y esos tokens de salida vuelven a convertirse en tokens de entrada en el siguiente turno.

Así que pagas dos veces por el mismo razonamiento: primero cuando el modelo lo escribe y luego cuando se lo envías de vuelta.

En el índice general, Kimi K3 utiliza un 21% menos de tokens de salida que su predecesor, K2.6. El modelo se ha vuelto más eficiente en comparación con su versión anterior. Claude sigue utilizando menos en las mismas tareas.

El prompt “hi” se factura como 86 tokens. Por debajo hay un prompt de sistema oculto de unos 85 tokens, que pagas en cada solicitud.

Tengo una reseña aparte sobre cómo calcular el uso y dónde consultar el saldo restante: cuántos tokens te dan Claude Pro y Max. La lógica de cálculo es la misma; solo cambian los precios.

¿Qué ocurre cuando el modelo se atasca razonando?#

Se ve así: el modelo empieza a pensar, pero en lugar de desarrollar la idea, el texto se repite: la misma palabra, luego fragmentos de sílabas, sin parar. La tarea se estanca mientras el contador de tokens sigue avanzando.

Un informe del 28 de julio en la lista de problemas conocidos de Moonshot describe cómo Kimi K3 intenta leer el mismo archivo seis veces seguidas, recibe siete veces el rechazo “no-op call, file hasn’t changed since the previous read” y luego termina el turno como si no hubiera pasado nada. En el rastreador de incidencias de Kimi CLI, el autor enumera cuatro variantes del mismo tipo de bloqueo —leer, reemplazar, probar y analizar— y lo resume en una frase:

Moonshot expone la causa directamente. El modelo se entrenó en un modo que conserva el historial de razonamiento y necesita recibir de vuelta todo su razonamiento anterior. Si el historial llega incompleto, el modelo intenta reconstruir la respuesta, produce la misma llamada a la herramienta y empieza otro bucle.

El autor de un análisis en un enrutador de solicitudes de terceros ofrece el mismo diagnóstico: Kimi es lo bastante estricto como para rechazar solicitudes con un historial de razonamiento incompleto. Un wrapper externo no conoce este requisito y trunca el historial.

¿Por qué se viene abajo una configuración multiagente con Kimi K3?#

La documentación oficial de Moonshot lo afirma claramente: su API todavía no admite WebFetch. En otras palabras, Claude Code, que normalmente se conecta a internet para recuperar una página, no puede hacerlo con Kimi K3. La alternativa es pegar el contenido manualmente o conectar una herramienta de terceros.

Claude Code puede cargar herramientas bajo demanda y coloca en el historial un bloque de servicio del tipo tool_reference. Kimi no acepta este tipo y devuelve un error 400. Lo hace sin dar detalles, sin nombrar el campo ni el motivo:

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

A modo de comparación, así se ve el mismo fallo en la API nativa de Anthropic, donde el servidor al menos indica el campo y enumera los tipos aceptados:

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

La diferencia importa. Es imposible diagnosticar el primer mensaje: ni el cliente ni la persona que lo utiliza pueden saber qué bloque se rechazó. Eso es precisamente lo que critican los autores de los informes. Los desarrolladores de conmutadores de proveedores ya sugieren desactivar por defecto la carga diferida de herramientas para Kimi o marcar la API de Moonshot como incompatible con estos bloques.

La consecuencia se describe en un informe aparte, abierto el 17 de julio y todavía sin respuesta. El autor se encontró con este error siete veces en una sesión. La sesión sobrevivió a las seis primeras; la séptima la terminó para siempre: después, incluso escribir el texto sin formato “continue” hacía que se bloqueara. El autor señala aparte que ni siquiera se había acercado al límite de contexto, así que la explicación de que «el historial era demasiado largo» no se sostiene.

Este es un resumen de los tipos de bloques que la API de Moonshot acepta y rechaza:

Aquí, la palabra “compatible” describe únicamente el formato de la solicitud. Todo lo demás es distinto: qué tipos de bloques se aceptan, qué debe incluir el historial y qué herramientas están disponibles.

¿Qué no se traslada a Kimi K3?#

La sección de limitaciones de la publicación de lanzamiento lo dice textualmente:

El desarrollador del modelo está diciendo: usa nuestro cliente; no garantizamos cómo se comportará el de otra persona.

El segundo punto de esa misma sección explica otra cosa que había atribuido a la terquedad del modelo:

Mi CLAUDE.md se escribió para el hábito opuesto: preguntar, mostrar un plan y esperar confirmación. Las instrucciones siguen ahí, pero ahora las interpreta un modelo con un temperamento distinto.

Si quieres mantener un único archivo de reglas para varios agentes, describí esa configuración por separado: un archivo de instrucciones para Claude Code, Codex y Cursor.

¿Cuánto costó realmente Kimi K3?#

Primero, los precios, que favorecen a Kimi K3:

Los precios de Kimi proceden de la documentación sobre el almacenamiento en caché del contexto; la columna de la derecha muestra los precios de Claude Opus 5 a 30 de julio de 2026.

El caché de Kimi es automático, no se puede desactivar y se identifica mediante el hash al comienzo de la solicitud. Cualquier cambio en el prompt de sistema o en la lista de herramientas borra por completo el caché de mensajes.

Esto es lo que hace Claude Code durante una jornada laboral normal:

1. Conecta y desconecta herramientas externas a medida que avanza la tarea.
2. Carga herramientas bajo demanda cuando hacen falta.
3. Inicia subagentes con un conjunto diferente de herramientas.
4. Añade el archivo de instrucciones al prompt de sistema.
5. Reconstruye el historial al comprimir el contexto.

Cada elemento de esta lista restablece el inicio de la solicitud y, por tanto, el caché. Los tokens de entrada vuelven a costar $3 por millón en vez de 30 centavos: diez veces más. A eso se suma el razonamiento constante, a $15 por millón de tokens de salida, y esos mismos tokens vuelven como entrada en el turno siguiente. Así es como un modelo con un precio anunciado bajo puede generar una factura inesperada.

Según los datos agregados de OpenCode, en casi 280.000 sesiones activas, una sesión media de Kimi K3 cuesta $1.86 y consume 3,1 millones de tokens de media. Esa cifra presupone que el caché recibe el 93% de los tokens de entrada. Cambia el inicio de la solicitud y ya no se aplica a tu caso.

Los planes de Kimi cuestan $19, $39, $99 y $199. La cuota procede de una bolsa compartida por toda la suscripción, se restablece semanalmente sin acumular las cantidades no utilizadas y utiliza una ventana móvil de cinco horas. La reseña de los planes lo expresa así: cuatro terminales ejecutando Kimi K3, que razona constantemente, agotan rápidamente una ventana de cinco horas.

La cuota de programación del plan de $99 es comparable a la del plan de Anthropic de $200, lo que contradice mi postura. Kimi es más barato por token, pero por la noche ya no se nota en la factura.

¿En qué destaca Kimi K3 objetivamente?#

1. Frontend. Primer puesto en una comparación a ciegas realizada por desarrolladores en activo. Construye diseños ordenados y con bastante buen gusto.
2. Volumen. Una ventana de contexto de un millón de tokens, y los archivos largos no le intimidan. Analizar un repositorio grande y trazar su mapa es el tipo de tarea que se le da bien.
3. Primera respuesta. El tiempo hasta el primer token es la mitad que el de Claude. Se nota y resulta agradable en una conversación breve.
4. Precio por token. Aproximadamente el 60% del precio de Claude Opus 5. Si el inicio de la solicitud no cambia, esto permite ahorrar de verdad en cargas de trabajo grandes y repetitivas.
5. Pesos abiertos. El modelo no está ligado a un solo proveedor.

El último punto tiene una salvedad. No es realista ejecutar en casa un modelo así: incluso comprimidos, sus pesos ocupan terabytes. Aquí, que sea abierto significa independencia de un único proveedor.

Cómo probar todo esto por tu cuenta en una noche#

1. Configura el acceso siguiendo las instrucciones. Describí las tres variables de entorno y las sustituciones de modelos según el nivel en la reseña de Kimi K3 frente a Claude Code. Comprueba la configuración con el comando /status: Kimi no aparecerá en el menú de selección de modelos porque tiene una lista integrada de alias y no hace falta tocarla.
2. Elimina la clave antigua. Si antes tenías definido ANTHROPIC_API_KEY, elimínalo. Junto con ANTHROPIC_AUTH_TOKEN, provoca un conflicto y recibirás un error de autorización sin motivo válido.
3. Desactiva de inmediato la carga diferida de herramientas. Hazlo antes de la primera ejecución, no después de que se bloquee la primera sesión.
4. No cambies de modelo a mitad de una tarea. Si empezaste con Kimi K3, termina con Kimi K3. Lo mismo vale al revés. Es un requisito directo de Moonshot, citado más arriba.
5. Usa una tarea real tuya. Una en la que trabajaste ayer, con todo su desorden y los hilos sin terminar. Un juego de la serpiente no mostrará la diferencia: solo aparece con el tiempo.
6. Anota dos cifras. Cuántos minutos tardó y cuánto dinero gastaste esa noche. Compáralo con una noche normal usando Claude.
7. Registra por separado el tiempo de inactividad. Cuando el agente se queda colgado, lee el mismo archivo en bucle o responde con un error, eso también forma parte del coste.

Si la factura de la noche sale más alta de lo esperado, casi siempre es por el caché: cuenta cuántas veces se restableció el inicio de la solicitud esa noche. El precio por token tiene poco que ver.

Lo que decidí conservar#

Los lectores del canal que probaron el modelo conmigo llegaron por su cuenta a la misma configuración: envían Kimi K3 a inspeccionar el repositorio y dar una segunda opinión, mientras dejan el trabajo principal a su agente habitual. Esta configuración funciona porque no exige cambiar el wrapper ni estropear lo que ya funciona.

Dicho de otro modo: una tarea completa va a Kimi K3; una larga cadena con herramientas y subagentes va a Claude Code. Cuantos más cambios de herramienta requiera una tarea, más cuesta con Kimi K3 y mayor es la posibilidad de que la sesión se interrumpa.

Tengo una reseña aparte sobre cómo asignar funciones a dos agentes sin confundirlos: tres formas de trabajar con dos agentes.

Los benchmarks responden a la pregunta «¿Quién es más potente en condiciones de laboratorio?». La factura de la noche y la lista de tareas terminadas responden a «¿Quién es más potente para ti?». Si las respuestas difieren, confía en la segunda: los cálculos los hiciste tú, no el departamento de marketing.

Después de analizarlo todo, tomé mi propia decisión: digan lo que digan de los nuevos modelos, un líder sigue siendo un líder. Claude Code sigue siendo mi motor principal.