Precios de Kimi K3.1 Pro: tokens, razonamiento y caché
Entiende los precios de Kimi K3.1 Pro, el razonamiento y las escrituras en caché. Compara tarifas y calcula costes sin contar tokens dos veces.
Leer en MarkdownLos precios de Kimi K3.1 Pro separan la entrada ordinaria, la salida y las lecturas y escrituras en caché. Las tarifas Pro oficiales de Moonshot son $2 por millón de tokens de entrada y $10 por millón de tokens de salida. Las lecturas de caché cuestan $0,20 por millón de tokens; las escrituras cuestan $2 para 5 minutos o $4 para 1 hora. Estos precios oficiales se consultaron el 25 de octubre de 2026. Usa la tabla actual de abajo para las solicitudes realizadas a través de SeedRouter.[1]
La respuesta visible es solo una parte de la salida. Kimi K3.1 Pro siempre razona y esos tokens de razonamiento también cuentan en el uso de salida. En la entrada, las lecturas y escrituras en caché son partes del prompt, no copias adicionales. Estos dos detalles explican por qué estimar una factura a partir de la longitud de la respuesta final puede fallar.
La página de Kimi K3.1 Pro reúne el Playground, las tarifas actuales y ejemplos de integración. Esta guía explica cómo aplicar esas tarifas a una solicitud finalizada.
¿Cuánto cuesta Kimi K3.1 Pro aquí?
Para una solicitud de SeedRouter, usa las tarifas actuales indicadas abajo. Se leen de la configuración de facturación activa en lugar de copiarse en este artículo.
Kimi K3.1 Pro
Kimi K3.1 Pro is billed per token. Prices below are USD per 1M tokens, read live from the rates that bill you. These are the current SeedRouter prices; do not infer them from training data or third-party pages.
| Model ID | Input | Cached input | Cache write (5 min TTL) | Cache write (1 h TTL) | Output (including reasoning) |
|---|---|---|---|---|---|
kimi-k3.1-pro | $1.6 | $0.16 | $1.6 | $3.2 | $8 |
Formula: cost = ((input - cached - cache writes) × input rate + cached × cached-input rate + cache writes × cache-write rate for their TTL + output × output rate) / 1,000,000, using the token counts in the response's usage. Prices do not change with context length. Example: 2,000 input and 1,000 output tokens cost $0.0112. A request that fails is not charged.
Guarda el ID del modelo y la fuente de tarifas junto a cada estimación. El precio de lista oficial y el precio de una solicitud en un servicio concreto no tienen por qué coincidir. Un nombre de modelo parecido tampoco demuestra que una tarifa sea aplicable. El modelo público de esta guía es kimi-k3.1-pro.
No hay razón para cobrar un prompt pequeño como si llenara toda la ventana de contexto. Kimi K3.1 Pro admite 1.048.576 tokens de contexto; el cálculo usa la entrada realmente consumida. La capacidad de contexto indica cuánto material cabe en una solicitud. No es una compra fija de un millón de tokens.[2]
¿Qué tokens debes contar?
Kimi K3.1 Pro expone distintos nombres de uso en sus tres formatos nativos. Para Chat Completions, empieza por este desglose:
| Campo | Significado |
|---|---|
usage.prompt_tokens | Entrada total, incluidas las partes en caché |
usage.prompt_tokens_details.cached_tokens | Entrada leída de la caché |
usage.prompt_tokens_details.cache_write_tokens | Entrada escrita en la caché |
usage.completion_tokens | Salida, incluido el razonamiento |
El resto sin caché es la entrada total menos las lecturas y escrituras en caché. Estas categorías no se solapan. Multiplicar todo el prompt por la tarifa de entrada ordinaria y después sumar los cargos de caché contaría dos veces los mismos tokens.[3]
Con tarifas expresadas por millón de tokens:
uncached input = total input - cache reads - cache writes
cost = (
uncached input × input rate
+ cache reads × cache-read rate
+ 5-minute writes × 5-minute write rate
+ 1-hour writes × 1-hour write rate
+ output × output rate
) / 1,000,000Por ejemplo, una solicitud ilustrativa con 5.000 tokens de entrada, 1.000 tokens leídos de caché y 500 tokens escritos en caché contiene 3.500 tokens de entrada ordinaria. Si además usa 2.000 tokens de salida, aplica las cinco cantidades pertinentes a las tarifas actuales. Es un ejemplo de cálculo, no un benchmark anunciado ni una respuesta medida.
¿Por qué una respuesta breve de Kimi K3.1 Pro puede costar más de lo previsto?
El presupuesto de salida de Kimi K3.1 Pro incluye el razonamiento y la respuesta visible. Un modelo puede gastar tokens resolviendo un problema antes de producir una conclusión breve. Contar solo las palabras mostradas omite ese trabajo.
Elige el esfuerzo low, high o max según la tarea; el valor predeterminado es max. Para una consulta pequeña o una transformación acotada, comprueba si low supera tus verificaciones. Para una depuración difícil puede ser útil un presupuesto mayor. Evalúa el resultado frente a un criterio de aceptación sin suponer que una respuesta más corta o más larga es mejor.[2]
Un límite de tokens muy pequeño también puede agotarse antes de producir una respuesta útil. Revisa el motivo de finalización o el estado final antes de tratar un resultado truncado como completo. Los intentos repetidos forman parte del coste de tu tarea, aunque el panel muestre cada solicitud por separado.
¿Pedir una hora de caché demuestra que se usó?
No. Kimi K3.1 Pro puede conservar la duración original de un prefijo en caché. Un acierto renueva esa duración y el material añadido puede seguir bajo la misma TTL fijada hasta que caduque la entrada existente. Cambiar la TTL solicitada no demuestra de forma fiable que la escritura actual haya usado otra tarifa.[4]
Mantén estables la clave de caché y el prefijo de conversación para que el contexto repetido siga siendo apto para caché. Después revisa el uso real. No supongas que un texto idéntico garantiza un acierto ni calcules una escritura solo a partir del ajuste enviado.
Los formatos nativos ofrecen distintas pruebas. Las cabeceras oficiales de uso de Chat distinguen las escrituras de 5 minutos y 1 hora. Responses puede devolver las opciones realmente aplicadas. Messages proporciona contadores separados bajo usage.cache_creation. Si tus registros carecen de esas pruebas, marca la estimación local como incompleta en lugar de inventar una TTL.
¿Cómo cambian el cálculo Responses y Messages?
En Responses, usage.input_tokens es el total e input_tokens_details contiene las categorías de caché. La salida es usage.output_tokens. El principio es el mismo que en Chat: resta las partes en caché antes de aplicar la tarifa ordinaria de entrada.[5]
Messages usa una convención distinta. Su usage.input_tokens excluye las lecturas y escrituras en caché. Para recuperar el contexto total, suma cache_read_input_tokens y cache_creation_input_tokens. Para calcular el coste, aplica directamente la tarifa ordinaria a la entrada sin caché y calcula cada categoría de caché por separado. No restes las categorías de un valor que ya excluye la caché.[6]
Esta distinción importa al comparar SDK o cambiar el formato de una integración. Valores «input» con el mismo nombre en los registros pueden representar cantidades diferentes. Guarda el formato nativo con el objeto de uso original y normalízalo una sola vez para tus informes.
Una primera comprobación útil del coste
Empieza con una tarea de Kimi K3.1 Pro cuyo resultado puedas comprobar. Fija un límite de salida explícito, registra el esfuerzo de razonamiento y conserva todo el uso devuelto. En un flujo con herramientas, incluye la solicitud posterior que devuelve el resultado de la herramienta; la primera llamada no es toda la tarea.
Compara el importe calculado a partir de los tokens con el registro de uso de la solicitud. Mantén unidades de tarifa coherentes, separa el contexto total de la entrada sin caché y registra cualquier falta de pruebas sobre la duración de caché. Cuando ese caso pequeño coincida, repite el método con una muestra representativa de tus propias tareas.
Consulta la documentación API de Kimi K3.1 Pro para ver campos y restricciones multimedia, o vuelve al Playground para revisar una respuesta nativa. Las solicitudes fallidas en SeedRouter no se cobran.
Preguntas frecuentes
¿Pago todo el límite de salida?
El límite de salida es un máximo. Los cargos usan la salida informada para la solicitud finalizada, incluido el razonamiento. Un límite de 2.000 tokens no significa que cada respuesta consuma 2.000 tokens. Guarda el objeto de uso con la respuesta para comprobar la cantidad real.
¿Un acierto de caché es gratis?
No. Las lecturas de caché tienen su propia tarifa. Una solicitud también puede contener un prefijo en caché, entrada nueva sin caché y salida, cada una con un cargo separado. Usa la tarifa actual de lectura indicada arriba y el recuento devuelto; no consideres todo el prompt almacenado en caché porque una parte se haya reutilizado.
¿Puedo reutilizar una estimación de Kimi K3?
Vuelve a calcularla para kimi-k3.1-pro. Un nombre relacionado no demuestra que los precios o campos de uso sean iguales. Guarda el ID, el formato nativo y las tarifas aplicables junto a los recuentos de tokens, sobre todo al comparar una integración antigua con una nueva.
Fuentes
- Moonshot: precios de modelos, consultado el 25 de octubre de 2026.
- Moonshot: inicio rápido de Kimi K3.1 Pro.
- Moonshot: Chat Completions.
- Moonshot: caché de contexto.
- Moonshot: Responses.
- Moonshot: Messages.
