Cursor metió su agente en GitHub Actions y desde el 12 de octubre cada run de CI quema tokens a precio de lista, no contra tu cupo del plan. Tu pipeline dejó de ser infraestructura y se volvió una factura abierta que nadie firma.
La movida es elegante desde el marketing: «agente headless en tu CI», reviews automáticos, PRs que se arreglan solos. Desde la trinchera suena distinto. La propia documentación de Cursor admite que el uso del CLI se cobra por tokens a las tarifas publicadas del modelo elegido. Y en la reestructuración de planes del 12 de octubre, los modelos de terceros salieron del cupo y se pagan a precio de API desde la primera petición.
Traducción para el que opera: cada reintento fallido de un workflow, cada review que se dispara dos veces porque el PR se actualizó, cada job que lee un repo entero para escribir tres líneas, es una línea de factura. Y nadie la aprueba. Simplemente aparece a fin de mes.
Qué pasó con Cursor CLI GitHub Actions
Cursor convirtió su CLI en un agente ejecutable dentro de GitHub Actions. Se instala, se le pasa una API key como secreto de repo u organización, y el agente corre sin humano delante: edita archivos, comenta en el PR, hace commits si le dejas. La integración es real y funciona.
El detalle está en cómo se cobra. Composer 2.5 en modo estándar cuesta $0.50 por millón de tokens de entrada y $2.50 por millón de salida. El tier rápido, que viene por defecto, sube a $3.00 y $15.00 por millón. Eso es 6x en entrada y 6x en salida solo por no cambiar un flag.
Con esa aritmética, un job de documentación que lee 200.000 tokens y escribe 20.000 cuesta alrededor de $0.15 en modo estándar. Barato. Pero ese mismo job en tier rápido se va a casi un dólar, y si lo multiplicas por 40 PRs al mes, por tres workflows, por los reintentos, la conversación cambia. Ojo: son cálculos sobre tarifas publicadas, no mediciones auditadas. Aun así, la dirección del número no se discute.
Qué significa para tu operación
El problema no es el precio unitario. El problema es que el consumo ocurre en un lugar donde nadie está mirando. Un humano en el IDE ve que el agente lleva diez minutos dando vueltas y lo corta. Un agente en CI no tiene ese freno: corre hasta terminar, hasta el timeout, o hasta que el workflow se cae.
Y hay un agravante de arquitectura. La API key se guarda como secreto de organización con gh secret set CURSOR_API_KEY --org ORG --visibility all. Una sola clave, visibilidad total, todos los repositorios. Si esa clave se filtra o si un workflow mal configurado entra en bucle, la factura no es de un proyecto: es de la empresa completa.
El segundo agravante es el mix de modelos. En Cursor, los modelos de terceros —Claude, GPT, Gemini— quedan fuera del cupo del plan y se facturan a precio de lista de API desde la primera petición. Incluso en el tier Ultra de $200 al mes. Si tu equipo usa el CLI para reviews con un modelo flagship porque «es el que mejor razona», estás pagando tarifa completa por cada PR, sin red.
Ahí está la ironía del modelo híbrido: te venden suscripción y te cobran API. La defensa de Cursor es razonable en el papel —facturar por tokens es más honesto que un cupo opaco— pero honesto no significa predecible. Y para un operador, predecible vale más que honesto.
La comparación con Claude Code y GitHub Copilot se vuelve obligatoria. Claude Code mantiene el uso dentro de planes planos con límites de 5 horas y semanales. Copilot arranca en $10 al mes. Si tu volumen de tokens cabe en un plan plano con techo conocido, la factura variable del CLI puede ser peor economía que una suscripción. No siempre. Pero es una cuenta que tienes que hacer con tus números, no con los del blog de turno.
Qué hacer al respecto
1. Instrumenta el coste por run antes de escalar. Loguea tokens de entrada y salida por job desde la página de usage y calcula el coste medio por PR. Sin esa métrica no estás presupuestando, estás adivinando. Y adivinar con dinero ajeno se paga caro.
2. Pon topes duros en el workflow. Límite de runs por PR, timeout explícito, paths restringidos y --mode=ask para reviews de solo lectura. El bucle descontrolado es el riesgo real, no el precio unitario. Un agente que solo lee no puede romper nada ni gastar tres veces lo previsto.
3. Usa claves API separadas por proyecto y rótalas. Una clave de organización con visibilidad all convierte un secreto filtrado en una factura de toda la empresa. Separa por repo, separa por entorno, y ten un procedimiento de rotación que no dependa de que alguien se acuerde.
4. Reevalúa el mix de modelos. Si tu carga es alto volumen y bajo razonamiento —formatear, renombrar, generar docs, clasificar— un modelo barato en modo estándar puede bajar el coste por run en un orden de magnitud frente al tier rápido por defecto. Revisa ese flag hoy: probablemente estás pagando 6x por inercia.
5. Adopta el patrón de autonomía restringida. Cursor mismo lo recomienda para CI en producción: el agente solo edita archivos, y el workflow hace branch, commit, push y comment. Menos superficie de daño, menos tokens quemados en operaciones de git que el runner ya sabe hacer gratis.
Si ya corres Cursor CLI en GitHub Actions, abre tu página de usage ahora y mira el gasto de la última semana. Si no sabes cuánto costó cada run, ese es exactamente el problema. Cuéntame en comentarios cuál es tu coste real por PR: los números de verdad valen más que cualquier benchmark de vendor.
Preguntas frecuentes
¿Cursor CLI en GitHub Actions se cobra contra mi plan o por tokens?
Por tokens, a las tarifas publicadas del modelo elegido. Desde la reestructuración del 12 de octubre, los modelos de terceros quedan fuera del cupo del plan y se facturan a precio de lista de API desde la primera petición, incluido el tier Ultra.
¿Cuánto cuesta un review automático típico?
Un job que lee 220.000 tokens y escribe 20.000 ronda los $0.15 en modo estándar con Composer 2.5. En tier rápido se va cerca de un dólar. Son cálculos sobre tarifas publicadas, no mediciones auditadas: verifica con tu propio volumen.
¿Cómo evito que un workflow descontrolado me vacíe la cuenta?
Timeout explícito, límite de runs por PR, --mode=ask para tareas de solo lectura, claves separadas por proyecto y un tope de gasto monitoreado. El coste unitario no te mata; el bucle sin freno sí.
¿Conviene más que Claude Code o Copilot?
Depende de tu volumen. Si tu uso cabe en un plan plano con límites de 5 horas y semanales, la suscripción suele ganar. Si necesitas agente headless dentro del CI con control fino, el CLI de Cursor es más flexible pero te traslada el riesgo de coste.