
Grok 4.6 vs Kimi K3: ¿cuál deberías usar ahora?
Conclusión rápida: evalúa Kimi K3 si necesitas un modelo documentado, una ruta de texto listada en EvoLink, pesos abiertos o un modelo upstream con comprensión nativa de imagen y vídeo y una ventana de contexto de un millón de tokens. Antes de producción, verifica la ruta con una solicitud real, la identidad del modelo devuelto, el uso y la facturación. Espera a juzgar Grok 4.6 hasta que xAI publique una API invocable y EvoLink verifique su ID de modelo, precio, contrato de entrada, parámetros, límites y comportamiento de la ruta.
A 11 de agosto de 2026 este no es un duelo de benchmarks convencional. Kimi K3 está publicado y se puede probar. Grok 4.6 se menciona públicamente, pero no aparece en el catálogo oficial de modelos de la API de xAI, ni en la página de precios, ni en las notas de versión. Cualquier tabla que asigne a Grok 4.6 un número de parámetros confirmado, una ventana de contexto, un precio, una puntuación de benchmark o la condición de ganador se adelanta a la evidencia.
Grok 4.6 o Kimi K3: ¿cuál deberías usar ahora?
Elige Kimi K3 si necesitas construir o probar ya. Grok 4.6 todavía no es una opción desplegable: no hay ID de modelo oficial, ni precio de API, ni contrato de entrada, ni ruta de EvoLink verificada. Mantén Grok 4.6 como candidato de evaluación futura, no como dependencia de producción.
| Tu necesidad | Mejor decisión ahora | Por qué |
|---|---|---|
| Un candidato de producción para verificar hoy | Evaluar Kimi K3 | Su identidad y documentación de API están publicadas; EvoLink lista una ruta para verificarla mediante llamadas. |
| Investigación sobre pesos abiertos o despliegue propio | Elegir Kimi K3 | Moonshot publica los pesos de K3 y un repositorio del modelo; no existe una publicación equivalente de Grok 4.6. |
| Experimentos a escala de repositorio o multimodales | Probar antes Kimi K3 | Moonshot documenta un contexto de un millón de tokens y comprensión nativa de imagen y vídeo; confirma que la ruta de API elegida expone cada modo de entrada necesario. |
| Un posible sucesor de Grok 4.5 | Preparar una prueba de repetición de Grok 4.6 | Hay interés por el lanzamiento, pero todavía no existe un contrato de API verificado ni evidencia sobre tu carga de trabajo. |
| Un cambio de bajo riesgo cuando llegue Grok 4.6 | Mantener ambos tras el enrutamiento de EvoLink | Una pasarela común reduce el trabajo de integración, pero cada ruta sigue necesitando criterios de calidad, coste y compatibilidad. |
| Una respuesta universal a «¿cuál es más inteligente?» | No afirmes ninguna todavía | No hay ninguna ruta invocable de Grok 4.6 para una evaluación en igualdad de condiciones. |
Hechos verificados a 11 de agosto de 2026
La diferencia más importante es la madurez de la evidencia, no una puntuación especulativa de benchmark.
| Área | Grok 4.6 | Kimi K3 | Implicación para producción |
|---|---|---|---|
| Estado oficial | Mencionado públicamente; ausente de los modelos de API, los precios y las notas de versión de xAI | Publicado oficialmente por Moonshot | K3 se puede evaluar ahora; 4.6 no. |
| Acceso en EvoLink | Solo aviso de lanzamiento; sin ruta invocable | Ruta listada/configurada; falta verificar la evidencia de llamadas en producción | Valida identidad, uso, facturación y alternativa antes del tráfico de producción. |
| ID del modelo | Sin publicar | kimi-k3 | Mantén el ID en configuración para poder añadir 4.6 más adelante. |
| Precios de la API | Sin publicar | Publicados por Moonshot; el precio vigente en EvoLink está en la página del modelo | Compara el precio de la ruta y el coste por tarea aceptada en el momento de la prueba. |
| Modos de entrada | Sin documentar | Moonshot confirma texto, imagen y vídeo en upstream; EvoLink registra K3 hoy como ruta de texto | Prueba solo las modalidades documentadas para la ruta elegida; no deduzcas paridad de la pasarela a partir de la capacidad upstream. |
| Ventana de contexto | Sin documentar | 1 millón de tokens | Un contexto amplio es una capacidad de K3 que hay que probar, no una prueba de calidad de recuperación. |
| Pesos | Sin publicación | Pesos abiertos bajo la licencia de Kimi K3 | K3 permite inspección a nivel de pesos e investigación con despliegue propio. |
| Datos de arquitectura | Sin documentar | 2,8 billones de parámetros totales, 104.000 millones activados, KDA y Attention Residuals | La arquitectura explica compromisos operativos, no por sí sola la calidad en tus tareas. |
| Control del razonamiento | Sin documentar | Razonamiento siempre activo con niveles documentados low, high y max | Anota el ajuste de K3; prueba los controles de 4.6 solo cuando exista documentación. |
| Herramientas y salidas estructuradas | Sin documentar | Compatibilidad documentada con reglas específicas por flujo de trabajo | Valida K3 hoy y exige a 4.6 el mismo contrato después. |
Las cifras de Kimi K3 de esta tabla proceden del repositorio oficial de Moonshot y de la documentación de la plataforma. Las celdas de Grok 4.6 se dejan deliberadamente como desconocidas allí donde xAI no ha publicado una fuente. Así se evita convertir los comentarios de lanzamiento en una especificación de API.
Acceso: Kimi K3 está publicado; Grok 4.6 es un plan de pruebas
kimi-k3 y muestra los precios vigentes a través del sistema de precios existente. Antes de llamarla apta para producción, registra una solicitud completada con éxito, la identidad del modelo devuelto, el uso y la facturación, el importe cobrado, los errores y la alternativa.Grok 4.6 aún no puede entrar en esa prueba. El slug de una página de producto no es un ID de modelo, una fecha prometida no es un endpoint y un anuncio del proveedor no demuestra que una ruta de la pasarela funcione. Antes de que EvoLink pueda marcarlo como disponible, la ruta debe exponer un modelo upstream verificado, un esquema de solicitud, contabilidad de uso, precio, capacidad, comportamiento ante errores y una vía de rollback.
Eso simplifica la decisión inmediata: verifica K3 si puede resolver un problema actual y prepara trazas de Grok 4.6 si el próximo lanzamiento de xAI es estratégico para ti. Esperar no debería bloquear un trabajo que ya puede avanzar con la verificación de una ruta listada y criterios de producción explícitos.
Pesos abiertos y control del despliegue
La publicación de pesos abiertos de K3 crea opciones que una comparación limitada a servicios alojados pasa por alto:
- inspeccionar los artefactos del modelo publicados y la licencia;
- evaluar la viabilidad de servirlo por tu cuenta;
- probar cuantización u optimizaciones específicas de tu infraestructura;
- mantener más partes de la pila de servicio bajo control de la organización;
- comparar una vía directa o autogestionada con una ruta gestionada de EvoLink.
Esas opciones tienen costes reales. Un modelo mixture-of-experts de 2,8 billones de parámetros es exigente de operar aunque solo se activen 104.000 millones de parámetros por token. Los pesos abiertos no hacen gratuitas la planificación de capacidad, la optimización de inferencia, la seguridad, las actualizaciones ni la observabilidad.
Grok 4.6 no tiene pesos publicados ni un modelo de despliegue confirmado. Si el acceso a los pesos es un requisito y no una preferencia, K3 gana esa decisión hoy por evidencia, no por benchmarks.
Contexto y trabajo multimodal
El modelo upstream K3 de Moonshot documenta una ventana de contexto de un millón de tokens y comprensión nativa de imagen y vídeo, lo que lo hace relevante para programación a escala de repositorio, colecciones de documentos, capturas de pantalla, referencias de diseño, evidencias en vídeo e historiales largos de herramientas. El catálogo actual de EvoLink registra K3 como ruta de texto, así que verifica el contrato real de la ruta antes de enviar entradas que no sean texto. La prueba correcta no es «¿cabe la solicitud?», sino «¿el modelo recupera y utiliza la evidencia adecuada sin desperdiciar tokens?».
Mide:
| Prueba | Señal de aceptación | Fallo oculto que revisar |
|---|---|---|
| Cambio en un repositorio grande | Se identifican los archivos e invariantes correctos | Hay código importante presente, pero se ignora. |
| Tarea de captura de pantalla a interfaz | La jerarquía visual y el comportamiento coinciden | Un resultado atractivo incumple el sistema de diseño o la accesibilidad. |
| Tarea con evidencia en vídeo | Los eventos y su orden temporal se identifican bien | El modelo inventa transiciones o pierde un fotograma decisivo. |
| Síntesis de documentos largos | Las afirmaciones se remontan a la evidencia aportada | Se inventan detalles con seguridad o se mezclan fuentes. |
| Sesión larga con herramientas | El estado y los argumentos se mantienen coherentes | Se pierden resultados previos o se acumulan llamadas mal formadas. |
En Grok 4.6, incluso los modos de entrada y el límite de contexto siguen siendo desconocidos. Conserva el conjunto de datos, pero no prometas una comparación multimodal directa hasta que xAI documente el contrato.
Migración de sesión, reutilización de caché y el «impuesto» del contexto de 1M
Una ventana de 1M de tokens es capacidad, no una recomendación de reenviar 1M de tokens en cada turno. Los historiales largos pueden aumentar la latencia de prefill y el coste de la entrada no cacheada aunque la respuesta sea corta. La caché puede reducir ese coste, pero solo cuando el proveedor, la versión del modelo, el prefijo de la solicitud, la ventana de retención y la ruta cumplen los requisitos.
| Pregunta operativa | Suposición segura | Qué medir |
|---|---|---|
| ¿Puede una sesión antigua de Kimi pasar a K3 sin cambios? | No asumas que el estado de razonamiento o la caché KV del proveedor se transfiere entre versiones. Empieza una sesión nueva y controlada para la referencia. | Prefill del primer turno, paridad de respuestas, continuidad del estado de herramientas y uso de lecturas de caché. |
| ¿Una ventana de 1M mejora toda tarea larga? | No. El historial irrelevante puede elevar el coste y distraer la recuperación. | Recuperación de evidencia útil con presupuestos fijos de 32k, 128k y el requerido por la carga. |
| ¿Los prefijos repetidos siempre se cachean? | No. La elegibilidad y el reporte de caché dependen del contrato de la ruta. | Entrada cacheada frente a no cacheada, comportamiento del TTL, estabilidad del prefijo y conciliación de factura. |
| ¿Se puede aplicar una tasa de caché de API directa a una pasarela? | No. Las cifras de caché publicadas por Moonshot describen su servicio directo; no son una garantía de EvoLink ni de terceros. | Campos de uso y importe facturado de la ruta real. |
| ¿Un agente de larga duración debe conservar todos los turnos previos? | Solo cuando el historial retenido mejora la finalización más que el resumen o la recuperación. | Coste por tarea aceptada, errores de compactación, restricciones perdidas y recuperación. |
Las conversaciones de lanzamiento preguntan repetidamente si hay que reiniciar una sesión existente de Kimi y si los agentes de gran contexto se encarecen tras historiales largos. Esos informes identifican pruebas; no demuestran una política de caché universal. La regla de producción es registrar por separado la entrada cacheada y la no cacheada, conservar solo el estado de herramientas necesario y comparar una referencia de sesión nueva con una ejecución de historial migrado.
¿API directa, pasarela, suscripción o pesos autoalojados?
«Precio de Kimi K3» puede referirse a cuatro productos distintos. Mezclarlos produce una comparación de costes falsa.
| Canal de acceso | Superficie de precio o control | Qué debe verificarse |
|---|---|---|
| API directa de Moonshot | Moonshot publica tarifas por token de entrada cacheada, entrada no cacheada y salida | Región, elegibilidad de cuenta, reglas de caché, contrato de entrada, retención y unidades de factura. |
| Ruta unificada de EvoLink | El precio actual de la ruta se muestra en la superficie de precios de modelo ya existente de EvoLink | Identidad del modelo en vivo, modalidades soportadas, parámetros, campos de uso, SLO y comportamiento de fallback. |
| Paquete de IDE o suscripción | Puede usar una cuota de solicitudes, un pool premium o una política de uso justo en lugar de facturación por token | Si el host identifica el modelo/proveedor upstream, el presupuesto de contexto, la política de herramientas y la limitación. |
| Pesos abiertos autoalojados | Sin SKU alojado por token, pero con coste sustancial de aceleradores, red, operaciones, seguridad y actualizaciones | Obligaciones de la licencia Kimi K3, encaje de infraestructura, calidad de cuantización, capacidad y control de los logs. |
| Grok 4.6 | Todavía sin API verificada ni condiciones comerciales | ID de modelo, canal, precio de lista, caché, límites, retención y disponibilidad de enrutamiento. |
La publicación oficial de lanzamiento de Moonshot indica tarifas de API directa de 0,30 dólares por millón de tokens de entrada cacheada, 3 dólares por millón de tokens de entrada no cacheada y 15 dólares por millón de tokens de salida. Esas cifras describen la API directa de Moonshot publicada el 11 de agosto; no son automáticamente el precio de una ruta de EvoLink, una suscripción de IDE o una inferencia autoalojada. Usa la superficie de precios en vivo del canal que vayas a desplegar realmente.
Parámetros y comportamiento de los agentes
low, high y max de reasoning_effort, la llamada a herramientas, la selección de herramientas, las salidas estructuradas y requisitos importantes sobre el historial de conversación. En trabajo con herramientas de varios turnos, conserva todo el contenido del asistente que K3 necesita en lugar de reenviar solo el texto final visible.Para Grok 4.6, sigue esta matriz de compatibilidad el día del lanzamiento:
| Campo o comportamiento | Referencia de Kimi K3 | Qué debe confirmar Grok 4.6 |
|---|---|---|
model | kimi-k3 | ID exacto, alias y comportamiento con versión fijada |
| input/messages | Texto, imagen y vídeo; las entradas visuales de la API directa de Moonshot usan Base64 o IDs de archivo ms:// en lugar de URLs públicas de imagen | Esquema del endpoint y del contenido multimodal |
| control del razonamiento | reasoning_effort: low, high, max | Valores admitidos, valor por defecto, facturación, latencia |
| límite de salida | max_completion_tokens es 131.072 por defecto y admite hasta 1.048.576 en upstream | Valor por defecto, máximo, comportamiento de truncado y facturación |
| controles de muestreo | temperature=1.0, top_p=0.95, n=1 y ambas penalizaciones a 0 están fijados en upstream | Campos de muestreo admitidos y comportamiento de validación |
stream | Probar en la ruta elegida | Tipos de eventos, eventos de uso, deltas de herramientas |
tools / tool_choice | Documentados con indicaciones propias de K3 | Subconjunto del esquema, selección forzada, comportamiento en paralelo |
| salidas estructuradas | Documentadas | Compatibilidad con JSON Schema y convivencia con herramientas |
| repetición de estado | Conservar el historial de razonamiento y herramientas necesario | IDs de conversación, contenido de razonamiento, reglas de retención |
| límites | Contexto de un millón de tokens documentado en upstream | Contexto, salida, RPS, TPM, concurrencia, regiones |
| usage | Disponible para la contabilidad de la ruta | Categorías de tokens, uso de razonamiento, caché, conciliación con la factura |
La compatibilidad debe demostrarse con solicitudes y respuestas, no deducirse de que ambos proveedores usen nombres de campo familiares.
Coste: compara trabajo terminado, no un precio desconocido
Kimi K3 tiene precios directos públicos y una superficie de precios activa en EvoLink. Grok 4.6 no tiene ni precio oficial ni referencia en EvoLink. Una comparación numérica de costes hoy sería, por tanto, inventada.
Lo que sí pueden hacer los equipos es fijar ya el cálculo de coste que K3 —y cualquier futura ruta 4.6— tendrá que satisfacer:
accepted_task_cost = primary_calls
+ retries
+ fallback_calls
+ tool charges
+ reviewer_time
+ defect_repairRegistra la entrada, la entrada en caché, la salida, el uso de razonamiento, las tarifas de herramientas, el tiempo transcurrido y si el resultado se aceptó. Una ruta con una tarifa por token más baja puede salir más cara si genera razonamientos más largos, reintenta herramientas o aumenta la revisión. Una ruta premium puede ser económica si evita trabajo fallido.

