Migración a Kimi K3.1 Pro: corrige los errores 400, ten en cuenta el esfuerzo máximo predeterminado y no escribas mal Highspeed

Kimi K3.1 Pro ya está disponible en Kimi Code, en la API de Moonshot como kimi-k3.1-pro y en AIHubMix con el mismo ID. Moonshot le aplica las mismas restricciones de parámetros que a Kimi K3, así que el código que ya funciona con K3 debería migrarse cambiando el ID del modelo e iniciando una sesión nueva. El código escrito para K2.x tiene fecha de caducidad en la plataforma de Moonshot: Moonshot dejará de admitir nuevos usuarios registrados en la serie K2 a partir del 31 October 2026 y tiene previsto retirarla a finales de diciembre. Ese código también es el que más probablemente fallará, porque suele enviar un valor de temperatura o desactivar el modo de pensamiento, y ninguna de las dos cosas funciona con K3.1 Pro. Además, el código que no haya configurado un nivel de esfuerzo se ejecuta con el máximo, lo que consume más tokens de lo que cabría esperar y, en Kimi Code, más cuota que K3.

Esta publicación enumera qué fallos son evidentes (los errores 400 y un 404), cuáles pasan desapercibidos (la factura, la caché y el ID de Highspeed) y cómo configurar Claude Code y Codex para K3.1 Pro a través de AIHubMix. Las reglas de K3.1 Pro proceden de la documentación de modelos de Kimi Code y de su referencia de parámetros del modelo, que indica que ambos IDs de K3.1 Pro tienen «las mismas restricciones de parámetros que kimi-k3». Las reglas identificadas como propias de K3 proceden de las guías de K3 de Moonshot y no se han vuelto a comprobar en K3.1 Pro. Los textos de error se citan de la documentación, de informes públicos, de la prueba de K3 de AIHubMix en julio y de las comprobaciones de K3.1 Pro de AIHubMix del 24 October 2026. Esas comprobaciones incluyeron los IDs principales y los IDs del canal de codificación coding-kimi-k3.1-pro y coding-kimi-k3.1-pro-highspeed. Cada afirmación indica de dónde procede.

¿Qué ruta usas?

En la API de Moonshot y en AIHubMix, los IDs son kimi-k3.1-pro y kimi-k3.1-pro-highspeed. En Kimi Code son k3.1-pro y k3.1-pro-highspeed. Una configuración de cliente observada el 21 de octubre asignaba k3 y kimi-for-coding a un modelo k3.1, pero la documentación actual de Kimi Code indica que k3 corresponde a K3 y kimi-for-coding a K2.8 Preview, así que selecciona K3.1 Pro explícitamente. Tu plan también importa: en Kimi Code, K3.1 Pro requiere Plus o superior (Pro para el contexto de 1M), y Highspeed requiere Pro o superior. En los planes antiguos, se necesita Moderato o superior, y Allegretto para el contexto de 1M y Highspeed.

Las fechas de K2 son las de Moonshot. A partir del 31 October 2026, los modelos de la serie K2 dejarán de estar disponibles para los nuevos usuarios registrados, y está previsto que todos se retiren a finales de diciembre de 2026. Moonshot no ha anunciado una fecha de retirada para K3. El 24 de octubre, AIHubMix seguía ofreciendo K2.6 y K2.7 Code, sin fecha de retirada.

Los fallos evidentes

Modo de pensamiento desactivado: error HTTP 400 o ausencia total de razonamiento

Qué verás: un error HTTP 400 en Kimi Code. La documentación de Kimi Code de Moonshot indica que los modelos K3.1 Pro «solo admiten el modo de pensamiento. Las solicitudes con el modo de pensamiento desactivado se rechazan». La documentación no cita el cuerpo del error. En la API de Moonshot, K3.1 Pro hereda las restricciones de K3, que siempre razona. A través de AIHubMix no se produce un error 400: el 24 de octubre, thinking: {"type": "disabled"} devolvió 200 con los dos IDs principales, tanto en Chat Completions como en Messages, sin razonamiento en la respuesta. En este caso el fallo pasa desapercibido, así que comprueba si falta el razonamiento en las respuestas.

De dónde viene: código de K2.x que desactivaba el modo de pensamiento para responder más rápido, por ejemplo con extra_body={"thinking": {"type": "disabled"}}, y herramientas que envían un nivel de esfuerzo off, none o disabled (siguiente sección).

