Precios de Kimi K3: cómo desactivar el razonamiento «siempre activo»

La documentación de Kimi K3 afirma que no se puede desactivar el razonamiento y que reasoning_effort solo acepta "max". En nuestras mediciones, la API también acepta "none" y respeta ese valor: la misma pregunta trivial que cuesta $0.00179 con el razonamiento predeterminado baja a $0.000285 sin él, una diferencia de 6.3x. K3 se lanzó el 2026-07-16 a $3 por millón de tokens de entrada y $15 por millón de tokens de salida. Es el precio de catálogo más alto que ha publicado un laboratorio chino e iguala al de Claude Sonnet 5. Con ese precio de salida, los tokens de razonamiento que el modelo consume de forma predeterminada determinan la factura. Por eso conviene entender bien este mecanismo de desactivación no documentado.

TL;DR

• Con la configuración predeterminada, Kimi K3 dedica entre el 69% y el 93% de sus tokens de salida al razonamiento; un párrafo de 120 palabras facturó 2,289 tokens de salida, $0.0346.
• reasoning_effort: "none" se acepta aunque la documentación diga lo contrario y redujo 6.3x el coste de nuestras consultas simples, pero la precisión en operaciones aritméticas de varios pasos cayó de 3/3 a 0/6.
• La caché de prompts de Kimi K3 empieza a registrar hits con unos 256 tokens de prefijo, en bloques de 256 tokens, a una tarifa de lectura de $0.30/M.
• El chino es el idioma CJK más barato en K3: 52 tokens netos por cada 100 caracteres, por debajo de los 58 de GLM-5.2 y DeepSeek.

Todo lo que sigue se midió el 2026-07-20 con kimi-k3, disponible en el gateway de Synthorai con los precios de catálogo de Moonshot. Añadimos valores aleatorios a los prompts repetidos para evitar las cachés de respuesta y contrastamos las observaciones de comportamiento mediante una segunda ruta de solicitud independiente. Cada cifra está respaldada por registros de uso sin procesar.

¿Cuánto cuesta por defecto cada respuesta de Kimi K3?

El razonamiento domina la factura en todos los tipos de tareas que probamos, incluso en las que no requieren razonamiento. Con la configuración predeterminada, el coste por respuesta fue:

El gráfico sirve para comparar modelos: GPT-5.6 razona de forma adaptativa, con cero tokens de razonamiento para las preguntas triviales y factuales y entre un 65% y un 70% para matemáticas y redacción. Claude Sonnet 5 viene con el razonamiento desactivado, mientras que GLM-5.2 dedica proporcionalmente aún más tokens que K3 a razonar. Sin embargo, la salida de GLM cuesta $4.40/M y la de K3, $15/M. Por eso, la misma respuesta a 17×23 costó $0.00078 en GLM-5.2, $0.00027 en GPT-5.6, $0.0001 en Sonnet 5 y $0.0018 en K3. La diferencia aumenta con la longitud de la salida: el mismo párrafo de 120 palabras costó $0.0346 en K3, frente a $0.0186 en GLM-5.2, $0.0072 en GPT-5.6 y $0.0024 en Sonnet 5. Es una diferencia de 15x en la tarea más corriente del conjunto. El porcentaje dedicado al razonamiento se parece al de otros modelos chinos de razonamiento, pero el importe resultante no.

Hay otros dos factores del modo predeterminado que deben incluirse en el presupuesto. Primero, el modo de razonamiento añade un preámbulo oculto de unos 67 tokens a cada solicitud: un mensaje idéntico de una sola palabra facturó 86 tokens de prompt con el razonamiento activado y 19 con él desactivado. Es el «prompt de sistema oculto» que detectaron los primeros usuarios, y desaparece al desactivar el razonamiento. Segundo, K3 es lento por ahora: nuestras solicitudes con preguntas triviales tardaron entre 19 y 24 segundos de extremo a extremo con el razonamiento activado, y entre 3 y 8 segundos con él desactivado, incluyendo las condiciones de servicio de la semana de lanzamiento. Hay que presupuestar latencia, no solo dinero.

¿Se puede desactivar el razonamiento de Kimi K3?

Sí, aunque la documentación diga lo contrario. La referencia de la API oficial afirma que K3 «siempre activa el razonamiento» y que reasoning_effort solo acepta "max". En la práctica, el endpoint aceptó "none", "low", "medium" y "high" sin errores y aplicó los valores. Confirmamos el mismo comportamiento mediante una ruta de solicitud independiente. En el problema verbal de varios pasos, el control funciona, aunque sus niveles son poco precisos:

Destacan dos cosas. Los niveles intermedios están muy próximos: de low a max, el número de tokens y la precisión fueron similares en esta tarea. En la práctica, el cambio relevante es binario. Además, none provoca una caída brusca: al obligar a K3 a responder de forma concisa un problema aritmético de varios pasos, falló las seis veces, con respuestas incorrectas distintas y no por un único error sistemático. Cuando no exigimos un formato breve, el modelo a veces ignoró la concisión y desarrolló los pasos en la respuesta visible. El resultado era correcto, pero los tokens pasaban del campo de razonamiento al campo de texto en vez de desaparecer.

