Claude Fable 5 y Cambios en la API de Mythos: Qué Sigue Funcionando y Cómo Probarlo

Anthropic lanzó sus modelos Fable y Mythos con cambios que afectan directamente a las integraciones en producción: una retención de datos de 30 días para tráfico de esos modelos y ajustes en las barreras de seguridad que pueden modificar respuestas, rechazos y streaming sin romper necesariamente el contrato de la API.

Prueba Apidog hoy

Si usas la API de Claude, no asumas que tu integración se comporta igual que antes. En esta guía verás qué sigue estable, qué debes validar y cómo montar pruebas reproducibles con Apidog para detectar cambios antes de que lleguen a tus usuarios.

Qué cambió realmente

Hay tres cambios o áreas de riesgo que conviene separar.

1. Retención de datos

El cambio principal es una ventana de retención de 30 días aplicada a solicitudes de Fable y Mythos.

En la práctica, esto significa que los datos de solicitud y respuesta vinculados a esos modelos pueden conservarse durante un periodo fijo. Si tu producto promete a sus usuarios que no retiene prompts, o que minimiza datos enviados a proveedores externos, debes revisar esa promesa teniendo en cuenta el comportamiento del proveedor upstream.

Acción recomendada:

• Audita qué datos envías en cada prompt.
• Elimina campos que no sean necesarios.
• Documenta internamente qué modelos usan retención de 30 días.
• Revisa la documentación oficial vigente de Anthropic antes de actualizar políticas públicas.

2. Barreras de seguridad

También se discutieron cambios en las barreras de seguridad de Fable. El problema práctico para desarrolladores no es que existan guardrails, sino que el comportamiento puede cambiar.

Un prompt que ayer devolvía una respuesta válida puede hoy:

• ser rechazado;
• ser reformulado;
• devolver una respuesta parcial;
• activar una intervención durante streaming.

Si tu aplicación depende de una salida estable, esto puede romper parsers, flujos de agentes o lógica downstream.

3. Acceso programático

La superficie principal de la API no se reemplazó.

Siguen funcionando:

• claves existentes;
• encabezado x-api-key;
• llamadas a messages;
• prompts system;
• array messages;
• uso de herramientas;
• streaming.

El riesgo no está en que el endpoint deje de responder. El riesgo está en que el comportamiento cambie debajo del mismo contrato.

Qué sigue funcionando

Antes de reescribir código, confirma qué partes permanecen estables.

• Autenticación: las claves de API y el encabezado x-api-key siguen funcionando. No necesitas rotar claves por este cambio, aunque la rotación periódica sigue siendo una buena práctica. Revisa la referencia de la API para el contrato actual de encabezados.
• API de Messages: el cuerpo de solicitud, model, max_tokens, prompts system y messages mantienen la misma estructura.
• Uso de herramientas: las definiciones de herramientas y el ciclo tool_use / tool_result siguen usando el mismo patrón.
• Streaming: los eventos enviados por servidor siguen transmitiendo tokens, aunque el contenido puede cambiar si una barrera de seguridad interviene.
• IDs de modelos: si fijas un modelo por ID completo en lugar de usar un alias flotante, reduces el riesgo de deriva silenciosa.

No necesitas una reescritura de emergencia. Necesitas pruebas que demuestren que los supuestos de tu aplicación siguen siendo válidos.

Cómo probar tu integración con Apidog

Puedes leer changelogs, pero la única forma de saber cómo responde tu integración es ejecutar solicitudes reales, guardar respuestas y automatizar verificaciones.

Con Apidog puedes:

• definir solicitudes contra la API de Claude;
• guardar respuestas de referencia;
• crear aserciones;
• simular respuestas del upstream;
• ejecutar pruebas automatizadas;
• compartir casos con tu equipo.

Si vienes de Postman o quieres estandarizar pruebas, también puedes revisar esta guía sobre pruebas de API sin Postman.

1. Captura una línea base conocida

Crea una solicitud en Apidog contra la API de Messages usando un prompt representativo de producción.

Evita prompts de juguete. Usa entradas que se parezcan a las que realmente procesa tu aplicación.

Ejemplo:

POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json

{
  "model": "claude-fable-5",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Summarize this support ticket and label its priority: ..."
    }
  ]
}

Buenas prácticas:

• Guarda ANTHROPIC_API_KEY como variable de entorno en Apidog.
• No codifiques claves en solicitudes guardadas.
• Usa un ID de modelo fijo cuando pruebes rutas críticas.
• Guarda la respuesta como línea base.

Este patrón también aplica si estás probando Claude, el SDK de Claude Code u otro componente que dependa de la misma API.

2. Añade aserciones sobre la respuesta

No basta con mirar manualmente la respuesta. Convierte la línea base en una prueba automatizada.

Aserciones útiles:

• El código HTTP es 200.
• stop_reason es end_turn.
• La respuesta incluye el campo que tu aplicación parsea.
• El formato sigue siendo válido.
• La latencia está por debajo de tu timeout.
• No aparece una forma de rechazo inesperada.

Ejemplo conceptual de validación:

pm.test("status is 200", function () {
  pm.response.to.have.status(200);
});

pm.test("stop_reason is end_turn", function () {
  const json = pm.response.json();
  pm.expect(json.stop_reason).to.eql("end_turn");
});

pm.test("response contains priority label", function () {
  const json = pm.response.json();
  const text = JSON.stringify(json);
  pm.expect(text).to.include("priority");
});

La sintaxis exacta dependerá del entorno de scripting que uses, pero el objetivo es el mismo: probar el contrato real que tu aplicación asume.

Este enfoque es similar a las pruebas de contrato de API: defines qué comportamiento es aceptable y fallas rápido cuando cambia.

3. Prueba rechazos y guardrails de forma explícita

Los rechazos son fáciles de ignorar hasta que rompen un flujo de producción.

Crea una colección pequeña con prompts cercanos a tus límites de contenido:

• entradas que suelen activar filtros;
• prompts ambiguos;
• prompts que antes eran aceptados;
• prompts que tu aplicación reformula automáticamente;
• casos donde esperas una negativa segura.

Guarda las respuestas esperadas y añade aserciones.

Por ejemplo:

{
  "expected_behavior": "safe_refusal",
  "must_not_include": ["internal stack trace", "raw policy text"],
  "must_include": ["no puedo ayudar", "alternativa segura"]
}

La idea no es evitar los guardrails. Es detectar cuándo cambian de forma que rompe tu producto.

4. Simula Anthropic para que CI no dependa de la API en vivo

No conviene que tu suite de CI llame siempre a una API externa de pago, con límites de velocidad y comportamiento variable.

Usa el servidor de mocks de Apidog para crear un endpoint falso de Messages con respuestas predefinidas.

Casos que deberías simular:

• respuesta correcta;
• rechazo por barrera de seguridad;
• error HTTP;
• timeout;
• respuesta truncada;
• streaming parcial;
• payload con estructura inesperada.

Ejemplo de respuesta mock:

{
  "id": "msg_mock_123",
  "type": "message",
  "role": "assistant",
  "model": "claude-fable-5",
  "content": [
    {
      "type": "text",
      "text": "{\"priority\":\"high\",\"summary\":\"El cliente no puede acceder a su cuenta.\"}"
    }
  ],
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 120,
    "output_tokens": 32
  }
}

Luego cambia la URL base de tu aplicación:

# Producción
ANTHROPIC_BASE_URL=https://api.anthropic.com

# Desarrollo / CI
ANTHROPIC_BASE_URL=https://mock.example.apidog

Así pruebas tu código sin gastar tokens ni depender del comportamiento vivo del modelo.

Si estás construyendo agentes, este mismo patrón es útil para una configuración de pruebas de agentes de IA.

5. Audita datos sensibles por la retención de 30 días

Si la retención de 30 días afecta tu cumplimiento, no lo trates como una nota legal aislada. Llévalo a tus pruebas y revisiones técnicas.

Checklist de auditoría:

• ¿Qué endpoints llaman a Fable o Mythos?
• ¿Qué campos del usuario salen en cada prompt?
• ¿Estás enviando datos personales innecesarios?
• ¿Puedes resumir, anonimizar o truncar antes de enviar?
• ¿Tus logs internos guardan el mismo prompt?
• ¿Tu política de privacidad depende de la retención del proveedor?

Ejemplo de reducción de payload antes de enviar al modelo:

function buildSupportPrompt(ticket) {
  return {
    customer_tier: ticket.customer_tier,
    issue_type: ticket.issue_type,
    message: ticket.message,
    // Evita enviar campos que no sean necesarios:
    // email: ticket.email,
    // phone: ticket.phone,
    // billing_address: ticket.billing_address
  };
}