Solución: elimina el interruptor. Para mantener breve el razonamiento, envía reasoning_effort: "low".

Un bloque «enabled» que haya quedado de antes es otro caso. En la comprobación del 24 de octubre, AIHubMix envió thinking: {"type": "enabled"}, usado en K2.x, a K3.1 Pro y recibió 200, tanto con los IDs principales como con el canal de codificación. La documentación de Moonshot describe thinking como «un parámetro de solicitud exclusivo de K2.x», y una guía de solución de problemas de terceros señala que un bloque antiguo puede provocar errores 400 tras cambiar de K2.x a K3, así que elimínalo de todos modos.

Si mantienes K2.7 Code como opción de respaldo hasta que se retire, deja activado su modo de pensamiento. La guía de Claude Code de Moonshot documenta el error 400 invalid thinking: only type=enabled is allowed for this model para K2.7 Code con el modo de pensamiento desactivado.

Valores de esfuerzo: off, none y los valores desconocidos devuelven 400

Qué verás: un error HTTP 400 cuando el esfuerzo sea off, none, disabled o un valor que Kimi Code no reconozca. K3.1 Pro tiene tres niveles: low, high y max. La documentación de Kimi Code de Moonshot explica cómo asigna estos valores a los que envían las herramientas de terceros:

La API de Moonshot solo documenta low, high y max para K3.1 Pro; max es el valor predeterminado y no se describe ninguna asignación. En AIHubMix, el 24 de octubre, low, medium, high, max y xhigh devolvieron 200 con los cuatro IDs de K3.1 Pro. En kimi-k3.1-pro, off y un valor desconocido también devolvieron 200 con razonamiento, mientras que none devolvió 200 sin razonamiento. En AIHubMix estos casos fallan silenciosamente, no con un error 400.

La parte que pasa desapercibida: no hay un nivel medium. Una herramienta configurada en medium recibe high, y una configurada en xhigh recibe max, el nivel más caro.

Solución: envía explícitamente low, high o max y comprueba qué envía realmente tu herramienta.

«temperatura no válida: solo se permite 1 para este modelo»

Qué verás: 400 invalid temperature: only 1 is allowed for this model. En la comprobación del 24 de octubre, AIHubMix obtuvo exactamente este error de kimi-k3.1-pro y kimi-k3.1-pro-highspeed al enviar temperature: 0.2. El mismo mensaje se había notificado para la API de Moonshot con K3 el 3 October 2026 y para el endpoint de Kimi Code con k3 el 21 de octubre.

Por qué: la referencia de parámetros de Moonshot aplica a K3.1 Pro las restricciones de K3: temperature fija en 1.0, top_p en 0.95, n en 1 y ambas penalizaciones en 0; cualquier otro valor produce un error. K2.6 también tenía un valor fijo, 0.6 con el modo de pensamiento desactivado, así que el código que todavía envía 0.6 suele ser el culpable.

La excepción que lo oculta: en la misma comprobación, el canal de codificación de AIHubMix aceptó temperature: 0.2. El código probado únicamente allí todavía puede fallar con los IDs principales o en la API de Moonshot.

La trampa que lo oculta aún más: muchos frameworks detectan los modelos Kimi por el prefijo kimi- y les eliminan temperature. Los IDs de Kimi Code k3.1-pro y k3.1-pro-highspeed no tienen ese prefijo; tampoco lo tienen los IDs del canal de codificación de AIHubMix, que empiezan por coding-. Un problema de Hermes Agent detectó exactamente esto en K3. La ruta principal del chat omitía temperature, pero una llamada auxiliar a k3 seguía enviándolo y recibía el error 400 cada vez.

Solución: no envíes temperature, top_p, n, presence_penalty ni frequency_penalty. Detecta la familia del modelo, no un prefijo del nombre.

Para comprobar una ruta, envía una solicitud con un valor de temperatura:

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3.1-pro", "temperature": 0.2, "messages": [{"role": "user", "content": "hi"}]}'

El 24 de octubre, esto devolvió el error 400 anterior. Pruébalo con todos los IDs de modelo que use tu código: el canal de codificación respondió 200 a la misma solicitud.

Codex a través de AIHubMix: error 404 en la API Responses

