Cargando
Cargando

Cuándo usar qué modelo

Los modelos de Claude difieren en capacidad, velocidad y costo, y no tienes que adivinar cuál se ajusta a tu tarea, porque puedes medirlo. Esta lección muestra cómo hacerlo, siguiendo a Meridian, una consultoría de ingeniería ficticia que usa una indicación para extraer tres campos de 50 informes de proyectos.

La demostración de este video se grabó en agosto de 2026. Se ejecutó en Claude Haiku 4.5, Claude Sonnet 5 y Claude Opus 5. Los resultados serán diferentes en modelos más nuevos. La demostración de cada lección es una ejecución de evaluación independiente, por lo que sus puntuaciones y costos no coincidirán con los de otras lecciones.

Cuando eliges un modelo de Claude para una tarea, probablemente lo hagas por instinto, o por recomendación de un colega. Los modelos de Claude realmente difieren en capacidad, velocidad y costo, pero ninguna comparación publicada ha visto jamás tu indicación específica, así que ninguna de ellas puede decirte cómo le irá a un modelo en tu tarea. La forma de elegir es medir con qué frecuencia cada modelo acierta en tu tarea, y solo entonces fijarte en lo que cuesta cada uno.

Es muy parecido a comprar una escalera para alcanzar la parte superior de una pared. Antes de mirar los precios, averiguas qué tan alta es la pared, porque una escalera demasiado corta es inútil a cualquier precio. Adivinar no te dirá qué escaleras alcanzan, así que las mides, y de las que alcanzan, compras la más barata. Una pared más alta necesita una escalera más larga, y esa es la correcta para comprar aunque cueste más.

Con los modelos, esa medición se hace mediante una evaluación (eval), que es un conjunto de casos que ejecutas en cada modelo. Cada caso es una entrada que verá tu indicación y la respuesta que esperas recibir, y una persona escribe esa respuesta a partir de la entrada antes de que se ejecute ningún modelo. Cada ejecución recibe luego una puntuación según cuántos casos acertó el modelo.

Esta lección sigue a Meridian. Cada mes recibe 50 informes de proyectos en Markdown, y una indicación extrae tres campos de cada uno: el ID del proyecto, el estado del cronograma y el riesgo principal. Sus casos son los 50 informes de un mes, y lo que todavía no sabe es qué modelo debería ejecutar esa indicación.

Meridian lo resuelve en cinco pasos, que puedes seguir con tu propia indicación:

  1. Decide qué tan precisa debe ser un modelo
  2. Puntúa cada modelo con los mismos casos
  3. Calcula cuánto cuesta una llamada
  4. Compara los modelos por lo que cuesta cada tarea completada
  5. Elige el modelo con la precisión que necesitas al menor costo

Decide qué tan precisa debe ser un modelo

Esto es la altura de la pared, y la defines antes de mirar lo que cuesta cualquier cosa. Tu umbral de precisión es la proporción de casos que un modelo debe acertar antes de que lo pongas en producción. Para fijar el umbral, calcula cuánto te cuesta una respuesta incorrecta, porque cuanto más cuesta, más alto debería ser tu umbral.

Para Meridian, una respuesta incorrecta significa que alguien tiene que revisar ese informe a mano, lo que toma unos 5 minutos. Sus ingenieros pueden absorber 5 de esas revisiones al mes, y como 5 de 50 es 10%, el umbral de Meridian es 90%.

Una tarea diferente puede elevar el umbral mucho más. Digamos que una respuesta incorrecta cuesta $1,000, quizás porque llegó a un cliente. Entonces el umbral sube a 100%, y lo que cuesta el modelo apenas importa.

Puntúa cada modelo con los mismos casos

Un umbral es solo un número hasta que mides los modelos contra él. Ejecuta cada modelo con los mismos casos y la misma indicación, de modo que el modelo sea lo único que cambie de una ejecución a otra. Meridian pasó sus 50 informes por una indicación en tres modelos: Claude Haiku 4.5, Claude Sonnet 5 y Claude Opus 5.

Un script de Meridian verifica cada campo contra la respuesta esperada. El ID del proyecto y el estado del cronograma deben coincidir exactamente, pero el riesgo principal es una oración, así que el script lo compara de manera más flexible y permite ligeras variaciones en la redacción. Cada caso es una tarea, que para Meridian significa un informe del que extraer tres campos. Un modelo completa la tarea solo cuando acierta en los tres campos.

De los 50 casos, 30 son informes típicos, 10 abarcan varios proyectos a la vez, y 10 no tienen sección de riesgo. La tabla desglosa la puntuación de cada modelo según esos tres tipos.

ModeloTípicoMultiproyectoRiesgo faltanteGeneral
Haiku 4.590%100%50%84%
Sonnet 5100%100%100%100%
Opus 5100%100%100%100%

Proporción de casos que cada modelo acertó, por tipo de informe, con la misma indicación y un umbral de 90%

