Anthropic lanzó sus líneas de modelos Fable y Mythos con un conjunto de reglas diferente al que los desarrolladores estaban acostumbrados, y la reacción fue ruidosa. Dos temas dominaron la discusión: un nuevo requisito de retención de datos de 30 días para el tráfico de Fable y Mythos, y una serie de cambios en las barreras de seguridad que llegaron sin mucho aviso. Si ejecutas algo contra la API de Claude en producción, estos cambios te afectan directamente.
Esta publicación separa el ruido de las partes que afectan tu código. Verás qué cambió supuestamente, qué sigue funcionando de la misma manera que la semana pasada y cómo verificar tu propia integración con Apidog en lugar de adivinar. Si mantienes una integración de Claude, la medida más segura ahora mismo es probar tus suposiciones, no confiar en ellas.
Qué cambió realmente
Tres cosas se están confundiendo en la discusión. Sepáralas y la imagen se vuelve más clara.
Retención de datos. El cambio principal es una ventana de retención de 30 días aplicada a las solicitudes de Fable y Mythos. En la práctica, esto significa que los datos de solicitud y respuesta vinculados a esos modelos se retienen durante un período fijo en lugar de eliminarse inmediatamente. Los equipos con estrictos compromisos de manejo de datos se preocupan por esto porque cambia lo que puedes prometer a tus propios usuarios. Si tu política de privacidad dice "no retenemos los prompts", el comportamiento de retención de tu proveedor upstream ahora forma parte de esa afirmación.
Barreras de seguridad (Guardrails). Un hilo separado cubrió los cambios en las barreras de seguridad de Fable que algunos investigadores de seguridad rechazaron. La queja no fue que existan barreras de seguridad; fue que el comportamiento cambió silenciosamente, por lo que las respuestas que pasaron ayer podrían ser filtradas o reformadas hoy. Para una aplicación que depende de una salida consistente, un cambio silencioso en el comportamiento de rechazo es una verdadera fuente de errores.
Acceso programático. Esta es la parte en la que la mayoría de los desarrolladores realmente necesitan actuar. La superficie de la API, el modelo de autenticación y la forma principal de la solicitud no han sido reemplazados. Tus claves existentes, tus llamadas a `messages` y tu esquema de uso de herramientas siguen funcionando. Lo que puede cambiar por debajo es el comportamiento: qué prompts son rechazados, cuánto tiempo tardan las llamadas bajo carga y cómo se ve una respuesta transmitida cuando una barrera de seguridad se activa a mitad de la generación.
La versión corta: el contrato es estable, el comportamiento no está garantizado como estable y la política sobre tus datos es más estricta. Esa combinación es exactamente para lo que sirve la prueba.
Qué sigue funcionando
Antes de reescribir nada, confirma lo que no ha cambiado para que no soluciones problemas que no tienes.
- Autenticación. Las claves de API y el encabezado `x-api-key` funcionan como antes. No necesitas rotar las claves debido a estos cambios, aunque la rotación de claves es una buena práctica de higiene independientemente. Consulta la referencia de la API de Anthropic para conocer el contrato de encabezado actual.
- La forma de la API de Messages. El cuerpo de la solicitud, el campo `model`, `max_tokens`, los prompts `system` y el array `messages` no han cambiado. El código escrito para la API de Messages sigue funcionando.
- Uso de herramientas. Tus definiciones de herramientas y el ciclo de `tool_use` / `tool_result` se comportan de la misma manera. Si construiste un agente utilizando llamadas a funciones, el cableado se mantiene.
- Streaming. Los eventos enviados por el servidor siguen transmitiendo tokens de la misma manera. Lo que puede diferir es el contenido de la transmisión cuando una barrera de seguridad interviene a la mitad.
- Alias de modelos. Si fijas un modelo por su ID completo en lugar de un alias flotante, controlas exactamente qué modelo responde. Fijar es tu mejor defensa contra la deriva silenciosa del comportamiento.
Así que nada fuerza una reescritura de emergencia. El trabajo es la verificación: probar que el comportamiento del que depende tu aplicación sigue siendo válido, y detectar los casos en los que silenciosamente no lo es.
Cómo probar tu integración con Apidog
Aquí es donde un cliente de API real se gana su lugar. Puedes leer los changelogs todo el día, pero la única forma de saber cómo responde tu integración es enviando solicitudes e inspeccionando lo que regresa. Apidog te ofrece un espacio de trabajo para diseñar esas solicitudes, guardarlas, simular el upstream y ejecutarlas como comprobaciones automatizadas. Si te has movido de Postman o nunca estandarizaste, este es un lugar limpio para empezar; aquí está el caso más amplio para las pruebas de API sin Postman.
1. Captura una línea base conocida y buena
Crea una solicitud en Apidog que llegue a la API de Messages con un prompt que te interese; un prompt de producción representativo, no un juguete. Fija la ID completa del modelo. Guarda la respuesta. Esta es tu línea base. Cuando el comportamiento cambie más tarde, compararás con esta respuesta guardada en lugar de confiar en la memoria.
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: ..." }
]
}
Almacena la clave de API como una variable de entorno en Apidog en lugar de codificarla. Esto mantiene la clave fuera de tus solicitudes guardadas y te permite alternar entre staging y producción con un solo desplegable. El mismo patrón funciona ya sea que estés probando Claude, el SDK de Claude Code, o cualquier otro modelo detrás de la misma clave.
2. Afirma sobre la respuesta, no la examines a ojo
Una línea base solo es útil si la verificas automáticamente. En Apidog, añade aserciones a la solicitud:
- El estado es `200`.
- `stop_reason` es `end_turn`, no `max_tokens` o un rechazo.
- El cuerpo de la respuesta contiene el campo estructurado que analiza tu aplicación (por ejemplo, una etiqueta de prioridad).
- El tiempo de respuesta se mantiene por debajo de tu presupuesto de tiempo de espera.
Ahora tienes una prueba, no una captura de pantalla. Ejecútala en un horario y te enterarás el día que un cambio en las barreras de seguridad comience a filtrar un prompt que solía pasar. Esta es la misma disciplina detrás de las pruebas de contrato de API; estás fijando el comportamiento que tu código downstream asume.
3. Prueba los caminos de rechazo y de barrera de seguridad a propósito
Las quejas sobre las barreras de seguridad importan porque los rechazos son fáciles de ignorar hasta que rompen un flujo de trabajo. Construye un pequeño conjunto de solicitudes que se encuentren cerca de tus límites de contenido y guarda las respuestas. Si un prompt previamente aceptado comienza a ser rechazado o reformado, tu aserción fallará y lo sabrás antes que tus usuarios. Trata el comportamiento de rechazo como un contrato probado, no como una ocurrencia tardía.
4. Simula Anthropic para que tus propias pruebas no dependan de la API en vivo
No querrás que tu suite de CI llame a un servicio upstream de pago, con límite de velocidad y comportamiento cambiante en cada ejecución. El servidor de mock de Apidog te permite levantar un endpoint falso de Messages que devuelve respuestas predefinidas; incluyendo las formas de rechazo y error que capturaste anteriormente. Apunta tu aplicación al mock durante el desarrollo y las pruebas de integración. Tu código ejercitará la estructura de respuesta real sin gastar tokens ni exceder los límites de velocidad. Cuando quieras lo real, simplemente cambia la URL base. ¿Construyendo un agente sobre esto? El mismo patrón de mock es la columna vertebral de una buena configuración de pruebas de agentes de IA.
5. Verifica el comportamiento sensible a la retención
Si la ventana de retención de 30 días es importante para tu historia de cumplimiento, documéntala donde tu equipo la vea y prueba los controles que tengas. Confirma qué endpoints llamas, qué datos salen de tu sistema en cada solicitud y si estás enviando más de lo necesario. El historial de solicitudes de Apidog facilita la auditoría de exactamente qué cargas útiles envía tu integración, para que puedas eliminar cualquier cosa sensible que no necesite estar en el prompt. No puedes cambiar la política de retención de Anthropic, pero puedes controlar lo que le entregas.
6. Prueba bajo carga y tiempos de espera
El comportamiento bajo carga es donde se esconden los cambios silenciosos. Utiliza Apidog para ejecutar la misma solicitud repetidamente y observar si hay un aumento de la latencia, transmisiones parciales o activaciones intermitentes de las barreras de seguridad. Establece un tiempo de espera realista y una política de reintentos en tu cliente, luego prueba que tu reintento realmente maneja una respuesta lenta o truncada en lugar de agravar el problema. Si estás viendo lentitud en el upstream, el enfoque de depuración en solucionar los tiempos de espera de solicitudes upstream se aplica directamente.
Una lista de verificación práctica
Revisa esto una vez y sabrás exactamente dónde te encuentras:
- [ ] Fija las IDs completas de los modelos; deja de depender de alias flotantes para las rutas de producción.
- [ ] Guarda una respuesta de línea base para cada prompt del que dependa tu aplicación.
- [ ] Agrega aserciones sobre el estado, `stop_reason` y los campos que analizas.
- [ ] Captura las formas de rechazo y error; asegura que no cambien silenciosamente.
- [ ] Simula la API de Messages para que CI no acceda al endpoint en vivo.
- [ ] Audita las cargas útiles de salida con la ventana de retención de 30 días.
- [ ] Prueba el comportamiento de tiempo de espera y reintentos bajo carga repetida.
Nada de esto requiere esperar a que Anthropic publique más detalles. Tú controlas la verificación, y la verificación es lo que convierte un titular de política en un no-evento para tu equipo.
Preguntas Frecuentes
¿Necesito cambiar mis claves de API debido a los cambios de Fable y Mythos? No. La autenticación no ha cambiado. Rotar las claves periódicamente sigue siendo una buena práctica, pero estos cambios no la fuerzan.
¿Mi código existente de la API de Messages y de uso de herramientas dejará de funcionar? El contrato de solicitud y respuesta es estable, por lo que tu código sigue funcionando. Lo que sí puede cambiar es el comportamiento: rechazos, latencia y contenido transmitido bajo las barreras de seguridad. Eso es un problema de pruebas, no de reescritura.
¿Qué es el cambio de retención de 30 días? Los informes describen una ventana de retención de 30 días aplicada al tráfico de Fable y Mythos. Si tus propios compromisos de privacidad dependen del comportamiento de retención del proveedor upstream, ten esto en cuenta y confirma qué datos envías realmente. Consulta siempre la documentación actual de uso de datos de Anthropic para conocer los términos autorizados.
¿Cómo detecto los cambios en las barreras de seguridad antes que los usuarios? Guarda las respuestas de referencia para los prompts cercanos a tus límites de contenido, añade aserciones y ejecútalas periódicamente en Apidog. Una aserción fallida te indicará el día en que el comportamiento cambie.
¿Puedo probar todo esto sin gastar tokens? Sí. Utiliza el servidor de mocks de Apidog para reproducir las respuestas capturadas, incluyendo los casos de rechazo y error, para que tus ejecuciones de desarrollo y CI nunca toquen la API en vivo.
Conclusión
Los cambios de Fable y Mythos son reales, pero para la mayoría de los desarrolladores son una historia de comportamiento y política, no una historia de API rota. Tus claves funcionan, tus llamadas a Messages funcionan, tus herramientas funcionan. La exposición está en las partes que se mueven silenciosamente: rechazos, latencia y lo que sucede con tus datos después de que salen de tu sistema. Fija tus modelos, captura líneas base, haz aserciones sobre ellas y simula el upstream para que tus pruebas sigan siendo económicas y honestas. Descarga Apidog y convierte "creo que todavía funciona" en "lo comprobé, y aquí está la prueba".