La API de Claude para desarrolladores

La API de Mensajes

La API de Mensajes es el punto de acceso HTTP principal que permite a cualquier programa comunicarse con Claude. En lugar de abrir una ventana de chat, su código envía una solicitud JSON estructurada y recibe una respuesta JSON estructurada. JSON (JavaScript Object Notation) es un formato de texto estándar para el intercambio de datos.

Cada solicitud debe incluir tres elementos: el identificador del modelo (qué versión de Claude usar), max_tokens (el número máximo de tokens, o fragmentos de palabras, que Claude puede generar en la respuesta), y un arreglo messages (el historial de la conversación como lista de pares rol/contenido).

El SDK de Anthropic (kit de desarrollo de software) oficial para Node.js envuelve esta llamada HTTP en una simple función JavaScript. Instálelo con npm y luego escriba unas pocas líneas:

• Defina su clave API como variable de entorno con el nombre ANTHROPIC_API_KEY.
• Cree un cliente: const Anthropic = require("@anthropic-ai/sdk"); const client = new Anthropic();
• Llame a client.messages.create({ ... }) con su modelo, max_tokens y mensajes.
• Lea la respuesta desde response.content[0].text.

Los identificadores de modelo para junio de 2026 son claude-opus-4-8 (el más capaz), claude-sonnet-4-6 (equilibrado) y claude-haiku-4-5 (el más rápido). Comience con Haiku mientras aprende: es económico e instantáneo.

System, user, assistant en la API

Cada llamada a la API de Claude se construye a partir de una secuencia de mensajes, cada uno etiquetado con un rol. Los tres roles son system, user y assistant. El rol system es un parámetro especial de nivel superior (no forma parte del array de mensajes) que establece instrucciones persistentes para toda la conversación. Piense en él como el briefing que le da a Claude antes de que comience la conversación.

El array messages alterna entonces entre user (el turno humano) y assistant (la respuesta de Claude). Puede pre-rellenar este array con turnos anteriores para simular una conversación de múltiples turnos, o inyectar un turno assistant parcial para dirigir la primera palabra de la respuesta.

¿Por qué importa el orden de los roles? Claude está entrenado para respetar la jerarquía: las instrucciones system tienen el mayor peso, seguidas del historial de la conversación. Si un mensaje user entra en conflicto con el system prompt, Claude sigue el system prompt. Esto convierte al parámetro system en el lugar adecuado para reglas, personas, formatos de salida y salvaguardas de seguridad.

• system: cadena de texto de nivel superior, definida una vez por solicitud, nunca mostrada como burbuja de mensaje.
• user: un turno humano, obligatorio al menos una vez como último mensaje.
• assistant: las respuestas anteriores de Claude, o una cadena de pre-relleno para restringir la siguiente respuesta.
• Los mensajes deben alternar user/assistant; dos turnos user consecutivos son rechazados por la API.

Uso de herramientas a través de la API

La API de Claude le permite proporcionar al modelo una lista de herramientas (también llamadas definiciones de funciones) que puede invocar. Cada herramienta es un objeto JSON que describe un nombre, una descripción y un esquema de entrada (un objeto JSON Schema que indica a Claude qué parámetros acepta la herramienta). Claude nunca ejecuta la herramienta por sí mismo; devuelve un bloque estructurado tool_use que su código debe gestionar.

Un ciclo típico funciona de la siguiente manera:

1. Usted envía una solicitud messages que incluye un array tools.
2. Si Claude decide llamar a una herramienta, el stop_reason de la respuesta es "tool_use" y el contenido incluye un bloque tool_use con un id, el name de la herramienta y el objeto input.
3. Su código ejecuta la acción real (consulta a base de datos, llamada a API, cálculo) y luego agrega un bloque tool_result a la conversación usando el mismo tool_use_id.
4. Usted envía la conversación actualizada de vuelta a Claude, que lee el resultado y produce su respuesta final.

