Inicio / La API de Claude para quienes construyen

Elegir un modelo, cambiarlo, encajar un rechazo

La elección de un modelo es un compromiso entre calidad, velocidad y coste que se revisa en cada nueva generación, y un rechazo devuelto por un clasificador de seguridad se trata como un caso normal del protocolo, no como una averia.

Claude Sonnet 5 se factura al precio anunciado como temporal en el lanzamiento de este modelo. Ese precio debía subir en una fecha fijada de antemano, con un regreso a una tarifa estándar más alta. Esa subida no ha tenido lugar: la tarifa de lanzamiento se convirtió en la tarifa permanente, sin ninguna nueva fecha anunciada. Elegir un modelo es elegir un punto en tres ejes, la calidad de las respuestas, la velocidad y el coste por token, y ese punto se desplaza en cada nueva generación sin avisar.

Un identificador sin fecha ya es la referencia

Durante mucho tiempo, la práctica prudente consistía en fijar en producción un identificador con fecha, para no sufrir un cambio silencioso el día en que el identificador genérico apuntara a un modelo nuevo. A partir de la generación 4.6, esta precaución se aligera para los modelos afectados: cada identificador sin fecha de esta generación y de las siguientes ya designa una instantánea fija. Esta regla no es válida para los modelos anteriores a la generación 4.6, entre ellos claude-haiku-4-5, donde el identificador sin fecha sigue siendo un simple alias que apunta a una instantánea con fecha distinta. Entre los modelos actualmente activos, claude-fable-5-1 es el más reciente y el más capaz de la gama, claude-fable-5 sigue activo pero pasa al estatus de modelo histórico, y claude-opus-5, claude-sonnet-5 y claude-haiku-4-5 se cuentan entre los más empleados, sin agotar el inventario completo, mantenido al día en la página de depreciaciones de Anthropic. Un modelo más antiguo de la familia Opus ya ha dejado de responder en las plataformas operadas por Anthropic, la figura de cronología que sigue sitúa esa fecha. Comparar dos modelos antes de migrar sigue siendo un gesto útil, pero recae sobre la calidad y el coste, más que sobre el riesgo de que un identificador cambie a tus espaldas.

El rechazo, un caso normal del protocolo

Un clasificador de seguridad puede detener una respuesta antes de que termine. Este rechazo no se presenta como una avería: el servidor responde con un código HTTP 200, como para cualquier respuesta exitosa, y es el campo stop_reason el que lleva la información, con el valor refusal en lugar de end_turn. El campo stop_details que lo acompaña precisa una categoría abierta, por ejemplo cyber, bio, o extracción de razonamiento, y una explicación legible.

{
  "stop_reason": "refusal",
  "stop_details": {
    "category": "cyber",
    "explanation": "La solicitud corresponde a un uso excluido por la política."
  }
}

Un código que solo trata end_turn y max_tokens, dos valores vistos en la primera lección de este módulo, deja pasar un rechazo sin verlo. Existe un mecanismo de repliegue en el lado del servidor: se activa mediante una cabecera beta y un parámetro dedicado, y enruta automáticamente hacia otro modelo según la categoría del rechazo, sin que sea necesario mantener uno mismo una lista de modelos de reserva.

Revisar la elección en cada generación

La tarifa de Sonnet 5 vuelta permanente y la reclasificación de Fable 5 como modelo histórico desde la salida de un modelo más reciente muestran lo mismo desde dos ángulos distintos: la comparación entre modelos hecha unos meses antes ya no vale nada hoy. La lección sobre la caché y el procesamiento por lotes reduce el coste de un modelo ya elegido, esta se centra en la elección misma, que hay que rehacer en cada generación en lugar de fijarla de una vez por todas.