API de Kimi K2: retirada y migración a K3.1 Pro

Migra las cargas de kimi-k2.6 y kimi-k2.7-code a kimi-k3.1-pro antes de la retirada prevista para finales de diciembre de 2026. Define explícitamente el esfuerzo de razonamiento y el límite de generación. Antes de cambiar el tráfico de producción, verifica el historial de llamadas a herramientas y los cargos de caché.

A fecha de 2026-11-05, las restricciones para cuentas nuevas ya están activas.

¿Cuándo dejará de funcionar Kimi K2?

Las cuentas existentes que cumplen los requisitos conservan el acceso por ahora. Kimi no ha publicado en estos avisos un día ni una hora exactos para la retirada.

El aviso de precios indica que K2 dejó de estar disponible para nuevos usuarios registrados a partir del 31 de octubre de 2026. La empresa planea retirar todos los modelos K2 para finales de diciembre de 2026.

La lista de modelos actual utiliza una formulación algo distinta. Indica que los usuarios registrados antes del 1 de noviembre pueden seguir usando kimi-k2.6, kimi-k2.7-code y kimi-k2.7-code-highspeed. Su retirada está prevista para finales de diciembre de 2026.

Si te registraste cerca de esas fechas, comprueba el acceso real de tu cuenta. Las formulaciones no establecen un momento de corte preciso. Para nuevos despliegues, empieza con K3.1 Pro.

No presupongas que todos los fallos de acceso a K2 devuelven el mismo error. El registro de cambios de agosto confirma 404 “model not found” para los modelos retirados kimi-k2.5 y moonshot-v1. Esa afirmación no especifica la respuesta que devolverá la retirada de K2.6 o K2.7 Code.

Cambia el formato de las solicitudes antes de migrar el tráfico

Actualiza conjuntamente el cuerpo de las solicitudes y el almacenamiento de las conversaciones. La comparación de parámetros de Kimi documenta diferencias que una sustitución del nombre del modelo puede pasar por alto.

Ajuste	`kimi-k2.6`	`kimi-k2.7-code`	`kimi-k3.1-pro`
Razonamiento	Activado por defecto; se puede desactivar	Siempre activado	Siempre activado; elimina el objeto `thinking` de K2
`reasoning_effort`	No admitido	No admitido	Campo de nivel superior: `low`, `high` o `max`; por defecto, `max`
`temperature`	Valor fijo de `1.0` con razonamiento; `0.6` sin razonamiento	Valor fijo de `1.0`	Valor fijo de `1.0`; omite el campo
Límite de generación documentado por defecto	`max_tokens`: `32768`	`max_tokens`: `32768`	`max_completion_tokens`: `131072`

K2.7 Code ya exigía razonar y conservar el razonamiento. El cambio es mayor si vienes del modo sin razonamiento de K2.6.

La guía de inicio de K3.1 Pro también fija top_p=0.95, n=1, presence_penalty=0 y frequency_penalty=0. Omite estos campos y temperature. Revisa también los valores por defecto del cliente o adaptador: pueden insertar un valor de muestreo que tu aplicación nunca haya definido.

Usa max_completion_tokens en las nuevas solicitudes de Chat Completions. La referencia de la API marca max_tokens como obsoleto; no indica que se haya eliminado. K3.1 Pro admite un máximo configurable de 1048576, sujeto al espacio disponible en el contexto.

El límite de generación es un máximo, no un consumo fijo por solicitud. Elige un límite para tu tarea en lugar de heredar el nuevo valor por defecto, que es mayor.

Para el esfuerzo de razonamiento, empieza con low en comprobaciones de conectividad y consultas acotadas. Prueba high para el trabajo habitual de programación. Usa max cuando tus pruebas de regresión justifiquen el razonamiento adicional. low reduce el esfuerzo; no desactiva el razonamiento.

Comprueba la API y una llamada a herramienta

Verifica la API directamente antes de depurar la configuración de un agente.

Crea una clave de API de Global Kimi Open Platform. A fecha de 2026-11-05, los requisitos de acceso exigen una recarga completada de al menos $1. Usa una clave de la plataforma que corresponda a https://api.moonshot.ai. Para errores de cuenta de Kimi Code, consulta la guía específica de límites de Kimi Code.