Dos decisiones de diseño clave afectan la fiabilidad. Primero, redacte la descripción de la herramienta como si estuviera explicando la función a un colega sin experiencia: Claude la usa para decidir si y cuándo llamar a la herramienta. Segundo, mantenga su esquema de entrada estricto: marque los campos obligatorios, use enum cuando los valores son fijos y evite campos string vagos cuando un número o booleano es más apropiado. Los esquemas vagos producen entradas vagas.

Cuando necesite que Claude llame exactamente a una herramienta específica, establezca tool_choice en {"type": "tool", "name": "your_tool_name"}. El valor predeterminado "auto" deja que Claude decida. Use "any" para forzar al menos una llamada a herramienta sin especificar cuál.

Respuestas en streaming

Por defecto, la API de Anthropic espera a que el modelo termine de generar antes de enviar cualquier respuesta. El streaming cambia esto: la API envía cada token (un fragmento de palabra, aproximadamente 3 o 4 caracteres) a su cliente en el momento en que se produce, de modo que el usuario ve el texto aparecer palabra por palabra en lugar de esperar la respuesta completa.

El streaming utiliza el protocolo Server-Sent Events (SSE). El servidor mantiene la conexión HTTP abierta y envía pequeños fragmentos de eventos. Cada fragmento contiene un delta, que es el nuevo texto incremental que se debe agregar. Su cliente acumula los deltas para reconstruir el mensaje completo.

Para activar el streaming con el SDK de Python o Node de Anthropic, pase stream=True (Python) o use el método .stream() (Node). El SDK expone un iterador asíncrono para procesar un fragmento a la vez sin almacenar toda la respuesta en memoria. Esto importa para salidas largas: una respuesta de 4000 tokens puede comenzar a renderizarse en menos de un segundo en lugar de esperar varios segundos.

• stream=True (Python): devuelve un gestor de contexto; itere text_stream para obtener fragmentos de texto sin procesar.
• .stream() (Node/TS): devuelve un iterable asíncrono; use for await para consumir los fragmentos.
• Tipos de eventos: message_start, content_block_delta, message_delta, message_stop.
• Las estadísticas de uso llegan en el último evento message_stop, no al principio.

Caché de prompts en la API

Cada llamada a la API reprocesa todos los tokens que se envían. El prompt caching permite marcar secciones estables de la solicitud para que Anthropic almacene una versión compilada en sus servidores. Las llamadas posteriores que coincidan con el mismo prefijo omiten el reprocesamiento y pagan una tarifa mucho menor: aproximadamente el 10 % del costo de entrada normal para los cache hits, frente al 125 % de la escritura inicial que rellena el caché.

Se marca un límite de caché añadiendo "cache_control": {"type": "breakpoint"} dentro de un bloque de contenido. Claude lee el prompt de arriba a abajo y almacena en caché todo lo que precede a ese marcador. Se pueden colocar hasta cuatro puntos de ruptura por solicitud. El patrón más habitual es un punto de ruptura después de un prompt de sistema largo o de un documento grande que se reutiliza en muchas llamadas.

Algunas reglas determinan si el caché se utiliza realmente:

• El prefijo debe tener al menos 1024 tokens (aproximadamente 750 palabras) para ser elegible para el almacenamiento en caché.
• Las entradas del caché expiran tras cinco minutos de inactividad; cada hit reinicia el temporizador.
• El modelo, la versión y todo el contenido anterior al punto de ruptura deben ser byte a byte idénticos entre llamadas.
• Modelos compatibles (junio de 2026): claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5.

La respuesta de la API incluye un objeto usage con cache_creation_input_tokens y cache_read_input_tokens, lo que permite verificar los hits y medir el ahorro en tiempo real.

La API Batch

La API Batch permite enviar hasta 10 000 solicitudes en una sola llamada y recibir todos los resultados de forma asíncrona (es decir, no se espera una respuesta en tiempo real: se consultan los resultados más adelante). A cambio de esta flexibilidad, Anthropic cobra un 50 % menos por token que la API estándar en tiempo real.