Sonnet 5 y Opus 5 acertaron los 50. Haiku 4.5 acertó 42 de 50, que es 84%, así que en esta tarea y con esta indicación no supera el umbral.

Calcula cuánto cuesta una llamada

Ahora que dos modelos han superado el umbral, entra el costo. Se te factura por token, una parte del texto que los modelos procesan, y cada respuesta de la Messages API incluye un bloque usage que contiene el recuento exacto de tokens por el que se te factura. El ejemplo siguiente es una ilustración, una llamada a Sonnet 5 del tamaño aproximado de una de las de Meridian, con 780 tokens de entrada y 41 tokens de salida.

json
"usage": {
  "input_tokens": 780,
  "output_tokens": 41
}

Lee esos recuentos desde usage para cada modelo en lugar de estimarlos a partir de tu texto. El tokenizador de un modelo es la parte que divide el texto en tokens, y no todos los modelos usan el mismo. Así que el mismo texto puede dar lugar a un número diferente de tokens en distintos modelos. Sonnet 5 y Opus 5 usan un tokenizador más nuevo que produce aproximadamente un 30% más de tokens para el mismo texto, y Haiku 4.5 usa el anterior.

Los tokens de entrada y los tokens de salida tienen tarifas distintas, cada una indicada por millón de tokens. La tabla muestra las tarifas de los tres modelos tal como se listaban en agosto de 2026, que es cuando Meridian ejecutó la evaluación, y la página de precios de Claude tiene las tarifas que aplican hoy.

ModeloEntradaSalida
Haiku 4.5$1$5
Sonnet 5$2$10
Opus 5$5$25

Tarifa de cada modelo por millón de tokens de entrada y salida, tal como se listaban en agosto de 2026

El costo de una llamada es sus tokens de entrada multiplicados por la tarifa de entrada, más sus tokens de salida multiplicados por la tarifa de salida. El ejemplo es una llamada a Sonnet 5, así que usa las tarifas de Sonnet 5 de esa tabla.

text
780 input tokens  × $2 per million  = $0.0016
 41 output tokens × $10 per million = $0.0004
                              total = $0.0020

Compara los modelos por lo que cuesta cada tarea completada

Suma lo que cuesta cada llamada en una ejecución, y el total se llama el costo de ejecución. Divide el costo de ejecución entre el número de tareas que completó el modelo, y obtienes el costo por tarea completada, que es la cifra con la que comparas los modelos.

Divides entre tareas completadas, no entre llamadas. Eso es porque cada llamada se factura, incluso una que acierta de manera incorrecta la tarea. Así que las respuestas incorrectas de un modelo se suman al costo de cada tarea que ese mismo modelo sí completa.

ModeloCompletadasCosto de ejecuciónCosto por tarea completada
Haiku 4.542 de 50$0.0380$0.0009
Sonnet 550 de 50$0.0984$0.0020
Opus 550 de 50$0.2323$0.0046

Costo de ejecución y costo por tarea completada para los 50 casos, a las tarifas listadas en agosto de 2026

Elige el modelo con la precisión que necesitas al menor costo

Tu umbral determina qué modelos son candidatos, y de esos eliges el que tenga el costo por tarea completada más bajo. Sonnet 5 y Opus 5 acertaron ambos 50 de 50, a $0.0020 y $0.0046 por tarea completada, así que en esta tarea Meridian elige Sonnet 5. El $0.0009 de Haiku 4.5 es la cifra más baja de la tabla, pero no es un candidato, porque no supera el umbral.

En una tarea más difícil, el modelo más capaz podría ser el único que supere el umbral, y entonces es la elección correcta. Cada resultado también está ligado a la indicación y a los casos que usó la evaluación. Cambia la indicación o los casos, y el modelo correcto también puede cambiar, así que vuelve a ejecutar la evaluación cada vez que cambies uno de los dos.

Esta evaluación no mide la latencia. Si tus usuarios esperan las respuestas, mide el tiempo de las respuestas con tus propios casos, tal como las puntuaste aquí.

Reduce el costo de ejecutar la evaluación

Esos cinco pasos te dan un modelo, y hay una forma más de reducir lo que cuesta la evaluación en sí. Nadie espera las respuestas de una evaluación, así que puedes enviarla a través de la Batch API, que procesa las solicitudes de forma asíncrona. La Batch API ejecuta los mismos modelos a la mitad del precio en tokens de entrada y salida.

Cuando compares modelos, no mezcles las tarifas por lotes con las tarifas estándar en una misma comparación. Calcula el costo de cada modelo a tarifas por lotes, o el costo de cada modelo a tarifas estándar.

En resumen

  1. Fija primero tu umbral de precisión, a partir de lo que te costaría una respuesta incorrecta.
  2. Dale a cada modelo los mismos casos, y descarta cualquier modelo que no supere el umbral.
  3. Toma el costo de cada llamada de su bloque usage, y luego divide el costo de ejecución entre el número de tareas que completó el modelo.
  4. De los candidatos que superan el umbral, elige el que tenga el costo por tarea completada más bajo.