Qué verás: un error HTTP 404 con The model kimi-k3.1-pro is not available on this endpoint.. En la comprobación del 24 de octubre, AIHubMix lo recibió de la API Responses con los dos IDs principales, mientras que Chat Completions y Messages respondieron con normalidad.

Solución: Codex solo admite la API Responses, así que configura coding-kimi-k3.1-pro, que respondió a las solicitudes de Responses en la misma comprobación. AIHubMix califica el canal de codificación como una versión preliminar de evaluación no recomendada para producción, y algunas solicitudes devolvieron un 404 transitorio, «The requested resource was not found», así que vuelve a intentarlo una vez antes de investigar el problema. Úsalo hasta que AIHubMix añada la API Responses para los IDs principales. Claude Code usa Messages y funciona con los IDs principales.

Límites de stop

Qué verás: la prueba de K3 de AIHubMix en julio devolvió estos dos mensajes:

• Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 instead
• Invalid request: stop sequence must not be longer than 32, but got 33 instead

Por qué: K3 acepta como máximo cinco secuencias de detención, cada una de hasta 32 bytes, y la API Messages aplica las mismas comprobaciones a stop_sequences. Moonshot aplica a K3.1 Pro las mismas restricciones de parámetros, así que cabe esperar los mismos límites.

Solución: reduce la lista. Ten en cuenta que 32 bytes son menos de 32 caracteres en chino o japonés.

Codex en la API de Moonshot: «web_search.search_context_size is not supported» (guía de K3)

Qué verás: 400 web_search.search_context_size is not supported, citado de la guía de Codex de Moonshot, redactada para K3. A través del canal de codificación de AIHubMix, el 24 de octubre una solicitud de Responses con ese campo devolvió 200, así que este error procede del propio endpoint de Moonshot.

Solución: elimina search_context_size de la configuración de Codex o de la definición de la herramienta. Codex no lo envía de forma predeterminada.

Los fallos silenciosos

Estos no generan errores. Se hacen evidentes más tarde, en la factura, en la cuota de tu plan o en la calidad de las respuestas.

Esfuerzo y sesiones

• El valor predeterminado es max, y eso es nuevo en Kimi Code. K3.1 Pro usa max de forma predeterminada. En Kimi Code, el valor predeterminado de K3 era high, así que una sesión que nunca configura el nivel de esfuerzo ahora razona más, consume más tokens y agota la cuota más rápido. En la API de Moonshot, tanto K3 como K3.1 Pro usan max de forma predeterminada. El razonamiento se factura como salida: en la prueba de AIHubMix de julio, en la que K3 creó un juego con una sola instrucción, el 73% de los 74,994 tokens de finalización correspondió al razonamiento.
• Un nivel de esfuerzo bajo aún puede implicar miles de tokens de razonamiento. En una comprobación puntual de AIHubMix el 24 de octubre, un prompt que pedía una explicación de 600 palabras hizo que K3.1 Pro razonara entre 5,561 y 7,356 tokens con low antes de responder, y una ejecución alcanzó el límite de 8,192 tokens. K3 razonó entre 3,013 y 7,051 tokens con el mismo prompt, así que esto no es nuevo en K3.1 Pro, pero low no es un modo barato en ninguno de los dos; deja max_completion_tokens con un valor generoso. Se trata de un prompt y tres ejecuciones por modelo con los ID principales de AIHubMix, así que mide el rendimiento en tu propia carga de trabajo.
• Cambiar a K3.1 Pro dentro de una sesión antigua perjudica la calidad. La documentación de Kimi Code de Moonshot desaconseja cambiar a los nuevos modelos «dentro de una sesión existente de la serie K3, K2.8 Preview o K2.7 Code Highspeed»: degrada la calidad de las respuestas y reduce los aciertos de caché. Inicia una sesión nueva.
• Cambiar el modelo o el nivel de esfuerzo invalida la caché. La documentación de Kimi Code de Moonshot lo indica para ambos casos, y la documentación de K3 decía que cambiar el nivel de esfuerzo «invalida los aciertos de la caché de prefijos». Elige el modelo y el nivel al iniciar la sesión.

Highspeed