Se envía un archivo JSON con una lista de solicitudes, cada una con su propio custom_id único para poder relacionar los resultados con las entradas. Claude las procesa en segundo plano, normalmente en pocos minutos para cientos de solicitudes, aunque el SLA (Service Level Agreement, la garantía oficial de tiempo) permite hasta 24 horas.

La API Batch tiene su propio límite de velocidad independiente, separado de la API en tiempo real. Esto significa que un trabajo batch intensivo no consume la cuota interactiva. Es ideal para cualquier tarea sin conexión: generación de conjuntos de datos, evaluaciones, traducción de grandes catálogos o clasificación de miles de registros.

• Modelos compatibles: claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5
• Máximo de solicitudes por batch: 10 000
• Descuento: 50 % en tokens de entrada y salida frente al precio en tiempo real
• Formato de resultados: una línea JSONL por solicitud, identificada por custom_id
• Cancelación: es posible cancelar un batch en curso con una sola llamada a la API

Contar tokens

Antes de enviar una solicitud a Claude, puede pedirle a la API que cuente exactamente cuántos tokens (los fragmentos de texto que el modelo lee y escribe) consumirá esa solicitud. Para ello se utiliza el endpoint de conteo de tokens: POST /v1/messages/count_tokens. Acepta el mismo cuerpo que una solicitud de mensajes normal, pero devuelve solo un conteo, nunca una respuesta, y no tiene costo.

Los conteos de tokens importan por dos razones. Primero, cada modelo tiene una ventana de contexto (el máximo de tokens que puede procesar a la vez): 200 000 para Opus y Sonnet, 200 000 para Haiku. Segundo, la facturación se realiza por token de entrada y de salida, por lo que enviar de más es un desperdicio de dinero y enviar de menos puede truncar el prompt. Contar le permite mantenerse bajo el límite y estimar el costo antes de confirmar.

Lo que puede contar antes de enviar:

• El prompt de sistema solo, para entender su costo fijo.
• Las definiciones de herramientas, que a menudo sorprenden a los desarrolladores por su tamaño.
• El historial de conversación, para decidir cuándo resumir o descartar turnos anteriores.
• Archivos adjuntos o documentos largos, para verificar que caben en la ventana.

Para el presupuesto de tokens, establezca un límite suave en su código: si input_tokens devuelto por el endpoint de conteo supera, por ejemplo, 150 000, trunce o resuma antes de enviar. También puede combinar el conteo con el parámetro max_tokens (que limita la longitud de la salida) para controlar con precisión el gasto total por llamada.

Identificadores de modelo, precios y migración

Cada modelo Claude tiene un identificador de modelo, la cadena exacta que se pasa a la API para solicitar una versión específica. A partir de junio de 2026, los tres identificadores actuales son claude-opus-4-8 (el más capaz, el de mayor costo), claude-sonnet-4-6 (equilibrio entre rendimiento y costo) y claude-haiku-4-5 (el más rápido, el de menor costo). Utilice siempre el identificador completo con versión en el código de producción, nunca un alias como "claude-opus" sin sufijo de versión, porque Anthropic puede redirigir silenciosamente los alias a modelos más nuevos y cambiar sus costos o comportamientos.

Elegir el modelo correcto implica un equilibrio entre costo y rendimiento. Una regla práctica:

• Opus (claude-opus-4-8): decisiones de arquitectura, razonamiento complejo, análisis de documentos largos, bucles agentivos donde la calidad es lo más importante.
• Sonnet (claude-sonnet-4-6): tareas de codificación cotidianas, resumen, redacción, flujos de trabajo de múltiples pasos donde importan la velocidad y el costo.
• Haiku (claude-haiku-4-5): clasificación, enrutamiento, consultas rápidas, trabajos por lotes de alto volumen donde la latencia es crítica.

