Kimi K2.7 Code (2026): ¿Un recorte del 30% de tokens baja tu factura?

La decisión entera gira sobre la fracción de tus tokens de salida que van a razonamiento. Mide eso primero; luego elige.

Siete filas cubren los casos habituales. Si no haces nada más, toma en serio la fila de "mide primero" — cada cifra depende de la fracción de tokens de salida que van a razonamiento, específica de tu tráfico. Los benchmarks del proveedor no te lo dicen; tus propios logs sí.

Si no haces nada más, toma en serio la fila de "mide primero" — cada cifra en dólares depende de la fracción de tokens de salida que van a razonamiento, específica de tu tráfico. Los benchmarks del proveedor no te lo dirán; tus propios logs sí.

Comparación lado a lado de las dos cadenas de modelo. Misma ventana de contexto y mismo precio por token; la caché es peor y la modalidad es más estrecha en K2.7 Code.

Tres hechos lo resumen todo: (1) el precio por token es idéntico — $0.95 de entrada y $4.00 de salida en ambos; (2) las lecturas de caché son peores en K2.7 ($0.19 frente a $0.16); (3) K2.7 Code es solo texto (no acepta imágenes; K2.6 sí). Igualdad de precio + caché peor = exactamente una palanca puede bajar tu factura: la reducción de tokens de pensamiento.

Las tres cifras que alimentan el hype son todas propietarias de Moonshot, sin reproducción independiente. Trata a K2.7 Code como aproximadamente clase K2.6 en calidad hasta que tus propias evaluaciones digan lo contrario.

Las tres son benchmarks propietarios de Moonshot. No hay reproducción independiente. Ningún resultado público de SWE-bench Verified / LiveCodeBench / GPQA en el lanzamiento. VentureBeat lo cubrió bajo "los practicantes dicen que los benchmarks no se sostienen". El investigador Elliot Arledge corrió K2.7 Code frente a K2.6 en KernelBench-Hard (benchmark público de kernels de GPU): la puntuación de MoE-kernel retrocedió a 0.157 frente al 0.222 de K2.6 con peor ajuste.

Razón estructural para descontar: un benchmark de proveedor con una dispersión estrecha de puntuación puede mostrar una ganancia porcentual grande sobre un movimiento absoluto pequeño, y un harness propietario puede afinarse al modelo que se lanza con él. El benchmark que resolvería la decisión de routing tiene una dispersión amplia entre modelos y una metodología pública. K2.7 no se sometió a eso en el lanzamiento. Justifica el cambio en la matemática de tokens, no en deltas de benchmark.

Trata a K2.7 Code como aproximadamente clase K2.6 en calidad hasta que tus propias evaluaciones digan lo contrario; justifica el cambio en la matemática de tokens, no en deltas de benchmark.

Los tokens de pensamiento se facturan como tokens de salida. La entrada no se mueve. El ahorro real es 30% multiplicado por la fracción de tu gasto que va a razonamiento.

La reducción limpia es: reduction ≈ 0.30 × (gasto en pensamiento / gasto total). Si el pensamiento es prácticamente toda tu factura, te acercas al 30%; si es una porción pequeña, el ahorro es una porción pequeña. La variable es la fracción de gasto en razonamiento, que va desde casi total (codificación agents multi-paso) hasta casi cero (entrada larga, respuesta de una línea).

El ejemplo de Moonshot: una corrida de 12 horas que cae de ~2M tokens de razonamiento a ~1.4M (el 30%). Es un ejemplo del proveedor, no tu resultado medido, pero muestra la forma del ahorro.

No generalices esa corrida de 12 horas a todo trabajo — una llamada de resumir que lee 200K y escribe 200 es el perfil opuesto. No tienes que adivinar: cada respuesta trae usage con prompt_tokens y completion_tokens; el pensamiento va dentro de completion; la fracción que te importa es completion_tokens × $4.00/M ÷ factura total. Regístralo a lo largo de una semana representativa antes de cambiar una cadena de modelo.

Tu proporción pensamiento-a-salida medida decide, no el folleto.

Mismos precios ($0.95/$4.00), sin aciertos de caché. La facturación se calcula por trabajo y se extrapola a un mes para tres perfiles de carga distintos.

La única diferencia entre K2.6 y K2.7 Code en estas cuentas es el recorte del 30% en tokens de pensamiento. La entrada no se mueve; los tokens visibles no se mueven. Lo que cambia es el total de tokens de salida y, por tanto, el coste de salida.

Los tres ejemplos acotan el mundo real: de ~1% a ~26% según la fracción de razonamiento; una carga de codificación mixta típica cae en torno al 13% en el medio. Cuanto más cerca esté la salida de ser todo pensamiento, más cerca del titular; cuanto más factura sea entrada, menos ahorras.