• Si escribes mal el ID de Highspeed, obtendrás un modelo más lento. En Kimi Code, un ID de Highspeed incorrecto «vuelve silenciosamente a K2.8 Preview sin razonamiento: no hay aceleración». Copia el ID exactamente y comprueba qué modelo aparece en los registros.
• Highspeed solo acelera la generación del modelo. Moonshot sitúa K3.1 Pro Highspeed en torno a 2–3× la velocidad de K3.1 Pro, con capacidades idénticas. En la comprobación puntual de AIHubMix, su generación fue aproximadamente 1.6–1.8× más rápida que la de Pro. Las llamadas a herramientas y los scripts no se aceleran en absoluto, así que la mejora es pequeña en un turno dominado por la lectura de archivos y la ejecución de pruebas, mientras que los planes de Kimi Code cuentan aproximadamente el doble de cuota.

Protocolos

• Los proxies pueden cambiar el comportamiento. La documentación de Kimi Code de Moonshot advierte: «La traducción de protocolos a través de herramientas proxy puede hacer que el comportamiento del modelo varíe». Usa con cada herramienta el protocolo que admite: Messages para Claude Code y Responses para Codex. El 24 de octubre, AIHubMix respondió a Chat Completions y Messages en los cuatro ID de K3.1 Pro e incluyó el razonamiento, como reasoning_content y como bloques thinking. Responses funcionó en el canal de programación, con un elemento reasoning, y devolvió el error 404 mencionado arriba con los ID principales.
• La salida estructurada en la API Messages mejoró. En la prueba de julio de AIHubMix con K3, /v1/messages ignoró un esquema y devolvió texto sin formato. El 24 de octubre, una solicitud del mismo tipo a K3.1 Pro, con un esquema JSON en output_config.format y un prompt que no pedía JSON, devolvió {"city":"Paris"} con los cuatro ID. Se trata de un esquema de un solo campo, así que valida la salida antes de volver a usar JSON en Messages. No se volvió a probar otra peculiaridad de Messages observada en julio: cuando se alcanzaba una secuencia de parada, la respuesta se devolvía como end_turn con stop_sequence: null.

Solicitudes largas

• Los tiempos de espera cortos hacen fallar incluso solicitudes moderadas. En la comprobación puntual, las respuestas completas de K3.1 Pro con low tardaron entre 80 y 99 segundos. Un cliente sin streaming con un tiempo de espera de 60 segundos habría fallado en todas las ejecuciones, y un reintento volvería a pagar por el mismo razonamiento. En la API de Moonshot, el límite de salida predeterminado de K3.1 Pro es de 131,072 tokens y puede llegar hasta 1,048,576; además, la compilación de un juego con K3 que AIHubMix hizo en julio tardó 2,541 segundos en una sola solicitud. Usa streaming y configura tiempos de espera de varios minutos.

Aspectos heredados de las guías de K3

Estos puntos provienen de las guías de K3:

• Eliminar reasoning_content degrada la calidad en varios turnos. El mensaje completo del asistente, incluidos reasoning_content y tool_calls, debe volver a enviarse sin cambios. El código que conserva solo content sigue funcionando, pero Moonshot advierte que la calidad de las respuestas será inestable.
• Las herramientas dinámicas desaparecen si eliminas su mensaje. K3 permite cargar herramientas a mitad de una conversación mediante un mensaje del sistema sin contenido. El servidor no lo conserva, así que hay que volver a enviarlo con cada solicitud. En AIHubMix, esto funciona con Chat Completions: el 24 de octubre, kimi-k3.1-pro llamó a una herramienta inyectada de esta manera. En la prueba de K3 de AIHubMix de julio, la API Messages ignoró una herramienta inyectada.

Reglas de facturación fáciles de pasar por alto

Los precios siguientes son los de AIHubMix, tomados de sus páginas de modelos, por millón de tokens:

En AIHubMix, K3.1 Pro es un 30% más barato que K3 en entrada y entrada en caché, y un 26% más barato en salida. Highspeed cuesta el doble que Pro en entrada y salida, con la misma tarifa para la caché. El ID del canal de programación tiene un precio distinto: $0.88 por entrada, $3.23 por salida y $0.132 por caché.