La migración consiste en cambiar en su base de código un identificador de modelo antiguo por uno nuevo. El patrón seguro es: actualizar la cadena del identificador de modelo, ejecutar su suite de evaluación o pruebas existente contra el nuevo modelo, comparar las salidas en una muestra de prompts reales y luego publicar. Dado que los modelos más nuevos pueden rechazar de forma diferente o formatear la salida de manera distinta, nunca migre sin un paso de comparación. Anthropic publica una guía de migración para cada generación; consúltela para detectar cambios que puedan romper los formatos de llamada a herramientas o los tamaños de ventana de contexto antes de cambiar.

El precio es por token (un token equivale aproximadamente a cuatro caracteres de texto en inglés). Se paga por separado por los tokens de entrada (lo que se envía) y los tokens de salida (lo que devuelve el modelo). Los tokens de salida cuestan más. Use el prompt caching para reutilizar un prompt de sistema extenso entre llamadas y reducir los costos de entrada hasta un 90 por ciento en la porción almacenada en caché. La API Batch de Anthropic ofrece un 50 por ciento de descuento en entrada y salida a cambio de mayor latencia, ideal para la generación de conjuntos de datos sin conexión.

Actualización, julio de 2026: la gama actual es Fable 5 (claude-fable-5, 10/50 dólares por millón de tokens), Opus 4.8 (claude-opus-4-8, 5/25), Sonnet 5 (claude-sonnet-5, 3/15, precio de lanzamiento 2/10 hasta el 31 de agosto de 2026) y Haiku 4.5 (claude-haiku-4-5-20251001, 1/5). Opus 4.1 se retira el 5 de agosto de 2026; Opus 4.7/4.6/4.5 y Sonnet 4.6/4.5 son legacy. Desde la generación 4.6, los ids de modelo sin fecha son instantáneas fijadas, no punteros evolutivos. Dos lecciones al final de este módulo cubren las rupturas de Sonnet 5 y el contrato de rechazo de Fable 5.

Entradas de visión y PDF

La API de Claude acepta mucho más que texto. Puedes enviar imágenes y archivos PDF directamente en el arreglo messages, junto a un prompt de texto o en su lugar. El modelo lee el contenido visual y razona sobre él de la misma forma que lo haría con palabras escritas. Esta capacidad se llama entrada multimodal (multiformato, no solo texto).

Las imágenes se pasan como cadenas codificadas en base64 (una forma de representar datos binarios como texto ASCII puro) dentro de un bloque content con "type": "image". Se especifica el tipo de medio, como image/jpeg, image/png, image/gif o image/webp. También puedes pasar una URL pública usando "type": "image" con una fuente "url" en lugar de base64.

Los PDF usan "type": "document" con "media_type": "application/pdf" y el contenido del archivo en base64. Claude lee la capa de texto completa del PDF y, cuando las páginas contienen diagramas o gráficos, también los interpreta visualmente. Los PDF tienen un límite de 100 páginas y aproximadamente 32 MB por archivo.

• Formatos de imagen admitidos: JPEG, PNG, GIF, WebP.
• Tamaño máximo de imagen por solicitud: 20 MB (el peso codificado en base64 es aproximadamente un 33 por ciento mayor que el archivo original).
• Hasta 20 imágenes por solicitud en los modelos actuales.
• PDF: máximo 100 páginas, 32 MB en bruto. Se analiza tanto el contenido textual como el visual.
• La visión está disponible en claude-opus-4-8, claude-sonnet-4-6 y claude-haiku-4-5.

Sonnet 5 en la API: qué se rompe, qué gana

El 30 de junio de 2026, Anthropic lanzó claude-sonnet-5, sustituyendo a Sonnet 4.6 como el modelo de gama media de la familia Claude. Es también el nuevo modelo por defecto en los planes Free y Pro de claude.ai, y en Claude Code desde la versión 2.1.197. Si desarrollas contra la API, este es el modelo por el que pasará la mayor parte de tu tráfico de producción, salvo que fijes deliberadamente uno más antiguo.

