Grok 4.7 en Cursor y la API de xAI: cálculo de precios, modos de esfuerzo, modo Fast y caché de contexto

La integración de Grok 4.7 (identificador del modelo: grok-4.7) en Cursor ha despertado un gran interés entre los desarrolladores. La interfaz del editor incorporó nuevos controles: profundidad de razonamiento (reasoning_effort) y un selector para el modo Fast. Sin embargo, desde su lanzamiento, ha existido confusión en torno a estos ajustes: ¿cómo afectan al consumo del allowance de la suscripción y cuántas solicitudes se descuentan en las tareas de desarrollo habituales?

El principal error metodológico radica en intentar deducir las reglas de descuento de Cursor directamente a partir de las tarifas públicas de la API de xAI. Para tomar decisiones fundamentadas, es imprescindible distinguir entre dos niveles independientes: los precios oficiales de xAI (incluidos el almacenamiento en caché de contexto y el umbral de contexto largo) y las reglas internas de cuotas de Cursor, que solo pueden comprobarse mediante la observación directa en la cuenta.

---

Debate en la comunidad: incertidumbre con el allowance y ausencia de pruebas comparativas

El debate sobre el nuevo modelo comenzó el 23 de septiembre en la comunidad r/cursor tras una publicación del usuario IACROS, quien destacó la renovación del menú de selección de modelos.

En el hilo, el usuario diymuppet señaló la ambigüedad respecto a los costos de uso:

«…no hay una idea clara del costo en allowance… High / Extra High: ¿qué significa eso para mí en la práctica?»

El miembro de la comunidad abjectchain96 desaconsejó utilizar el modo Fast, suponiendo que implicaba un costo doble, y sugirió hacer coincidir los niveles de razonamiento con la complejidad de la tarea.

A pesar de parecer lógica, la discusión no presentó ninguna prueba comparativa controlada ni un registro verificado del saldo en Cursor. Los participantes compartieron suposiciones sin medir las deducciones reales de cuota. Llegar a conclusiones sobre cómo se consume el allowance basándose únicamente en especulaciones de foros resulta poco fiable: las normas de facturación están determinadas por las condiciones de suscripción de Cursor, no por estimaciones de la comunidad.

---

Precios oficiales de la API de xAI: contexto corto vs. largo

En la API pública de xAI, grok-4.7 cuenta con una ventana de contexto de 500.000 tokens y una fecha de corte de conocimiento de mayo de 2026. Las tarifas base están publicadas en la página oficial de precios de xAI.

Contexto estándar (< 200k tokens)

Para aquellas solicitudes en las que el tamaño total de entrada se mantiene por debajo de 200.000 tokens, aplican las tarifas estándar:

• Entrada no almacenada en caché (Uncached Input): $2.00 por 1M de tokens
• Entrada almacenada en caché (Cached Input): $0.50 por 1M de tokens
• Tokens de salida (incluido el razonamiento): $6.00 por 1M de tokens

Ejemplo de cálculo de una consulta de $0.27

Considere una solicitud aislada a la API con los siguientes parámetros:

• Entrada no en caché: 100.000 tokens (contexto base, instrucciones del sistema, código de la tarea)
• Entrada en caché: 20.000 tokens (historial inalterado de la sesión)
• Tokens de salida: 10.000 tokens (tokens de razonamiento más la respuesta generada)

Desglose paso a paso:

1. Entrada no en caché: $100,000 \times \frac{$2.00}{1,000,000} = $0.20$
2. Entrada en caché: $20,000 \times \frac{$0.50}{1,000,000} = $0.01$
3. Salida: $10,000 \times \frac{$6.00}{1,000,000} = $0.06$
4. Costo total de la consulta: $$0.20 + $0.01 + $0.06 = \mathbf{$0.27}$

Umbral de contexto largo (≥ 200k tokens)

La API de xAI emplea una tarificación escalonada: en cuanto la entrada total del prompt alcanza o supera los 200.000 tokens, las tarifas elevadas se aplican a todos los tokens de esa solicitud, y no solo al excedente marginal.

Tarifas para contexto ≥ 200k:

• Entrada no en caché: $4.00 por 1M de tokens
• Entrada en caché: $1.00 por 1M de tokens
• Tokens de salida: $12.00 por 1M de tokens

Ejemplo coherente para una solicitud ≥ 200k