Una tarifa más baja no garantiza una factura menor. Tomemos la compilación de un juego con un solo prompt en K3 que AIHubMix hizo en julio: 74,994 tokens de salida, suponiendo 5,000 tokens de entrada. Con los mismos recuentos de tokens, cuesta aproximadamente $1.08 con K3, aproximadamente $0.80 con K3.1 Pro (5,000 × $2.00 + 74,994 × $10.50, por millón) y aproximadamente $1.59 con Highspeed. El recuento de tokens varía según el prompt (en la comprobación puntual, K3.1 Pro y K3 quedaron en un rango similar con low), así que mide antes de hacer un presupuesto.

La documentación de la API de Moonshot factura las escrituras en caché de K3.1 Pro según el TTL, de 5 minutos o 1 hora, igual que en K3. Las tarifas publicadas de K3, según la guía de almacenamiento en caché de contexto de Moonshot, muestran cómo funciona la estructura:

Moonshot afirma que desglosar las escrituras en caché no aumentó el costo total de K3: el costo de escritura ya formaba parte del precio de entrada, así que las solicitudes con el TTL predeterminado de 5 minutos cuestan lo mismo que antes.

Estas son las tarifas directas de Moonshot. Las páginas de modelos de AIHubMix solo muestran los precios de entrada, salida y entrada en caché, sin una tarifa aparte para las escrituras en caché, y no especifican cómo se factura una escritura con TTL de 1 hora. AIHubMix sí transmite el TTL: el 24 de octubre, una solicitud Messages con un TTL cache_control de nivel superior de 1h informó que la escritura se había contabilizado como tokens de caché de 1 hora, y se aceptó una solicitud Chat Completions con prompt_cache_options.

• El almacenamiento en caché es automático. En K3, el TTL predeterminado es de 5 minutos. En las comprobaciones de AIHubMix del 24 de octubre, un prompt repetido de 93 tokens volvió completamente almacenado en caché en el canal de programación, pero no con los ID principales. Con un prompt de 7,658 tokens, la segunda llamada a kimi-k3.1-pro volvió con 7,424 tokens en caché, tanto con Chat Completions como con Messages.
• El TTL de 1 hora, en la API de Moonshot, cuesta $3.00 más por millón de tokens escritos, según las tarifas de K3. Cada acierto ahorra $2.70, así que, según los propios cálculos de Moonshot, resulta rentable a partir del segundo acierto.
• El TTL queda fijado al realizar la primera escritura (K3). No puedes ampliar una entrada de 5 minutos a una hora. Primero debe caducar.
• Los paneles de costos necesitan un campo nuevo (K3). Las escrituras en caché aparecen como prompt_tokens_details.cache_write_tokens en Chat Completions, input_tokens_details.cache_write_tokens en Responses y cache_creation_input_tokens en Messages.
• El razonamiento cuenta como salida. En K3, los tokens de razonamiento se facturan a la tarifa de salida en todos los niveles de esfuerzo. AIHubMix no indica un precio aparte para el razonamiento en K3.1 Pro.

Pasos para reducir la factura:

1. Configura reasoning_effort según la carga de trabajo, en lugar de heredar max. Prueba low para búsquedas de información y clasificación, y high para tareas de programación rutinarias.
2. Mantén el modelo y el nivel de esfuerzo fijos durante cada sesión e inicia una sesión nueva cuando cambies cualquiera de los dos.
3. Coloca primero las partes estables: el prompt del sistema, las definiciones de herramientas y el contexto del repositorio. Después, el turno que cambia.
4. Usa Highspeed cuando el cuello de botella sea la espera de la respuesta del modelo, no en bucles dominados por llamadas a herramientas.
5. Vigila la proporción de razonamiento en los tokens de finalización. Si supera la mitad de forma constante en tareas sencillas, reduce el nivel de esfuerzo.

Agentes con permisos reales

El problema de Hermes Agent muestra cómo un error de migración se convierte en un problema de seguridad. Su clasificador de «aprobación inteligente» llamaba a k3 con una temperatura, y todas las llamadas devolvían un error 400. En palabras de quien informó del problema, el clasificador «escala los permisos (falla en abierto) en cada llamada»: la comprobación de seguridad dejó de cumplir su función, y nada parecía ir mal en el chat principal.

