Metodología

Cómo se producen las cifras de estas páginas y qué puede afirmar cada una.

Grados de confianza

Cada cupo lleva un grado. Describe la fuerza de nuestra evidencia, no el tamaño de la cifra.

official
Publicado por el proveedor. Requiere URL de origen y su propio texto.
measured
Medido por nosotros o por la comunidad. Requiere fuente citable y descripción del método.
estimated
Derivado de otras cifras conocidas. Requiere dejar por escrito el razonamiento.

Una cifra derivada toma el grado más débil de sus entradas. Esta comparativa solo muestra cifras official y measured; las estimated aparecen en el planificador, donde puedes ver y cambiar los supuestos.

Qué revela el proveedor

Distinto de la confianza y a menudo confundido con ella. El «5 veces más uso que Pro» de Anthropic es evidencia de grado official —sus propias palabras— de un plan cuyo cupo sigue sin ser un número.

published
Una cifra absoluta, o un «ilimitado» explícito.
relative
Solo una proporción respecto a otro plan, cuyo propio cupo puede no estar publicado.
undisclosed
Ninguna cifra.

Un cupo no publicado no es un hueco en nuestra investigación. Callar la cifra es lo que permite a un proveedor endurecer el cupo más adelante sin anunciar el cambio ni romper una promesa, así que lo marcamos como riesgo y no como celda vacía.

Niveles de capacidad

Los niveles etiquetan a los modelos cuyo proveedor publicó una puntuación comparable. Aparecen en las etiquetas de modelo y en ningún otro sitio: un nivel es un filtro grueso, nunca una puntuación ni un orden interno, y nada en este sitio filtra ni clasifica por él.

El nivel sale de una puntuación de Terminal-bench 2.1 publicada por un proveedor: frontier a partir de 80, strong entre 70 y 79,9, efficient por debajo de 70. Si no hay puntuación pero el proveedor afirma un orden inequívoco sobre su propio modelo, esa frase fija el nivel y se registra literalmente. Si no hay ninguna de las dos, el modelo queda sin nivel.

Sin nivel no significa flojo. Significa que nadie publicó una cifra comparable. Antes le costaba al modelo su lugar bajo un mínimo de capacidad; ese mínimo ya no existe, porque lo que rechazaba eran sobre todo proveedores que no publican ninguna referencia, no modelos que se quedaran cortos. Ahora cada cifra de valor indica sobre qué modelo se calculó.

Dos cosas que no usamos a propósito: puntuaciones de versiones distintas del mismo benchmark, que mueven un modelo un nivel entero solo por la versión; y los niveles de facturación de los distribuidores, que siguen tan de cerca al precio que ordenar valor-por-precio con ellos sería circular.

Cobertura actual: 9 de 19 modelos base tienen nivel.