Las especificaciones suponen un salto real. Sonnet 5 se lanza con una ventana de contexto de 1M de tokens (aproximadamente un millón de tokens combinando entrada e historial de conversación) como único tamaño ofrecido, sin variante más pequeña donde elegir. La salida máxima por solicitud es de 128.000 tokens (el parámetro max_tokens, que limita cuánto texto puede generar una sola respuesta). Su fecha de corte de conocimiento (la fecha a partir de la cual no tiene datos de entrenamiento sobre el mundo) es enero de 2026. Anthropic lo describe como el Sonnet más agéntico hasta la fecha, es decir, planifica y ejecuta tareas de múltiples pasos con uso de herramientas con menos supervisión manual, y ahora se acerca a la calidad de Opus 4.8 en muchos benchmarks de programación y agénticos, a un precio mucho más bajo.

El precio durante el periodo introductorio, que se extiende hasta el 31 de agosto de 2026, es de 2 dólares por millón de tokens (MTok) de entrada y 10 dólares por MTok de salida. Después de esa fecha vuelve a la tarifa estándar del nivel Sonnet, de 3 dólares de entrada / 15 dólares de salida por MTok. Si estás calculando el coste de un proyecto que abarca esa fecha, presupuesta la tarifa más alta para todo lo que se ejecute después del 1 de septiembre de 2026.

Tres cambios romperán el código existente de la API que se escribió para Sonnet 4.6 o modelos anteriores, así que trátalo como una lista de comprobación antes de cambiar la cadena del modelo. Primero, el razonamiento adaptativo está activado por defecto: a diferencia de Opus 4.7 y 4.8, donde omitir el parámetro thinking ejecuta el modelo sin razonamiento, en Sonnet 5 el simple hecho de no configurar thinking sigue activando el razonamiento adaptativo (el modelo decide por su cuenta cuándo y cuánto razonar antes de responder). Segundo, se elimina el razonamiento extendido manual: enviar thinking: {type: "enabled", budget_tokens: N}, la antigua forma de darle al modelo un presupuesto fijo de tokens de razonamiento, ahora devuelve un error 400 (una respuesta de solicitud rechazada) en lugar de ser aceptado en silencio o simplemente quedar obsoleto. Tercero, se rechazan los parámetros de muestreo distintos de los predeterminados: configurar temperature, top_p o top_k con un valor distinto al predeterminado devuelve un error 400. Estos controles de muestreo, que antes permitían ajustar la aleatoriedad de la salida del modelo, han desaparecido por completo en los modelos de clase Sonnet a partir de esta versión.

Hay también un cambio más discreto pero costoso: el tokenizador (el algoritmo que divide el texto en las unidades que el modelo realmente cuenta y factura). El tokenizador de Sonnet 5 divide el mismo texto de entrada en aproximadamente un 30% más de tokens que el tokenizador de Sonnet 4.6. Eso significa que un prompt que te costaba 10.000 tokens en Sonnet 4.6 podría costar alrededor de 13.000 tokens en Sonnet 5, aunque el texto no haya cambiado en absoluto. Cualquier estimación de coste, presupuesto de ventana de contexto o cálculo de límite de tasa que hayas construido para Sonnet 4.6 debe volver a ejecutarse contra Sonnet 5 en lugar de reutilizarse.

Junto con el lanzamiento, Anthropic reorganizó la gama de modelos. Opus 4.1 queda obsoleto y se retirará el 5 de agosto de 2026, así que cualquier código que aún lo use como destino necesita un plan de migración antes de esa fecha. Opus 4.7, Opus 4.6, Opus 4.5, Sonnet 4.6 y Sonnet 4.5 se consideran ahora heredados (legacy), lo que significa que siguen siendo invocables, pero ya no son la opción recomendada para trabajo nuevo. Un detalle de nomenclatura que conviene conocer: desde la generación 4.6 de modelos, un id de modelo sin fecha (un nombre como claude-sonnet-5 sin sufijo de fecha) es una instantánea fijada (pinned snapshot), no un puntero perenne que se actualiza en silencio a un modelo más nuevo con el tiempo. Ese id seguirá devolviendo la misma versión del modelo indefinidamente, lo cual es bueno para la reproducibilidad, pero significa que tienes que cambiar tú mismo la cadena activamente para adoptar una versión futura.

