AIREITERAnthropic Python SDK v1.0 llegó a PyPI el 20 de agosto de 2026 y, en la mayoría de los proyectos, el código que realiza las llamadas seguirá funcionando sin cambios. El riesgo serio está donde no se ve: la capa HTTP ha pasado de httpx a httpx2. Por eso, los trazadores, agentes APM y mocks de pruebas que parchean httpx pueden seguir ejecutándose mientras dejan de registrar silenciosamente todas las solicitudes del SDK. Que la batería de tests siga en verde tras actualizar no demuestra tanto como parece.
Tres versiones en dos días y, después, la 1.0
El historial de versiones en PyPI de anthropic lo resume en cinco líneas: 0.123.0, 0.124.0 y 0.125.0 se publicaron el 19 de agosto de 2026; 1.0.0 llegó al día siguiente como una publicación estándar mediante Trusted Publishing.
Según las notas de lanzamiento oficiales, estos son los cambios:
- La capa HTTP pasa de
httpxahttpx2, un fork mantenido y compatible a nivel de API. - Ahora se exige Python 3.10 o superior; los clasificadores incluyen de 3.10 a 3.14.
- Se elimina una superficie largamente deprecada: la API heredada Text Completions, los parámetros
temperature,top_pytop_kde los métodos Messages, ycompaction_control, que gestionaba la compactación en el cliente dentro del tool runner. AnthropicBedrocklanza ahora un error si no hay una región AWS configurada, en lugar de usar silenciosamenteus-east-1.
La etiqueta v1.0.0 en GitHub lo define como una «actualización a httpx2 y algunos cambios menores incompatibles». Hay además un efecto fácil de pasar por alto en las notas: ha desaparecido el aviso beta de los helpers parse, stream y tool_runner. Un número 1.0 sin advertencias de beta indica que Anthropic considera estable esta superficie de la API.
Qué cambia al pasar de httpx a httpx2
Si creas los clientes de la forma más simple, no notarás nada. Si interactúas con la capa HTTP, el cambio afecta a todo.
La diferencia está en lo que entregas al cliente. Los valores numéricos siguen funcionando: Anthropic(timeout=30.0) se comporta exactamente igual. Los objetos, no. Pasar un httpx.Client convencional mediante http_client= provoca ahora un TypeError al construir el cliente, no al lanzar la primera petición. Los clientes personalizados, timeouts y transportes deben crearse con httpx2; los timeouts que antes eran objetos httpx.Timeout pasan a ser anthropic.Timeout o httpx2.Timeout.
# 0.x
client = Anthropic(http_client=httpx.Client(proxy="http://proxy:8080"))
# 1.0
client = Anthropic(http_client=DefaultHttpxClient(proxy="http://proxy:8080"))DefaultHttpxClient y DefaultAsyncHttpxClient conservan tanto el nombre como el comportamiento: mantienen los valores recomendados por el SDK para timeout, pooling y redirecciones, ahora sobre httpx2. El anuncio de un empleado de Anthropic, el ingeniero de platform devx @cjav_dev, apunta al mismo punto de partida recomendado: el archivo MIGRATION.md oficial, con todos los cambios y ejemplos de antes y después.
Este movimiento tiene un precedente directo. La guía de migración a httpx2 del SDK de Python de OpenAI recorrió primero el mismo camino: el mismo fork, el mismo patrón de helpers DefaultHttpx2Client y las mismas advertencias de compatibilidad con respx. Los equipos que ya migraron openai pueden reutilizar su procedimiento casi palabra por palabra.
Todo lo que desaparece en v1.0
| Eliminado en v1.0 | Alternativa |
|---|---|
client.completions.create() (Text Completions) | client.messages.create() |
Constantes HUMAN_PROMPT / AI_PROMPT | Bloques de contenido con formato Messages |
temperature, top_p, top_k en las firmas de métodos | extra_body={"temperature": ...} para modelos heredados que aún los acepten |
messages.parse(stream=True) | messages.stream(...) |
tool_runner(compaction_control=...) | Configuración de compactación en el servidor |
Alias anthropic.Transport y anthropic.ProxiesTypes | Tipos de transporte de httpx2 |
body= en métodos de solicitud de bajo nivel | content= |
Diccionario de esquema output_format en APIs beta | output_config={"format": ...} (los helpers de salida estructurada siguen aceptando output_format=MyModel) |
Comprobaciones isinstance(stream, anthropic.Stream) | Comprobar el tipo concreto MessageStream |
Dos matices sobre la tabla. Pydantic v1 y v2 continúan siendo compatibles, así que las clases de modelos no presentan problema. Además, la combinación de cabeceras distingue ahora mayúsculas y minúsculas de forma insensible, lo que cambia el comportamiento si alguna vez defines la misma cabecera dos veces con distinta capitalización. Es un caso límite, pero no genera ningún error cuando ocurre.
Cambios asíncronos que afectan a usuarios de raw responses
Los cambios asíncronos son acotados, pero pueden ser desagradables si utilizas .with_raw_response. En el cliente asíncrono, parse(), read(), text() y json() requieren ahora await. En el cliente síncrono, .text y .content dejan de ser propiedades y pasan a ser métodos. Ninguno falla al importar: el caso síncrono falla de forma clara con un error de atributo; el asíncrono puede fallar de manera sutil si no esperaste nada y obtuviste una corrutina que nunca se ejecutó.
Relacionado con esto, los objetos de solicitud y respuesta incluidos en excepciones y resultados raw son ahora tipos de httpx2. El acceso a atributos suele funcionar igual, pero hay que actualizar las comprobaciones isinstance(x, httpx.Response) y las anotaciones de tipo. Precisamente es el tipo de detalle que pyright y mypy detectarán por ti.
El fallo de migración que no aparece en pantalla
Este es el punto que el changelog despacha en una frase y que tu panel de monitorización no te perdonará. Según la guía de migración de Anthropic, las herramientas que observan o simulan tráfico HTTP parcheando httpx —OpenTelemetry, Sentry, respx, pytest-httpx, vcrpy— pueden seguir funcionando tras la actualización mientras dejan de ver silenciosamente las solicitudes del SDK. Siguen importándose, ejecutándose e informando; simplemente ya no ven un tráfico que ha dejado de pasar por la biblioteca que parchean. Los tests basados en esos mocks pueden aprobar de forma vacía si no verifican que la intercepción se haya producido: ninguna solicitud llega al mock y nada falla.
La salida es httpx2.alias_httpx(), llamado en el punto más temprano posible del arranque de la aplicación o de los tests. La documentación del SDK de Python especifica que debe hacerse antes de cualquier importación de httpx. Esto registra httpx2 bajo el nombre httpx para que las herramientas de parcheo sigan funcionando. La guía de migración advierte que no debe llamarse desde código de biblioteca: únicamente desde el punto de entrada de la aplicación.
«Un arranque limpio no demuestra que tus llamadas de IA sigan trazadas o simuladas.» — @MarMarLabs, publicado al día siguiente del lanzamiento
Merece la pena leer la publicación completa: recomienda convertir este fallo invisible en la primera prueba de la migración. Actualiza y, después, verifica expresamente que se registra una llamada trazada y otra simulada. El mismo hilo señala los demás riesgos silenciosos: transportes personalizados que necesitan una migración manual a httpx2 e imágenes de CI antiguas que fallarán durante la instalación por el mínimo de Python 3.10.
Qué código sigue funcionando sin tocarlo
Para muchas bases de código, la respuesta honesta es sencilla: no hay nada que hacer. La migración HTTP no te afecta si nunca construyes clientes, transportes u objetos timeout personalizados. En concreto, esto no cambia:
- Llamadas a
client.messages.create(...)con parámetros básicos: misma solicitud y mismos modelos de respuesta. - Valores numéricos de timeout y valores predeterminados del SDK: 2 reintentos con backoff exponencial en errores de conexión, 408, 409, 429 y 5xx; un timeout predeterminado de 10 minutos.
- El enrutamiento mediante
base_url. Si apuntas el SDK a un gateway o a un relay compatible con la API, como el endpoint de Claude API de AIReiter, v1.0 no modifica esa capa: lo que ha cambiado es el cliente, no la URL. - Los modelos de Pydantic v1 y v2, los helpers de streaming SSE y las interfaces de subida de archivos.
El único requisito innegociable es Python 3.10 o superior. Todo lo demás en la lista de elementos seguros presupone que primero cumples ese requisito.
Un orden de migración que pasa una revisión de código
- Fija la versión de forma explícita: si todavía no estás listo,
anthropic>=0.125,<1mantiene el límite mientras programas el trabajo. - Busca en el código
import httpxyhttpx.: cada coincidencia en código próximo al SDK es un elemento de migración. - Ejecuta
/claude-api upgrade pythonen Claude Code, el comando que recomienda el anuncio de lanzamiento de @cjav_dev, para obtener un diff generado con los cambios de tu proyecto. - Reconstruye los clientes, transportes y timeouts personalizados con
httpx2o los helpersDefaultHttpxClient. - Añade
httpx2.alias_httpx()en el punto de entrada de la aplicación si algo parcheahttpx. - Ejecuta pyright o mypy: los cambios de tipos de httpx2 aparecerán como errores en anotaciones y en
isinstance. - En CI, verifica una solicitud trazada y una solicitud simulada por cada suite de pruebas. Los logs de arranque en verde no son una prueba.
Preguntas frecuentes sobre Anthropic Python SDK v1.0
¿Existe Anthropic Python SDK v1 o sigue en 0.x?
Sí existe. anthropic 1.0.0 se publicó en PyPI el 20 de agosto de 2026, con la etiqueta v1.0.0 en GitHub, después de 0.125.0 el día anterior. La página del proyecto en PyPI dirige ahora a los usuarios de 0.x a la guía de migración de v1.
¿Cómo paso temperature, top_p o top_k después de v1.0?
Han desaparecido de las firmas de métodos. Para los modelos heredados que todavía los acepten en el servidor, utiliza extra_body={"temperature": 0.7}. Ten en cuenta que los modelos actuales devuelven un 400 con valores de muestreo no predeterminados en cualquier caso: ese cambio ocurrió en el nivel de modelo, no en el SDK.
¿Siguen funcionando los tests con respx, pytest-httpx o vcrpy?
No con el cliente predeterminado del SDK, y no darán error: simplemente no coincidirán con nada. Llama a httpx2.alias_httpx() antes de cualquier importación de httpx durante el arranque de los tests, o migra los mocks a httpx2.MockTransport. Una versión de respx que solo parchee el httpx heredado no puede interceptar el tráfico del SDK.
¿Qué hace /claude-api upgrade python?
Es un comando de Claude Code, recomendado en el anuncio del ingeniero de Anthropic devx @cjav_dev, que analiza un proyecto que usa anthropic 0.x y genera un diff de migración —importaciones, objetos timeout, llamadas de raw response— para que revises los cambios en vez de descubrirlos mediante tracebacks.
¿Fijar 0.125 o pasar a 1.0?
No hay una respuesta correcta para todos los casos; este es el equilibrio real. Mantenerse por debajo de 1.0 conserva exactamente como están todos los mocks, trazadores y transportes personalizados, pero te deja en un SDK anterior a la estabilidad cuya política de versionado permite cambios incompatibles en versiones menores. También mantienes una superficie deprecada de la que dependes —completions y parámetros de muestreo— que oficialmente ya es lastre. Subir a 1.0 aporta una API estable y sin etiqueta beta, a cambio de realizar ahora la auditoría completa de la capa HTTP en vez de dejarla para otro día. La decisión depende de cuánto código posees en esa capa: un servicio con una sola llamada sencilla a Anthropic() se actualiza sin dificultad, mientras que una plataforma con transportes personalizados y suites respx debería realizar las comprobaciones de fallos silenciosos antes de desplegar.
Lecturas relacionadas: la salida de beta de Skills API esa misma semana y el carácter permanente del precio de Sonnet 5 el 10 de agosto, ambos dentro de la misma serie de lanzamientos de Claude Platform.