En Bash, introduce la clave sin mostrarla en pantalla:

read -rs MOONSHOT_API_KEY && export MOONSHOT_API_KEY

El siguiente comando de Bash utiliza la biblioteca estándar de Python 3. Envía dos solicitudes facturables y ejecuta localmente la multiplicación solicitada por la herramienta. El límite de generación 4096 corresponde a esta prueba aritmética, no a un presupuesto general para programar.

python3 - <<'PY'
import json
import os
import urllib.error
import urllib.request

tools = [{
    "type": "function",
    "function": {
        "name": "multiply",
        "description": "Multiply two integers.",
        "parameters": {
            "type": "object",
            "properties": {
                "a": {"type": "integer"},
                "b": {"type": "integer"}
            },
            "required": ["a", "b"],
            "additionalProperties": False
        }
    }
}]

def chat(messages, choice):
    payload = {
        "model": "kimi-k3.1-pro",
        "messages": messages,
        "reasoning_effort": "low",
        "max_completion_tokens": 4096,
        "tools": tools,
        "tool_choice": choice
    }
    request = urllib.request.Request(
        "https://api.moonshot.ai/v1/chat/completions",
        data=json.dumps(payload).encode("utf-8"),
        headers={
            "Authorization": "Bearer " + os.environ["MOONSHOT_API_KEY"],
            "Content-Type": "application/json"
        },
        method="POST"
    )
    try:
        with urllib.request.urlopen(request, timeout=120) as response:
            data = json.load(response)
    except urllib.error.HTTPError as error:
        raise SystemExit(f"HTTP {error.code}: check access and request parameters.")
    if data.get("model") != "kimi-k3.1-pro":
        raise RuntimeError("Unexpected response model.")
    if data["choices"][0]["finish_reason"] == "length":
        raise RuntimeError("Generation limit reached; do not accept this result.")
    return data

messages = [{
    "role": "user",
    "content": "Use multiply to calculate 6 times 7, then report the result."
}]
first = chat(messages, "required")
assistant = first["choices"][0]["message"]
calls = assistant.get("tool_calls") or []
if not calls:
    raise RuntimeError("Expected a tool call.")
messages.append(assistant)

for call in calls:
    function = call["function"]
    arguments = json.loads(function["arguments"])
    if function["name"] != "multiply":
        raise RuntimeError("Unexpected tool.")
    if not isinstance(arguments, dict) or set(arguments) != {"a", "b"}:
        raise RuntimeError("Unexpected arguments.")
    if any(type(arguments[key]) is not int for key in ("a", "b")):
        raise RuntimeError("Expected integer arguments.")
    result = arguments["a"] * arguments["b"]
    messages.append({
        "role": "tool",
        "tool_call_id": call["id"],
        "content": json.dumps({"result": result})
    })

final = chat(messages, "none")
choice = final["choices"][0]
answer = choice["message"].get("content") or ""
if choice["finish_reason"] != "stop" or not answer.strip():
    raise RuntimeError("Expected a completed final answer.")
print(answer)
print(json.dumps({"first": first["usage"], "final": final["usage"]}))
PY

El resultado esperado es una respuesta final que contenga 42, seguida de los objetos de consumo de ambas solicitudes. La prueba rechaza resultados sin llamadas a herramientas, con otro modelo, argumentos inválidos, generación truncada o una respuesta final incompleta.

La operación importante es messages.append(assistant). Conserva el mensaje completo de respuesta, incluidos reasoning_content y tool_calls. Cada resultado de herramienta utiliza después el tool_call_id correspondiente. Aplica esta regla de conservación del historial al almacenamiento de conversaciones en producción.

La prueba utiliza deliberadamente llamadas obligatorias y llamadas prohibidas para comprobar ambas etapas. Los bucles habituales de un agente pueden usar auto cuando el modelo deba decidir si necesita otra llamada a herramienta.

Si falla la solicitud, elige la siguiente comprobación con la referencia de errores:

Para 401, comprueba la plataforma de origen de la clave y el endpoint. Después, repite la misma prueba.
Para 400 en tu aplicación existente, revisa si el JSON enviado contiene ajustes thinking de K2 o valores que sobrescriben los parámetros fijos de muestreo.
Para 404, comprueba tanto el identificador del modelo como el acceso de la cuenta. El código por sí solo no demuestra una errata.
Para finish_reason="length", considera incompleta la respuesta. Ajusta la tarea, el esfuerzo o el límite de generación antes de aceptarla.

A fecha de 2026-11-05, BetterToken también incluye kimi-k3.1-pro en su catálogo. Su API compatible con OpenAI utiliza https://www.bettertoken.ai/v1 con tu propia clave de API de BetterToken. Comprueba sus precios actuales y los requisitos de las solicitudes por separado; las reglas de caché de Moonshot no describen el comportamiento de esta pasarela.

Actualiza OpenCode y Claude Code

Cambia todas las rutas que puedan seleccionar K2, incluidas las tareas en segundo plano y los subagentes. Que la conversación principal funcione no valida esas rutas.

OpenCode: selecciona el proveedor Moonshot

Usa el proveedor integrado Moonshot AI y actualiza su catálogo de modelos. Su identificador es moonshotai y lee la clave de MOONSHOT_API_KEY.

Para la interfaz CLI de OpenCode v1.19.5, ejecuta estos comandos en la misma sesión de Bash:

opencode models moonshotai --refresh
opencode run --model moonshotai/kimi-k3.1-pro --variant high \
  "Inspect the current project and identify the test command. Do not edit files."

La lista actualizada debería contener moonshotai/kimi-k3.1-pro. La ejecución debería devolver una respuesta específica de tu proyecto con ese proveedor y modelo. Si falta el modelo, comprueba la versión instalada del cliente y la actualización del catálogo antes de continuar.

La referencia de la CLI documenta ambas opciones. Para guardar el modelo, establece "model": "moonshotai/kimi-k3.1-pro" en el archivo del proyecto opencode.json o en el global ~/.config/opencode/opencode.json. Aplica las reglas de prioridad de configuración cuando existan ambos archivos.

El comando establece high para esa ejecución. En una sesión interactiva, selecciona el esfuerzo con /variants antes de enviar el primer mensaje. Si también actualizas el cliente, revisa los cambios de permisos de OpenCode 2 antes de permitir modificaciones del repositorio.

Claude Code: actualiza todos los alias de modelo

Moonshot documenta una ruta compatible con Claude Code. La documentación de pasarelas de Anthropic indica que no ofrece soporte para dirigir Claude Code a modelos que no sean Claude. Trata esta integración como una ruta mediante el adaptador de Moonshot y valídala con tu cliente instalado.

Primero revisa ~/.claude/settings.json y los ajustes del proyecto. Corrige los valores antiguos de endpoint, credenciales, modelo y esfuerzo en sus bloques env. Moonshot advierte que las variables de estos archivos pueden sobrescribir las exportadas en el terminal.

El ejemplo actual de Moonshot todavía asigna Haiku a kimi-k2.7-code. La siguiente configuración de Bash propone dirigir todos los niveles de modelo indicados al destino de la migración:

unset ANTHROPIC_API_KEY
export ANTHROPIC_BASE_URL="https://api.moonshot.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="$MOONSHOT_API_KEY"
export ANTHROPIC_MODEL="kimi-k3.1-pro"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_FABLE_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_EFFORT_LEVEL="high"

claude --model kimi-k3.1-pro

Esto reutiliza la clave exportada para la prueba de la API. Revisa cualquier ajuste antiguo de K2 que quede, incluido ANTHROPIC_SMALL_FAST_MODEL.

Ejecuta /status y comprueba la URL base y el modelo. Después, pide una respuesta sencilla y una tarea que lea un archivo local. Confirma el esfuerzo efectivo mediante los controles de configuración del modelo.

Claude Code utiliza el protocolo Messages. Distingue estos campos de Kimi Messages de los de Chat Completions:

Propósito	Chat Completions	Kimi Messages
Esfuerzo de razonamiento	`reasoning_effort`	`output_config.effort`
Límite de generación	`max_completion_tokens`	`max_tokens`, obligatorio
Duración de la caché	`prompt_cache_options.ttl`	`cache_control.ttl`, con `cache_control` en el nivel superior

No cambies el nombre de max_tokens en Messages porque su equivalente de Chat Completions esté obsoleto.

Comprueba los costos de caché sin contar tokens dos veces

Separa la entrada en lecturas de caché, escrituras en caché y entrada sin caché. K3.1 Pro factura las escrituras en caché por separado. Incluye esos cargos en el cálculo de costos.

Para Chat Completions, lee estos campos:

Entrada total: usage.prompt_tokens.
Lecturas de caché: usage.prompt_tokens_details.cached_tokens.
Escrituras en caché: usage.prompt_tokens_details.cache_write_tokens.
Salida total: usage.completion_tokens.

Las reglas de contabilización de la API establecen que las tres categorías de entrada son mutuamente excluyentes. La salida ya incluye los tokens de razonamiento y de respuesta.

Usa tarifas expresadas en una misma moneda por 1,000,000 tokens:

uncached = prompt_tokens - cached_tokens - cache_write_tokens

token_cost = (
    uncached * miss_rate
    + cached_tokens * hit_rate
    + write_5m * write_5m_rate
    + write_1h * write_1h_rate
    + completion_tokens * output_rate
) / 1_000_000

Aquí, write_5m + write_1h debe ser igual a cache_write_tokens. Obtén las tarifas de los precios actuales del proveedor. El cálculo estima los cargos por tokens; compáralo con la factura.

Kimi utiliza automáticamente una caché de 5m cuando omites sus opciones. Para solicitudes con intervalos mayores, evalúa "prompt_cache_options": {"mode": "implicit", "ttl": "1h"}.

La guía de caché indica que una entrada existente conserva su duración inicial, o TTL. Enviar 1h no amplía una entrada activa de 5m. Captura los encabezados de respuesta Msh-Usage-Cache-Write-Tokens-5m y Msh-Usage-Cache-Write-Tokens-1h para identificar las cantidades realmente escritas.

Prueba varias solicitudes con un prefijo representativo que no cambie. La prueba aritmética puede ser demasiado pequeña para demostrar un uso útil de la caché, porque los bloques parciales no se almacenan. Mantén constante el esfuerzo de razonamiento durante la prueba: cambiarlo invalida los aciertos de caché de prefijos.

En aplicaciones con respuestas en streaming, establece también stream_options.include_usage=true. Sigue la guía de streaming para ensamblar los fragmentos de razonamiento, respuesta y llamadas a herramientas. Lee el último fragmento de consumo aunque su lista choices esté vacía.

Define las pruebas de regresión antes del cambio

Migra una pequeña parte del tráfico solo cuando la nueva ruta supere tus pruebas de aceptación existentes.

Usa la misma revisión del repositorio, los mismos prompts, las mismas definiciones de herramientas y los mismos comandos de prueba en cada comparación. Ejecuta low, high y max en sesiones separadas. Registra la calidad de las tareas completadas y la latencia total. Anota también las categorías de entrada, la salida total, los reintentos y el costo facturado.

Incluye estos escenarios en las pruebas de regresión:

Una conversación de varios turnos que dependa de una respuesta anterior del asistente.
Una llamada a herramienta seguida de otra respuesta del modelo.
Una llamada a herramienta en streaming con argumentos JSON fragmentados.
Una tarea cercana al límite de generación configurado.
Una tarea en segundo plano o de un subagente que pueda conservar un alias de K2.

Elige el esfuerzo más bajo que cumpla tus requisitos de calidad y latencia. Si high falla en una tarea importante que max completa de forma fiable en tus comprobaciones, conserva max para esa clase de tareas.

Mantén la opción de volver a K2 solo mientras la cuenta conserve el acceso. Antes del período de retirada, prueba una ruta de respaldo que no dependa de K2. Elimina los identificadores antiguos de K2 de las tareas programadas, las rutas de reintento y la configuración de los agentes.