ModelVendorTierEvidence
Claude Fable 5AnthropicfrontierNo Terminal-bench score published; Anthropic reports benchmarks as chart images. Tiered on Anthropic's own ordering: the Claude Opus 5 launch post (2026-07-24) describes Opus 5 as coming "close to the frontier intelligence of Claude Fable 5 at half the price", placing Fable 5 at the vendor's capability ceiling. https://www.anthropic.com/news/claude-opus-5
Claude Haiku 4.5Anthropicsin nivel
Claude Opus 4.6Anthropicsin nivel
Claude Opus 4.8Anthropicsin nivel
Claude Opus 5AnthropicfrontierNo Terminal-bench score published. Tiered on Anthropic's own claim in the launch post (2026-07-24): "on Frontier-Bench v0.1, Opus 5 surpasses all other models, and more than doubles Opus 4.8's performance at a lower cost per task", and "It's the new default model on Claude Max, and the strongest model on Claude Pro." https://www.anthropic.com/news/claude-opus-5
Claude Sonnet 4.6Anthropicsin nivel
Claude Sonnet 5AnthropicfrontierTerminal-bench 2.1 (Terminus-2 harness) 80.4%, as reported by Google in the Gemini Flash model table, retrieved 2026-07-27. At or above the 80.0 frontier threshold. https://deepmind.google/models/gemini/flash/
Composer 2.5Cursorsin nivel
Gemini 3.1 ProGooglestrongTerminal-bench 2.1 (Terminus-2 harness) 73.8%, published by Google in its own Gemini Flash model table, retrieved 2026-07-27. The same model scores 68.5% on Terminal-Bench 2.0 in Google's Gemini 3.1 Pro table — the two versions are three points apart on one model, which is why they are not mixed. https://deepmind.google/models/gemini/flash/
Gemini 3.5 FlashGooglestrongTerminal-bench 2.1 (Terminus-2 harness) 76.2%, published by Google in its own Gemini Flash model table, retrieved 2026-07-27. https://deepmind.google/models/gemini/flash/
Gemini 3.6 FlashGooglestrongTerminal-bench 2.1 (Terminus-2 harness) 78.0%, published by Google in its own Gemini Flash model table, retrieved 2026-07-27. Within the 70.0-79.9 strong band. https://deepmind.google/models/gemini/flash/
Gemini 3 FlashGooglesin nivel
GPT-5.3 CodexOpenAIsin nivel
GPT-5.5OpenAIfrontierTerminal-bench 2.1 83.4%, as reported by Anthropic in the Claude Opus 4.8 launch post's footnotes, retrieved 2026-07-27. Harness caveat recorded because it matters: the figure is OpenAI's self-reported score using the Codex CLI harness, not the Terminus-2 harness the other tiered figures use, so it is not strictly comparable with them. https://www.anthropic.com/news/claude-opus-4-8
GPT-5.6 LunaOpenAIfrontierTerminal-bench 2.1 (Terminus-2 harness) 84.7%, as reported by Google in the Gemini Flash model table, retrieved 2026-07-27 — the highest figure in that table. Note the tension worth keeping visible: OpenAI positions Luna as the lightweight, high-volume member of the GPT-5.6 family, while the benchmark places it above both flagships that have scores. https://deepmind.google/models/gemini/flash/
GPT-5.6 SolOpenAIsin nivel
GPT-5.6 TerraOpenAIsin nivel
Grok 4.5xAIfrontierTerminal-bench 2.1 (Terminus-2 harness) 83.3%, as reported by Google in the Gemini Flash model table, retrieved 2026-07-27. xAI's own docs publish no benchmark figures. https://deepmind.google/models/gemini/flash/
Grok Build 0.1xAIsin nivel

Supuestos

Convertir un cupo en dólares exige un modelo de cómo consume tokens una sesión de programación. Son supuestos editoriales, no mediciones, y se pueden ajustar en el planificador.

ParámetroValorBase
Tokens de entrada por turnoinputTokensPerTurn12,000Contexto medio de un turno de programación con agente, incluidas las lecturas de archivos
Tasa de acierto de cachécacheHitRatio0.7Tasa típica de acierto de caché de prompt en una sesión larga
Tokens de salida por turnooutputTokensPerTurn1,500Generación media por turno
Turnos por horaturnsPerHour20Ritmo de interacción mientras se programa activamente
Horas al díahoursPerDay6Horas que un desarrollador a tiempo completo dedica realmente a programar
Días al mesdaysPerMonth22Días laborables

Cómo se construye una cifra de valor

El valor equivalente en API de un plan sale de una sola asignación, calculada sobre un solo modelo. Tres pasos deciden cuál asignación y cuál modelo.

  1. 1Dentro de un modelo, las filas que lo rigen son restricciones. Una asignación general y una fila que nombra a ese modelo no son dos ofertas entre las que elegir: la segunda estrecha a la primera, así que el techo del modelo es la más estricta de las dos.
  2. 2Entre modelos, esas mismas filas son alternativas. Los modelos que comparten una ventana de cinco horas la gastan en el que tú elijas, así que el grupo vale la mejor opción que contenga. El modelo que gana es aquel sobre el que se calcula la cifra.
  3. 3Entre grupos, todas las filas obligan a la vez. Una ventana de cinco horas y un tope semanal se alcanzan ambos, así que el plan vale la más estricta.

Múltiplo de valor = esa cifra ÷ el precio mensual. Por encima de 1,00, la asignación compra más, a tarifas de API publicadas, de lo que cuesta la suscripción.

El modelo sobre el que se calculó la cifra aparece junto a ella y hay que leerlo con el múltiplo. Como entre modelos gana la mejor opción, un plan puede sostener todo su múltiplo con una asignación generosa de su modelo más barato: la cifra es correcta y describe un modelo que quizá nunca uses. Nombrarlo es la única garantía aquí. No filtramos modelos por capacidad: eso exigiría una cobertura de referencias que este catálogo no tiene, y la sección siguiente dice cuán poca hay.

