Ir al contenido principal

Grok 4.5 es el modelo de código de xAI para software agéntico y trabajo de ingeniería, tras una llamada de chat compatible con OpenAI. Admite hasta 500.000 tokens de entrada, responde hasta 450.000 y el esfuerzo de razonamiento llega hasta xhigh.

Entrada $2Salida $6por 1 millón de tokensEntrada en caché $0.30Prompts de 200K tokens o másEntrada $4Salida $12

Playground

Grok 4.5

¿En qué te puede ayudar Grok 4.5?

Modelos relacionados y tareas siguientes

¿No está el modelo que buscas?

Dinos cuál añadir y para qué lo usarías. Las solicitudes llegan directamente al equipo que decide los próximos modelos.

Flujos de mensajes estables para el software agéntico, la ingeniería y los bucles con prompt largo repetido

Grok 4.5 es el modelo de xAI orientado a software agéntico, ingeniería y tareas de flujo de trabajo. Contexto, tope de respuesta y rango de esfuerzo coinciden con el hermano de mayor capacidad; lo que cambia es la tarifa más baja de la entrada en caché, que es justo donde se va el presupuesto de un bucle que reenvía el mismo bloque de cabecera.

Abrir el Playground de chat
Flujos de mensajes estables para el software agéntico, la ingeniería y los bucles con prompt largo repetido
Modelo
Grok 4.5
Recomendado para
el software agéntico, la ingeniería y los bucles con prompt largo repetido
Forma del mensaje
Reglas de sistema → evidencia y estado → tarea del turno → contrato de salida
Límite de los hechos
Capacidades, controles y precio vienen del esquema en vivo

Principio de integración

Valida primero con el conjunto de mensajes más pequeño y añade solo el contexto necesario. Separa hechos, supuestos y restricciones, y diseña los flujos de interrupción, reintento, liquidación y revisión humana.

Crea flujos de trabajo reproducibles para el software agéntico, la ingeniería y los bucles con prompt largo repetido

Grok 4.5 es el modelo de xAI orientado a software agéntico, ingeniería y tareas de flujo de trabajo. Contexto, tope de respuesta y rango de esfuerzo coinciden con el hermano de mayor capacidad; lo que cambia es la tarifa más baja de la entrada en caché, que es justo donde se va el presupuesto de un bucle que reenvía el mismo bloque de cabecera.

  • Cabecera en caché

    La repetición es el punto

    Mantén el inicio de la petición idéntico byte a byte durante todo el bucle para que pueda reutilizarse. El objeto usage informa cuántos tokens de entrada quedaron en caché: un acierto es algo que se mide, no algo con lo que se cuenta.

  • El mismo envase

    500.000 de entrada, 450.000 de salida

    La ventana de contexto y el tope de una respuesta igualan a los del hermano mayor, así que un diseño de mensajes que funciona allí se traslada sin cambios.

  • Rango de esfuerzo

    de low a xhigh, high por defecto

    Este modelo no tiene interruptor de apagado. Los tokens de razonamiento cuentan como salida, así que max_tokens debe subir junto con el esfuerzo.

Elige Grok 4.5 por el costo de la tarea y la forma de la interacción

Prueba una tarea real midiendo calidad, verificabilidad, latencia y encaje con el precio de venta, en lugar de fiarte de una tabla general.

  1. Elige 4.5

    La misma consigna larga corre muchas veces al día

    Agentes de ingeniería, bots de revisión y pasos de flujo que reproducen un conjunto fijo de instrucciones sobre entradas cambiantes.

  2. Elige 4.6

    Cada petición es distinta

    Si el bloque de cabecera cambia cada vez no hay nada que reutilizar, y entonces el hermano mayor es el mejor cambio.

  3. Elige 4.3

    Hay pasos que no requieren deliberar

    Dentro del mismo agente, el reparto, el etiquetado y la extracción pueden moverse al hermano que acepta el nivel none.

Convierte Grok 4.5 en trabajo concreto, no en etiquetas genéricas

