Límites de Cursor Ultra: pools, uso on-demand y tope de gasto
Guía práctica para desarrolladores independientes que usan Cursor de forma intensiva: distingue los dos pools mensuales del límite semanal de Grok Bot, valora el uso on-demand y controla el gasto adicional.
Índice

Pagas 200 dólares al mes por Cursor Ultra y, aun así, aparece un aviso de que estás cerca de un límite. El error más caro es tratar todos los porcentajes como si fueran una sola bolsa y cambiar de inmediato el gasto a No Limit. Primero identifica qué contador está subiendo, después decide si mantener el trabajo sin interrupciones justifica el coste adicional y, por último, fija un tope mensual que puedas asumir.
La idea clave: Ultra no tiene un único medidor de uso
A 27 de septiembre de 2026, Cursor indica que Pro, Pro Plus y Ultra incluyen dos pools de uso independientes, y que ambos se reinician con el ciclo mensual de facturación: Cursor Models y Other Models. Ultra figura a 200 dólares al mes e incluye los dos pools, pero la velocidad de consumo depende del modelo elegido.
- Cursor Models incluye actualmente Grok 4.7, Grok 4.6, Grok 4.5 y Composer 2.5. Cursor describe este pool como el que ofrece bastante más uso incluido.
- Other Models cubre los modelos de terceros que eliges de forma explícita; el consumo se calcula según el precio de API de cada modelo.
Por eso, decir «he gastado el 80 % de Ultra» no es un diagnóstico suficiente. Necesitas saber si se está agotando Cursor Models, Other Models o un límite semanal propio de alguna función.
Por ejemplo, una captura publicada por un usuario en X mostraba a la vez un 72 % de uso mensual de Cursor Models y un 90 % del límite semanal de Grok Bot. Son contadores distintos. Un aviso semanal de Grok Bot no demuestra por sí solo que se haya agotado alguno de los dos pools mensuales de Ultra.
Identifica el contador antes de cambiar el plan o la facturación
La comprobación más fiable consiste en relacionar el lugar donde aparece el aviso con el modelo seleccionado y las líneas de facturación, en vez de intentar adivinar cuántos tokens quedan.
| Señal que ves | Qué suele significar | Qué hacer después |
|---|---|---|
| Sube el porcentaje de Cursor Models | Grok o Composer está consumiendo el pool Cursor Models | Comprueba si Other Models conserva margen y si otro modelo encaja con la tarea |
| Sube el porcentaje de Other Models | Un modelo de terceros consume uso según su tarifa de API | Revisa modelos caros, contextos largos o trabajo frecuente con Agent |
| Grok Bot muestra un aviso semanal | La cuota semanal de esa función se acerca al reinicio | Espera al reinicio o reduce ese uso; no lo interpretes como agotamiento mensual de Ultra |
| Included Usage y On-Demand Usage aparecen por separado | El uso incluido y el uso adicional medido se contabilizan en líneas distintas | Confirma si on-demand está activado y si existe un tope de gasto |
Un diagnóstico verificable en tres minutos
- Abre los ajustes del editor o el usage dashboard de Cursor y anota los porcentajes de Cursor Models y Other Models, además de la fecha de reinicio mensual. Cursor afirma que ambos pools se muestran en esos lugares.
- Vuelve a la última tarea intensiva y confirma qué modelo seleccionaste realmente. Los modelos consumen valor incluido a ritmos distintos, así que el número de solicitudes no basta para estimar el coste.
- En Billing & Invoices, compara Included Usage con On-Demand Usage. Si la segunda línea ya muestra una cantidad, estás generando cargos fuera del uso incluido en la suscripción.
- Entra en Spending y comprueba si on-demand está activo, cuál es el límite mensual y si aparece No Limit.
- Ejecuta una tarea pequeña y acotada, como refactorizar un solo archivo, y vuelve a mirar qué pool o línea de facturación cambió.
Si el aviso emergente es ambiguo, da prioridad a los dos pools y a las líneas de facturación de tu propio dashboard. Una captura, una respuesta en un chat o un único banner no sustituyen los datos en tiempo real de tu cuenta.
Cuándo tiene sentido activar el uso on-demand
On-demand compensa cuando el valor de evitar una interrupción supera el importe adicional que estás dispuesto a pagar. La documentación de Cursor sobre cargos basados en el uso indica que los usuarios individuales deben activar on-demand de forma explícita; las solicitudes que superan el uso incluido se facturan a tarifas de API y aparecen separadas de la suscripción.
Suele ser una opción razonable cuando se cumplen estas tres condiciones:
- Hay una entrega, corrección o migración con una fecha límite clara y el coste del retraso se puede estimar.
- El trabajo restante está acotado, por ejemplo dos revisiones de código o un módulo definido, no un bucle de Agent sin final.
- Vas a revisar el consumo después de cada tarea pesada y puedes detenerte al alcanzar el presupuesto.
Conviene mantenerlo desactivado por ahora si ocurre algo de lo siguiente:
- Aún no sabes qué pool está creciendo.
- Ejecutas varios Agents, automatizaciones o tareas de contexto largo en paralelo y el gasto es difícil de prever.
- Tienes un presupuesto personal rígido o puedes aplazar el trabajo hasta el siguiente ciclo.
- El otro pool incluido conserva margen y contiene un modelo adecuado para la tarea.
Activar on-demand no recupera un uso «ilimitado» de los modelos. Autoriza a continuar con facturación medida después del uso incluido. Resuelve la continuidad, pero no controla el coste por sí solo.
Cómo elegir un tope de gasto sin adivinar
El tope más seguro no es una supuesta recomendación de la plataforma, sino el máximo adicional que aceptas pagar durante el ciclo actual. Después de habilitar on-demand, puedes configurar un límite mensual individual en Spending. La documentación de Cursor sobre límites de gasto deja claro que elegir No Limit elimina ese límite.
Utiliza este método para fijar el primer tope:
- Cuenta las sesiones de desarrollo intensivo que aún esperas durante el ciclo, no solo los días del calendario.
- Decide el importe adicional total que puedes asumir.
- Divide ese importe entre las sesiones intensivas restantes para obtener un umbral de revisión.
- Configura en Cursor el tope mensual total y compara el consumo real con tu umbral después de cada sesión.
Por ejemplo, si puedes aceptar como máximo 40 dólares adicionales y esperas diez sesiones intensivas de Agent antes del reinicio, usa 4 dólares por sesión como señal de revisión manual. No es un límite de Cursor por sesión ni una garantía de precio; sirve para detectar pronto una tarea anormalmente cara.
Hay dos detalles importantes sobre la aplicación del límite
Primero, el cambio de límite entra en vigor de inmediato, pero la aplicación no es instantánea. Cursor explica que el uso puede superar brevemente el tope antes de que el sistema lo reconozca. Ese exceso limitado previo a la aplicación se registra como un crédito temporal de límite de gasto, y la facturación queda limitada al tope vigente.
Segundo, si aumentas el límite durante el mismo ciclo, Cursor puede facturar una parte o todo ese importe previamente acreditado, hasta el nuevo límite. Para conservar el crédito, deja el límite sin cambios o desactiva on-demand.
Para un desarrollador independiente, un tope finito suele ser más seguro que No Limit. Elimina el límite solo si aceptas conscientemente un gasto adicional sin ese freno durante el resto del ciclo y vas a vigilar activamente la factura.
¿Seguir pagando o cambiar el flujo de trabajo?
La decisión depende de qué pool esté bajando, de la urgencia y de si el patrón es puntual o se repite cada mes.
| Situación actual | Acción prioritaria | Motivo |
|---|---|---|
| Cursor Models casi agotado y Other Models con margen | Pasa solo las tareas difíciles adecuadas a un modelo de terceros y mantén la rutina en Cursor Models | Aprovechas el segundo pool, pero cada modelo de terceros consume según su propia tarifa de API |
| Other Models casi agotado y Cursor Models con margen | Mueve a Grok o Composer la programación rutinaria, las reescrituras y la exploración | Usas el pool incluido restante y reservas el modelo caro para lo que realmente lo necesita |
| Ambos pools cerca del límite y queda una única entrega urgente | Activa on-demand con un tope mensual finito | El valor de continuar está claro y el riesgo económico tiene un límite |
| Ambos pools se agotan pronto cada mes y usas Agents paralelos o automatización | Reduce concurrencia, acorta contexto y procesa tareas por lotes durante un ciclo | Un problema recurrente del flujo no suele resolverse con un aumento puntual del tope |
| La mayor parte del trabajo son completados, cambios mecánicos o ediciones locales | Prioriza Tab y tareas de menor alcance | Ultra incluye unlimited Tab completions, por lo que puedes reservar Agent para decisiones difíciles |
La misma página de Cursor ofrece una orientación general: los usuarios diarios de Tab suelen permanecer dentro del uso incluido; quienes usan Agent de forma limitada, a menudo también; los usuarios diarios de Agent suelen generar entre 60 y 100 dólares mensuales de uso total; y los usuarios intensivos con varios Agents o automatización suelen alcanzar 200 dólares o más. Son categorías amplias, no una predicción de tu factura. El coste real de on-demand depende del modelo, los tokens, la longitud del contexto y la forma de trabajar.
Decide por el valor de la tarea, no por los 200 dólares ya pagados
La suscripción Ultra es un coste ya incurrido y no debería ser el único motivo para añadir cargos medidos. Antes de una tarea intensiva, responde a tres preguntas:
- ¿Cuánto tiempo manual o coste de retraso evita terminar ahora?
- ¿Puede hacer el trabajo un modelo del otro pool incluido sin una pérdida de calidad inaceptable?
- Si otro intento de pago tampoco termina la tarea, ¿en qué importe me detendré?
Cuando las tres respuestas son concretas, on-demand con tope puede ser más racional que una interrupción brusca. Si no puedes responder a la tercera, es más seguro cambiar primero el flujo de trabajo.
Un orden de actuación que puedes aplicar hoy
Sigue esta secuencia para no empezar a pagar antes de diagnosticar:
- Identifica el origen del aviso: Cursor Models, Other Models, Grok Bot o la página de facturación.
- Registra ambos pools mensuales: guarda los porcentajes y la fecha de reinicio, sin reducirlos a una impresión global.
- Relaciona modelos y tareas: localiza los modelos seleccionados, Agents paralelos y contextos largos de los trabajos recientes más pesados.
- Comprueba las categorías de factura: confirma si Included Usage y On-Demand Usage ya crecen por separado.
- Define el presupuesto antes de activar: decide el máximo adicional del ciclo y habilita on-demand con un tope finito.
- Haz una prueba acotada: completa una tarea con límites claros y vuelve a revisar pools y facturación.
- Amplía solo después de revisar: aumenta el tamaño de las tareas o el tope únicamente si el resultado y el consumo son aceptables.
El éxito no consiste solo en hacer desaparecer el aviso. Consiste en poder explicar qué pool se consume, por qué crecen los cargos adicionales y cuál es el importe exacto en el que debes detenerte.
Preguntas frecuentes sobre los límites de Cursor Ultra
¿Un 90 % en Grok Bot significa que Ultra está casi agotado?
No necesariamente. La cuota semanal de Grok Bot y los pools mensuales Cursor Models y Other Models son contadores distintos. Comprueba ambos pools en el usage dashboard antes de concluir que se está acabando el uso incluido de Ultra.
¿No Limit convierte Cursor en ilimitado?
No. No Limit solo elimina el tope mensual del gasto on-demand. Las solicitudes que superan el uso incluido siguen siendo facturables. Que Ultra incluya unlimited Tab completions tampoco hace gratuitas y sin límite todas las solicitudes de Agent o de modelos.
¿Puede seguir creciendo el uso después de alcanzar el tope?
Cursor indica que la aplicación no es instantánea, por lo que puede existir un exceso breve. Ese exceso limitado se trata como crédito temporal y se factura hasta el límite actual. Si elevas el límite en el mismo ciclo, una parte o todo el crédito puede convertirse en uso facturable, hasta el nuevo tope.
¿Puedo calcular cuánto trabajo queda solo con el porcentaje usado?
No de forma fiable. Influyen la tarifa de API del modelo, la longitud de entrada y salida y la concurrencia. Una tarea pequeña y acotada, seguida de una comprobación del dashboard, ofrece una referencia más útil.
La regla que conviene recordar
Comprueba el pool antes de activar el uso medido y fija el presupuesto antes de elevar el límite. Para un desarrollador independiente con mucha carga, la opción más controlable suele ser un tope finito, asignar el trabajo valioso al pool adecuado y revisar el consumo tras cada tarea cara, no pasar de inmediato a No Limit.