Qué quieren decir los usuarios con “mejor”
El lenguaje de búsqueda y de la comunidad en torno a esta comparación es más operativo que centrado en parámetros. La gente pregunta si debe usar Kimi K3 ahora o esperar, si los pesos abiertos importan, si 1M de contexto recupera la evidencia correcta, si un agente completa todo el flujo y qué ruta cuesta menos tras los reintentos. Esas preguntas deben convertirse en casos de prueba en lugar de declaraciones especulativas de ganador.
| Pregunta del usuario | Evidencia necesaria |
|---|---|
| «¿Uso Kimi K3 ahora o espero a Grok 4.6?» | Fecha de entrega, SLO de la ruta actual y coste de oportunidad de esperar |
| «¿De verdad ayuda el contexto de 1M?» | Precisión de recuperación y resultados aceptados en repositorios o colecciones documentales largas |
| «¿Cuál es mejor para agentes de código?» | Ejecuciones de herramientas equiparadas, tasa de cambio completo, recuperación y tasa de falsa finalización |
| «¿Cuál es más barato?» | Coste por tarea aceptada, incluidos reintentos, llamadas a herramientas, fallback y revisión |
| «¿Importan los pesos abiertos?» | Un requisito real de autoalojamiento, inspección, personalización o control |
| «¿Puedo cambiar más adelante?» | IDs configurables, subconjunto de solicitudes compartido, replay sin conexión, canary y rollback |
La evaluación equiparable que conviene preparar
Construye un conjunto de 20 a 50 tareas a partir de trazas reales y asigna criterios de aceptación objetivos antes de ejecutar cualquiera de los dos modelos.
| Carga de trabajo | Por qué debe estar | Qué puntuar |
|---|---|---|
| Corrección de errores en un repositorio existente | Pone a prueba el diagnóstico y las restricciones ocultas | Causa raíz, pruebas, regresiones, cambios innecesarios |
| Implementación visual en React | Pone a prueba la visión nativa y el criterio de frontend | Fidelidad visual, adaptabilidad, accesibilidad, mantenibilidad |
| Ejecución de agente con muchas herramientas | Pone a prueba esquemas, estado y recuperación | Llamadas válidas, recuperación, número de bucles, intervención humana |
| Extracción estructurada | Pone a prueba la fiabilidad del contrato | Validez del esquema, exactitud de campos, tasa de reparación |
| Tarea de contexto largo | Pone a prueba la recuperación, no la capacidad | Exactitud de las citas, evidencia omitida, afirmaciones sin respaldo |
| Tarea de razonamiento difícil | Pone a prueba el equilibrio entre calidad y coste | Respuesta aceptada, uso de razonamiento, latencia, corrección del revisor |
Ejecuta K3 para establecer una base medible. Cuando Grok 4.6 sea invocable, congela el prompt, el estado del repositorio, las herramientas, los permisos, los presupuestos de tiempo y dinero, la rúbrica, la frescura de la sesión y el presupuesto de contexto útil. Registra por separado las entradas en caché y sin caché, y repite las pruebas cuando los resultados varíen. No compares un ajuste limitado de K3 con una demostración ilimitada de Grok ni llenes ambas ventanas máximas si la tarea necesita mucho menos contexto.
Árbol de decisión de enrutamiento en producción
Usa la disponibilidad como primer filtro, después los requisitos de la carga de trabajo y después los resultados medidos. Así evitas comparar una ruta operativa con una hipotética.
¿Necesitas entregar antes de que Grok 4.6 tenga una ruta de API verificada?
├─ Sí → Verifica la ruta Kimi K3 listada en EvoLink o usa otra ruta EvoLink cuya capacidad de llamada esté verificada.
└─ No → ¿La continuidad específica con Grok es el requisito principal?
├─ Sí → Mantén la base actual de Grok y prepara un carril de repetición para 4.6.
└─ No → ¿Necesitas pesos abiertos, contexto de 1M o entrada de imagen nativa?
├─ Sí → Evalúa primero Kimi K3.
└─ No → Haz benchmark de K3 ahora; añade 4.6 solo tras verificar la ruta.
Cuando Grok 4.6 sea invocable:
contrato verificado → repetición emparejada offline → prueba shadow → canary pequeño
→ promociona solo la carga ganadora → conserva una alternativa probada| Punto de decisión | Acción sobre la ruta | Condición de parada |
|---|---|---|
| Sin ID de modelo, precio o ruta de EvoLink verificados para Grok 4.6 | Mantener Grok 4.6 desactivado | No envíes tráfico a un identificador supuesto |
| La capacidad de K3 encaja con una carga inmediata | Probar K3 con trazas representativas | No promocionar si la calidad, la latencia o el coste por tarea aceptada incumplen el SLO |
| La continuidad con Grok importa pero la ruta actual es estable | Mantener la ruta actual y preparar la repetición emparejada | No esperes si bloquea un lanzamiento comprometido |
| La ruta de Grok 4.6 queda verificada | Ejecutar evaluación offline y shadow | Nada de salida hacia clientes antes de superar los criterios de compatibilidad |
| Una ruta gana un canary en una carga concreta | Promocionar solo esa clase de tareas | Rollback ante regresión de identidad, fiabilidad, coste o calidad crítica |
Política de enrutamiento recomendada en EvoLink
| Papel de la ruta | Ruta inicial | Regla de promoción |
|---|---|---|
| Verificación de la ruta K3 | Kimi K3 | Promocionar solo cargas que superen los criterios de calidad, latencia y coste aceptado. |
| Alternativa de producción actual | Ruta admitida existente | Mantenerla hasta que K3 o 4.6 demuestren un reemplazo seguro para el SLO. |
| Candidato Grok 4.6 | Desactivado / lista de espera | Activar solo tras verificar el upstream y la ruta de EvoLink. |
| Prueba shadow de Grok 4.6 | Grok 4.6 tras el lanzamiento | Sin salida visible para clientes hasta superar las pruebas de contrato y calidad. |
| Canary | Ganador en una carga concreta | Empezar con una parte pequeña del tráfico y rollback automático. |
EvoLink reduce el trabajo de aplicación necesario para comparar proveedores a través de una única capa de acceso, pero no elimina la validación propia de cada modelo. Mantén el ID del modelo configurable, apunta al subconjunto común de solicitudes cuando sea posible, registra las diferencias de compatibilidad y enruta en fronteras de tarea limpias.
Cuándo usar K3 ahora y cuándo esperar
Usa Kimi K3 ahora si:
- necesitas un modelo invocable con identidad de modelo publicada;
- los pesos abiertos o el control del despliegue cambian la decisión;
- el contexto de un millón de tokens o la entrada visual forman parte de la carga de trabajo;
- la tarea tiene pruebas de aceptación claras y una alternativa;
- puedes medir el coste por tarea terminada en lugar de fiarte de la reputación.
Espera evidencia de Grok 4.6 si:
- tu producto ya está estandarizado en Grok y una actualización reduciría el trabajo de migración;
- quieres comprobar específicamente si 4.6 corrige un patrón de fallo de Grok 4.5;
- una ruta actual cumple el SLO, de modo que esperar no tiene coste de oportunidad;
- necesitas capacidades propias de xAI que aún no están documentadas para 4.6.
No esperes si eso bloquea un producto urgente que ya cuenta con una ruta adecuada. Tampoco migres a K3 solo porque su arquitectura sea abierta o su contexto amplio. Ambas decisiones necesitan evidencia sobre tu carga de trabajo.
Preguntas frecuentes
¿Es Grok 4.6 mejor que Kimi K3?
No hay base verificada para esa afirmación. Kimi K3 está publicado y se puede probar; Grok 4.6 todavía no tiene una API pública documentada que permita una prueba en igualdad de condiciones.
¿Está disponible la API de Grok 4.6?
No según el catálogo oficial de modelos de la API de xAI, la página de precios y las notas de versión consultados el 11 de agosto de 2026. EvoLink aún no tiene una ruta invocable de Grok 4.6.
¿EvoLink lista una ruta Kimi K3?
kimi-k3. Esto demuestra el listado y la configuración, no una llamada de producción correcta. Consulta los precios en la página del modelo y verifica identidad, uso y facturación antes de producción.¿Qué modelo tiene mayor ventana de contexto?
Kimi K3 documenta una ventana de contexto de un millón de tokens. La de Grok 4.6 no está publicada, así que no es posible una comparación factual de tamaño.
¿Son multimodales ambos modelos?
El modelo upstream Kimi K3 de Moonshot admite oficialmente la comprensión nativa de imagen y vídeo. Verifica si la ruta directa o de pasarela elegida expone esos modos. Los modos de entrada de Grok 4.6 no están documentados; no asumas paridad con modelos Grok anteriores.
¿Qué modelo tiene pesos abiertos?
Kimi K3 cuenta con una publicación oficial de pesos abiertos bajo la licencia de Kimi K3. No hay ninguna publicación de pesos documentada para Grok 4.6.
¿Cuál es más barato?
Kimi K3 publica precios para la API directa de Moonshot; Grok 4.6 no. Una pasarela, una suscripción de IDE y el autoalojamiento tienen ámbitos comerciales distintos. Compara el precio vigente del canal elegido y el coste por tarea aceptada cuando 4.6 tenga una ruta verificada y resultados equiparables.
¿Podré cambiar rápido cuando se lance Grok 4.6?
Sí, si el ID del modelo es configurable, tu aplicación usa un contrato de solicitud compatible y mantienes K3 u otra ruta admitida como alternativa. Aun así, exige comprobaciones offline, shadow, canary y de rollback.
Verifica la ruta listada y sigue al candidato
Empieza verificando la ruta Kimi K3 listada en EvoLink con una carga medible, mantén la ruta configurable y suscríbete a las actualizaciones de Grok 4.6. El objetivo no es elegir proveedor por un titular, sino avanzar tras criterios de producción explícitos y conservar la opción de adoptar una ruta mejor cuando aparezca evidencia verificada.
Comparar modelos disponibles en EvoLinkLecturas relacionadas:
Fuentes
- xAI: catálogo de modelos de la API
- xAI: precios de la API
- xAI: notas de versión de la API
- Moonshot AI: repositorio oficial de Kimi K3
- Kimi: publicación oficial de lanzamiento de Kimi K3 y tarifas de la API directa
- Moonshot AI: colección de modelos Kimi K3
- Kimi Platform: guía de inicio rápido de Kimi K3
- Kimi Platform: precios de la API directa de Kimi K3
- Linux.do: debate sobre migración de sesión y caché de Kimi K3
- Linux.do: debate sobre Kimi K3 y precios de OpenCode
Las conversaciones de la comunidad y los resultados de búsqueda actuales solo sirvieron para elegir el tema de comparación, el vocabulario de canales de acceso, las dudas de migración de sesión y las preguntas de evaluación. El estado de los modelos, los IDs, la arquitectura, el contexto, los modos de entrada, los parámetros y los precios directos proceden de fuentes oficiales o de los registros de rutas de EvoLink.


