Moonshot abre Kimi a Codex y Claude Code, replanteando el conflicto entre Anthropic y Moonshot
Moonshot AI abrió Kimi a dos entornos rivales de programación el 2 de septiembre, pese a una disputa no resuelta entre Anthropic y Moonshot sobre el entrenamiento y el acceso a modelos. La API de Kimi ahora acepta solicitudes de OpenAI Responses API desde Codex y solicitudes de Anthropic Messages API desde Claude Code. Moonshot afirma que los desarrolladores pueden conectarse sin un conversor de formato ni un proxy local.
El cambio parece una actualización de compatibilidad. Es más trascendental porque los agentes de programación dependen de comportamientos detallados de protocolo, no solo de la generación de texto convencional. El cliente envía definiciones de herramientas, recibe llamadas estructuradas, devuelve resultados de ejecución y repite ese ciclo hasta que la tarea termina.
Por tanto, Moonshot intenta separar la interfaz de programación de la empresa que la creó. Codex puede seguir siendo el cliente del desarrollador mientras un modelo Kimi sustituye a un modelo de OpenAI. Claude Code puede mantener su flujo de trabajo habitual mientras las solicitudes viajan a Moonshot en lugar de Anthropic.
La estrategia somete a OpenAI y Anthropic a un tipo distinto de presión. Ninguna de las dos empresas pierde la propiedad de su cliente o protocolo. Sin embargo, ambas se enfrentan ahora a otro proveedor que utiliza la compatibilidad para competir dentro de los flujos de trabajo que ayudaron a establecer.
La compatibilidad de Kimi API con Codex elimina una barrera práctica
El cambio importante de Moonshot es la compatibilidad nativa con el protocolo, no una nueva interfaz de programación.
El anuncio de Moonshot del 2 de septiembre indica que Kimi es compatible con el formato Responses API utilizado por Codex. También admite Messages API, el formato asociado con Anthropic y Claude Code. La empresa publicó guías de configuración independientes para cada vía.
Para Codex, Moonshot documenta un proveedor personalizado que utiliza la URL base de su API y un formato de transmisión Responses. Un proveedor personalizado indica al cliente adónde deben dirigirse las solicitudes de modelo y qué protocolo debe utilizar. El desarrollador puede entonces seleccionar un modelo Kimi mientras continúa trabajando dentro de Codex.
Moonshot identifica kimi-k3, kimi-k2.7-code-highspeed, kimi-k2.7-code y kimi-k2.6 como opciones compatibles. La disponibilidad aún puede depender de la cuenta, el endpoint, la versión del cliente y la configuración actual de la plataforma.
La configuración de Codex es destacable porque elimina una capa de traducción que las integraciones anteriores solían requerir. Un adaptador local recibía un formato de solicitud, lo reescribía para otra API y traducía de vuelta la respuesta transmitida.
Cada adaptador se convierte en una pieza móvil adicional. Puede gestionar mal las llamadas a herramientas, omitir un tipo de evento, exponer una credencial o dejar de coincidir con el cliente tras una actualización. También complica la depuración porque un fallo puede originarse en el cliente, el adaptador, la red o el modelo ascendente.
La compatibilidad nativa con Responses reduce esa superficie de integración. No garantiza un comportamiento idéntico al de un modelo alojado por OpenAI. Significa que el servidor de Moonshot acepta el contrato de transmisión esperado por el cliente.
Esta distinción importa porque Codex hace más que enviar un prompt e imprimir una respuesta. La explicación de OpenAI sobre el bucle de agentes de Codex describe intercambios repetidos entre la inferencia del modelo y la ejecución de herramientas. El cliente transporta mensajes, instrucciones, definiciones de herramientas, elementos relacionados con el razonamiento y resultados de herramientas a lo largo de esos intercambios.
Un servidor compatible debe preservar suficiente estructura para que el ciclo continúe. La generación de texto por sí sola es insuficiente. Los eventos de transmisión, los identificadores de llamadas a herramientas, los elementos de entrada y el comportamiento de finalización afectan a la fiabilidad con la que funciona el cliente.
Por ello, la vía Kimi API para Codex se dirige a desarrolladores a quienes ya les gusta la interfaz de Codex pero quieren otro backend de modelos. También ofrece a los equipos una forma de comparar modelos sin sustituir su flujo de trabajo de terminal ni reconstruir los scripts circundantes.
La misma lógica se aplica a la experiencia de escritorio cuando hay proveedores personalizados disponibles. Según la documentación de Moonshot, un selector de modelos puede mostrar una etiqueta genérica de proveedor personalizado, incluso cuando el backend configurado sea Kimi. Esa limitación de la interfaz puede hacer importante la verificación.
Los desarrolladores deben confirmar el proveedor activo mediante la configuración, los registros de solicitudes y pruebas controladas. Una respuesta correcta no demuestra por sí sola qué backend procesó la solicitud.
Moonshot también afirma que su implementación de Responses acepta entradas de texto e imágenes, pero actualmente no admite entradas de vídeo. Esa limitación acota el significado de la compatibilidad nativa. La compatibilidad de protocolo puede ser suficientemente amplia para el trabajo de programación sin abarcar todas las posibles entradas o funciones de plataforma.
La ganancia inmediata sigue siendo clara. Los desarrolladores ya no necesitan mantener un puente de protocolo local para la vía documentada. Esto reduce el trabajo de configuración y ofrece a Moonshot una ruta más directa hacia un flujo de trabajo de agentes consolidado.
La compatibilidad de Kimi con Claude Code convierte un cliente en un canal de distribución
La ruta de API configurable de Claude Code permite a Moonshot competir por la inferencia sin crear un cliente igual de conocido.
La configuración de Kimi para Claude Code utiliza el endpoint compatible con Anthropic de Moonshot. Claude Code envía solicitudes de Messages API, mientras que el modelo Kimi seleccionado realiza la inferencia. El cliente sigue gestionando archivos, herramientas, permisos y su flujo de trabajo interactivo.
La guía de Claude Code de Moonshot describe el endpoint y las credenciales necesarios. Esto sustituye el patrón anterior de instalar un relé local únicamente para convertir el formato de las solicitudes.
Messages API de Anthropic es una interfaz estructurada para conversaciones, bloques de contenido y uso de herramientas. Admitir su formato permite a otro proveedor recibir solicitudes de software diseñado en torno a ese contrato. No convierte un modelo Kimi en Claude ni transfiere el comportamiento del modelo de Anthropic.
Esta distinción debe permanecer visible. Claude Code es el cliente de agente. Claude es la familia de modelos de Anthropic. Un usuario puede ejecutar el cliente contra un endpoint externo compatible, pero el resultado procede del proveedor configurado.
La propia documentación de gateway de Anthropic reconoce que los formatos de API compatibles pueden conectar Claude Code a gateways. También afirma que Anthropic no respalda, mantiene ni audita productos de gateway de terceros. De forma más directa, Anthropic dice que no admite enrutar Claude Code a modelos que no sean Claude a través de un gateway.
Moonshot no afirma que Anthropic respalde Kimi. Está implementando el formato de solicitud que espera el cliente. Esa diferencia separa la interoperabilidad técnica de una asociación comercial.
La configuración ofrece a los desarrolladores un caso de uso real. Un equipo puede conservar un único cliente de programación, dirigir un entorno de prueba a Kimi y ejecutar la misma tarea de repositorio con otro backend. Puede comparar la calidad de los parches, la fiabilidad de las herramientas, la latencia y la recuperación ante fallos mediante controles conocidos.
El flujo de trabajo también reduce los costes de cambio. Antes, evaluar otro modelo podía requerir adoptar su cliente dedicado o mantener un proxy. La compatibilidad nativa acerca la decisión a un cambio de configuración.
Eso ejerce presión sobre los proveedores de modelos porque la lealtad del usuario puede vincularse a la capa del agente, y no al modelo subyacente. Un desarrollador puede preferir una interfaz mientras elige distintos modelos para revisión de código, exploración de repositorios, depuración asistida por imágenes o ediciones de larga duración.
En consecuencia, los protocolos se convierten en canales de distribución. Una vez que un cliente acepta endpoints personalizados, todo proveedor suficientemente compatible puede buscar acceso a sus usuarios. El proveedor original sigue controlando la evolución del cliente, pero ya no controla cada solicitud de inferencia.
Hay límites. Claude Code añade funciones con el tiempo, y las implementaciones externas deben seguir el ritmo de los campos de solicitud y respuesta que esas funciones requieren. Anthropic advierte que los gateways pueden romper capacidades cuando no reenvían nuevos comportamientos.
Un endpoint directo de terceros afronta la misma carga de compatibilidad. Si Claude Code introduce otro esquema de herramientas, encabezado, bloque de contenido o evento de transmisión, Moonshot debe implementarlo correctamente. «Nativo» describe la ruta de integración actual, no una paridad permanente de funciones.
La autenticación también cambia el límite de confianza. Las solicitudes enviadas a Moonshot se rigen por el servicio de Moonshot, su gestión de datos, sus reglas de retención y su disponibilidad regional. No se procesan bajo una cuenta de Anthropic simplemente porque Claude Code siga apareciendo en pantalla.
Los equipos deben tratar la selección de proveedor como una decisión de infraestructura. El código fuente, los prompts, la salida de herramientas y el contexto del repositorio pueden pasar por el endpoint configurado. Las revisiones de seguridad deben seguir al backend que recibe ese material.
Por tanto, la vía de Kimi para Claude Code es a la vez más sencilla y más trascendental que un plugin convencional. Permite a Moonshot entrar en un flujo de trabajo identificado con un competidor mientras asume la responsabilidad del servicio de modelos que hay debajo.
El conflicto entre Anthropic y Moonshot trata de control, no de compatibilidad
La tensión central es que la apertura técnica puede coexistir con la desconfianza comercial.
La palabra clave principal, anthropic moonshot, apunta a una relación adversarial, no cooperativa. La compatibilidad de Moonshot con Messages no debe confundirse con un acuerdo con Anthropic.
El 23 de febrero de 2026, Anthropic acusó públicamente a Moonshot, DeepSeek y MiniMax de llevar a cabo lo que denominó campañas de destilación a escala industrial. La destilación entrena un modelo utilizando resultados generados por otro modelo, aunque el método puede ser legítimo cuando el acceso y los permisos lo permiten.
Anthropic afirmó que las tres empresas generaron colectivamente más de 16 millones de intercambios con Claude mediante aproximadamente 24.000 cuentas fraudulentas. Atribuyó más de 3,4 millones de intercambios a Moonshot y afirmó que la actividad se dirigió a programación, uso de herramientas, razonamiento, análisis de datos, uso de ordenadores y visión.
Estas son alegaciones de Anthropic, no conclusiones establecidas de forma independiente en el material revisado para este artículo. La compatibilidad de API recientemente anunciada por Moonshot no las confirma ni las resuelve. No debe extraerse ninguna inferencia sobre el entrenamiento de Kimi únicamente a partir de su compatibilidad con el formato de mensajes de Anthropic.
Aun así, el historial cambia cómo se interpreta este lanzamiento. Anthropic sostiene que las salidas de los modelos y las restricciones de acceso requieren una protección más estricta. Mientras tanto, Moonshot facilita el uso de la interfaz asociada con Anthropic junto con un modelo competidor.
Por tanto, el conflicto entre Anthropic y Moonshot opera en dos niveles. Uno se refiere a quién puede acceder a las capacidades de los modelos y bajo qué condiciones. El otro se refiere a si un protocolo de cliente puede funcionar como una interfaz de implementación amplia.
Las alegaciones de destilación de Anthropic enfatizan el primer nivel. El lanzamiento de compatibilidad de Moonshot enfatiza el segundo. Ambas partes disputan el control, pero sobre diferentes partes de la pila tecnológica.
El protocolo en sí no contiene todo el comportamiento del modelo. Define cómo viajan las solicitudes, el contenido, las herramientas y las respuestas entre cliente y servidor. Varios proveedores pueden implementar interfaces similares y, al mismo tiempo, producir resultados diferentes.
Esta separación es conocida en otros mercados informáticos. Las aplicaciones pueden comunicarse mediante un protocolo de base de datos compartido sin utilizar el mismo motor de base de datos. Los servicios en la nube pueden exponer interfaces compatibles de almacenamiento de objetos sin igualar cada detalle operativo.
Los agentes de IA dificultan la separación porque el comportamiento del modelo influye en el ciclo del cliente. Un agente de programación espera que el modelo seleccione herramientas, interprete resultados, produzca ediciones válidas y se recupere tras los errores. La compatibilidad formal de la API es necesaria, pero la compatibilidad de comportamiento determina si la experiencia sigue siendo útil.
Moonshot se beneficia si los desarrolladores ven Codex y Claude Code como interfaces neutrales. OpenAI y Anthropic se benefician si los usuarios asocian sus clientes con modelos optimizados específicamente para ellos. La cuestión competitiva es cuál de estas visiones se impondrá.
Si la interfaz se independiza, el enrutamiento de modelos resulta más sencillo. Las empresas pueden negociar acceso con proveedores, aplicar distintas políticas regionales o asignar modelos a cargas de trabajo específicas. Los desarrolladores pueden conservar sus hábitos mientras cambian de proveedor de inferencia.
Si prevalece la optimización profunda entre modelo y cliente, los rivales compatibles podrían seguir siendo secundarios. Las diferencias sutiles en llamadas a herramientas, gestión del contexto, almacenamiento en caché, controles de razonamiento y recuperación de errores pueden pesar más que la comodidad de un endpoint compartido.
Por eso el cambio del 2 de septiembre no es simplemente otra casilla de verificación de API. Pone a prueba si la distribución de agentes de programación puede desvincularse de la propiedad del modelo.
Los formatos nativos aún no garantizan un rendimiento nativo
Una conexión que se inicia correctamente aún puede fallar durante las partes más exigentes de una ejecución de agente.
El anuncio de Moonshot establece una ruta documentada. No aporta evidencia independiente de que todas las funciones de Codex o Claude Code se comporten de forma idéntica en los modelos Kimi enumerados.
La primera incertidumbre es la cobertura del protocolo. Responses y Messages no son campos de texto únicos. Abarcan streaming, contenido multimodal, esquemas de herramientas, resultados de herramientas, metadatos, informes de uso y estructuras de error.
Un proveedor puede aceptar la solicitud principal y, aun así, manejar los casos límite de forma diferente. Las llamadas paralelas a herramientas pueden llegar en otro orden. Un stream puede omitir un evento que espera un cliente. La cancelación puede comportarse de forma distinta durante un comando prolongado.
La segunda incertidumbre es el ajuste de comportamiento. Los clientes de programación dependen de que los modelos sigan instrucciones especializadas y operen las herramientas con cuidado. Un modelo que obtiene buenos resultados en un benchmark de programación puede seguir teniendo dificultades con los prompts de un cliente concreto o el flujo de trabajo de un repositorio.
Por tanto, una evaluación útil debe medir la finalización de tareas, no el éxito de la conexión. Los equipos deben comprobar si el modelo edita los archivos correctos, respeta las instrucciones del proyecto, interpreta la salida de los comandos y se detiene cuando se requiere aprobación.
La tercera incertidumbre es la evolución del cliente. OpenAI y Anthropic pueden modificar sus clientes a medida que incorporan nuevas capacidades. Los proveedores externos deben seguir esos cambios sin controlar su calendario.
La descripción de OpenAI sobre Codex muestra hasta qué punto se ha detallado el ciclo del agente. Las salidas de las llamadas a herramientas se añaden a solicitudes posteriores, y el contexto de la conversación se amplía a lo largo de turnos repetidos. Los cambios en esos objetos pueden afectar a la compatibilidad incluso cuando el endpoint sigue siendo /responses.
Anthropic formula una advertencia similar para los operadores de gateways. Su documentación señala que las nuevas capacidades de Claude Code pueden fallar cuando un gateway no las reenvía. Un proveedor que implemente el formato directamente asume un riesgo de mantenimiento comparable.
La cuarta incertidumbre es la gobernanza de datos. Sustituir el backend cambia por dónde viajan el código y el contexto. Las organizaciones no pueden asumir que los controles asociados a una cuenta de OpenAI o Anthropic acompañen la solicitud hasta Moonshot.
Una revisión de seguridad debe cubrir el almacenamiento de credenciales, la retención, el registro, el procesamiento geográfico, la respuesta a incidentes y el control de acceso. Los equipos también deberían identificar qué archivos del repositorio puede leer el agente antes de enviar una tarea real de producción.
La quinta incertidumbre es la observabilidad. Una etiqueta de modelo genérica puede hacer menos evidente cuál es el backend activo. Las organizaciones necesitan registros que vinculen cada solicitud con un proveedor, un identificador de modelo, un desarrollador, un repositorio y una política.
Aquí es donde una base de conocimiento de ingeniería interna puede ayudar. Los equipos pueden registrar configuraciones aprobadas, resultados de evaluación, incompatibilidades conocidas y pasos de reversión sin depender de la memoria individual.
Ninguna de estas preocupaciones invalida el lanzamiento. Definen qué debería significar en la práctica el “soporte nativo”. Significa que el proveedor ha eliminado un componente de traducción necesario, no que todas las funciones del cliente hayan alcanzado una paridad permanente.
Una prueba responsable comienza con un repositorio representativo y permisos limitados. Incluye tareas de búsqueda de archivos, ediciones en varios archivos, ejecución de pruebas, fallos de comandos, entrada de imágenes y secuencias largas de herramientas.
Los equipos deben comparar el parche final y el proceso que lo produjo. Un resultado correcto conseguido mediante acceso innecesario a archivos o comandos fallidos repetidos sigue indicando un riesgo operativo.
La mejor evidencia provendrá de un uso sostenido a lo largo de las actualizaciones de los clientes. Moonshot ha facilitado la adopción. Ahora debe demostrar que la compatibilidad sigue siendo fiable después del primer prompt exitoso.
Lo que los desarrolladores deberían vigilar después del 2 de septiembre
Tres señales determinarán si este lanzamiento cambia la competencia entre modelos o sigue siendo una opción de integración conveniente.
La primera señal es la paridad de funciones a lo largo de las actualizaciones de los clientes. Los desarrolladores deberían observar si las nuevas capacidades de Codex y Claude Code funcionan con rapidez a través de los endpoints de Moonshot.
Esto incluye nuevos tipos de contenido, definiciones de herramientas, eventos de streaming, controles de razonamiento y comportamiento de autenticación. Un soporte rápido reforzaría la afirmación de Moonshot de que puede operar como proveedor de primera clase. Fallos recurrentes la debilitarían.
La documentación pública ofrecerá un indicador temprano. Las matrices de compatibilidad claras, los requisitos de versión, las limitaciones conocidas y las actualizaciones fechadas importan más que una afirmación general de soporte.
La segunda señal es el rendimiento verificado en cargas de trabajo. Las pruebas independientes deberían examinar tareas completas de repositorio en lugar de preguntas de programación aisladas. Entre las métricas útiles se incluyen parches exitosos, tasas de aprobación de pruebas, llamadas a herramientas innecesarias, latencia, recuperación tras errores de comandos y tiempo de corrección humana.
La comparación relevante no es simplemente Kimi frente a Claude o un modelo de OpenAI en una ventana de chat. Es Kimi dentro del ciclo exacto de cliente que los desarrolladores pretenden utilizar.
Distintos modelos pueden destacar en distintas cargas de trabajo. Un modelo rápido puede ser adecuado para la búsqueda en repositorios y transformaciones rutinarias. Un modelo más reflexivo puede rendir mejor en cambios de arquitectura o depuración compleja. La compatibilidad nativa facilita estas comparaciones, pero no las decide.
La tercera señal es cómo respondan OpenAI y Anthropic a la portabilidad entre proveedores. Pueden profundizar la optimización entre modelo y cliente, endurecer las políticas de proveedores compatibles, mejorar el enrutamiento empresarial o hacer más atractivas las opciones oficiales en la nube.
Anthropic ya establece un límite entre los gateways que documenta y los modelos que no son Claude y que no admite. La disputa no resuelta entre Anthropic y Moonshot añade otra razón para observar si ese límite se vuelve más estricto.
OpenAI ha descrito explícitamente el endpoint Responses de Codex como configurable. Esa decisión arquitectónica favorece la portabilidad, aunque los detalles de implementación y las configuraciones admitidas pueden cambiar. El lanzamiento de Moonshot pone a prueba hasta qué punto los desarrolladores utilizarán esa flexibilidad.
Para los desarrolladores individuales, la acción inmediata es sencilla. Traten Kimi como otro backend que evaluar, no como un reemplazo directo de identidad. Empiecen con una rama desechable, confirmen el modelo activo, restrinjan las credenciales e inspeccionen cada parche.
Para los líderes de ingeniería, la cuestión más importante se refiere a la dependencia. ¿Quiere la organización un proveedor integrado o una capa de cliente que pueda enrutar entre varios proveedores? La compatibilidad hace más práctico el segundo enfoque, pero también transfiere al cliente el trabajo de pruebas y gobernanza.
Mantengan un breve registro de evaluación en una base de conocimiento personal. Registren la versión del cliente, el modelo seleccionado, el tipo de repositorio, la tarea, los fallos observados y la revisión humana final. Repetir la misma prueba tras las actualizaciones revelará si la compatibilidad está mejorando.
Moonshot ha eliminado una barrera visible entre Kimi, Codex y Claude Code. La siguiente es la confianza ganada mediante ejecuciones repetidas de agentes. ¿Seguirá siendo fiable el soporte de protocolo nativo cuando cambien los clientes, las tareas se alarguen y el conflicto entre Anthropic y Moonshot mantenga en primer plano las cuestiones de acceso y control?