Imaginemos una consulta en una base de código amplia donde el contexto total de entrada supera el umbral de 200k:

• Entrada no en caché: 180.000 tokens
• Entrada en caché: 40.000 tokens (entrada total: $180,000 + 40,000 = 220,000$ tokens ≥ 200k)
• Tokens de salida: 10.000 tokens

Cálculo:

1. Entrada no en caché: $180,000 \times \frac{$4.00}{1,000,000} = $0.72$
2. Entrada en caché: $40,000 \times \frac{$1.00}{1,000,000} = $0.04$
3. Salida: $10,000 \times \frac{$12.00}{1,000,000} = $0.12$
4. Costo total de la consulta: $$0.72 + $0.04 + $0.12 = \mathbf{$0.88}$

Este umbral se aplica estrictamente a las llamadas directas a la API de xAI. No es posible extrapolar el umbral de 200k a las deducciones internas de Cursor: Cursor gestiona las ventanas de contexto y los límites de los planes mediante sus propios mecanismos propietarios.

---

Modo Fast: posicionamiento y particularidades de precios

Con frecuencia se confunde el modo Fast con una destilación ligera del modelo. Según las especificaciones de xAI:

1. Arquitectura: se trata del modelo completo grok-4.7 alojado en infraestructura optimizada de alto rendimiento para minimizar la latencia de respuesta.
2. Disponibilidad: este modo está diseñado para integraciones asociadas (partners como Cursor y la plataforma Grok Build) y no se ofrece en los endpoints públicos habituales de xAI.
3. Precios para partners: xAI establece las tarifas de Fast para socios en $4.00 / $1.00 / $12.00 para contexto < 200k (exactamente el doble de la estándar) y en $6.00 / $1.50 / $18.00 para contexto ≥ 200k (un multiplicador de 1.5x respecto a las tarifas estándar de contexto largo).

Deducciones del modo Fast en Cursor

La estructura tarifaria para partners de xAI no implica que Cursor descuente exactamente dos solicitudes o duplique el consumo del allowance. El registro de facturación de Cursor opera según sus propias métricas de uso (fast requests y niveles de suscripción). Las deducciones reales dependen de las condiciones de su plan y únicamente pueden validarse mediante el seguimiento directo en la cuenta.

---

Gestión de Reasoning Effort y almacenamiento en caché de prompts

En Grok 4.7, el razonamiento está integrado de forma nativa en la arquitectura del modelo y no se puede desactivar. Los parámetros presencePenalty, frequencyPenalty y stop no son compatibles y generan errores en las solicitudes.

El parámetro reasoning_effort configura la profundidad del análisis:

• low: tiempo mínimo de deliberación y la menor latencia; ideal para ediciones sencillas y ejecuciones puntuales de herramientas.
• medium: equilibrio entre velocidad de generación y profundidad de síntesis de código.
• high (predeterminado): análisis arquitectónico exhaustivo, dependencias complejas y algoritmos.
• xhigh: máxima profundidad de búsqueda de soluciones, acompañada de un incremento notable en la latencia.

La cantidad exacta de tokens internos de razonamiento no está especificada en la documentación pública, y estos se facturan a la tarifa estándar de tokens de salida. No se debe asumir que high sea inútil para tareas directas ni que xhigh sea obligatorio para código complejo. El único referente fiable es evaluar la calidad del código, la latencia de respuesta y el gasto de allowance en su base de código específica.

Cómo funciona el Prompt Caching

El mecanismo de Prompt Caching permite reducir los costos al procesar contexto repetido e invariable:

• Enrutamiento y localidad: incluir el parámetro prompt_cache_key en la Responses API o la cabecera x-grok-conv-id en Chat Completions dirige las solicitudes a nodos con cachés activas (warm). Esto eleva la probabilidad de acierto de caché (cache hit), aunque no es un requisito estricto: omitir estas claves no garantiza que cada llamada posterior sea «fría» (cold).
• Naturaleza probabilística: no se garantiza una tasa de acierto del 100 % debido a posibles reinicios de nodos o desalojo de datos. El volumen real en caché reconocido por el modelo se devuelve en el campo usage.prompt_tokens_details.cached_tokens.
• Contexto multiturno: en sesiones multiturno, la Responses API devuelve un bloque cifrado reasoning.encrypted_content (o referencias a través de previous_response_id). Reenviarlo en llamadas consecutivas mantiene la continuidad del hilo de razonamiento dentro de la especificación admitida. Sin embargo, no conviene afirmar que en otros escenarios la caché vaya a descartarse obligatoriamente o que el contexto se pierda de forma irreversible.
• Invariabilidad del prefijo: editar mensajes previos de la conversación, modificar el prompt del sistema o reordenar fragmentos de contexto rompe el prefijo de la caché, reduciendo drásticamente la proporción de aciertos.