K3.1 Pro conserva ese desencadenante y añade otro. Las llamadas al clasificador son precisamente aquellas que los equipos aceleran y abaratan al establecer una temperatura baja o desactivar el razonamiento, y en K3.1 Pro ninguna de las dos opciones funciona: una temperatura puede provocar un error 400 en cada llamada, y en AIHubMix una solicitud con el razonamiento desactivado volvió sin razonamiento. Si una comprobación de seguridad se ejecuta en K3.1 Pro, usa reasoning_effort: "low" para ganar velocidad, decide qué hacer ante un error de la API y configúrala para que falle de forma segura.

Hay otros aspectos importantes para los agentes que actúan por su cuenta:

• Las llamadas forzadas a herramientas funcionan. K3.1 Pro admite tool_choice: "required", que K2.x rechazaba, así que puedes eliminar la solución alternativa de K2.x para forzar una llamada a una herramienta.
• La búsqueda web integrada no está lista para producción (K3). La guía de K3 de Moonshot indica que su búsqueda web «está en proceso de actualización y no se recomienda para flujos de trabajo de producción a corto plazo». Trátala de la misma manera en K3.1 Pro hasta que Moonshot indique lo contrario. A través de AIHubMix, un ciclo de búsqueda de K3.1 Pro no se completó el 24 de octubre: el modelo solicitó $web_search, y al enviarle el resultado de vuelta se obtuvo 400 Invalid request: tokenization failed.
• Las imágenes de entrada deben estar en base64. K3 no obtiene imágenes de URL públicas y, el 24 de octubre, kimi-k3.1-pro en AIHubMix rechazó una con 400 Invalid request: unsupported image url, así que un agente que envíe enlaces a capturas de pantalla recibirá un error. La otra opción de Moonshot, un ID de archivo obtenido al subirlo a su servicio, no está disponible en AIHubMix: una referencia ms:// devolvió 404. Una imagen en base64 sí funcionó. K3.1 Pro también acepta entradas de video en Kimi Code.

Herramientas de programación: Claude Code y Codex

Claude Code usa la API Messages de Anthropic, a la que los ID principales de AIHubMix respondieron el 24 de octubre. Codex usa la API Responses, a la que solo respondió el canal de programación. Las guías permanentes de AIHubMix cubren la instalación y la configuración básica. A continuación se indica únicamente lo que cambia con K3.1 Pro.

La columna Codex usa el ID del canal de programación hasta que los ID principales respondan en la API Responses. Cualquier valor de esfuerzo que una herramienta envíe que no sea uno de los tres se asigna según la tabla de esfuerzo anterior.

Claude Code

Sigue la guía de settings.json de Claude Code. Después, configura todos los niveles de modelo, no solo el principal:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://aihubmix.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-aihubmix-key",
    "ANTHROPIC_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3.1-pro"
  }
}

Problemas conocidos, según la documentación de Kimi Code de Moonshot, su guía de Claude Code (escrita para K3) y las pruebas de AIHubMix:

• Inicia una sesión nueva. No cambies una sesión de K3 en curso a K3.1 Pro. Abre una nueva para empezar con la caché y la calidad de salida limpias.
• Los niveles sin configurar fallan silenciosamente. Claude Code usa distintos niveles para el chat principal, los resúmenes y los subagentes. Moonshot advierte que, si solo configuras algunos, el resto «fallará silenciosamente». Puedes asignar un modelo más barato al nivel Haiku para las tareas en segundo plano.
• La configuración obsoleta prevalece. Los valores antiguos del bloque env de ~/.claude/settings.json anulan las variables exportadas en tu shell.
• Contexto de 1M. La guía de K3 de Moonshot usa kimi-k3[1m] para que Claude Code trate la ventana como de 1M. kimi-k3.1-pro[1m] funciona igual a través de AIHubMix: Claude Code elimina el sufijo antes de enviar la solicitud, y AIHubMix respondió a la solicitud resultante, incluido el encabezado de contexto de 1M, el 24 de octubre. Solo Claude Code entiende el sufijo. Si se envía como ID de modelo desde cualquier otro cliente, kimi-k3.1-pro[1m] devuelve un 400.
• Esfuerzo. K3.1 Pro ya tiene max como valor predeterminado, el nivel que recomendaba la guía de K3 de Moonshot con CLAUDE_CODE_EFFORT_LEVEL=max. Para el trabajo rutinario, high consume menos tokens. El nivel que envíe Claude Code se asigna según la tabla de esfuerzo, y AIHubMix aceptó los cinco valores probados.
• Niveles Highspeed. Si asignas un nivel a kimi-k3.1-pro-highspeed, copia el ID exactamente. En Kimi Code, un error tipográfico provoca una sustitución silenciosa; en AIHubMix, un ID mal escrito devuelve un 400.