La latencia cambia menos de lo que sugieren los tokens. Al enviar el mismo problema mediante streaming con cada nivel de esfuerzo, el tiempo hasta el primer byte osciló entre 6 y 24 segundos, con bastante solapamiento entre los distintos niveles. Incluso none, sin nada que razonar, tardó entre 12 y 13 segundos. Para una tarea de este tamaño, la infraestructura de servicio domina el tiempo hasta el primer token. Lo que el control modifica realmente es el intervalo entre el primer byte y el primer token de la respuesta: la fase de razonamiento que el usuario debe esperar.

En la práctica, none permite reducir de verdad el coste de tareas de recuperación, formateo o un solo paso, pero es peligroso para cualquier tarea que necesite pasos intermedios. No existe ninguna garantía documentada de que este parámetro vaya a seguir funcionando. Trátalo como un comportamiento medido, compruébalo en tus propios campos de usage y asume que podría oficializarse o desaparecer cuando se actualice la documentación.

¿Cuándo conviene mantener el razonamiento en cargas de agentes?

Probamos K3 en cinco escenarios propios de agentes, dos veces cada uno: con la configuración predeterminada y con reasoning_effort: "none". Usamos las mismas tareas simples, que ambas configuraciones resolvieron por completo:

La primera fila es inesperada: en los bucles de llamadas a herramientas, K3 apenas razona incluso con la configuración predeterminada, solo un 8%, por lo que hay poco que ahorrar. El modelo trata la selección de herramientas como una reacción directa, no como una decisión que requiera deliberación. El ahorro se concentra en tareas mecánicas con una proporción alta de razonamiento, como las búsquedas RAG y la extracción por lotes. Es precisamente donde menos sentido tiene aplicar un coste fijo por razonamiento siempre activo. En planes de agentes que requieran de verdad varios pasos, se aplica la caída de precisión de la sección anterior: deja el razonamiento activado y asume esos tokens.

A escala, el efecto sobre la latencia es real aunque las solicitudes individuales tengan bastante variación: en estos escenarios, los primeros tokens llegaron entre 10 y 19 segundos con la configuración predeterminada y entre 8 y 13 segundos con none. La generación alcanzó una mediana de 35 tokens por segundo en salidas con contenido sustancial. Incluidas las condiciones de servicio de la semana de lanzamiento, estas cifras encajan mejor con cargas asíncronas y por lotes que con usos conversacionales.

¿El razonamiento que se reenvía vuelve a facturarse como entrada?

Sí, token por token. La documentación de Kimi indica que debes conservar sin modificar el reasoning_content de cada turno del asistente en el historial de mensajes. Medimos cuánto cuesta: un segundo turno enviado con la cadena de pensamiento del primero facturó 599 tokens de prompt; la solicitud idéntica sin ella facturó 198. La diferencia de 401 tokens coincide casi exactamente con los 402 tokens de razonamiento del primer turno. Por tanto, el razonamiento conservado vuelve a entrar en cada solicitud posterior a la tarifa completa de entrada de $3/M. Una conversación larga vuelve a pagar en cada turno todo el razonamiento acumulado.

Eliminarlo tampoco sale necesariamente más barato. Sin la cadena de pensamiento anterior, K3 volvió a razonar desde cero para responder al seguimiento: los tokens de razonamiento del segundo turno aumentaron un 31%, de 343 a 449. Con la entrada a $3/M y la salida a $15/M, conservar la CoT resultó más barato en términos netos durante nuestra prueba. La recomendación de la documentación tiene sentido tanto por coste como por calidad. La palanca que realmente reduce el gasto aquí es la caché de prompts de la siguiente sección: el historial conservado forma un prefijo estable, y los prefijos estables dejan de facturarse a precio completo.

¿Kimi K3 almacena prompts en caché y a partir de cuántos tokens?

La caché de prompts de K3 es automática y tiene un umbral bajo: empezó a registrar hits con unos 256 tokens de prefijo compartido y avanzó en bloques de 256 tokens. Un prompt de 303 tokens almacenó 256 en caché; uno de 153 nunca se almacenó tras varios intentos. La entrada en caché se factura a $0.30/M, un descuento fijo del 90% frente a la tarifa de $3/M para entrada nueva. Ninguna de nuestras llamadas tuvo un recargo por escribir en caché. Hicieron falta entre dos y cinco solicitudes idénticas para obtener el primer hit, así que un solo reintento no demuestra nada; hay que medir varias solicitudes.

