Depois do Claude Sonnet 5.5, o preço não mudou — por que a extração JSON ainda dá 400. De between_tools ao JSON Schema

Conclusão primeiro: o Sonnet 5.5 mantém cada linha da tabela de preços e muda o contrato do request. Em 28 de setembro de 2026 a Anthropic lançou o Claude Sonnet 5.5 (claude-sonnet-5-5). Input / output ficam $2 / $10; cache reads ficam $0.20. A Anthropic diz que o output é 30%+ mais rápido e a maior parte do trabalho custa cerca de 30% menos — essa economia é tokens por tarefa, não o adesivo. O que quebra produção são os switches antigos copiados do Sonnet 5: thinking: {"type": "disabled"} devolve 400; os valores any e tool de tool_choice devolvem 400; um temperature, top_p ou top_k fora do padrão também é 400. A armadilha mais quieta é a extração de JSON: num request sem tools, between_tools significa que o modelo não pensa primeiro, e o Structured Output ainda sai torto. A página de prompting da Anthropic classifica esse caso em “Reasoning tasks with JSON output.”

Escrito em 29 de setembro de 2026, contra a página de modelos, o What’s new e o guia de migração ainda atuais naquele dia. Este site já tem por que o Opus 5.5 não deixa você forçar JSON com tool_choice (24 de setembro). Este texto não reescreve aquelas quatro falhas. Só responde o que um pipeline JSON de Sonnet 5 → 5.5 precisa mudar por cima. O Haiku 5.5 ainda é “in the coming weeks.” Este artigo não empresta essa data.

O que saiu em 28 de setembro

O Claude Sonnet 5.5 é o segundo modelo da família Claude 5.5. Posicionamento oficial: o meio entre velocidade e inteligência; coding do dia a dia, correção de bugs, documentos e planilhas. O ID é claude-sonnet-5-5 na Claude API, no Google Cloud, no Microsoft Foundry e no Claude Platform on AWS; o Bedrock usa anthropic.claude-sonnet-5-5. A aposentadoria não é antes de 28 de setembro de 2027. O tokenizer é o mesmo do Sonnet 5, então o mesmo texto produz a mesma contagem de tokens.

Preços por milhão de tokens: $2 in, $10 out, $2.50 para um cache write de 5 minutos, $4 para um cache write de 1 hora, $0.20 para um cache read. Batch é metade do preço. Contexto é 1M; output máximo síncrono é 128K. Message Batches chegam a 300K com output-300k-2026-03-24. O prompt mínimo cacheável cai dos 1.024 tokens do Sonnet 5 para 512. O effort padrão é high — o Opus 5.5 defaulta para medium. Omita effort e o request roda em high. Isso não é compatibilidade silenciosa com o Sonnet 5.

O lançamento posiciona o Sonnet 5.5 como o complemento mais rápido e mais barato do Opus 5.5. Este artigo não escolhe um modelo a partir de um leaderboard. O que importa é que a tabela de preços ficou parada enquanto thinking, tool_choice e o contrato de extração JSON se moveram.

Cinco falhas duras, uma tabela

A documentação lista os requests que viram 400 no 5.5. Os três primeiros compartilham a raiz com o Opus 5.5 e o Fable 5.1. O substituto da primeira linha é diferente:

Mais uma mudança não falha o request, mas fica quieta: notas mais longas entre tool calls chegam como thinking blocks. No padrão display: "omitted" o texto vem vazio. Uma UI que transmitia essas frases como barra de progresso fica muda. Para progresso no thinking adaptativo, defina thinking.display (updates precisa de um header beta). between_tools devolve o texto de resumo, e esse type rejeita um campo display.

Sampling não é mais um knob. Um temperature, top_p ou top_k fora do padrão é um 400. Requests que usavam temperature mais baixa para “estabilizar JSON” agora têm de estabilizar o schema.

disabled acabou; between_tools é o piso

O Sonnet 5 desligava thinking com disabled. No 5.5 essa linha é um 400 cuja mensagem aponta para between_tools. O setting mais baixo fica assim:

{
  "model": "claude-sonnet-5-5",
  "thinking": { "type": "between_tools" },
  "output_config": { "effort": "high" }
}