Cuatro casos no dan cifra en lugar de dar una blanda: un plan que solo se cotiza bajo consulta; una asignación publicada que no podemos convertir a dólares en algún punto de la cadena; un plan gratuito, que no tiene precio por el que dividir; y asignaciones que no alcanzan a ninguno de los modelos que listamos.

Qué modelo para qué tipo de trabajo

El planificador asigna cada categoría de trabajo a un modelo. Es la evidencia más débil del sitio, y la cobertura de abajo es lo primero que conviene leer.

Cobertura

CategoríaBenchmarkModelos con puntuación
Arquitectura y diseñoninguno publicado0
Depuración difícilDeepSWE v1.16
Implementación de backendSWE-Bench Pro (Public)7
Interfaz de usuarioninguno publicado0
Refactorización y pruebasninguno publicado0
DevOps y scriptingTerminal-bench 2.1 (Terminus-2)6

Donde hay benchmark, el nivel de un modelo se fija en relación con la mejor puntuación publicada en esa misma categoría: preferido a partir del 92% de ella, apto a partir del 70%, no apto por debajo. Relativo y no absoluto porque estos benchmarks no son igual de difíciles: en uno el máximo ronda el 85% y en otro el 65%, y un corte fijo clasificaría al mismo modelo de forma distinta solo por la dificultad de la prueba.

Donde ningún benchmark cubre una categoría, el modelo hereda 'apto' de su nivel de capacidad y no lleva tasa de éxito. Puede asignarse igualmente, pero nunca ganará una comparación de coste en la que nunca se le midió, y el planificador marca esa fila como elegida por nivel.

Tres tipos de evidencia, de más a menos fuerte: benchmarks que un proveedor publica en su propia tabla comparativa; comportamiento agregado de rankings de terceros, que todavía no se usa porque hay que aclarar antes la licencia de redistribución de cada uno; y comentarios de los lectores de este sitio, que pueden generar una propuesta de cambio para revisión y nunca editan nada por sí solos.

Arquitectura y diseño no tiene un benchmark público maduro ni se espera que lo tenga, así que el planificador indica el nivel de capacidad que buscar y no nombra ningún modelo.

Del precio por token al coste por tarea

Un modelo más fuerte cuesta más por token y necesita menos intentos, así que 'más caro por token' y 'más barato por tarea' suelen ser ciertos del mismo modelo a la vez. El planificador compara el coste esperado de terminar una tarea: los tokens base de la categoría, ajustados al modelo, divididos por su tasa de resolución.

Tokens base por tarea

Arquitectura y diseño120,000
Depuración difícil180,000
Implementación de backend90,000
Interfaz de usuario70,000
Refactorización y pruebas45,000
DevOps y scripting35,000

Todos los resultados son rangos, obtenidos variando el consumo de tokens un ±30% y la tasa de resolución ±10 puntos porcentuales. Una cifra única construida sobre una línea base editorial multiplicada por una tasa de benchmark sería el número más seguro en apariencia de este sitio y el menos defendible.

Umbrales del feedback

Un desacuerdo sobre qué modelo conviene a una categoría se convierte en propuesta de cambio cuando 5 lectores han dicho lo mismo y suponen al menos el 70% de los votos sobre ese par. La propuesta pasa a una persona, que la contrasta con un benchmark publicado; el feedback nunca edita los datos por sí solo.

Los informes de haber alcanzado el límite se agrupan por plan, periodo e intensidad de uso, sin mezclar nunca intensidades: los usuarios intensivos se concentran en los planes grandes, y mezclarlos haría parecer que los planes caros se agotan antes, cuando eso solo refleja quién los compra. Se muestra un porcentaje únicamente cuando un grupo reúne al menos 20 informes. Por debajo, la celda lo indica.

Cómo se mantienen al día las cifras

Un vigilante relee las páginas de cada proveedor cada tres días y compara lo que encuentra con lo que tenemos. Nada se publica sin que una persona lo confirme contra la fuente. Cuando la página de un proveedor deja de poder leerse, eso se muestra en el plan en lugar de absorberse en silencio.

Última verificación: 2026-07-29

Todas las suscripciones