AIREITERO Anthropic Python SDK v1.0 chegou ao PyPI em 20 de agosto de 2026, e a maior parte do código que faz chamadas à API continua funcionando sem alterações. O risco real está onde quase ninguém olha: a camada HTTP saiu de httpx para httpx2. Com isso, rastreamento, agentes de APM e mocks de teste que fazem patch em httpx podem seguir em execução enquanto deixam de registrar, silenciosamente, todas as requisições do SDK. Se os testes passam depois do upgrade, isso prova menos do que parece.
Três versões em dois dias antes do 1.0
O histórico de releases do anthropic no PyPI resume bem a sequência: 0.123.0, 0.124.0 e 0.125.0 foram publicadas em 19 de agosto de 2026; no dia seguinte, 20 de agosto, saiu a 1.0.0 via o processo padrão de Trusted Publishing.
Segundo as notas oficiais de lançamento, estas são as mudanças:
- A camada HTTP deixa o
httpxe passa a usarhttpx2, um fork compatível com a API e mantido ativamente. - Agora é necessário Python 3.10 ou superior; os classificadores incluem as versões 3.10 a 3.14.
- Recursos descontinuados há bastante tempo foram removidos: a API legada Text Completions, os parâmetros
temperature,top_petop_knos métodos de Messages, além decompaction_controlno lado do cliente do tool runner. AnthropicBedrockpassa a gerar erro quando nenhuma região AWS está configurada, em vez de assumir silenciosamenteus-east-1.
A tag v1.0.0 no GitHub descreve o lançamento como "upgrade to httpx2 and some minor breaking changes". Há ainda um detalhe fácil de deixar passar nas notas: o aviso beta das funções auxiliares parse, stream e tool_runner desapareceu. Uma versão 1.0 sem essas ressalvas indica que a Anthropic agora considera essa superfície estável.
Na prática, o que muda de httpx para httpx2
Quem instancia o cliente da forma mais simples provavelmente não percebe mudança alguma. Mas quem interage com a camada HTTP precisa revisar tudo.
O divisor de águas é o que você entrega ao cliente. Valores numéricos continuam válidos — Anthropic(timeout=30.0) se comporta exatamente como antes. Já objetos deixam de ser intercambiáveis: passar um httpx.Client comum em http_client= agora gera TypeError durante a construção do cliente, e não na primeira requisição. Clientes personalizados, timeouts e transports devem ser criados com httpx2. E os objetos httpx.Timeout viram anthropic.Timeout ou 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"))Os nomes e o comportamento de DefaultHttpxClient e DefaultAsyncHttpxClient não mudaram. Eles continuam preservando os valores recomendados pelo SDK para timeout, pool de conexões e redirecionamentos — agora sobre httpx2. O anúncio de um funcionário da Anthropic, o engenheiro de platform devx @cjav_dev, aponta para o mesmo ponto de partida recomendado: o MIGRATION.md oficial, que lista cada mudança com exemplos de antes e depois.
Essa não é a primeira migração desse tipo. O guia de migração para httpx2 do OpenAI Python SDK percorreu o mesmo caminho antes, inclusive com o mesmo fork, o padrão de helper DefaultHttpx2Client e os mesmos alertas sobre compatibilidade com respx. Equipes que já migraram o pacote openai podem reaproveitar quase integralmente o procedimento.
Tudo o que foi removido no v1.0
| Removido no v1.0 | Alternativa |
|---|---|
client.completions.create() (Text Completions) | client.messages.create() |
Constantes HUMAN_PROMPT / AI_PROMPT | Blocos de conteúdo no formato Messages |
temperature, top_p, top_k nas assinaturas dos métodos | extra_body={"temperature": ...} para modelos legados que ainda os aceitam |
messages.parse(stream=True) | messages.stream(...) |
tool_runner(compaction_control=...) | Configuração de compactação no servidor |
Aliases anthropic.Transport, anthropic.ProxiesTypes | Tipos de transport do httpx2 |
body= em métodos de requisição de baixo nível | content= |
Dicionário de schema output_format nas APIs beta | output_config={"format": ...} (os helpers de saída estruturada ainda aceitam output_format=MyModel) |
Verificações isinstance(stream, anthropic.Stream) | Verifique o tipo concreto MessageStream |
Há duas observações importantes sobre essa tabela. Pydantic v1 e v2 continuam suportados, portanto as classes de modelo estão seguras. Além disso, a mesclagem de headers agora ignora maiúsculas e minúsculas. Isso altera o comportamento caso você defina duas vezes o mesmo header com grafias diferentes — um caso de borda, mas que não gera erro quando acontece.
Mudanças assíncronas que afetam usuários de raw response
As alterações no modo assíncrono são pontuais, mas podem ser bem desagradáveis para quem usa .with_raw_response. No cliente assíncrono, parse(), read(), text() e json() agora exigem await. No cliente síncrono, .text e .content deixaram de ser propriedades e viraram métodos. Nenhuma dessas mudanças falha no import: no caso síncrono, o erro é evidente, com attribute error; no assíncrono, pode ser sutil se você não fez await e recebeu uma coroutine que nunca foi executada.
Outro ponto relacionado: objetos de request e response presentes em exceções e resultados brutos agora são tipos do httpx2. O acesso a atributos tende a continuar igual, mas verificações como isinstance(x, httpx.Response) e as anotações de tipo precisam ser atualizadas. É exatamente o tipo de problema que pyright e mypy conseguem encontrar.
A falha de migração que você não enxerga
Este é o ponto que o changelog resume em uma frase, mas que seu dashboard de monitoramento não vai perdoar. Conforme o guia de migração da Anthropic, ferramentas que observam ou simulam tráfego HTTP fazendo patch em httpx — OpenTelemetry, Sentry, respx, pytest-httpx, vcrpy — podem continuar em execução após o upgrade e, ainda assim, deixar de capturar silenciosamente as requisições do SDK. Elas continuam importando, rodando e emitindo relatórios; apenas não veem mais o tráfego que deixou de passar pela biblioteca corrigida via patch. Testes baseados nesses mocks podem passar sem validar nada quando não verificam se uma interceptação realmente ocorreu: nenhum tráfego chega ao mock, mas nada falha.
A saída é chamar httpx2.alias_httpx() o mais cedo possível na inicialização da aplicação ou dos testes. A documentação do Python SDK determina que isso ocorra antes de qualquer import de httpx. A função cria um alias de httpx2 sob o nome httpx, permitindo que ferramentas que fazem patch continuem funcionando. O guia de migração alerta para não chamá-la em código de biblioteca: use-a apenas no ponto de entrada da aplicação.
"Uma inicialização sem erros não prova que suas chamadas de IA continuam sendo rastreadas ou simuladas." — @MarMarLabs, em uma publicação no dia seguinte ao lançamento
Vale ler a publicação completa: a recomendação é tratar essa falha invisível como o primeiro teste da migração. Faça o upgrade e, em seguida, verifique deliberadamente se uma chamada rastreada e uma chamada simulada continuam sendo registradas. A mesma thread destaca os outros riscos silenciosos: transports personalizados que exigem migração manual para httpx2 e o requisito mínimo de Python 3.10, que pode quebrar imagens mais antigas de CI na instalação.
O que continua funcionando sem mexer no código
Para muitas bases de código, a resposta honesta é: não há nada a fazer. Você não é afetado pela mudança de HTTP se nunca cria clientes, transports ou objetos de timeout personalizados. Estes itens, especificamente, não mudam:
- Chamadas
client.messages.create(...)com parâmetros simples — mesma requisição e mesmos modelos de resposta. - Valores numéricos de timeout e os padrões do SDK: 2 tentativas com backoff exponencial para erros de conexão, 408, 409, 429 e 5xx; timeout padrão de 10 minutos.
- Roteamento por
base_url. Se você aponta o SDK para um gateway ou relay compatível com a API, como o endpoint da Claude API da AIReiter, a v1.0 não muda nada nessa camada — o que mudou foi o cliente, não a URL. - Modelos Pydantic v1 e v2, helpers de streaming SSE e interfaces de upload de arquivos.
O único bloqueio rígido é Python 3.10+. Todo o restante da lista de itens seguros pressupõe que você cumpra esse requisito primeiro.
Uma ordem de migração que passa no code review
- Faça o pin de propósito: se ainda não é hora de migrar,
anthropic>=0.125,<1mantém a versão enquanto você agenda o trabalho. - Faça grep na base por
import httpxehttpx.— cada ocorrência em código próximo ao SDK é um item de migração. - Execute
/claude-api upgrade pythonno Claude Code — comando recomendado no anúncio de lançamento de @cjav_dev — para gerar um diff das mudanças necessárias no projeto. - Reconstrua clientes, transports e timeouts personalizados com
httpx2ou os helpersDefaultHttpxClient. - Adicione
httpx2.alias_httpx()no ponto de entrada da aplicação caso algo faça patch emhttpx. - Rode pyright ou mypy — as mudanças de tipos do httpx2 aparecem como erros de anotações e de
isinstance. - No CI, valide uma requisição rastreada e uma requisição simulada por suíte de testes. Logs verdes na inicialização não são evidência.
Perguntas frequentes sobre o Anthropic Python SDK v1.0
O Anthropic Python SDK v1 já existe ou ainda está no 0.x?
Já existe. O anthropic 1.0.0 foi publicado no PyPI em 20 de agosto de 2026 e recebeu a tag v1.0.0 no GitHub, após a versão 0.125.0 no dia anterior. A página do projeto no PyPI agora direciona usuários do 0.x ao guia de migração para v1.
Como passo temperature, top_p ou top_k depois do v1.0?
Esses parâmetros saíram das assinaturas dos métodos. Para modelos legados que ainda os aceitam no servidor, use extra_body={"temperature": 0.7}. Vale observar que os modelos atuais retornam 400 para valores de amostragem fora do padrão de qualquer forma — essa mudança ocorreu no nível do modelo, não no SDK.
Testes com respx, pytest-httpx ou vcrpy ainda funcionam?
Não com o cliente padrão do SDK, e eles não vão gerar erro — simplesmente não encontrarão correspondência. Você pode chamar httpx2.alias_httpx() antes de qualquer import de httpx durante a inicialização dos testes ou migrar os mocks para httpx2.MockTransport. Uma versão do respx que faz patch apenas no httpx legado não consegue interceptar o tráfego do SDK.
O que faz o /claude-api upgrade python?
É um comando do Claude Code, recomendado no anúncio do engenheiro de devx da Anthropic @cjav_dev. Ele examina um projeto que usa anthropic 0.x e produz um diff de migração — imports, objetos de timeout e chamadas de raw response — para que você revise as alterações em vez de descobri-las por tracebacks.
Ficar no 0.125 ou migrar para o 1.0?
Não existe uma resposta certa para todos os casos; o que há é uma troca clara. Permanecer abaixo do 1.0 preserva cada mock, tracer e transport personalizado exatamente como foi construído, mas mantém o projeto em um SDK anterior à estabilidade, cuja política de versionamento permite mudanças incompatíveis em releases menores. Também significa seguir dependendo de uma superfície oficialmente obsoleta, como completions e parâmetros de amostragem. Migrar para 1.0 traz uma API estável e sem rótulos beta, ao custo de realizar agora a auditoria completa da camada HTTP. O fator decisivo é quanto código de HTTP você mantém: um serviço com uma única chamada simples a Anthropic() faz o upgrade sem dificuldade; já uma plataforma com transports próprios e suítes respx precisa executar as verificações de falha silenciosa antes de colocar a mudança em produção.
Leituras relacionadas: a Skills API saindo do beta na mesma semana e os preços do Sonnet 5 se tornando permanentes em 10 de agosto — ambos parte da mesma sequência de lançamentos da Claude Platform.