between_tools não precisa de header beta e é aceito em toda plataforma que oferece o modelo. Ele desliga só o thinking antecipado. Notas de progresso mais longas entre tool calls ainda voltam como thinking blocks. Ecoe-as sem modificar; o modelo recebe a nota completa, não o resumo. Sem tools, a resposta costuma ser só text — o formato antigo do disabled.

Os limites são rígidos. Ele é aceito em low / medium / high. Emparelhe com xhigh ou max e você leva 400. Adicione display, budget_tokens ou block_binding e também leva 400. Uma mudança no meio da conversa em output_config.effort é um 400 — effort por turno precisa de thinking adaptativo. Quando o fallback no servidor cai no Sonnet 5, between_tools é traduzido para disabled lá.

Então o 5.5 não força thinking a ficar na profundidade máxima. Ele remove o switch antigo disabled. Com o switch fora, quem quer thinking desligado tem de enviar um type novo. Quem quer JSON estável muitas vezes não deveria desligar — veja a seção seguinte.

Para extração JSON sem tools, não desligue thinking

A página de prompting da Anthropic tem uma seção só para isso: dê ao Sonnet 5.5 uma tarefa JSON que precisa de alguns passos (totais, uma regra, um ranking) e em low / medium ele muitas vezes responde sem pensar primeiro. Com Structured Output, o texto visível só pode ser JSON, então o trabalho só pode acontecer no thinking. Pule thinking e a acurácia cai.

A ordem documentada é:

1. Use Structured Output quando puder. O body vira um objeto que bate com o schema. Você não faz JSON.parse da prosa do chat. Veja o que é Structured Output.
2. Use thinking adaptativo, não between_tools. Num request sem tools, between_tools significa não pensar primeiro. Uma linha “think before you answer” no prompt não tem efeito ali. Separar “resposta, depois JSON” em dois requests foi bem nos testes deles e custou latência e tokens demais para ser o padrão.
3. Termine o system prompt com Think the problem through before you answer. Em high, a acurácia se aproxima de xhigh com um extra modesto de tokens de output. Em low / medium também sobe, com custo de tokens maior.
4. Deixe folga em max_tokens para o thinking. Com Structured Output em low / medium, o modelo ocasionalmente pensa até o teto. Trate uma resposta cujo stop_reason é max_tokens como falha mesmo se o texto for JSON válido, e tente de novo.

