Grok 4.7 vs Grok 4.6: diferencias y cuándo cambiar
Mantén Grok 4.6 para el trabajo que ya resuelve bien y prepara una evaluación específica de Grok 4.7. A 18 de septiembre de 2026, la documentación para desarrolladores de xAI no tiene ninguna entrada formal de lanzamiento de Grok 4.7 y en EvoLink todavía no se puede llamar. Aún no hay resultados medidos, así que no hay un ganador al que señalar.
Grok 4.7 vs Grok 4.6: ¿qué diferencias se pueden verificar hoy?
Grok 4.6 tiene un registro oficial de modelo. Grok 4.7 tiene declaraciones con fuente sobre la hoja de ruta, incluida una explicación del retraso. Es una diferencia de evidencia y de madurez, no una prueba de que el modelo anterior sea mejor.
| Dimensión | Grok 4.6 (según la documentación oficial) | Grok 4.7 hoy |
|---|---|---|
| ID del modelo | xAI documenta grok-4.6 | ID oficial del modelo sin confirmar |
| Contexto | 500.000 tokens | Sin confirmar |
| Modalidades | Entrada de texto e imagen; salida de texto | Sin confirmar |
| Herramientas y salida | Function calling y salidas estructuradas recogidos en la documentación oficial | Compatibilidad sin confirmar |
| Razonamiento | low, medium, high, xhigh; por defecto high | Controles admitidos sin confirmar |
| En EvoLink | Página de producto y precios existentes | Estado previo al lanzamiento y alerta de API |
| Evidencia de rendimiento en igualdad de condiciones | Tu carga de trabajo actual puede aportar una línea base | Todavía no hay ninguna prueba de 4.7 en igualdad de condiciones |
Empieza por el problema que una actualización debe resolver
Si 4.6 ya cumple tus reglas de aceptación y tu plazo, esperar a 4.7 no tiene por qué detener la entrega. Conserva la línea base y reserva el esfuerzo de evaluación para las tareas con un beneficio potencial claro.
Un asistente de código puede fallar porque se detiene tras explicar una corrección en lugar de cambiar el repositorio. Un pipeline de extracción puede devolver JSON válido al que le faltan campos. Un agente de larga duración puede completar la tarea pero superar el presupuesto de latencia porque repite llamadas a herramientas. Estos fallos requieren pruebas diferentes y pueden llevar a elegir modelos distintos.
| Tu situación actual | Preparación que merece la pena | Qué justificaría mover la carga de trabajo |
|---|---|---|
| Resultados correctos, coste y latencia aceptables | Guarda una pequeña línea base de regresión | Un beneficio claro sin perder el comportamiento exigido |
| Tareas de repositorio que quedan sin terminar con frecuencia | Reúne fallos representativos y tests independientes | Más correcciones aceptadas con el mismo presupuesto por tarea |
| Bucles de herramientas o reintentos caros | Conserva las trazas y los casos de error controlados | Mejor recuperación y menor coste por tarea aceptada |
| Regresiones en traducción o extracción | Añade comprobaciones específicas por tarea más allá del código | Calidad estable o mejorada en esas categorías |
| Plazo de entrega estricto | Mantén la configuración ya validada | Acceso al candidato y validación completados antes del plazo |
Elige la regla de aceptación antes de mirar los resultados del candidato. De lo contrario, un ejemplo llamativo puede cambiar sin que se note lo que el equipo considera un éxito.
Monta una evaluación en igualdad de condiciones a partir de trabajo real con Grok 4.6
Una primera pasada útil contiene éxitos rutinarios, fallos conocidos y casos límite caros. No hace falta que sea lo bastante grande como para sostener una afirmación estadística de rendimiento. Su primera función es detectar incompatibilidades evidentes y mostrar si merece la pena financiar una prueba mayor.
Congela el commit del repositorio o la versión del documento, la instrucción del usuario, el contexto relevante y las respuestas simuladas de las herramientas. Mantén el mismo límite de tiempo y el mismo presupuesto de acciones. Guarda la configuración de la solicitud por separado para que un cambio en el esfuerzo de razonamiento o en el tope de salida no se haga pasar por una mejora del modelo.
Haz primero una pasada de compatibilidad con los ajustes admitidos que ambos comparten. Una pasada de optimización posterior puede usar controles específicos del modelo, pero asigna a ambas configuraciones un presupuesto de ajuste explícito e informa de ellas por separado. No está garantizado que ajustes de esfuerzo con el mismo nombre consuman un cómputo comparable entre versiones.
Una tarea de repositorio concreta
Supón que tu agente debe corregir la paginación de un endpoint sin cambiar la autenticación. Guarda un test de paginación que falla, los archivos permitidos, la revisión del repositorio y el requisito de que los tests de autenticación sigan pasando. Son los datos de prueba de la tarea, no evidencia sobre ninguno de los dos modelos.
Una ejecución aceptada debe producir un parche que funcione, pasar los tests pertinentes y mantenerse dentro del alcance permitido. Una explicación plausible sin parche es un fallo. Un parche que corrige la paginación pero debilita la autenticación también es un fallo. Si el agente dice que ejecutó los tests, conserva la salida de la herramienta para que un revisor pueda comprobar esa afirmación.
Así la calidad de la finalización se vuelve observable. También evita que una respuesta prolija o segura de sí misma se lleve el mérito que merece un parche más discreto que funciona.
Incluye el trabajo que es fácil pasar por alto
No dejes que un benchmark de programación sustituya la combinación de tareas de tu aplicación. Si el producto también traduce comentarios técnicos, extrae campos estructurados o lee capturas de pantalla, conserva esas categorías en el conjunto de regresión. Para cualquier modalidad o herramienta que la documentación de 4.7 aún no recoja, marca la evaluación como bloqueada o no aplicable en lugar de fabricar una puntuación.
Cuando las herramientas puedan cambiar un estado externo, usa datos de reproducción grabados o un sandbox aislado. Ejecutar dos veces la misma acción de cliente no es una comparación justa si la primera ejecución cambia el entorno de la segunda.
Puntúa el trabajo completado, no solo la respuesta
Cada ejecución debería producir un artefacto, una traza y un registro de costes. Una única media oculta diferencias útiles, así que examina las categorías de tareas y los tipos de fallo antes de combinarlos.
| Métrica | Cómo medirla | Error que evita |
|---|---|---|
| Tasa de tareas aceptadas | Tareas que cumplen la rúbrica congelada divididas entre las tareas intentadas | Contar respuestas plausibles como trabajo completado |
| Cumplimiento del alcance | Comprueba las ediciones, las acciones y las restricciones permitidas | Premiar un atajo eficaz pero inaceptable |
| Tiempo de finalización | Mide desde el inicio de la tarea hasta el artefacto aceptado, reintentos incluidos | Presentar la velocidad del primer token como latencia de extremo a extremo |
| Recuperación con herramientas | Usa fallos controlados e inspecciona la traza resultante | Confundir una ejecución limpia por suerte con fiabilidad |
| Coste facturado por aceptación | Todos los cargos de los intentos divididos entre las tareas aceptadas | Ocultar el gasto en solicitudes fallidas y reintentos |
| Carga de revisión | Registra por separado las correcciones y el tiempo del revisor | Trasladar de forma invisible trabajo del modelo a una persona |
Mantén los recuentos brutos junto a los porcentajes. Una mejora pequeña en una muestra pequeña es un motivo para investigar, no una afirmación universal. Repite casos difíciles representativos para sacar a la luz la variabilidad e indica los ajustes y la fecha junto a cualquier resultado publicado.
Cómo puede cambiar el coste la actualización incluso antes de que difieran los precios por token
La cuestión del coste es si la carga de trabajo sale más barata de terminar con la calidad exigida. El precio de Grok 4.7 todavía no está confirmado, así que una comparación real de precios tendrá que esperar. Aun así, puedes definir ya la medición:
cost per accepted task = total billed cost of all attempts / accepted tasksCuenta los fallos y los reintentos en el numerador. Si no se acepta ninguna tarea, informa de ese resultado de forma explícita; no muestres un coste cero. Mantén el coste de la revisión humana separado de los cargos de la API, salvo que publiques deliberadamente un modelo de coste operativo combinado.
Considera un ejemplo ilustrativo de reintentos, no una prueba de un modelo. La primera pasada gasta 24 $ en 100 tareas y acepta 80: 0,30 $ por aceptación. Reintentar los 20 fallos cuesta otros 12 $ y rescata ocho tareas. El flujo completo cuesta, por tanto, 36 $ por 88 tareas aceptadas, es decir, unos 0,41 $ cada una. Los reintentos aumentaron las tareas completadas, pero también el coste unitario. Compara las versiones candidatas con el mismo tope de reintentos y analiza si el trabajo aceptado adicional compensa ese aumento.
Una comparación real también debe tener en cuenta el comportamiento de la caché, los cargos por herramientas y los tramos de contexto largo. La documentación de 4.6 de xAI señala un precio más alto para contextos grandes en torno a su umbral de 200K. Comprueba el precio vigente del canal que uses antes de reproducir trazas largas; un prompt nuevo y compacto y una conversación larga acumulada son casos de coste diferentes. No copies ese umbral en una configuración de 4.7.
Comprueba la compatibilidad antes de mover tráfico
Usar la misma familia del proveedor no reduce la necesidad de validar la salida ni la de inspeccionar los errores. Una integración unificada con EvoLink te permite seguir usando la misma cuenta y la misma integración con el gateway, pero la forma de llamar a cada modelo sí cambia.
| Área | Qué conservar | Qué volver a probar |
|---|---|---|
| ID del modelo | Configuración explícita y valor de reversión | El nuevo ID del modelo que indique la documentación oficial y el ID del modelo que devuelve la respuesta |
| Salida estructurada | Tu esquema y tu validador | Campos ausentes, valores no válidos y truncamiento |
| Herramientas | Definiciones de las herramientas y límites de autorización | Argumentos, llamadas repetidas y recuperación ante errores |
| Streaming | Gestión de la salida parcial en la aplicación | Forma de los eventos, respuestas interrumpidas y estado terminal |
| Estado de la conversación | Mensajes y datos de prueba originales | Límites de contexto, compactación y restricciones conservadas |
| Uso y facturación | Registros que vinculan una tarea con sus intentos | Contabilidad de caché, razonamiento, salida y herramientas |
No cambies a la vez el modelo, el prompt, el adaptador de herramientas y la política de reintentos. Cuando un resultado mejora o empeora, necesitas saber qué cambio lo provocó. Mantén una configuración de línea base estable hasta que el candidato haya superado las comprobaciones que importan para tu carga de trabajo.
Despliega por carga de trabajo, con una condición de reversión real
Empieza con una reproducción offline. Si el candidato la supera, ejecútalo en la sombra sobre trabajo adecuado de solo lectura mientras el modelo actual sigue siendo el responsable del resultado que ve el usuario. Solo entonces pasa una carga de trabajo limitada a un despliegue controlado. Es una recomendación de despliegue para tu aplicación, no una afirmación de que EvoLink gestione automáticamente tu evaluación ni tu política de failover.
Define una condición de parada en términos operativos: un fallo crítico de esquema, un comportamiento no autorizado de las herramientas, una caída significativa de los resultados aceptados o un coste y una latencia fuera del presupuesto acordado. El umbral debe corresponderse con el impacto del fallo. Un asistente que redacta borradores y un agente que modifica un repositorio no deberían compartir una misma tolerancia universal fijada a la ligera.
Al volver atrás, conserva la solicitud y la traza del candidato para el diagnóstico. En trabajos con efectos secundarios, comprueba qué acciones ya se completaron antes de reintentar con 4.6. Reproducir a ciegas una tarea parcialmente completada puede duplicar una acción incluso cuando el modelo de respaldo funciona correctamente.
La promoción no tiene por qué ser todo o nada. Un candidato podría ganarse las tareas de repositorio difíciles mientras la línea base conserva el trabajo de extracción predecible. Mantén el reparto solo si su beneficio medible compensa la monitorización y la configuración adicionales.
La decisión práctica en EvoLink
Preguntas frecuentes
¿Es Grok 4.7 mejor que Grok 4.6?
Todavía no se puede afirmar, porque aún no hay ninguna prueba de 4.7 en igualdad de condiciones. Un modelo posterior también debe evaluarse con las tareas, el presupuesto y las restricciones que exige tu aplicación.
¿Debería dejar de usar Grok 4.6 mientras espero?
Mantén una línea base que funcione para las entregas programadas. Prepara los datos de prueba de la evaluación, pero no hagas que el trabajo de producción dependa de un modelo nuevo cuya disponibilidad aún no está confirmada.
¿Puedo reutilizar el mismo prompt?
Empieza con un prompt congelado para la comparación y, si hace falta, ejecuta después una pasada de ajuste de la que se informe por separado. Cambiar a la vez el modelo y el prompt hace que el resultado inicial sea más difícil de interpretar.
¿Hay que volver a probar las llamadas a herramientas y las salidas estructuradas?
Sí. Vuelve a probar los esquemas, los argumentos, la recuperación y la validación de la salida siguiendo la documentación oficial del nuevo modelo, incluso dentro de la misma familia de modelos.
¿Y si mejora la programación pero empeora la traducción?
Evalúa esas cargas de trabajo por separado. Promueve solo las categorías que cumplan tus requisitos, o conserva la línea base si gestionar un reparto añade más complejidad que valor.
¿Un precio por token más bajo garantiza un ahorro?
No. Los intentos fallidos, las herramientas repetidas, la longitud de la salida y el esfuerzo de revisión pueden anular una tarifa más baja. Compara todos los cargos por tarea aceptada.
¿Cuántas tareas son suficientes?
No hay un tamaño de muestra universal. Empieza con regresiones representativas, registra los recuentos brutos y la variabilidad, y amplía la muestra antes de hacer afirmaciones amplias de rendimiento o de mover tráfico de alto impacto.
¿Cuándo debería revertir?
Revierte cuando falle un comportamiento crítico o se superen tus límites predefinidos de calidad, coste o latencia. Inspecciona los efectos secundarios ya completados antes de reintentar una tarea con otro modelo.
