Coste de Real-SWE por issue resuelto

Actualizado September 27, 2026 · publicado originalmente September 27, 2026

Real-SWE se publicó el 12 de septiembre de 2026 y reunió 275 puntos y 158 comentarios en Hacker News. Su premisa es lo que la mayoría de los modelos de costes hace mal: las suites de benchmarks son públicas, están memorizadas y no representan el código que tus agentes tocan de verdad. Real-SWE ejecuta los modelos contra repositorios empresariales reales y privados.

Por qué el coste importa más que la puntuación

Un benchmark público te da una tasa de aciertos. No te da un coste. El coste por issue resuelto necesita tres cosas a la vez:

• Tasa de aciertos en las tareas difíciles y privadas.
• Tokens consumidos por intento, incluidos los fallos.
• Número de intentos — ¿necesitó el modelo un reintento, una revisión del plan, un bucle de comparar el diff y replantear?

Si los multiplicas, obtienes la única cifra que se corresponde con una partida contable. Un modelo que puntúa 4 puntos por debajo del líder, pero resuelve los issues en un intento y con un tercio de los tokens, sale más barato por issue resuelto, y en un backlog real esa diferencia se acumula más rápido de lo que sugiere la brecha de puntuación.

Por qué los benchmarks públicos exageran la calidad

Las bases de código empresariales tienen las propiedades que rompen los supuestos de los benchmarks públicos: convenciones internas largas, invariantes sin documentar, tests que codifican accidentes históricos y sistemas de build que nadie entiende del todo. Un modelo que reconoce patrones en un repositorio público no puede hacerlo en un monorepo de 400 archivos con tres años de decisiones acumuladas. Por eso un resultado muy comentado este mes fue el de un modelo de escritura creativa de 27B con pesos abiertos que rinde al nivel de Fable 5 con un precio, según se informa, 40x más barato — los pesos abiertos parten de un prior de repositorio local del que carecen los modelos de API.

Hacer el cálculo

Toma un repositorio backend real con 40 issues dentro del alcance. Supongamos que el modelo más barato resuelve 22 en un intento con 60K de entrada / 8K de salida, y el modelo premium resuelve 26 con un multiplicador de reintentos de 1.4x y 90K de entrada / 14K de salida. Con las tarifas de Opus 5.5 ($4/$20, lecturas de caché $0.20):

El premium cuesta 2.3x el total por un 18% más de issues resueltos. En un backlog de 40 issues son $9 más. El mismo intercambio con 4,000 issues al mes son $880 — y solo compra un 18% más de rendimiento. El nivel económico no es claramente un error; estás cambiando tasa de resolución por volumen, y la respuesta correcta depende de si un issue sin resolver cuesta más de un dólar.

Qué instrumentar

1. Coste por issue resuelto, no por intento. El denominador son los PR fusionados, no las solicitudes.
2. Multiplicador de reintentos por modelo. Un modelo a 1.4x es un tercio de su precio de lista antes de contar nada más.
3. Tokens por diff aceptado, incluidos los tokens de plan y autorrevisión que el diff nunca muestra.
4. Minutos de revisión humana. Un modelo un 12% más barato que tarda un 20% más en revisarse resulta más caro.

Conclusión

Los benchmarks públicos clasifican la capacidad en tareas que no se parecen a tu backlog. Real-SWE es un primer intento de la versión honesta. Hasta que lo ejecutes en tus propios repositorios, trata cada comparación de modelos como una hipótesis de coste por issue resuelto y valora esa hipótesis con tus propios recuentos de tokens.

Relacionado

• Coste real por tarea: modelos de frontera
• Coste por tarea exitosa
• Coste de programación agéntica intensiva: Claude frente a Qwen
• Control de costes de las evaluaciones
• Cómo valorar un modelo de pesos abiertos

¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita →

Volver a finopsllm.com