Precio de la API de Kimi K3, medido: apaga el razonamiento «siempre activo»

La documentación de Kimi K3 dice que el razonamiento no se puede desactivar y que reasoning_effort solo acepta "max". En nuestras mediciones, la API acepta "none" igualmente, y funciona: la misma pregunta trivial que cuesta $0.00179 con el razonamiento por defecto cuesta $0.000285 sin él, una diferencia de 6.3x. K3 salió el 2026-07-16 a $3 por millón de tokens de entrada y $15 por millón de salida, el precio de lista más caro que ha lanzado un laboratorio chino y el mismo que Claude Sonnet 5. A ese precio de salida, los tokens de razonamiento que el modelo gasta por defecto son la factura, así que vale la pena entender bien ese interruptor no documentado.

TL;DR

• Kimi K3 gasta entre el 69 y el 93% de sus tokens de salida en razonamiento con los ajustes por defecto; un párrafo de 120 palabras facturó 2.289 tokens de salida, $0.0346.
• reasoning_effort: "none" se acepta aunque la doc diga lo contrario, y redujo 6.3x el coste de nuestra consulta simple, pero la aritmética de varios pasos pasó de 3/3 aciertos a 0/6.
• La caché de prompts de Kimi K3 empieza a acertar desde unos 256 tokens de prefijo, en bloques de 256 tokens, a una tarifa de lectura de $0.30/M.
• El chino es el carril CJK más barato de 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 contra kimi-k3, que está en producción en el gateway de Synthorai a los precios de lista de Moonshot, con prompts repetidos y modificados para saltarse las cachés de respuesta y las afirmaciones de comportamiento verificadas en un segundo camino de petición independiente. Cada número está respaldado por registros de uso reales.

¿Cuánto cuesta por respuesta Kimi K3 con la configuración por defecto?

El reasoning domina la factura en todos los tipos de tarea que enviamos, incluso en los que no requieren razonar nada. Por respuesta, con la configuración por defecto:

El contraste entre modelos es lo que muestra el gráfico: GPT-5.6 razona de forma adaptativa (cero tokens de reasoning en las preguntas triviales y de datos, 65-70% en matemáticas y escritura), Claude Sonnet 5 viene con el thinking desactivado, y GLM-5.2 razona incluso más que K3 en términos relativos. Pero el precio de salida de GLM es $4.40/M y el de K3 es $15/M, así que 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 crece 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, un factor de 15x en la tarea más corriente del conjunto. La tasa del impuesto es comparable a la de otros modelos de reasoning chinos; la factura del impuesto no.

Dos datos más del modo por defecto que conviene tener en cuenta al presupuestar. Primero, el modo thinking inyecta un preámbulo oculto de unos 67 tokens en cada petición: un mensaje idéntico de una sola palabra facturó 86 tokens de prompt con reasoning activado y 19 con él desactivado. Es el “system prompt oculto” que notaron los primeros testers, y desaparece cuando desaparece el reasoning. Segundo, K3 va lento por ahora: nuestras llamadas de preguntas triviales tardaron unos 19-24 segundos de principio a fin con reasoning activado y 3-8 segundos con él desactivado, incluyendo el serving de la semana de lanzamiento. Presupuesta la latencia, no solo los dólares.

¿Se puede desactivar el razonamiento de Kimi K3?

Sí, a pesar de lo que dice la documentación. La referencia oficial de la API afirma que K3 “siempre activa el pensamiento” y que reasoning_effort solo acepta "max". En la práctica, el endpoint aceptó "none", "low", "medium" y "high" sin error, los respetó, y confirmamos el mismo comportamiento por una ruta de petición independiente. En el problema de lógica de varios pasos, el control existe, pero es tosco:

Destacan dos cosas. Los valores intermedios se agrupan: de low a max el conteo de tokens fue similar y la precisión idéntica en esta tarea, así que el interruptor útil es binario. Y none tiene un salto abrupto real: obligado a responder de forma escueta un problema aritmético de varios pasos, K3 falló seis de seis veces, con respuestas erróneas dispersas en lugar de un único error sistemático. Cuando no forzamos un formato escueto, el modelo a veces ignoraba la brevedad y resolvía los pasos en la respuesta visible: correcto, pero los tokens pasaban del campo de razonamiento al de texto en vez de desaparecer.