Como referencia, ese umbral es una cuarta parte del mínimo documentado de 1,024 tokens de OpenAI, y los bloques son más grandes que la granularidad de 64 tokens que medimos en otros proveedores. La duración es de tipo best-effort, no un TTL fijo: en nuestra prueba, las entradas de caché sobrevivieron a periodos de inactividad de 4 y 15 minutos, mientras que una pausa de 8 minutos terminó en miss. Hay que tratar la expiración como una expulsión dependiente de la carga y comprobar en cada llamada el reparto de tokens almacenados. Otro dato relevante para calcular costes: la ventana de contexto de 1M tokens tiene una tarifa plana, sin un nivel adicional para contextos largos en la lista de precios. Una ventana completa cuesta $3.00 de entrada nueva por llamada y $0.30 cuando el prefijo ya está en caché. Por eso, la viabilidad de las cargas con contextos grandes depende mucho más de la caché que del precio de catálogo. Si tu tráfico reutiliza un prompt de sistema de apenas unos cientos de tokens, la caché de K3 ya entra en funcionamiento cuando la mayoría de los proveedores aún no habría alcanzado su mínimo. Nuestra guía de caché de prompts explica su funcionamiento y cómo comprobar los hits mediante usage; el estudio de mínimos de caché medidos compara los umbrales.

¿El chino es realmente más caro en Kimi K3?

No. El tokenizador de K3 es especialmente eficiente para el chino frente a otros modelos, una cuestión planteada repetidamente durante la semana del lanzamiento. Estos son los tokens netos por cada 100 caracteres en pasajes semánticamente equivalentes, descontando la sobrecarga del envoltorio:

K3 factura 52 tokens por cada 100 caracteres chinos, un 11% menos que GLM-5.2 y DeepSeek y menos de la mitad que Sonnet 5. Su punto débil es el japonés, donde consume entre un 16% y un 24% más que los otros modelos de pesos abiertos. También confirmamos que el tokenizador no cambia dentro de la familia: K3, K2.7-code y K2.5 produjeron recuentos idénticos en las 23 muestras equivalentes. Por tanto, los presupuestos de tokens por idioma creados para K2 siguen siendo válidos. Nuestro estudio sobre el LLM más barato por idioma analiza cómo se combinan la densidad del tokenizador y el precio por token en nueve idiomas.

Preguntas frecuentes

¿Cuándo se publicarán los pesos abiertos de Kimi K3?

Moonshot ha prometido publicar los pesos completos con una licencia Modified MIT antes del 27 de julio de 2026; en la fecha de este artículo, K3 solo está disponible mediante API. La presentación como «el mayor modelo de pesos abiertos de la historia» sigue siendo un compromiso, no un enlace de descarga. El funcionamiento de la caché en el ecosistema de pesos abiertos al que se incorporará se detalla en caché de prompts para LLM de pesos abiertos.

¿Qué aporta realmente K3 frente a la familia K2?

En la factura medimos tres diferencias: el precio, con $3/$15 para K3 frente a $0.95/$4 para K2.7-code, un aumento de 3.2-3.75x; el razonamiento siempre activo, ya que K2.5 no razona y K2.7-code permite activarlo o desactivarlo; y nada más. El tokenizador produce exactamente los mismos bytes en K3, K2.7-code y K2.5 para nuestras 23 muestras equivalentes, por lo que los presupuestos de tokens de la era K2 siguen siendo válidos. Según la ficha técnica de Moonshot, K3 incorpora un nuevo MoE de 2.8T parámetros, con 896 expertos y 16 activos por token, Kimi Delta Attention, una ventana de contexto de 1M tokens frente a los 256K de K2.7-code y entrada nativa de imágenes. Medimos las afirmaciones de facturación, no las de arquitectura.

¿Kimi K3 admite salida estructurada?

Sí. En nuestra prueba, un response_format con json_schema devolvió un objeto válido que cumplía el esquema. El razonamiento sigue ejecutándose internamente: 66 de los 97 tokens de salida de esa llamada de extracción correspondían al razonamiento. Por tanto, las llamadas restringidas por un esquema pagan el mismo coste de razonamiento que las demás, salvo que también se configure reasoning_effort: "none".

¿Desactivar el razonamiento cambia lo que se puede ver?

Sí. Con la configuración predeterminada, K3 devuelve la cadena de pensamiento completa en reasoning_content, y la documentación recomienda reenviarla sin modificaciones en el historial de varios turnos. Con reasoning_effort: "none", el campo desaparece por completo, al igual que el preámbulo de razonamiento de unos 67 tokens incluido en la factura del prompt.

Mediciones realizadas el 2026-07-20 con kimi-k3 y los precios de catálogo de la semana de lanzamiento ($3/M de entrada, $0.30/M en caché y $15/M de salida). Añadimos valores aleatorios a los prompts repetidos para evitar cachés en el nivel de respuesta; los recuentos de precisión usan tareas con una única respuesta verificable; las observaciones de comportamiento se reprodujeron mediante una segunda ruta de solicitud independiente. Los precios y el comportamiento pueden cambiar a medida que madure la versión; comprueba tus propios registros de usage antes de basarte en cualquiera de estas cifras.

← Volver al blog