Sem Structured Output, o modelo muitas vezes trabalha na prosa e põe o JSON no final. Fazer parse da resposta inteira falha. O fallback documentado: leia só text blocks, tente um parse a partir de cada { ou [, e fique com o último valor completo. Não pegue o intervalo do primeiro { até o último } — um rascunho pode ficar no meio. Veja por que o JSON.parse falha. Isso é fallback, não contrato.

Tools forçadas são um 400, igual ao Opus 5.5

A família 5.5 compartilha o mesmo erro:

tool_choice: type "tool" and "any" are not supported for this model.

O substituto continua: mantenha tool_choice em auto, ligue strict: true na tool e fixe os parâmetros com JSON Schema. Ponha a resposta final no Structured Output. Se você quer que o modelo chame uma tool em vez de responder em prosa, diga no prompt quando a tool se aplica. O prompt influencia qual tool o auto escolhe. Ele não substitui o schema. A versão longa está em por que o Opus 5.5 não deixa você forçar JSON com tool_choice e por que o Tool Calling depende de JSON Schema.

O 5.5 adiciona uma nota de tolerância: de vez em quando chama uma tool com o case errado, ou um parâmetro com um nome um pouco diferente. Não trate isso como fatal. Aceite a chamada quando o match for único, ou devolva is_error: true com o nome exato. Mantenha o schema strict. O matching de nomes pode ser um ponto mais frouxo.

A tabela de preços não se moveu; o effort padrão é high

Os preços de tabela batem com o Sonnet 5. O oficial “cerca de 30% mais barato” é menos tokens por tarefa, não o cardápio. Textos independentes já mostram o outro lado: quando a tarefa não limita o próprio output, o modelo novo pode custar mais. Passe o mesmo schema por uma varredura de extração antes de mudar o roteamento.

Os níveis de effort foram recalibrados. O mesmo high não é a mesma quantidade de thinking que no Sonnet 5. A documentação começa em high para o dia a dia; medium para coding agentic bem especificado e loops de tool; medium ou low para chat e trabalho sensível a latência. Mudar o effort de nível superior quebra o prompt cache. Mudanças por turno precisam de effort per-message (beta) sob thinking adaptativo. between_tools não deixa o effort se mover no meio da conversa.

Não misture defaults com o Opus 5.5: aquele modelo defaulta para medium; o Sonnet 5.5 defaulta para high. Troque só a string do modelo e a conta e a latência saltam. Thinking blocks também não viajam livremente. O 5.5 consegue ler blocks do Sonnet 5, Opus 4.8, Haiku 4.5 e modelos anteriores. Ele não lê Opus 5, Opus 5.5, Fable nem Mythos. Nenhum outro modelo lê blocks do Sonnet 5.5. Mova uma conversa do Opus 5.5 para o Sonnet 5.5 e a API descarta o raciocínio. O request ainda devolve 200; blocks descartados não são cobrados.

Temperature, cache, computer use, advisor

Um temperature / top_p / top_k fora do padrão é um 400. Pipelines que “apertavam o JSON” com sampling agora têm de apertar o schema. O piso de cache é 512 tokens, então system prompts curtos entram no cache com mais facilidade. Mudar o effort de nível superior ainda invalida esse cache.

Na Claude API e no Google Cloud, computer use só aceita computer_toolset_20260801. O Bedrock ainda aceita computer_20251124. A tool advisor (beta) não deixa um executor 5.5 emparelhar com Opus 4.8 / 4.7 ou Sonnet 5. Advisors que o 5.5 aceita devolvem blocks advisor_redacted_result criptografados; o cliente não consegue ler o texto do conselho.

Para mudar um schema de tool no meio da conversa, inline-tools-2026-09-15 pode carregar uma definição completa numa system message no meio da conversa, sem editar o array tools de nível superior. É a mesma regra do thinking amarrado ao prefixo: faça append no histórico. Compaction (compact-2026-09-04) pode trocar por um resumo assinado e manter o thinking válido, nas condições da página de Compaction da Anthropic.

Cinco checagens antes de mudar a string do modelo

1. Busque thinking. Remova disabled e budget_tokens. Para desligar o thinking antecipado, envie between_tools em high ou abaixo. Para tarefas de raciocínio JSON, use thinking adaptativo.
2. Busque tool_choice. Troque todo any / tool nomeado por auto. Ligue strict e aperte o input_schema.
3. Busque temperature / top_p / top_k. Apague os que não forem o padrão. Estabilize JSON com o schema, não com sampling.
4. Defina effort explicitamente. Não herde o high padrão. Roteamento compartilhado com o Opus 5.5 tem dois defaults diferentes.
5. Replay e cache. Em contas pós-31 de agosto, não edite tools ou system no histórico. Vindo do Opus 5.5, espere que thinking blocks sejam descartados.

Inspecione o schema com ferramentas JSON locais

Antes de pôr o modelo em claude-sonnet-5-5, abra três textos no navegador: o input_schema antigo, um objeto arguments que você pegava com disabled ou um tool_choice forçado, e o schema que pretende pôr no Structured Output.

• Validador JSON — a gramática é legal; se você tem schema, cheque campos required e chaves a mais juntos.
• Formatador JSON — expanda uma definição de tool numa linha e veja se additionalProperties está definido.
• JSON Diff — compare uma amostra com thinking desligado com o menor objeto que o schema strict permite.

Nada sai do navegador. Estabilize o contrato, depois mude a string do modelo. O 5.5 vai mudar o effort e rejeitar disabled e o tool_choice antigo. Seus nomes de campo e a lista required não deveriam afrouxar junto.

FAQ

Resumo

O Sonnet 5.5 segura a tabela de preços e transforma disabled em 400. Copie um request do Sonnet 5 e você falha duro em thinking, tool_choice e temperature. Para desligar o thinking antecipado, envie between_tools. Para JSON estável, use thinking adaptativo mais Structured Output, ou auto mais strict mais JSON Schema. Numa tarefa de raciocínio sem tools, desligar thinking é uma queda de acurácia já medida.

Achate o schema, um objeto arguments de amostra e o contrato strict num validador local primeiro, depois troque para claude-sonnet-5-5. O adesivo pode ficar. O contrato de campos não deveria afrouxar junto.