Cada escenario necesita límites de entrada, verificación y recuperación; nunca inventamos capacidades oficiales, benchmarks ni soporte de herramientas.

  • Consigna fija, repositorio cambiante

    Agentes de ingeniería

    Consigna fija, repositorio cambiante

    Convenciones, reglas de revisión y contrato de salida viven en el bloque fijo; en el turno solo viajan los archivos modificados.

  • Cadenas de varios pasos bajo una sola política

    Flujos de trabajo

    Cadenas de varios pasos bajo una sola política

    Reutiliza la misma cabecera de política en cada paso y cambia únicamente la línea de tarea: así todos los pasos se miden con el mismo rasero.

  • Diffs medidos contra un estándar escrito

    Revisión de código

    Diffs medidos contra un estándar escrito

    Entrega el estándar una vez y luego envía los diffs; pide hallazgos, gravedad y la regla que invoca cada hallazgo.

  • Capturas como entrada de una comprobación fija

    Visión en el bucle

    Capturas como entrada de una comprobación fija

    Las partes de imagen aceptan detail auto, low o high. En esta ruta no hay partes de archivo ni PDF: los documentos deben llegar como texto o como imagen.

Organiza el contexto como una entrada inspeccionable para Grok 4.5

Objetivo, evidencia, estado, restricciones y contrato de salida deben cumplir funciones distintas para poder comprimir, depurar y reproducir la solicitud.

  1. Cabecera estable

    Escribe el bloque de cabecera una vez y no lo toques más

    Cada retoque invalida la cabecera que el bucle estaba reutilizando. Versiónala a propósito en lugar de ajustarla ejecución a ejecución.

  2. Cola variable

    Todo lo que cambia va al final

    Línea de tarea, diff y estado actual van después del bloque fijo, siempre en el mismo orden.

  3. Herramientas

    Declara la superficie de herramientas de forma explícita

    Hasta 128 definiciones de funciones con tool_choice. Nombres y esquemas también forman parte de la cabecera reutilizable: mantenlos estables.

  4. Medición

    Lee usage en cada ejecución

    Tokens de entrada en caché, tokens de salida y latencia dicen juntos si el bucle sigue comportándose como se diseñó.

Demuestra un caso reproducible de Grok 4.5 antes de integrarlo en el producto

Confirma esquema en vivo, estimación, streaming y comportamiento ante errores antes de reutilizar la solicitud normalizada.

  1. 01 · Línea base

    Valida la solicitud mínima en el Playground

    Revisa las capas del mensaje, la forma de salida, el streaming y los controles actuales.

  2. 02 · Límites

    Ejercita fallo, cancelación y reintento

    Comprueba tiempos agotados, flujos interrumpidos, entradas excesivas, regeneración y envíos duplicados.

  3. 03 · Integrar

    Copia la solicitud API normalizada

    Usa el id público del modelo y el contrato de mensajes; lee los controles del esquema en vivo.

  4. 04 · Operar

    Mide el consumo y sigue evaluando

    Guarda estado, consumo final, causas de fallo y comentarios de calidad; estima antes de las llamadas caras.

Lleva Grok 4.5 a un contrato de API claro

Playground, ejemplos de API, estados de solicitud y registros de consumo se mantienen alineados desde la evaluación hasta producción.

  • Contrato unificado

    Una sola forma para mensajes, flujos y errores

    La estructura de la solicitud, el manejo de estado y la recuperación de errores no cambian al cambiar de modelo.

  • Esquema en vivo

    Usa los controles del endpoint actual

    Playground y ejemplos de API exponen juntos campos disponibles, límites y comportamiento por defecto.

  • Ciclo de vida observable

    Cada solicitud tiene un estado claro

    Envío, streaming, fallo, cancelación y consumo usan semántica pública inspeccionable.

  • Integración portable

    Menos retrabajo cuando los modelos cambian

    Un contrato claro mantiene el código de producto centrado en entradas, resultados y experiencia.

Límites de la API de Grok 4.5 que conviene confirmar antes de integrar