---

Protocolo de prueba comparativa por pares: cómo medir el allowance en Cursor

Dado que la reducción del allowance en Cursor no equivale de forma 1:1 a los montos en dólares de la API de xAI ni al umbral de 200k, la única forma de evaluar el costo real es llevar a cabo una prueba comparativa aislada entre dos tareas equivalentes.

1. Configuración inicial (Setup)

• Prepare dos tareas con un alcance y complejidad equivalentes dentro del mismo repositorio (por ejemplo, Tarea A y Tarea B: redacción de conjuntos de pruebas para módulos similares).
• Abra el panel de uso de su cuenta de Cursor (ajustes de Subscription / Usage).
• Registre las métricas de referencia utilizando el siguiente esquema:

Campo	Ejemplo de registro
Identificador de la tarea	Tarea A (Standard) / Tarea B (Fast)
Interfaz del editor	Chat / Composer
Modelo y modo	Grok 4.7 Standard / Grok 4.7 Fast
Nivel de reasoning_effort	medium (idéntico para ambas pruebas)
Saldo inicial de allowance	Registrado antes del lanzamiento
Tiempo de generación (latencia)	Tiempo transcurrido medido (s)
Saldo final de allowance	Registrado después de la respuesta
Delta de deducción real	Diferencia (unidades deducidas / solicitudes)
Calidad de la solución	Corrección del código, pruebas superadas

2. Ejecución (Execution)

1. Prueba 1 (Standard): inicie una sesión limpia, elija Grok 4.7 en modo estándar con esfuerzo medium. Envíe la Tarea A. Registre la duración de la generación y anote la deducción de allowance en el perfil de su cuenta.
2. Prueba 2 (Fast): abra una nueva sesión limpia con los mismos archivos de trabajo, elija Grok 4.7 Fast con esfuerzo medium. Envíe la Tarea B. Registre la latencia de ejecución y la nueva cifra de consumo de cuota.

3. Árbol de decisiones (Decision Path)

• Si la deducción de Fast coincide con la de Standard o la diferencia es insignificante, con una ganancia de velocidad perceptible: el modo Fast es idóneo para sesiones interactivas de chat y depuración rápida.
• Si la deducción de Fast es sustancialmente superior y el ahorro de latencia resulta secundario (por ejemplo, en generaciones en segundo plano con Composer): mantenga el modo estándar como su opción predeterminada.
• Si la calidad del código con medium resulta insuficiente: evalúe high sobre el mismo tipo de tarea, controlando el incremento de la latencia y el gasto de cuota. Reserve high para lógica intrincada.

4. Diagnóstico y resolución de incidencias (Troubleshooting)

• El allowance se consume más rápido de lo esperado:
  • Revise el desglose detallado de uso en el panel de control de su cuenta de Cursor.
  • Compruebe el contexto de la sesión activa: los hilos largos con decenas de archivos adjuntos incrementan el tamaño del prompt con independencia del modelo elegido.
  • Revise las normas vigentes de su plan en Cursor. Evite asumir que el umbral de 200k de la API de xAI determina la facturación del editor.
• Latencia de respuesta prolongada o bloqueos aparentes:
  • Reduzca reasoning_effort a medium o low.
  • Inicie una conversación nueva para evitar procesar un historial obsoleto y redundante.
• Errores de disponibilidad del modelo:
  • Verifique la configuración de proveedores y el estado de autenticación dentro de Cursor.
  • Si utiliza una clave de API personalizada, verifique los saldos de su cuenta y los permisos en la consola para desarrolladores de xAI.

---

Referencias

1. xAI Docs — Grok 4.7
2. xAI Docs — Reasoning
3. xAI Docs — Prompt Caching in Multi-turn
4. xAI Docs — Pricing
5. Reddit r/cursor — Discussion on Grok 4.7