Codex

Codex solo admite la API Responses, así que wire_api = "responses" es obligatorio. La guía de config.toml de Codex explica el resto. Para K3.1 Pro:

# At launch (24 October 2026), the main ID kimi-k3.1-pro returned 404 on the Responses API.
# Use the coding-channel ID until AIHubMix adds it. AIHubMix labels the
# coding channel an evaluation preview, not for production.
model = "coding-kimi-k3.1-pro"
model_provider = "aihubmix"
model_context_window = 1048576
model_reasoning_effort = "high"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
env_key = "AIHUBMIX_API_KEY"
wire_api = "responses"

• Declara la ventana de contexto. Sin model_context_window, Codex recurre a los metadatos predeterminados de un modelo que no reconoce. La guía de Codex de Moonshot, escrita para K3, indica que el aviso Model metadata for kimi-k3 not found que aparece es normal e inocuo.
• Esfuerzo. Los niveles propios de Codex incluyen medium y xhigh. Según la correspondencia de Kimi Code, se ejecutan como high y max, y AIHubMix aceptó ambos el 24 de octubre. Configura low, high o max para saber qué nivel estás pagando.
• Los canales son distintos. El canal de programación aceptó una temperatura que los ID principales rechazaron. Cuando los ID principales empiecen a responder en Responses, vuelve a ejecutar la prueba rápida antes de cambiar.
• No uses search_context_size. Si tu configuración lo define, elimínalo (consulta los errores explícitos).
• Reinicia después de editar. Codex solo lee config.toml al iniciarse. Si CC Switch administra tu configuración de Codex, puede sobrescribir tus cambios.

Una prueba rápida de 15 minutos

Hazla una vez por herramienta, en un repositorio pequeño con un conjunto de pruebas:

1. Inicia una sesión nueva con K3.1 Pro. No continúes una sesión que haya usado K3 u otro modelo.
2. Pide: «Añade una prueba unitaria para una función de este repositorio, ejecuta las pruebas y corrige cualquier fallo».
3. Esto es lo que indica que ha funcionado: el modelo lee archivos y ejecuta las pruebas (las llamadas a herramientas funcionan). Continúa después de ver los resultados, lo que demuestra que se le devuelven el razonamiento y los resultados de las herramientas. Termina con las pruebas aprobadas y sin ningún 400 o 404 en la sesión.
4. En el registro de uso de AIHubMix, comprueba que el ID del modelo sea el que configuraste y que las solicitudes posteriores muestren tokens de entrada en caché para el prefijo estable. Si no aparecen nunca, algo en tu prefijo cambia en cada turno.
5. Anota el tiempo por turno y los tokens de finalización. Te servirán como referencia para elegir un nivel de esfuerzo y decidir si Highspeed compensa.

Lista de verificación para la migración

• Usa el ID de K3.1 Pro: kimi-k3.1-pro en la API de Moonshot y en AIHubMix, k3.1-pro en Kimi Code; para Codex a través de AIHubMix, coding-kimi-k3.1-pro por ahora.
• Migra el código de K2.x antes de que Moonshot retire la serie K2 a finales de diciembre de 2026; las cuentas nuevas de Moonshot perderán el acceso a K2 a partir del 31 de octubre.
• Inicia una sesión nueva para K3.1 Pro en lugar de cambiar una sesión antigua.
• Elimina temperature, top_p, n y ambos parámetros de penalización de todas las rutas de llamadas, incluidas las llamadas auxiliares.
• Elimina todas las opciones para desactivar el razonamiento, incluidos los valores de esfuerzo off, none y disabled, y borra los bloques de razonamiento de K2.x que hayan quedado.
• Envía el esfuerzo como low, high o max; medium se ejecuta como high, y xhigh como max.
• Mantén fijos el modelo y el esfuerzo durante toda la sesión.
• Copia exactamente el ID de Highspeed y comprueba el modelo en tu registro de uso.
• Limita las listas de stop a cinco entradas de 32 bytes o menos.
• Devuelve el mensaje completo del asistente, incluidos reasoning_content y tool_calls, y vuelve a enviar los mensajes dinámicos de las herramientas.
• Transmite en streaming las solicitudes largas y configura los tiempos de espera en minutos.
• Valida la salida estructurada antes de volver a pasar el JSON a la API Messages.
• Actualiza el seguimiento de costes para incluir el campo independiente de escritura en caché.
• Configura las comprobaciones de seguridad para que denieguen por defecto si se producen errores de API.
• Ejecuta la prueba rápida en cada herramienta de programación.

