Atualizar um modelo muda o contrato de integração, não apenas seu identificador

A Anthropic lançou Claude Sonnet 5.5 em 28 de setembro e anunciou ganhos de velocidade e eficiência por tarefa. Para equipas que constroem os seus próprios pedidos à Messages API, o guia de migração merece tanta atenção quanto os números de desempenho. Descreve mudanças nos parâmetros aceites e no tratamento das conversas. Já para utilizadores de Claude Managed Agents, a Anthropic afirma que basta atualizar o nome do modelo. A análise seguinte trata de integrações próprias com a API. [1] [2]

Um teste rápido de um único turno pode deixar passar dois problemas diferentes: um pedido que falha imediatamente e outro que termina com um contexto diferente. Cada caso pede um critério de aceitação próprio. Uma resposta HTTP bem-sucedida prova que o serviço respondeu, não que a aplicação preservou o seu fluxo de trabalho. Esta distinção deve orientar o plano de migração.

Sonnet 5 aceitava thinking: {"type": "disabled"}. Sonnet 5.5 rejeita essa configuração com erro 400. A configuração mínima de raciocínio é between_tools, disponível nos níveis de esforço low, medium e high; xhigh e max rejeitam-na. Isto muda o contrato do pedido, não apenas uma preferência de ajuste. Equipas que desativavam o raciocínio para controlar a latência precisam de escolher deliberadamente a nova configuração e voltar a medir o fluxo de trabalho, em vez de presumir que o pedido antigo continuará a funcionar. [2]

O modo between_tools elimina o raciocínio estendido antes da resposta, mas as atualizações de progresso entre chamadas a ferramentas ainda podem surgir em blocos thinking. O ciclo de ferramentas tem de reenviar esses blocos intactos com a mensagem completa do assistente. Convém rever leitores que pressupõem que o primeiro bloco de conteúdo é texto ou que reconstroem um turno apenas com texto e chamadas a ferramentas. Para ler, use o tipo de cada bloco; para continuar a conversa, preserve o turno do assistente exatamente como foi devolvido. [2] [6]

Sonnet 5.5 rejeita os valores de tool_choice que forçam uma chamada: tool e any. A Anthropic recomenda auto com esquemas strict para ferramentas, quando a plataforma oferece esse suporte. O modo estrito limita a estrutura dos argumentos de uma chamada que de facto ocorra; auto ainda permite que o modelo responda sem chamar qualquer ferramenta. O Amazon Bedrock não oferece strict tool use para este modelo, pelo que a aplicação tem de validar os argumentos nessa plataforma. [2] [4]

A distinção importa para o resultado operacional. Se um fluxo precisa de consultar o registo atual antes de responder, uma resposta bem formatada não prova que a consulta ocorreu. Considere a etapa concluída apenas após receber e validar o resultado da ferramenta exigida. Implemente esta regra na aplicação e teste os dois caminhos: uma chamada válida e uma resposta direta quando a chamada era obrigatória. Esta é uma inferência arquitetónica a partir do comportamento documentado, não uma afirmação sobre a frequência com que Sonnet 5.5 deixa de usar ferramentas.

Os blocos thinking de Sonnet 5.5 só podem ser reutilizados pela conta que os produziu ou por uma conta vinculada. Se uma conta não vinculada os reenviar, a API descarta-os antes da inferência e o pedido é concluído; sem o cabeçalho de diagnóstico correspondente, o descarte é silencioso. Uma troca de modelo também pode tornar um bloco ilegível. Portanto, uma resposta bem-sucedida do sistema de encaminhamento não prova que o modelo recebeu o raciocínio anterior. [3]

Há ainda uma regra de prefixo: instruções system, ferramentas e mensagens anteriores têm de permanecer inalteradas quando um bloco thinking assinado é reenviado. Contas criadas em 31 de agosto de 2026 ou depois têm esta verificação ativada por predefinição; as mais antigas seguem outra configuração predefinida. Por isso, um teste sem erros com uma chave não serve de garantia para todos. Preserve o histórico acrescentando apenas mensagens e teste a retoma de sessões guardadas, alterações nas ferramentas, cortes do histórico no cliente e mudanças de rota. Quando disponível, consulte input_transformations para identificar blocos descartados. [3]

O guia de migração também pede que as recusas sejam tratadas. Uma recusa deve entrar na lógica de resposta e revisão do produto; reenviar o pedido às cegas como se a rede tivesse falhado confunde uma decisão de política com uma indisponibilidade do serviço. A Anthropic documenta um fallback opcional no servidor para certas categorias de recusa na Claude API, sob condições específicas. Isto não torna toda a recusa passível de nova tentativa nem promete o mesmo comportamento em todas as plataformas. [5]

Nos testes de aceitação, registe o motivo real da interrupção, se um fallback oficialmente configurado foi acionado e o que o utilizador viu. Assim, o tratamento de segurança fica observável sem usar uma nova tentativa de baixo nível para contornar a recusa. Também se evita que um painel baseado apenas em respostas HTTP bem-sucedidas esconda mudanças nas respostas recebidas pelos utilizadores.

Propomos cinco caminhos de aceitação: um pedido antigo com raciocínio desativado; uma chamada a uma ferramenta antes imposta; uma troca de vários turnos que reenvie blocos thinking; uma conversa guardada e retomada com a conta e o encaminhamento reais; e uma recusa tratada pelo produto. Verifique o estado HTTP, os tipos de bloco, a execução e validação das ferramentas, os diagnósticos de continuidade disponíveis e o estado final visível ao utilizador. Inclua uma sessão longa e uma mudança de rota, pois um teste rápido de um único turno não revela erros no histórico.

Só então compare a taxa de tarefas aceites, o tempo total e o custo por tarefa aceite num nível de esforço declarado. Os números de velocidade e custo da Anthropic são hipóteses úteis para essa experiência, não substitutos para medições na sua própria carga de trabalho. A lição vai além deste lançamento: o modelo faz parte de um protocolo entre aplicação, ferramentas, histórico e utilizadores. A atualização só está concluída quando esse protocolo continua a entregar o resultado esperado. [1]