xAI describe Grok 4.7 como su modelo de vanguardia para programación, tareas agénticas y trabajo de conocimiento, con una ventana de contexto de 500K tokens. Según la página de precios actual de xAI, las tarifas directas de la API por debajo de 200,000 tokens de prompt son $2.00 por millón de tokens de entrada, $0.50 por millón de tokens en caché y $6.00 por millón de tokens de salida. Cuando un prompt alcanza 200,000 tokens o más, xAI lista $4.00, $1.00 y $12.00 respectivamente. Estas son tarifas directas de xAI, no un precio universal en plataformas de terceros.
El gasto real depende de más que la tarifa de entrada destacada. La entrada nueva, la entrada en caché, la salida, los reintentos, las llamadas a herramientas y el número de llamadas al modelo en un flujo de trabajo de agente pueden cambiar la factura. El umbral de 200K tokens de prompt es especialmente importante porque tanto xAI como CometAPI publican tarifas más altas de contexto largo una vez que se alcanza ese límite.
Esta guía primero establece la línea base de precios de xAI y luego compara la lista actual de CometAPI Grok 4.7. Al 28 de septiembre de 2026, CometAPI lista $1.60 / $0.40 / $4.80 por millón de tokens de entrada nueva, entrada en caché y salida en el nivel estándar, y $3.20 / $0.80 / $9.60 en el nivel de contexto largo, un 20% por debajo de las tarifas directas correspondientes de xAI. Las secciones siguientes explican cómo calcular el costo de trabajo, reducir desperdicios y acceder al modelo a través de CometAPI. Todos los precios son instantáneas con fecha y deben volver a verificarse antes del uso en producción.
xAI Direct vs. CometAPI Grok 4.7 Pricing
Tarifas de xAI direct (USD por 1M de tokens)
| Categoría de tokens | Por debajo de 200K tokens de prompt | Contexto largo (≥200K) |
|---|---|---|
| Entrada nueva | $2.00 | $4.00 |
| Entrada en caché | $0.50 | $1.00 |
| Salida | $6.00 | $12.00 |
Tarifas de CometAPI (USD por 1M de tokens)
| Categoría de tokens | CometAPI: por debajo de 200K tokens de prompt | CometAPI: nivel de contexto largo |
|---|---|---|
| Entrada nueva | $1.60 / 1M tokens | $3.20 / 1M tokens |
| Entrada en caché | $0.40 / 1M tokens | $0.80 / 1M tokens |
| Salida | $4.80 / 1M tokens | $9.60 / 1M tokens |
El límite de 200K tokens de prompt importa porque ambas plataformas actualmente listan tarifas de contexto largo al doble de sus tarifas del nivel estándar para Grok 4.7. Esta es una regla de precios establecida por cada plataforma de API, no un cambio en la capacidad del modelo. Una solicitud se vuelve más cara cuando una aplicación envía repetidamente prompts grandes o permite que el historial del agente crezca sin control, no simplemente porque Grok 4.7 admite una ventana de contexto de 500K.
Para presupuestación, trata cualquier solicitud que se proyecte alcanzar el límite como contexto largo hasta que se verifique el comportamiento de facturación activo. La disponibilidad del modelo y los precios pueden cambiar, por lo que las calculadoras de producción deben volver a verificar tanto la tarifa directa de xAI como la página actual del modelo en CometAPI en lugar de codificar valores permanentes.
The Formula for Estimating Grok 4.7 Cost
Estima una solicitud valorando cada categoría de tokens por separado:
request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000
Luego convierte la estimación por solicitud en una estimación de carga de trabajo:
monthly cost = request cost × requests per user × active users × days in billing period
Usa un percentil realista en lugar de un promedio único. Una estimación p50 describe una solicitud normal, pero las longitudes de entrada y salida p95 exponen la cola costosa que a menudo impulsa la factura. Para flujos de trabajo de agentes, multiplica por el número esperado de llamadas al modelo por tarea completada. Un flujo de trabajo de cinco pasos son cinco llamadas facturables, no una.
Worked Example 1: A Support Copilot
Supón que una solicitud de soporte envía 6,000 tokens de entrada nueva y genera 800 tokens de salida. Se mantiene por debajo del umbral de 200K y no recibe un descuento de caché.
- Entrada: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
- Salida: 800 × $4.80 ÷ 1,000,000 = $0.00384
- Total: $0.01344 por solicitud
Con 100,000 solicitudes por mes, el costo estimado de tokens es $1,344. Si la evaluación muestra que una respuesta de 400 tokens funciona tan bien como una de 800 tokens, la estimación cae a $0.01152 por solicitud, o $1,152 por mes. Ese único límite de salida ahorra alrededor de $192 por mes, o 14.3%, sin cambiar el modelo.
Por eso el control de salida merece atención. A la tarifa listada de CometAPI, los tokens de salida cuestan tres veces más que los tokens de entrada nueva en el mismo nivel.
Worked Example 2: Reusing a Stable 20K-Token Prefix
Supón que cada solicitud contiene un manual de producto de 20,000 tokens, 2,000 tokens de contexto de conversación nuevo y una respuesta de 600 tokens.
Sin un acierto de caché, la estimación es:
- 22,000 tokens de entrada nueva: $0.03520
- 600 tokens de salida: $0.00288
- Total: $0.03808 por solicitud
Si el prefijo estable de 20,000 tokens se factura como entrada en caché mientras solo 2,000 tokens permanecen como nuevos, la estimación se convierte en:
- 20,000 tokens de entrada en caché: $0.00800
- 2,000 tokens de entrada nueva: $0.00320
- 600 tokens de salida: $0.00288
- Total: $0.01408 por solicitud
Con 100,000 solicitudes, eso es $1,408 en lugar de $3,808: un ahorro estimado de $2,400, o 63.0%. El ahorro no es automático: la primera solicitud, un prefijo cambiado o una ruta que no produce un acierto de caché aún pueden facturarse a la tarifa de entrada nueva. Confirma el conteo de tokens en caché en los datos de uso reales antes de tratar la estimación como ahorro logrado.
Worked Example 3: The Cost of Crossing 200K
Considera una solicitud de agente de larga duración con 210,000 tokens de prompt y 2,000 tokens de salida. Usando las tarifas de contexto largo listadas:
- 210,000 tokens de entrada nueva: $0.67200
- 2,000 tokens de salida: $0.01920
- Total: $0.69120 por ejecución
Si la compactación del contexto, el filtrado de recuperación y los puntos de control de resúmenes reducen el prompt a 180,000 tokens preservando la misma salida de 2,000 tokens, la estimación del nivel estándar es:
- 180,000 tokens de entrada nueva: $0.28800
- 2,000 tokens de salida: $0.00960
- Total: $0.29760 por ejecución
La diferencia es $0.39360 por ejecución, o alrededor de 56.9%. En 10,000 ejecuciones, el ahorro estimado es $3,936. La lección no es eliminar contexto útil. Es conservar solo el contexto que cambia la respuesta y resumir o recuperar el resto antes de que la solicitud cruce un límite de precio.
A Python Calculator for Pre-Call Estimates
from dataclasses import dataclass
@dataclass(frozen=True)
class Rates:
input_per_million: float
cached_input_per_million: float
output_per_million: float
SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)
def estimate_grok_47_cost(
fresh_input_tokens: int,
cached_input_tokens: int,
max_output_tokens: int,
) -> float:
prompt_tokens = fresh_input_tokens + cached_input_tokens
rates = LONG if prompt_tokens >= 200_000 else SHORT
return (
fresh_input_tokens * rates.input_per_million
+ cached_input_tokens * rates.cached_input_per_million
+ max_output_tokens * rates.output_per_million
) / 1_000_000
estimate = estimate_grok_47_cost(
fresh_input_tokens=2_000,
cached_input_tokens=20_000,
max_output_tokens=600,
)
print(f"Estimated upper bound: ${estimate:.5f}")
Esto es un resguardo de planificación, no una factura. El costo final depende de la entrada real, la entrada en caché, la salida, los reintentos, las llamadas a herramientas y el precio activo en el momento de la ejecución. Después de cada respuesta, guarda el uso de tokens devuelto, el ID del modelo, el estado de la solicitud y el resultado de la tarea. Reconciliá esos valores con los registros de facturación del proveedor.
Five Grok 4.7 Cost Controls, Ranked by Likely Impact
1. Keep Repeated Context Stable Enough to Cache
Coloca instrucciones estáticas, documentación de producto, esquemas y ejemplos reutilizables antes del contenido específico de la solicitud. Evita cambiar marcas de tiempo, IDs, espacios en blanco o el orden dentro de un gran prefijo compartido a menos que el cambio sea necesario. La guía de Grok 4.7 de xAI recomienda identificadores de enrutamiento de caché estables para conversaciones; al usar una ruta intermedia, verifica qué controles de caché y campos de uso son compatibles antes de depender de ellos.
Mide los tokens con acierto de caché y la tasa de aciertos de caché por carga de trabajo. Un descuento de caché teórico no vale nada si la aplicación modifica constantemente el prefijo.
2. Treat 200K as an Engineering Budget, Not a Target
Reserva margen por debajo del umbral para instrucciones del sistema, pasajes recuperados, resultados de herramientas y el siguiente turno del usuario. Para un agente, compacta los turnos antiguos en un resumen validado y conserva la transcripción cruda fuera del contexto del modelo. Para la recuperación, clasifica y desduplica los pasajes antes de insertarlos en lugar de enviar cada coincidencia.
Supervisa las distribuciones de longitud del prompt y alerta antes de que el p95 se acerque al umbral. Según el cronograma oficial de xAI, una vez que un prompt alcanza 200K tokens, las tarifas de contexto largo se aplican a todos los tokens de esa solicitud. CometAPI igualmente lista un nivel separado y más alto de contexto largo para Grok 4.7. Estas son condiciones de precios de la plataforma, no capacidades del modelo.
3. Cap Output and Tune Reasoning Effort Against an Evaluation Set
Establece un límite de salida a nivel de aplicación que se ajuste al producto. Un resultado de clasificación puede necesitar decenas de tokens; una respuesta de soporte puede necesitar unos cientos; un informe de investigación puede necesitar más. Este límite es un control de presupuesto y de experiencia de usuario, no un límite rígido del modelo Grok 4.7. Las notas de la versión del 21 de septiembre de xAI indican que Grok 4.7 no tiene límite de salida de texto; eso no impide que una aplicación o una ruta de API específica imponga su propio límite por solicitud. Confirma cualquier límite por solicitud impuesto por el endpoint o el SDK con la ruta que realmente uses.
Grok 4.7 admite varios niveles de esfuerzo de razonamiento. Usa el nivel más bajo que pase un conjunto de evaluación representativo y reserva un mayor esfuerzo para tareas donde produzca una mejora medible. Reducir el razonamiento o la salida sin controles de calidad puede crear reintentos y borrar el ahorro.
4. Reject or Reshape Expensive Requests Before the API Call
Estima un límite superior a partir del tamaño de entrada y el límite de salida configurado. Si la solicitud excede el presupuesto del producto, la aplicación puede pedir al usuario que acote la tarea, resuma el material cargado, reduzca el contexto recuperado o mueva el trabajo a un flujo de trabajo asíncrono aprobado. Esto es más predecible que descubrir el costo después de la generación.
Una aproximación grosera de caracteres a tokens puede ser útil como guardia temprana, pero no debe sustituir a un tokenizador ni a los datos de uso reales. Idiomas, código, JSON y formato pueden producir densidades de tokens muy diferentes.
5. Optimize Cost per Successful Task, Not Cost per Call
Una llamada más barata que falla la validación dos veces puede costar más que una llamada exitosa. Rastrea:
- costo por respuesta aceptada;
- costo por tarea de agente completada;
- costo de reintentos y alternativas;
- tasa de aciertos de caché y proporción de tokens en caché;
- tokens de prompt y salida p50 y p95;
- puntaje de calidad, latencia y tasa de escalación humana.
Si el tráfico rutinario no requiere la calidad o la capacidad de contexto de Grok 4.7, el catálogo unificado de modelos de CometAPI puede facilitar un cambio de modelo administrado por la aplicación. Mantén explícita la regla de enrutamiento, evalúa cada modelo en el mismo conjunto de tareas y envía solo las solicitudes que se beneficien de Grok 4.7 a esta ruta.
A Practical Monthly Cost Review
Una vez a la semana, agrupa el tráfico por función y compara el costo estimado con el uso real. Comienza con las funciones responsables de más tokens de salida, los prompts más grandes y la menor tasa de aciertos de caché. Luego revisa los atípicos costosos en lugar de optimizar ciegamente la solicitud mediana.
| Señal | Problema probable | Primera acción |
|---|---|---|
| Baja proporción de tokens en caché | El prefijo compartido cambia con demasiada frecuencia | Estabiliza y versiona el contexto reutilizable |
| Los prompts se agrupan cerca de 200K | El historial o la recuperación no están acotados | Compacta, clasifica y reserva margen |
| La salida domina el gasto | Las respuestas son más largas de lo necesario | Reduce el límite y prueba la calidad de la respuesta |
| Alto costo por reintentos | La validación, los timeouts o los prompts son inestables | Corrige el modo de fallo en primera llamada |
| Bajo costo pero baja finalización de tareas | La optimización redujo la calidad útil | Mide el costo por resultado aceptado |
Where CometAPI Fits in the Grok 4.7 Cost Model
El papel de CometAPI en este flujo de trabajo es a nivel de plataforma de API: proporciona acceso a Grok 4.7, publica sus propias tarifas de tokens y documenta un punto de entrada compatible con OpenAI. No cambia las capacidades subyacentes del modelo Grok 4.7. Los equipos que ya usan un cliente al estilo OpenAI pueden mantener el mismo patrón de cliente mientras cambian la clave de API, la URL base y el ID del modelo, sujeto a la compatibilidad del endpoint.
Al 28 de septiembre de 2026, las tarifas listadas de Grok 4.7 en CometAPI están un 20% por debajo de las tarifas directas correspondientes de xAI tanto en el nivel estándar como en el nivel de contexto largo. Esta es una comparación de precios de plataforma, no una afirmación de calidad del modelo. Antes del despliegue en producción, los equipos también deben verificar el ID de modelo activo, los parámetros del endpoint, el comportamiento de la caché, los límites de tasa, la fiabilidad, el soporte y los términos de facturación.
Para probar el modelo, revisa los precios y detalles de acceso actuales en la página del modelo Grok 4.7 de CometAPI. Mantén la tabla de precios en la configuración, registra el uso real después de cada llamada y vuelve a ejecutar las estimaciones de carga de trabajo cuando cambie el modelo o el comportamiento del producto.
FAQ
¿Cuál es el precio por token de Grok 4.7 en CometAPI?
Para prompts por debajo de 200K tokens, CometAPI actualmente lista $1.60 por millón de tokens de entrada nueva, $0.40 por millón de tokens de entrada en caché y $4.80 por millón de tokens de salida. Las tarifas listadas para contexto largo son $3.20, $0.80 y $9.60 por millón de tokens respectivamente.
¿Cuánto cuesta una solicitud de API de Grok 4.7?
Depende de la entrada nueva, la entrada en caché, la salida y el nivel de contexto activo. Multiplica cada conteo de tokens por su tarifa por millón, suma los resultados y divide por un millón. Incluye también los reintentos y cada llamada al modelo en un flujo de trabajo de varios pasos.
¿Cuál es la forma más sencilla de reducir el costo de la API de Grok 4.7?
Comienza con el mayor impulsor de costos medido. Las instrucciones largas repetidas suelen beneficiarse de la caché; los historiales crecientes de agentes se benefician de la compactación; las respuestas verbosas se benefician de un límite de salida más bajo. Confirma que la calidad siga siendo aceptable después de cada cambio.
¿Una ventana de contexto de 500K significa que debo enviar 500K tokens?
No. La ventana de contexto es un límite de capacidad, no una recomendación. Tanto los precios directos de xAI como el listado actual de CometAPI usan tarifas más altas de contexto largo en el umbral de 200K tokens de prompt, por lo que las aplicaciones deben enviar solo el contexto necesario para la tarea.
¿Puedo estimar el costo antes de llamar a Grok 4.7?
Sí. Estima los tokens de entrada, elige el nivel de contexto correcto, agrega un límite de salida realista y calcula el límite superior. Después de la llamada, reemplaza la estimación con los datos de uso reales para informes y optimización.