La latencia se mueve menos de lo que sugiere el conteo de tokens. Al hacer streaming del mismo problema en cada nivel de esfuerzo, los tiempos hasta el primer byte fueron de 6-24 segundos, con rangos que se solapan mucho entre niveles; incluso none, sin nada que pensar, esperó 12-13 segundos, así que el servicio domina el tiempo hasta el primer token en tareas de este tamaño. Lo que realmente cambia el control es el hueco entre el primer byte y el primer token de respuesta, que es la fase de pensamiento que el usuario aguanta.

Lectura práctica: none es una palanca real de costes para tareas de recuperación, formateo o un solo paso, y un tiro en el pie para cualquier cosa que necesite pasos intermedios. No hay garantía documentada de que este parámetro siga funcionando; trátalo como comportamiento medido, verifícalo en tus propios campos usage y cuenta con que puede formalizarse o eliminarse cuando la documentación se ponga al día.

¿Cuándo debe quedarse activo el razonamiento en cargas de agente?

Pasamos K3 por cinco escenarios con forma de agente dos veces, por defecto frente a reasoning_effort: "none", con tareas simples idénticas que ambas configuraciones superaron por completo:

La sorpresa está en la primera fila: en los bucles de tool-call K3 apenas piensa incluso por defecto (8% de peso), así que hay poco que ahorrar; el modelo trata la selección de herramientas como un reflejo, no como una deliberación. El ahorro se concentra donde el peso del pensamiento es alto y la tarea es mecánica (búsquedas RAG y extracción por lotes), que es justo donde menos pinta un impuesto fijo de razonamiento siempre activo. Para planes de agente genuinamente de varios pasos, aplica el salto de precisión de la sección anterior; deja el razonamiento activo y gasta los tokens.

A escala, el efecto en la latencia es real aunque las llamadas individuales sean ruidosas: en estos escenarios los primeros tokens llegaron en 10-19 segundos por defecto y 8-13 segundos con none, y la generación corrió a una mediana de 35 tokens por segundo en salidas sustanciales. Esas cifras, con el servicio de la semana de lanzamiento incluido, encajan mejor con formatos asíncronos y por lotes que con cualquier cosa conversacional hoy.

¿El reasoning que devuelves se vuelve a facturar como input?

Sí, token por token. La documentación de Kimi indica que hay que mantener el reasoning_content de cada turno del assistant sin modificar en el historial de mensajes. Medimos cuánto cuesta esto: un segundo turno enviado con el chain of thought del primer turno facturó 599 prompt tokens; la misma petición sin él facturó 198. La diferencia de 401 tokens coincide casi exactamente con los 402 reasoning tokens del primer turno, así que el thinking retenido vuelve a entrar en cada petición posterior a la tarifa completa de $3/M de input, y una conversación larga vuelve a pagar todo su reasoning acumulado en cada turno.

Descartarlo tampoco sale más barato de forma automática. Sin el chain of thought previo, K3 volvió a razonar el follow-up desde cero: los reasoning tokens del segundo turno subieron un 31% (de 343 a 449). A $3/M de input frente a $15/M de output, mantener el CoT fue la opción neta más barata en nuestra prueba, lo que significa que el consejo de la documentación se sostiene tanto por coste como por calidad. La palanca que de verdad rinde aquí es el prompt cache de la siguiente sección: el historial retenido es un prefijo estable, y los prefijos estables dejan de facturarse a precio completo.

¿Kimi K3 cachea prompts, y a partir de cuántos tokens?

El prompt cache de K3 es automático, y su umbral es bajo: los hits empezaron alrededor de 256 tokens de prefijo compartido y avanzaron en bloques de 256 tokens (un prompt de 303 tokens cacheó 256; un prompt de 153 tokens nunca cacheó pese a los intentos repetidos). El input cacheado se factura a $0.30/M, un descuento fijo del 90% frente a la tarifa fresca de $3/M, sin recargo por cache-write en ninguna llamada que hicimos. El warm-up tardó entre dos y cinco llamadas idénticas antes del primer hit, así que un solo reintento no demuestra nada en ninguna dirección; mídelo con varias.