Para migrar código existente a Sonnet 5, sigue esta lista de comprobación en orden. Cambia el id del modelo a la cadena claude-sonnet-5. Elimina cualquier parámetro temperature, top_p, top_k y budget_tokens de las cargas útiles de tus solicitudes, ya que todos ellos ahora provocan errores. Vuelve a calcular el conteo de tokens usando el endpoint de conteo de tokens de la API con prompts reales, porque el desplazamiento del 30% en el tokenizador cambia cada estimación que tenías. Vuelve a calcular el precio de tu carga de trabajo usando la nueva tarifa introductoria de 2/10 dólares (o 3/15 dólares después del 31 de agosto de 2026) en lugar de reutilizar las antiguas cifras de coste de Sonnet 4.6. Por último, vuelve a probar tus salvaguardas, es decir, cualquier filtro de contenido, comprobación de longitud de salida o lógica de seguridad que hubieras ajustado según el comportamiento del modelo anterior, ya que un modelo más agéntico y con una tokenización distinta puede desplazar los patrones de respuesta de formas que se cuelan a través de comprobaciones calibradas para la versión previa.

Rechazos, alternativas de repliegue y el contrato de Fable 5

Claude Fable 5 se lanzó el 9 de junio de 2026 y se actualizó de nuevo en el redespliegue del 1 de julio de 2026. Cambió la forma en que la API de Claude gestiona los rechazos por seguridad. Cuando uno de los clasificadores de seguridad de doble uso de Fable 5 (filtros automatizados que verifican una solicitud contra categorías de política como riesgo cibernético o biológico, antes o durante la generación) se activa, la API no devuelve un código de error. Devuelve un HTTP 200 normal con stop_reason establecido en "refusal", e informa qué clasificador se activó. Esto es importante para la facturación: una solicitud rechazada antes de producir cualquier salida no se factura en absoluto. Si el rechazo ocurre a mitad del streaming, después de que ya se generaron algunos tokens, esos tokens transmitidos se facturan como de costumbre. Un desarrollador que solo verifica códigos de error HTTP se perderá cada uno de estos eventos, porque técnicamente la solicitud tuvo éxito.

Una vez que ocurre un rechazo, tienes tres rutas de reintento, y Anthropic recomienda probarlas en orden. La primera ruta, y la preferida, es el parámetro fallbacks, una función beta en la API de Claude y en Claude Platform on AWS (la oferta propia de Anthropic alojada en AWS, distinta de Amazon Bedrock). Declaras uno o más modelos de repliegue en la solicitud, y si el modelo principal rechaza, la plataforma reintenta automáticamente la solicitud contra el modelo de repliegue por ti, dentro de la misma llamada. Sin viaje de ida y vuelta adicional, sin lógica del lado del cliente. La segunda ruta es el middleware del SDK, disponible para TypeScript, Python, Go, Java y C#. Este es código del lado del cliente que intercepta un rechazo y reemite la solicitud por sí mismo, útil cuando el parámetro del lado del servidor no está disponible en tu plataforma de despliegue. La tercera ruta es el manejo manual en tu propio código: capturar el rechazo, decidir qué hacer y volver a llamar a la API tú mismo. Cada ruta intercambia comodidad por control, y deberías usar la primera por defecto a menos que tengas una razón específica para no hacerlo.

Un detalle que elimina una objeción común al reintento: existe un crédito de repliegue (fallback credit). Cuando cambias de un modelo a otro en medio de una conversación, normalmente pierdes tu caché de prompt (la reutilización a tarifa reducida de un prefijo de prompt procesado previamente) y pagas el precio completo para reconstruirlo en el nuevo modelo. Con el crédito de repliegue, el costo de ese cambio de caché se reembolsa cuando el repliegue se activa por un rechazo. Esto significa que optar por los repliegues es casi gratuito desde el punto de vista del costo, razón por la cual Anthropic recomienda tratarlo como un valor predeterminado en lugar de una opción que hay que justificar.