Preguntas frecuentes

¿Por qué K3.1 Pro devuelve HTTP 400?
Las causas habituales son una temperatura distinta de 1, el razonamiento desactivado o un esfuerzo de off, none, disabled o un valor desconocido. La primera se debe a las reglas de muestreo fijas de K3, que K3.1 Pro mantiene; las demás están documentadas en la documentación de Kimi Code de Moonshot. En los ID principales de AIHubMix, el 24 de octubre solo la temperatura devolvió un 400; los demás casos devolvieron un 200, y al desactivar el razonamiento o usar none no se obtuvo razonamiento.

¿Puedo desactivar el razonamiento?
No. K3.1 Pro solo funciona en modo de razonamiento. Configura reasoning_effort como low para que el razonamiento sea breve.

¿Se sigue rechazando temperature?
Sí, en la API de Moonshot y en los ID principales de AIHubMix, que el 24 de octubre de 2026 devolvieron «invalid temperature: only 1 is allowed for this model». En la misma comprobación, el canal de programación de AIHubMix aceptó una temperatura de 0.2. Omite temperature en todas las rutas.

¿Cuándo dejarán de estar disponibles los modelos K2?
A partir del 31 de octubre de 2026, los usuarios de Moonshot que se registren a partir de esa fecha no podrán usar los modelos de la serie K2, y Moonshot planea retirarlos todos a finales de diciembre de 2026. El 24 de octubre, AIHubMix todavía mostraba K2.6 y K2.7 Code, sin fecha de retirada.

¿Por qué se agota más rápido mi cuota de Kimi Code?
K3.1 Pro usa max effort de forma predeterminada, mientras que K3 usaba high en Kimi Code, y Highspeed consume aproximadamente el doble de cuota que el modelo normal. Configura un nivel de esfuerzo más bajo para el trabajo rutinario y mantenlo fijo durante toda la sesión.

¿Por qué Highspeed no es más rápido?
Puede que el ID esté mal escrito, lo que en Kimi Code provoca una sustitución silenciosa por K2.8 Preview sin razonamiento, o que las llamadas a herramientas dominen el turno. Highspeed solo acelera la generación del modelo.

¿Qué ID de modelo de AIHubMix debería usar Codex?
Por ahora, coding-kimi-k3.1-pro, con la API Responses en aihubmix.com/v1 y wire_api configurado como responses. El 24 de octubre, los ID principales devolvieron 404 en la API Responses. AIHubMix califica el canal de programación como una versión preliminar de evaluación, no apta para producción.

Sigue leyendo: la serie Kimi K3.1 Pro

• Antes de migrar, comprueba si la actualización realmente vale la pena: desde qué ha cambiado hasta cuánto cuesta una tarea real: Kimi K3.1 Pro frente a K3: qué ha cambiado, cuánto cuesta y quién debería cambiarse
• Si la migración te lleva a considerar alternativas, aquí comparamos K3.1 Pro con Qwen 4 y Claude Fable 5.5, incluido el coste de una tarea de desarrollo front-end en cada uno: Kimi K3.1 Pro frente a Qwen 4 y Claude Fable 5.5: calidad del front-end, coste por tarea y análisis del entusiasmo
• Si la cuota y el precio de Highspeed te hacen preguntarte si la variante rápida compensa, dedicamos una publicación a la relación entre velocidad y precio: Kimi K3.1 Pro frente a K3.1 Pro Highspeed: ¿merece la pena una velocidad 2–3× mayor por el doble de precio?

Fuentes

• Kimi Code: Configuración del modelo
• Moonshot AI: Referencia de parámetros del modelo
• AIHubMix: Página del modelo Kimi K3.1 Pro
• AIHubMix: Guía práctica de Kimi K3
• Incidencia #142365 de Hermes Agent: desviación de la configuración del endpoint de Kimi Code