CursorBench: el Benchmark con Uso Real que Redefine la Comparativa de Modelos
Los benchmarks de coding con los que comparamos modelos de IA están rotos. SWE-bench Verified, el estándar de facto durante dos años, acumula problemas de contaminación, saturación y tests defectuosos. Cursor ha respondido con CursorBench, un benchmark interno construido a partir de telemetría real de sus desarrolladores. Los resultados separan modelos que SWE-bench ya no distingue, y revelan que la mejor estrategia en 2026 no es elegir un solo modelo, sino combinar varios.
CursorBench en 30 segundos
CursorBench es la suite de evaluación interna de Cursor que mide modelos de IA usando tareas extraídas de sesiones reales de desarrollo, no de repositorios públicos. Evalúa corrección, calidad de código, eficiencia e interacción del agente. Su versión actual, CursorBench-3, genera tareas más largas y complejas que SWE-bench Verified, con menor riesgo de contaminación por datos de entrenamiento. Para los desarrolladores, esto significa que las puntuaciones de CursorBench reflejan mejor la experiencia real al usar un modelo en el IDE que cualquier benchmark público disponible.
Por qué SWE-bench ya no sirve para elegir modelo
SWE-bench Verified fue el referente desde agosto de 2024, pero a marzo de 2026 tiene tres problemas graves que lo invalidan como herramienta de decisión.
Saturación. Los modelos frontier se agrupan en torno al 80%. Claude Opus 4.6 marca 80,8%, GPT-5.4 ronda el 77-80%. Cuando cinco modelos puntúan dentro de un rango de 3 puntos, el benchmark deja de diferenciar. OpenAI dejó de reportar resultados en SWE-bench Verified por esta razón.
Contaminación. Los repositorios de SWE-bench son públicos y están ampliamente distribuidos. OpenAI encontró que todos los modelos frontier pueden reproducir los gold patches o los enunciados originales del benchmark con mínimo prompting, solo a partir del Task ID. Esto sugiere memorización, no capacidad real de resolución.
Tests defectuosos. En el 60,83% de las instancias resueltas, la solución estaba implícita en los comentarios del issue. En el 47,93%, los cambios del modelo son incorrectos o incompletos, pero pasan los tests porque estos son demasiado débiles. OpenAI analizó 138 problemas restantes y encontró que más del 60% eran irresolubles por fallos en los propios tests.
En la guía comparativa entre Claude Code, Cursor y Copilot ya mencionábamos que los benchmarks sintéticos no capturan la experiencia real. CursorBench es la primera respuesta seria a ese problema.
¿Qué es CursorBench y cómo funciona?
CursorBench es una suite de evaluación que Cursor construye a partir de sesiones reales de sus propios ingenieros. No usa repositorios públicos ni issues de GitHub. Las tareas vienen del uso diario del IDE, lo que las hace representativas de cómo un desarrollador interactúa con un agente de código.
La metodología se apoya en tres pilares:
- Cursor Blame: una extensión de git blame que traza código commiteado hasta la petición al agente que lo generó. Esto crea pares naturales de consulta + solución verificada, con ground truth real.
- Tareas cortas e infra-especificadas: las descripciones de CursorBench son intencionalmente breves, imitando cómo los desarrolladores hablan con sus agentes ("arregla el bug del login", no un issue de 500 palabras). Esto exige que el modelo entienda contexto implícito.
- Rotación periódica: la suite se renueva cada pocos meses para evitar que los modelos se optimicen contra tareas específicas.
CursorBench-3: el estado actual
La versión 3 duplica el alcance de las versiones anteriores tanto en líneas de código como en número de ficheros por tarea. Las tareas incluyen monorepos, investigación de logs de producción y experimentos de larga duración. Son significativamente más largas que las de SWE-bench Verified, Pro o Multilingual.
CursorBench vs SWE-bench: comparativa directa
| Dimensión | CursorBench-3 | SWE-bench Verified |
|---|---|---|
| Origen de tareas | Sesiones reales de Cursor | Issues públicos de GitHub |
| Longitud de descripción | Corta, infra-especificada | Larga, detallada |
| Líneas de código por tarea | Sustancialmente mayor | Menor |
| Riesgo de contaminación | Bajo (código interno) | Alto (repos públicos) |
| Separación entre modelos frontier | Alta | Saturada (~80%) |
| Evaluación | Correctores agentic + métricas online | Tests unitarios del repo |
| Actualización | Cada pocos meses | Estática desde su creación |
El punto clave es la separación. Donde SWE-bench pone a modelos como Haiku 4.5 al nivel de GPT-5 (lo cual contradice la experiencia real), CursorBench distingue modelos que los desarrolladores perciben como diferentes.
Qué modelos se han evaluado y qué revelan los resultados
Cursor no publica puntuaciones numéricas individuales. En su lugar, presenta gráficos de dispersión que cruzan corrección con tokens de completado (coste/latencia). Esto expone un trade-off que los benchmarks tradicionales ignoran: un modelo puede ser preciso pero lento, o rápido pero impreciso.
Los modelos evaluados se agrupan en categorías:
- Best Open: Qwen Coder, GLM 4.6
- Fast Frontier: Haiku 4.5, Gemini Flash 2.5
- Frontier 7/2025: el mejor modelo disponible a julio de 2025
- Best Frontier: GPT-5 y Claude Sonnet 4.5, que superan al resto
Composer: el modelo propio de Cursor
Cursor lanzó Composer (octubre 2025), un modelo MoE entrenado con reinforcement learning sobre tareas reales de ingeniería de software. Genera código a velocidades 4 veces superiores a modelos frontier comparables. En CursorBench, se sitúa entre la categoría "Frontier 7/2025" y "Best Frontier": GPT-5 y Sonnet 4.5 lo superan en corrección pura, pero Composer compensa con velocidad.
Composer 1.5 (febrero 2026) escala el RL 20 veces más, introduce capacidad de "thinking" adaptativo (más razonamiento en problemas difíciles, menos en fáciles) y auto-resumen para mantener precisión cuando el contexto se agota. Es un modelo pensante que prioriza el equilibrio velocidad/inteligencia para uso diario.
El flujo dual: por qué los mejores desarrolladores usan dos modelos
CursorBench confirma algo que la comunidad ya intuyó: no existe un modelo que domine en todas las dimensiones. Esto ha dado lugar a un patrón emergente en 2026, el flujo dual Claude + Codex.
El patrón funciona así:
- Claude Code (Opus 4.6) planifica la arquitectura y genera la implementación inicial.
- Codex (GPT-5.4) revisa el diff, detecta edge cases y propone simplificaciones.
- Se itera 2-3 rondas de revisión cruzada antes de mergear.
Los datos de desarrolladores que usan este flujo muestran patrones consistentes. Opus destaca en análisis de gaps (detecta inconsistencias arquitectónicas y errores en el manejo de errores). GPT-5.4 destaca en simplificación (identifica sobre-ingeniería y propone enfoques más directos). En una comparativa reciente de alternativas a Cursor, exploramos cómo cada herramienta encaja en estos flujos.
Hay desarrolladores que reportan sesiones de ejecución continua de 46+ minutos con Codex sin pérdida de contexto, mientras que Claude Code orquesta hasta 5-6 agentes en paralelo con consistencia en sesiones largas. Son fortalezas complementarias, no competitivas.
Aplicación práctica: cómo elegir modelo según la tarea
Si CursorBench nos enseña algo, es que la pregunta "¿cuál es el mejor modelo?" está mal planteada. La pregunta correcta es "¿cuál es el mejor modelo para esta tarea?".
| Tipo de tarea | Modelo recomendado | Por qué |
|---|---|---|
| Planificación y arquitectura | Claude Opus 4.6 | Razonamiento profundo, análisis de gaps |
| Revisión de código y edge cases | Codex / GPT-5.4 | Precisión en patrones, detección de bugs lógicos |
| Edición rápida en el IDE | Composer 1.5 | 4x más rápido que frontier, pensamiento adaptativo |
| Monorepo grande (+50K líneas) | Codex (1M tokens contexto) | Ventana de contexto completa sin truncamiento |
| Orquestación multi-agente | Claude Code | Spawn de subagentes, revisión interactiva |
En entornos donde configurar reglas de Cursor para el codebase es parte del flujo, CursorBench ayuda a validar que el modelo elegido se comporta bien con las restricciones específicas de tu proyecto.
En Producción
CursorBench aporta valor como herramienta de decisión, pero hay consideraciones que el benchmark no cubre y que aparecen al trabajar con estos modelos día a día.
Coste real. El gráfico de CursorBench cruza corrección con tokens consumidos, pero no incluye precio por token. La diferencia importa: benchmarks independientes muestran que Claude Code usa 5,5 veces menos tokens que Cursor para tareas idénticas. A escala, esto pesa más que unos puntos de corrección.
Contexto efectivo. Cursor reporta 200K de contexto con Opus 4.6 (1M en beta), pero tests independientes muestran que el contexto útil en Cursor IDE cae a 70K-120K tras el truncamiento interno. CursorBench usa tareas que se resuelven en una sola sesión, así que no captura esta degradación.
Resiliencia operativa. Depender de un solo proveedor es un riesgo real. El 11 de marzo de 2026, Claude Code tuvo una caída y los desarrolladores con Codex configurado como backup pudieron continuar sin interrupciones. Esto refuerza la estrategia dual, no como optimización de rendimiento, sino como redundancia operativa.
Limitaciones del benchmark. CursorBench es un benchmark cerrado. No se publican puntuaciones individuales ni se permite la reproducción externa. Esto genera confianza en los resultados internos de Cursor, pero impide verificación independiente. También existe un conflicto de interés inherente: Cursor evalúa modelos de terceros con su propio benchmark mientras vende un modelo propio (Composer).
Errores comunes al interpretar benchmarks de coding
Error: asumir que mayor puntuación en SWE-bench significa mejor modelo.
Causa: contaminación de datos y tests defectuosos inflan puntuaciones artificialmente.
Solución: complementa con benchmarks de uso real (CursorBench, Terminal-Bench 2.0) y prueba los modelos en tu propio codebase.
Error: elegir un solo modelo para todas las tareas.
Causa: los benchmarks evalúan dimensiones aisladas, pero el desarrollo real combina planificación, edición, revisión y debugging.
Solución: adopta el flujo dual. Usa Claude para planificar/generar y Codex para revisar/simplificar.
Error: ignorar el coste de tokens al comparar modelos.
Causa: los benchmarks miden corrección pero no eficiencia económica.
Solución: ten en cuenta los tokens de completado. Un modelo que necesita 3x más tokens para el mismo resultado cuesta 3x más en API.
Preguntas frecuentes
¿CursorBench es público y puedo evaluar mis propios modelos?
No. CursorBench es una suite interna de Cursor. No publican las tareas, el código de evaluación ni puntuaciones numéricas individuales. Los resultados están disponibles solo en formato gráfico en su blog. Si necesitas un benchmark abierto con propiedades similares (resistencia a contaminación, tareas realistas), SWE-bench Pro de Scale AI es la alternativa más cercana.
¿Composer de Cursor reemplaza a Claude o GPT-5 para coding?
No, al menos no todavía. GPT-5 y Claude Sonnet 4.5 superan a Composer en corrección pura según el propio CursorBench. Composer compite en velocidad (4x más rápido) y en coste-eficiencia para tareas de complejidad media. Para tareas complejas de arquitectura, los modelos frontier siguen siendo superiores.
¿Merece la pena pagar por dos herramientas de AI coding en paralelo?
Depende del volumen de trabajo. Con Cursor Pro a 20 €/mes y Claude Code a partir de 20 €/mes (hasta 100-200 €/mes en planes Max), la inversión ronda los 40-220 €/mes. Si el flujo dual te ahorra una hora diaria de revisión manual, la inversión se justifica. La redundancia operativa es un bonus, no el argumento principal.
Hacia dónde va la evaluación de modelos de coding
CursorBench marca una dirección clara: los benchmarks estáticos basados en repos públicos están agotados. La evaluación útil viene de datos de uso real, tareas que rotan, y métricas que incluyen el coste junto a la corrección. Cursor planea adaptar CursorBench para agentes de larga duración que trabajan de forma autónoma durante horas, lo que requerirá nuevos métodos de evaluación y reproducibilidad.
Lo que no cambia es la conclusión práctica: ningún modelo gana en todo. La estrategia que mejor funciona en 2026 es combinar modelos según la fase del desarrollo, como ya vimos al analizar los flujos de trabajo con Copilot Agent Mode y con la orquestación multi-CLI entre Claude, Codex y Gemini. CursorBench no te dice cuál es el mejor modelo. Te da datos para que elijas el mejor modelo para cada tarea. Y eso, en la práctica, es mucho más útil.
¿Ya has probado el flujo dual Claude + Codex en tu día a día? Cuéntame cómo te va en Twitter @sergiomarquezp_.