El razonamiento en Fable 5 funciona de manera diferente a los modelos Claude anteriores. El pensamiento adaptativo es el único modo: Fable 5 decide por sí mismo cuándo y cuánto razonar antes de responder, y no puedes pasar un parámetro para desactivar el pensamiento por completo. Esto es un cambio respecto a las configuraciones de pensamiento extendido más antiguas, donde un desarrollador establecía un presupuesto de tokens fijo para el razonamiento. Un segundo cambio: la cadena de pensamiento en bruto nunca se devuelve al llamador, independientemente de la configuración. Lo que sí puedes controlar es thinking.display, que admite dos valores: "summarized" te da una versión legible y resumida del razonamiento, y "omitted" (el valor predeterminado) no te da nada. Si tu producto muestra a los usuarios una vista en vivo del proceso de razonamiento de Claude, debes solicitar explícitamente "summarized" o el campo simplemente estará vacío.

El manejo de datos en Fable 5 tiene una restricción que los desarrolladores sensibles al cumplimiento normativo deben señalar desde el principio. Fable 5, junto con su modelo hermano Mythos 5, está clasificado como Modelo Cubierto (Covered Model), lo que conlleva una retención de datos obligatoria de 30 días y, de manera crucial, ninguna opción de retención cero de datos (ZDR). Las organizaciones que requieren ZDR por razones regulatorias o contractuales (finanzas, salud, trabajo gubernamental) actualmente no pueden desplegar Fable 5 en ese modo. Esto no es una configuración que puedas cambiar; es una propiedad del modelo en esta etapa de su despliegue. Cualquiera que esté diseñando una integración de Fable 5 para un cliente regulado debería exponer esta restricción antes de escribir una sola línea de código de integración, no después.

En cuanto a funciones, Fable 5 admite un conjunto bastante completo de capacidades de API desde el lanzamiento: el parámetro effort (controla cuánto esfuerzo computacional dedica el modelo a una tarea), los presupuestos de tarea (task budgets, una función beta para limitar el gasto en ejecuciones agénticas largas), la herramienta de memoria (permite que Claude conserve notas entre sesiones), la ejecución de código, la llamada programática a herramientas (Claude escribe código que llama directamente a tus herramientas en lugar de pasar por un viaje de ida y vuelta completo cada vez), la edición de contexto, la compactación (resumir turnos de conversación antiguos para ahorrar espacio de contexto) y la visión. El precio es de 10 dólares por millón de tokens de entrada y 50 dólares por millón de tokens de salida, lo cual es un nivel premium en comparación con modelos Claude anteriores, así que los desarrolladores deberían evaluar si una tarea realmente necesita la profundidad de razonamiento de Fable 5 o si funcionaría aceptablemente con un modelo más económico.

El patrón defensivo que hay que incorporar en cada integración de Fable 5: siempre bifurca explícitamente según stop_reason en lugar de asumir que content está poblado. Verifica "end_turn" (finalización normal), "max_tokens" (la salida se cortó porque alcanzó el límite de longitud) y "refusal" (un clasificador bloqueó la solicitud) como casos distintos, cada uno con un manejo diferente. Registra el nombre del clasificador cada vez que ocurra un rechazo, ya que ese es tu rastro de auditoría si un cliente se queja de que su solicitud legítima fue bloqueada. Finalmente, decide caso por caso si recurrir a Opus 4.8 es un resultado aceptable para servir silenciosamente al usuario, o si la solicitud debería en cambio mostrar un error visible para que un humano pueda revisarlo. Una herramienta de cumplimiento financiero y un chatbot casual probablemente deberían tomar decisiones opuestas aquí.