No puedes cambiar la política de retención del proveedor, pero sí puedes controlar qué datos le entregas.

6. Prueba timeouts, latencia y reintentos

Los cambios silenciosos suelen aparecer bajo carga.

Ejecuta la misma solicitud repetidamente y observa:

• latencia media;
• p95 / p99;
• errores intermitentes;
• respuestas parciales;
• activaciones inesperadas de guardrails;
• comportamiento de streaming.

Define un timeout realista en tu cliente:

const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 30000);

try {
  const response = await fetch("https://api.anthropic.com/v1/messages", {
    method: "POST",
    headers: {
      "x-api-key": process.env.ANTHROPIC_API_KEY,
      "anthropic-version": "2023-06-01",
      "content-type": "application/json"
    },
    body: JSON.stringify(payload),
    signal: controller.signal
  });

  if (!response.ok) {
    throw new Error(`Anthropic API error: ${response.status}`);
  }

  return await response.json();
} finally {
  clearTimeout(timeout);
}

Añade reintentos con cuidado. No reintentes indefinidamente ni dupliques operaciones no idempotentes.

Ejemplo simple:

async function callWithRetry(fn, retries = 2) {
  let lastError;

  for (let attempt = 0; attempt <= retries; attempt++) {
    try {
      return await fn();
    } catch (error) {
      lastError = error;

      if (attempt === retries) break;

      const delay = 500 * Math.pow(2, attempt);
      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }

  throw lastError;
}

Si estás investigando lentitud upstream, este enfoque complementa la guía para solucionar tiempos de espera de solicitudes upstream.

Lista de verificación práctica

Antes de dar por segura tu integración, revisa esto:

• [ ] Fija IDs completos de modelos en rutas de producción.
• [ ] Evita alias flotantes si necesitas comportamiento estable.
• [ ] Guarda una respuesta base para cada prompt crítico.
• [ ] Añade aserciones sobre estado HTTP, stop_reason y campos parseados.
• [ ] Prueba rechazos y guardrails explícitamente.
• [ ] Captura respuestas de error y streaming parcial.
• [ ] Simula la API de Messages para desarrollo y CI.
• [ ] Audita prompts con la retención de 30 días en mente.
• [ ] Elimina datos sensibles que no sean necesarios.
• [ ] Prueba timeouts, reintentos y latencia bajo carga.

Preguntas frecuentes

¿Necesito cambiar mis claves de API?

No. La autenticación no ha cambiado. Puedes seguir usando tus claves actuales. Rotarlas periódicamente sigue siendo buena práctica, pero estos cambios no obligan a hacerlo.

¿Mi código actual de Messages dejará de funcionar?

El contrato de solicitud y respuesta sigue estable. Tu código debería seguir funcionando si usa la API de Messages correctamente.

Lo que puede cambiar es el comportamiento: rechazos, latencia, contenido de respuestas y streaming bajo guardrails.

¿Qué implica la retención de 30 días?

Los informes describen una ventana de retención de 30 días para tráfico de Fable y Mythos. Si tus compromisos de privacidad dependen de cómo el proveedor maneja los datos, revisa qué envías y consulta la documentación oficial actual de Anthropic.

¿Cómo detecto cambios en guardrails antes que mis usuarios?

Guarda respuestas de referencia para prompts sensibles, añade aserciones y ejecútalas periódicamente en Apidog. Si una respuesta cambia, la prueba falla antes de que el problema llegue a producción.

¿Puedo probar sin gastar tokens?

Sí. Usa mocks en Apidog para reproducir respuestas capturadas, incluyendo rechazos, errores y casos de timeout. Así tus pruebas de desarrollo y CI no dependen de la API en vivo.

Conclusión

Los cambios de Fable y Mythos no significan necesariamente una API rota. Tus claves, llamadas a Messages, herramientas y streaming siguen funcionando. El riesgo está en el comportamiento: rechazos, latencia, streaming parcial y retención de datos.

La respuesta práctica es simple: fija modelos, captura líneas base, automatiza aserciones, simula el upstream y audita los datos que envías. Descarga Apidog y reemplaza “creo que sigue funcionando” por “lo probé y tengo evidencia”.