Para probar las integraciones de la API de Claude Fable 5.2, valida la autenticación, el cuerpo de la solicitud de Messages, los bloques de respuesta tipados y los fallos predecibles. Luego guarda esas comprobaciones como casos de prueba repetibles de Apidog que tu agente de código ejecute a través de la CLI. Mantén las aserciones de transporte separadas de las comprobaciones de calidad de la tarea, para que una respuesta HTTP exitosa no pueda ocultar una respuesta inutilizable.
El anuncio de Anthropic identifica claude-fable-5-2 como el ID de modelo de Claude Platform. Esta guía construye un flujo de trabajo de regresión en torno a ese modelo, en lugar de detenerse tras una única respuesta exitosa. Apidog ofrece a tu agente un lugar compartido para mantener el endpoint, los casos de prueba y los informes de ejecución.
¿Qué deben cubrir las pruebas de la API de Claude Fable 5.2?
Utiliza tres capas: las comprobaciones de transporte establecen si la solicitud llegó al servicio; las comprobaciones de contrato validan la estructura de la respuesta; las comprobaciones de comportamiento establecen si tu aplicación puede utilizar el resultado. Ejecuta las dos primeras para cada fixture. Define criterios de aceptación de comportamiento para cada tarea en lugar de comparar respuestas generadas completas byte por byte.
| Capa | Aserción de ejemplo | Un fallo significa |
|---|---|---|
| Transporte | Estado esperado y respuesta JSON | Problema de credenciales, red o servicio |
| Contrato | Mensaje del asistente con bloques de contenido tipados | Desajuste del parser o del contrato de la API |
| Comportamiento | Resultado aritmético correcto en el texto extraído | La salida no satisface este fixture |
Comienza con un fixture pequeño e inocuo: «¿Cuánto es 2 + 2? Responde solo con el número». Hace visible la regla de aceptación sin introducir archivos, herramientas ni historial de conversación. Añade fixtures representativos de la aplicación una vez que el contrato básico funcione.
No trates este fixture como un benchmark de razonamiento. Su propósito es detectar regresiones de integración, como extraer un bloque de pensamiento como texto orientado al usuario o aceptar una respuesta truncada.
Fija la autenticación y la configuración de la solicitud antes de probar
Para la API directa de Claude, usa el endpoint de Messages, una credencial de API con ámbito de workspace, una versión explícita de la API y un cuerpo de solicitud fijo. Mantén esas entradas constantes entre ejecuciones. La descripción general de la API documenta la autenticación Bearer, la selección de workspace y los encabezados de versión. Estas configuraciones difieren de la autenticación IAM de proveedores de nube.
Usa una clave de API de Claude Console suministrada a través de tu entorno local de secretos. Un token de acceso de Apidog autentica la CLI ante Apidog; no autentica las solicitudes ante Anthropic. Mantén ambas credenciales separadas.
La siguiente solicitud sigue la documentación actual de Messages, verificada el 10 de noviembre de 2026. Guarda el JSON como request.json:
{
"model": "claude-fable-5-2",
"max_tokens": 1024,
"stream": false,
"thinking": { "type": "adaptive" },
"messages": [
{
"role": "user",
"content": "What is 2 + 2? Reply with the numeral only."
}
]
}
Luego envíala desde tu terminal o pide a tu agente de código que la ejecute:
curl https://api.anthropic.com/v1/messages \
-H "Authorization: Bearer $ANTHROPIC_API_KEY" \
-H 'anthropic-version: 2026-10-21' \
-H 'Content-Type: application/json' \
--max-time 600 \
--dump-header response.headers \
--output response.json \
--write-out '%{http_code}\n' \
--data-binary @request.json
Si tu clave no tiene ámbito de workspace, incluye el encabezado anthropic-workspace-id documentado para el workspace de destino. Nunca introduzcas una credencial literal en el fixture guardado ni en un informe generado.
La referencia de creación de mensajes define model, messages y max_tokens, además de los campos del mensaje devuelto. Aquí, 1.024 es un presupuesto de salida elegido, no un mínimo documentado ni una garantía de que cada tarea quepa. Auméntalo deliberadamente cuando un fixture necesite más espacio.
Esta es una plantilla verificada contra la documentación. Ejecútala con tu propia cuenta de API autorizada antes de registrar una línea base exitosa; aquí no se afirma ninguna respuesta real de Fable ni medición de latencia.
Añade aserciones de respuesta que resistan la variación generada
Valida el envoltorio, inspecciona los tipos de bloque, extrae el texto y luego aplica la regla de aceptación del fixture. Una respuesta de Messages contiene un array content, así que no asumas que content[0].text contiene la respuesta. Conserva el mensaje original completo por separado si tu aplicación lo reenvía en turnos posteriores de la conversación.
Para el fixture aritmético, pide a tu agente que adjunte este script posterior a la respuesta al caso de prueba de Apidog:
pm.test("HTTP success", function () {
pm.response.to.have.status(200);
});
const body = pm.response.json();
pm.test("Assistant message contract", function () {
pm.expect(body.type).to.eql("message");
pm.expect(body.role).to.eql("assistant");
pm.expect(body.id).to.be.a("string");
pm.expect(body.model).to.be.a("string");
pm.expect(body.content).to.be.an("array");
});
const text = body.content
.filter(block => block.type === "text")
.map(block => block.text)
.join("\n").trim();
pm.test("Arithmetic fixture is complete", function () {
pm.expect(body.stop_reason).to.eql("end_turn");
pm.expect(text).to.eql("4");
});
La igualdad exacta tiene sentido para este numeral deliberadamente restringido. Para un resumen, usa criterios como los hechos requeridos, las afirmaciones no respaldadas prohibidas y los límites de longitud. Un cambio inocuo de redacción no debería romper una prueba de resumen útil.
Registra usage y el encabezado request-id de la respuesta para fines de diagnóstico. Compara los identificadores de modelo devueltos con el comportamiento documentado para el identificador elegido; no reetiquetes silenciosamente las respuestas de fallback como resultados de Fable.
Una razón de parada por max_tokens significa que la respuesta alcanzó su límite de salida. Marca como fallido este fixture aritmético y revisa el presupuesto de tokens. Otras tareas pueden devolver legítimamente razones de parada distintas, incluidas solicitudes de herramientas, así que asigna a cada caso su propia regla de finalización.
Prueba los casos negativos de la API de Claude Fable 5.2
Crea un caso separado para cada entrada inválida y cambia un solo campo a la vez. Comprueba el estado HTTP y el tipo de error estructurado en lugar de comparar el mensaje de error legible completo. Mantén la línea base válida sin cambios para que un fixture negativo no contamine la siguiente ejecución positiva.
La guía oficial de errores documenta los siguientes casos útiles:
| Caso | Cambio respecto a la línea base | Resultado esperado |
|---|---|---|
| Autenticación inválida | Reemplazar la credencial Bearer por un valor ficticio | 401, authentication_error |
| Pensamiento deshabilitado | Establecer thinking.type en disabled |
400, invalid_request_error |
| Extended thinking heredado | Establecer thinking.type en enabled |
400, invalid_request_error |
| Prefill del asistente | Terminar la conversación con un prefill del asistente | 400, invalid_request_error |
Fable 5.2 usa pensamiento siempre activo. No copies un tutorial antiguo de Claude que lo deshabilita o configura presupuestos de extended thinking. El caso de pensamiento deshabilitado es especialmente útil al actualizar código compartido de construcción de solicitudes.
Para cada caso de error, verifica body.type === "error", el body.error.type esperado y un mensaje de error no vacío. Conserva un ID de solicitud cuando esté disponible. Trata los fallos de DNS y los tiempos de espera del cliente como resultados separados, porque pueden no producir nunca un error JSON de Claude.
Prueba el manejo de límites de tasa y fallos del servicio en tu aplicación con fixtures controlados o un mock. No satures la API en vivo para provocar un 429. Distingue los problemas de capacidad reintentables de los fallos de autenticación y validación, y coloca un presupuesto de reintentos finito en torno a la lógica de reintentos de tu aplicación.
Permite que tu agente de código construya los casos de regresión en Apidog
Proporciona a tu agente el endpoint, los fixtures, las aserciones y el proyecto de destino. Puede descubrir el esquema actual de la CLI, validar cada payload, crear los casos de prueba y ejecutarlos. Tú revisas los casos generados y el resumen de fallos. Esto mantiene el flujo de trabajo repetible en la CLI de Apidog.
Instala la CLI y autentícate con tu token de Apidog:
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_APIDOG_TOKEN>
Para la configuración del agente, sigue las guías en vivo de Claude Code o Codex. Luego dale a tu agente un único prompt:
In Apidog project <PROJECT_ID>, define POST /v1/messages for the
Claude API. Use model claude-fable-5-2 and version 2026-10-21.
Keep the Anthropic credential in a private runtime variable.
Create the arithmetic success case and four negative cases above.
Read CLI help and input schemas before generating payloads.
Discover valid endpoint and category IDs; validate every payload.
Attach the response assertions, then run each case against
<ENVIRONMENT_ID>. Report failures, request IDs, and token usage.
Do not print credentials or claim unexecuted cases passed.
Los siguientes comandos fueron verificados contra la CLI 2.2.12 instalada. El agente necesita un ID de endpoint y un ID de categoría reales; test-case-create describe casos derivados de endpoints, por lo que crear una solicitud JSON independiente no relacionada no es suficiente.
apidog test-case category --project <PROJECT_ID>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <PROJECT_ID> --file case.json
apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
-e <ENVIRONMENT_ID> -r cli,json
Pide al agente que examine la ayuda de los comandos de endpoint y sus esquemas cuando el endpoint no exista. Usa los ID devueltos, no números ilustrativos copiados de otro proyecto. Valida case.json antes de escribirlo, luego lee el caso creado para confirmar que los encabezados, el cuerpo y las aserciones previstos se guardaron correctamente.
Ejecuta las pruebas de regresión de la API de Claude en CI
Ejecuta los mismos casos después de cambios en la autenticación, la serialización de mensajes, el análisis de bloques o el manejo de reintentos. Exporta informes legibles por máquina y conserva la versión del fixture junto con el cambio de tu aplicación. Establece una línea base exitosa antes de hacer comparaciones, y luego investiga los fallos individualmente en lugar de volver a ejecutar hasta que la compilación pase por casualidad.
Para un caso ya creado en Apidog, una invocación orientada a CI es:
apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
-e <ENVIRONMENT_ID> -r cli,json,junit \
--out-dir ./apidog-reports
Repite para los demás ID de casos o deja que tu agente organice los casos en una suite de pruebas usando el esquema actual de suites. La guía de CI/CD de Apidog cubre la integración con pipelines.
Conserva el modelo, la versión de la API, el cuerpo de la solicitud, el presupuesto de salida, la revisión del fixture y la versión de la CLI en el registro de ejecución. Almacena las credenciales a través del mecanismo de secretos de tu CI. Revisa los informes en busca de datos sensibles de solicitudes antes de compartirlos.
Usa un pequeño conjunto de smoke tests en vivo para cambios rutinarios y un conjunto más amplio de pruebas de comportamiento antes de los lanzamientos. Establece tus propios presupuestos de gasto y duración. Una prueba de contrato de API exitosa establece la compatibilidad de integración; tus pruebas de aceptación específicas de la aplicación establecen si la salida es útil.
Preguntas frecuentes
¿Qué ID de modelo debo probar?
Usa claude-fable-5-2 para este flujo de trabajo directo con Claude Platform. Verifica la disponibilidad en tu cuenta antes de guardar una línea base.
¿Es suficiente HTTP 200 para aprobar?
No. Comprueba el envoltorio del mensaje, el contenido tipado, la razón de finalización y los criterios de aceptación del fixture. El streaming requiere comprobaciones adicionales a nivel de eventos, porque los fallos pueden ocurrir después de que lleguen los encabezados de la respuesta.
¿Puedo deshabilitar el pensamiento de Fable 5.2?
No. Anthropic documenta el pensamiento siempre activo para este modelo. Mantén el pensamiento deshabilitado como un caso negativo que espera un error de validación.
¿Deben coincidir exactamente todas las respuestas?
Usa coincidencias exactas para fixtures restringidos como el ejemplo del numeral. Para tareas abiertas, define criterios factuales y estructurales que permitan variaciones válidas de redacción.
¿Puede mi agente volver a ejecutar las pruebas después de una corrección?
Sí. Dale los ID de casos guardados y el entorno, y pídele que ejecute los mismos comandos de la CLI y que resuma los informes. Empieza con el flujo de trabajo de la CLI con Claude Code si necesitas configurar el agente.