Para dar contexto, ese umbral es la cuarta parte del mínimo de 1.024 tokens documentado por OpenAI, y el tamaño de bloque es más grueso que la granularidad de 64 tokens que medimos en otros sitios. La vida útil es best-effort en lugar de un TTL fijo: en nuestra prueba las entradas cacheadas sobrevivieron a intervalos de inactividad de 4 y 15 minutos, mientras que un intervalo de 8 minutos falló, así que trata la expiración como una evicción dependiente de la carga y verifica el reparto cacheado en cada llamada. Un dato más de pricing que merece un cálculo: la ventana de contexto de 1M tokens tiene un precio plano, sin ningún tier de long-context en la lista de precios. Una ventana al máximo cuesta $3.00 de input fresco por llamada, y $0.30 una vez que el prefijo está caliente, así que las cargas de gran contexto se juegan la vida en el cache mucho más que en el precio de etiqueta. Si tu tráfico reutiliza un system prompt de aunque sea unos pocos cientos de tokens, el cache de K3 se activa donde el de la mayoría de proveedores ni habría empezado; la mecánica y cómo verificar los hits desde usage están cubiertas en nuestra guía de prompt caching y en el estudio de mínimos de cache medidos.

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

No. El chino es justo donde el tokenizador de K3 es más eficiente frente a sus competidores, lo que responde a una pregunta que salió una y otra vez durante la semana del lanzamiento. Tokens netos por cada 100 caracteres en pasajes alineados semánticamente, restando el overhead del sobre:

K3 factura el chino a 52 tokens por cada 100 caracteres: 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 paga entre un 16 y un 24% más que los otros modelos open-weight. También confirmamos que el tokenizador no ha cambiado en toda la familia: K3, K2.7-code y K2.5 dieron cuentas idénticas en las 23 muestras alineadas, así que los presupuestos por idioma hechos para K2 siguen sirviendo. Cómo se combina la densidad del tokenizador con el precio por token en nueve idiomas es el tema de nuestro estudio LLM más barato por idioma.

Preguntas frecuentes

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

Moonshot ha prometido pesos completos bajo una licencia MIT modificada para el 27 de julio de 2026; a fecha de esta publicación, K3 es solo API. El marco del “modelo de pesos abiertos más grande jamás creado” es un compromiso, todavía no un enlace de descarga. Cómo se comporta el almacenamiento en caché en el ecosistema de pesos abiertos al que se unirán los pesos se detalla en almacenamiento en caché de prompts para LLM de pesos abiertos.

¿Qué hay realmente de nuevo en K3 frente a la familia K2?

En la factura, tres cosas que medimos: el precio (los $3/$15 de K3 frente a los $0.95/$4 de K2.7-code, un salto de 3.2 a 3.75x), el thinking siempre activo (K2.5 no razona en absoluto, K2.7-code tiene un toggle) y nada más: el tokenizador es idéntico byte a byte en K3, K2.7-code y K2.5 en las 23 muestras alineadas, así que los presupuestos de tokens de la época K2 siguen valiendo. En la ficha técnica, según Moonshot: un nuevo MoE de 2.8T parámetros (896 expertos, 16 activos por token) con Kimi Delta Attention, una ventana de contexto de 1M tokens frente a los 256K de K2.7-code, y entrada de imágenes nativa. Nosotros medimos lo de la facturación, no lo de la arquitectura.

¿Kimi K3 admite structured output?

Sí. Un response_format con json_schema devolvió un objeto válido y conforme al esquema en nuestra prueba. Ojo: el razonamiento sigue corriendo por debajo: 66 de los 97 tokens de salida en esa llamada de extracción fueron de razonamiento, así que las llamadas con esquema pagan el impuesto del thinking igual que todo lo demás, salvo que además pongas reasoning_effort: "none".

¿Apagar el razonamiento cambia lo que puedes ver?

Sí. Con los ajustes por defecto, K3 devuelve toda su cadena de pensamiento en reasoning_content, y la documentación recomienda reenviarla sin modificar en el historial multi-turno. Con reasoning_effort: "none" el campo desaparece por completo, y con él se va de tu factura de prompt el preámbulo de razonamiento de unos 67 tokens.

Medido el 2026-07-20 sobre kimi-k3 a los precios de lista de la semana del lanzamiento ($3/M entrada, $0.30/M en caché, $15/M salida). Los prompts repetidos se salaron para evitar cachés a nivel de respuesta; los recuentos de precisión usan tareas con una única respuesta verificable; las afirmaciones sobre comportamiento se reprodujeron en una segunda ruta de petición independiente. Los precios y el comportamiento pueden cambiar a medida que madure el lanzamiento; verifica contra tus propios registros de usage antes de fiarte de cualquier cifra de aquí.

← Volver al blog