K2.7 Code cobra $0.19/M por entrada cacheada frente a $0.16/M en K2.6. En trabajos con mucho reuso de caché y poco razonamiento, esa prima puede comerse el ahorro de pensamiento y dejar a K2.7 como el modelo más caro.

K2.7 cuesta $0.0072 más por trabajo solo en entrada; ~$216/mes extra a 1,000 trabajos intensivos en caché por día; en un trabajo con mucha caché y poco razonamiento, K2.7 Code puede ser el modelo más caro.

El punto de K2.7 Code es una ganancia de eficiencia estrecha en texto con razonamiento pesado. Si eso no es tu cuello de botella, optimiza el routing, no este cambio.

• Solo texto — no necesitas entrada de imagen.
• Razonamiento pesado: trazas largas de pensamiento frente a respuesta visible (codificación agents, depuración multi-paso, planificación intensa).
• No dependes fuertemente del reuso de caché sobre contexto repetido.

Usa kimi-k2.7-code-highspeed para más throughput al mismo precio; la matemática de tokens no cambia.

Cuatro perfiles donde el cambio no se gana su salario: la palanca del 30% no tiene nada que cortar o la caché más barata gana de salida.

• Necesitas entrada de imagen — K2.7 Code es solo texto.
• Mucha entrada con salidas cortas (RAG, resumir, clasificar): el ahorro redondea a casi nada y la caché más barata te favorece.
• Dependes del modo non-thinking para respuestas directas rápidas: no hay nada que el 30% pueda recortar.
• Tienes K2.6 validado en producción sin una razón medida por la que K2.7 lo haga mejor (los benchmarks no están verificados).

En estos perfiles el ahorro redondea a cero o K2.6 es más barato de entrada; quédate.

Empareja el tier del modelo al trabajo primero; optimiza dentro de un tier después. Si el cuello de botella no es razonamiento pesado en texto, el routing gana al cambio.

El punto de K2.7 Code es una ganancia de eficiencia estrecha en razonamiento pesado de texto; si ese no es tu cuello de botella, optimiza el routing, no este cambio. Empareja el tier del modelo al trabajo primero; optimiza dentro de un tier segundo.

Empareja el tier del modelo al trabajo primero; optimiza dentro de un tier segundo.

Ambos comparten un endpoint compatible con OpenAI; el A/B es un bucle sobre dos cadenas de modelo. Corre tu prompt real por ambos, registra los conteos de tokens que devuelve la API y calcula la factura sobre tu tráfico.

Python — A/B de ambos modelos en un bucle

import os, openai
# Point at Moonshot's API or any OpenAI-compatible gateway carrying both Kimi variants; swap is one model string.
client = openai.OpenAI(
    base_url="https://api.moonshot.ai/v1",
    api_key=os.environ["MOONSHOT_API_KEY"],
)
models = ["kimi-k2.6", "kimi-k2.7-code"]
prompt = "Your real production prompt here"
bills = {}
for m in models:
    r = client.chat.completions.create(
        model=m,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    bills[m] = u.prompt_tokens * 0.95e-6 + u.completion_tokens * 4.00e-6
print(bills)

Node — misma forma

import OpenAI from "openai";
// Point at Moonshot's API or any OpenAI-compatible gateway carrying both Kimi variants; swap is one model string.
const client = new OpenAI({
  baseURL: "https://api.moonshot.ai/v1",
  apiKey: process.env.MOONSHOT_API_KEY,
});
const models = ["kimi-k2.6", "kimi-k2.7-code"];
const prompt = "Your real production prompt here";
const bills = {};
for (const m of models) {
  const r = await client.chat.completions.create({
    model: m,
    messages: [{ role: "user", content: prompt }],
  });
  const u = r.usage;
  bills[m] = u.prompt_tokens * 0.95e-6 + u.completion_tokens * 4.00e-6;
}
console.log(bills);

El cambio es una sola cadena; corre tus 20 prompts reales principales por ambos y suma las facturas. El número que decide el routing es tu propia factura sobre tráfico representativo, no un delta de benchmark.

# swap to kimi-k2.7-code -> error
r = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[
        {"role": "user", "content": [
            {"type": "text", "text": "What's in this screenshot?"},
            {"type": "image_url", "image_url": {"url": "https://example.com/shot.png"}},
        ]},
    ],
)

• Moonshot AI, descripción general de Kimi K2.7 Code (kimi.com/resources/kimi-k2-7-code)
• HuggingFace, moonshotai/Kimi-K2.7-Card
• VentureBeat, cobertura del lanzamiento de K2.7 Code
• Elliot Arledge, corrida de K2.7 Code frente a K2.6 en KernelBench-Hard
• Moonshot AI, Kimi K2.6