AI Watch · Anthropic & Claude
Claude Opus 4.1 retires today: how model lifecycles actually work
August 5, 2026 is the hard retirement date for claude-opus-4-1-20250805 on the Claude API. Two weeks later, Sonnet 5's introductory pricing expires. Together they're a good excuse to understand something most people learn the hard way: a model ID is not a permanent thing.
1. What happened, dated
- June 5, 2026 — Anthropic notified developers that Claude Opus 4.1 was being deprecated, with a scheduled API retirement.
- August 5, 2026 (today) —
claude-opus-4-1-20250805 retires. Requests to that model ID on the Claude API stop working. The recommended migration target is claude-opus-4-8.
- August 19, 2026 — the temporary 50% weekly usage boost for Claude Code subscribers ends.
- August 31, 2026 — Claude Sonnet 5's introductory pricing ($2 / $10 per million input / output tokens) ends. Standard pricing ($3 / $15) applies from September 1.
Notice the shape of that timeline: 60 days between the deprecation notice and the hard cutoff. Reporting on the change points out this is the same window Anthropic used for Claude Opus 4, and that it's the second retirement from the same provider in under two months — models now being retired roughly every 60–90 days after a successor ships.
2. The four-stage lifecycle
Anthropic documents a four-stage lifecycle that every model moves through. Understanding the vocabulary is the whole point, because the words are used precisely and people routinely conflate them:
| Stage | What it means | What you should do |
|---|
| Active | Fully supported, recommended for new work | Build on it |
| Legacy | Still works, but a newer model is now recommended | Start planning; no urgency yet |
| Deprecated | Officially on the way out, with an announced retirement date | Migrate — the clock is running |
| Retired | Requests to that model ID fail | Too late; you're down |
"Deprecated" is not "broken" and it is not "fine". It's a countdown. The single most common failure mode in production AI systems is treating a deprecation email as low-priority reading and finding out at retirement.
3. Why providers retire models at all
It's tempting to read retirements as hostile — you built on something and it was taken away. The actual pressures are more mundane:
- GPU capacity is finite and expensive. Every model kept online occupies accelerators that could be serving a newer, more capable, more efficient model. Serving an old model has a real opportunity cost measured in hardware.
- Each live model is a maintenance surface. Safety mitigations, evaluations, security patches, and infrastructure migrations all have to be applied per model. Ten live models is ten times the surface.
- Newer models are usually cheaper per unit of capability. The provider's incentive and the customer's incentive mostly point the same way — a successor typically does the same job for less.
- Fragmentation is a support burden. Documentation, prompting guidance, and behavioural expectations diverge across a long tail of old models.
The counter-argument is real too: retirements break reproducibility. If you published research or shipped a product whose behaviour was validated against a specific model, retirement means that exact behaviour is no longer reproducible anywhere. That's a genuine cost of the current industry norm, and there's an ongoing argument about whether providers should keep frozen snapshots available at a premium for exactly this reason.
4. The other deadline: Sonnet 5 pricing on Sept 1
Model retirement gets the attention, but the pricing deadline is arguably more consequential for anyone with real volume. Sonnet 5 launched at promotional rates of $2 per million input tokens and $10 per million output tokens. From September 1, 2026, standard rates of $3 / $15 apply.
That's a flat 50% increase on the per-token rate, on a date, with no code change on your side. If your product's unit economics were modelled at $2/$10, they are wrong as of September.
Worked example
A support-assistant feature handling 200M input tokens and 40M output tokens per month:
- At intro pricing: (200 × $2) + (40 × $10) = $800/mo
- At standard pricing: (200 × $3) + (40 × $15) = $1,200/mo
Same traffic, same code, +$400/mo. And that's before the tokenizer effect below.
5. The hidden multiplier: tokenizers
Here's the part that catches people, and it's a genuinely useful concept beyond this one price change. Reporting on the Sonnet 5 deadline notes that a new tokenizer adds roughly 30% more tokens for some workloads — meaning the effective cost increase from September 1 can exceed 50%.
Why? A tokenizer is the thing that chops your text into the units a model actually bills and reasons over. The same sentence can be 18 tokens under one tokenizer and 24 under another, depending on how the vocabulary was built. Change the tokenizer and you've changed your bill without changing a single character of your prompts.
Compounding the two effects on the example above: 260M billed tokens becoming ~338M at the higher rate pushes that $800 baseline past $1,500 — closer to doubling than to a 50% bump.
The lesson generalises: "price per million tokens" is only half of a cost estimate. The other half is how many tokens your actual text becomes — which is a property of the model, not of you. Never compare two providers on headline token price alone.
6. What this means if you build on an API
None of this requires panic, but it does require a couple of habits that separate systems that survive from systems that page someone at 3am:
- Never hardcode a model ID in more than one place. One constant, one config value, one environment variable. Migration should be a one-line change, not a grep across a codebase.
- Read the deprecation emails, and put the retirement date in a calendar. A 60-day window is generous if you notice on day 1 and brutal if you notice on day 55.
- Keep an evaluation set. Twenty or thirty representative inputs with known-good outputs. Swapping models is only scary when you have no way to tell whether the new one got better or worse at your task. With an eval set, migration becomes a measurement instead of a gamble.
- Re-test prompts on migration, don't just swap the string. Newer Claude models are documented as more literal and instruction-following — they do what you asked and not more. A prompt that relied on an older model inferring your intent may quietly under-deliver on a successor.
- Alert on cost, not just on errors. A pricing change or tokenizer change shows up as a spend graph bending, never as an exception.
7. Version pinning: a genuine tradeoff
Anthropic's model IDs carry dates (claude-opus-4-1-20250805) precisely so you can pin to an exact snapshot. That's a real feature — pinned behaviour doesn't shift under you mid-quarter. But it has a symmetrical cost, and it's worth stating both sides plainly:
| Pinning to a dated snapshot | Tracking the latest alias |
|---|
| Behaviour | Stable until retirement | Can shift without you acting |
| Failure mode | Hard stop on retirement day | Silent quality/behaviour drift |
| Best for | Regulated, evaluated, high-stakes output | Exploration, internal tools, cost-sensitive work |
Pinning doesn't remove the migration problem — it schedules it. Which, for most production systems, is the better bargain: a known date you can plan for beats an unannounced behaviour change. But you have to actually plan for the date.
8. The takeaway
Two dates, one lesson. Opus 4.1 retiring today shows that model IDs are perishable infrastructure with a documented shelf life. Sonnet 5's pricing change on September 1 shows that the cost side is equally non-static — and that headline per-token pricing hides a tokenizer variable most people never check. Building on top of these APIs means treating "which model, at what price, tokenized how" as a configuration decision you revisit on a schedule, not a choice you make once at the start of a project.
9. Sources
Information gathered via web search on August 5, 2026. Prices and dates change — verify against Anthropic's official docs before making a decision based on them.
IA Watch · Anthropic e Claude
Claude Opus 4.1 é aposentado hoje: como funciona o ciclo de vida de um modelo
5 de agosto de 2026 é a data de aposentadoria definitiva do claude-opus-4-1-20250805 na API do Claude. Duas semanas depois, o preço promocional do Sonnet 5 expira. Juntos, são uma boa desculpa pra entender algo que a maioria aprende do jeito difícil: um ID de modelo não é uma coisa permanente.
1. O que aconteceu, com datas
- 5 de junho de 2026 — a Anthropic notificou desenvolvedores de que o Claude Opus 4.1 estava sendo descontinuado, com uma data de aposentadoria agendada na API.
- 5 de agosto de 2026 (hoje) — o
claude-opus-4-1-20250805 é aposentado. Requisições pra esse ID de modelo na API do Claude param de funcionar. O destino de migração recomendado é o claude-opus-4-8.
- 19 de agosto de 2026 — termina o aumento temporário de 50% no limite semanal de uso pra assinantes do Claude Code.
- 31 de agosto de 2026 — termina o preço promocional do Claude Sonnet 5 (US$ 2 / US$ 10 por milhão de tokens de entrada / saída). O preço padrão (US$ 3 / US$ 15) passa a valer em 1º de setembro.
Repare no formato dessa linha do tempo: 60 dias entre o aviso de descontinuação e o corte definitivo. A cobertura da mudança aponta que essa é a mesma janela que a Anthropic usou pro Claude Opus 4, e que essa é a segunda aposentadoria do mesmo provedor em menos de dois meses — modelos hoje sendo aposentados a cada 60–90 dias depois que um sucessor sai.
2. O ciclo de vida em quatro estágios
A Anthropic documenta um ciclo de vida em quatro estágios pelo qual todo modelo passa. Entender o vocabulário é o ponto central, porque as palavras são usadas com precisão e as pessoas costumam confundi-las:
| Estágio | O que significa | O que você deve fazer |
|---|
| Active | Totalmente suportado, recomendado pra trabalho novo | Construa sobre ele |
| Legacy | Ainda funciona, mas já existe um modelo mais novo recomendado | Comece a planejar; sem urgência ainda |
| Deprecated | Oficialmente a caminho da saída, com data de aposentadoria anunciada | Migre — o relógio está correndo |
| Retired | Requisições pra esse ID de modelo falham | Tarde demais; você caiu |
"Deprecated" não é "quebrado" e não é "tudo bem". É uma contagem regressiva. O modo de falha mais comum em sistemas de IA em produção é tratar um e-mail de descontinuação como leitura de baixa prioridade e descobrir na data da aposentadoria.
3. Por que provedores aposentam modelos
É tentador ler aposentadorias como hostilidade — você construiu sobre algo e ele foi tirado de você. As pressões reais são mais prosaicas:
- Capacidade de GPU é finita e caríssima. Cada modelo mantido no ar ocupa aceleradores que poderiam estar servindo um modelo mais novo, mais capaz e mais eficiente. Servir um modelo velho tem um custo de oportunidade real, medido em hardware.
- Cada modelo ativo é uma superfície de manutenção. Mitigações de segurança, avaliações, correções de vulnerabilidade e migrações de infraestrutura precisam ser aplicadas por modelo. Dez modelos vivos é dez vezes a superfície.
- Modelos mais novos normalmente são mais baratos por unidade de capacidade. O incentivo do provedor e o do cliente apontam quase na mesma direção — um sucessor costuma fazer o mesmo trabalho por menos.
- Fragmentação é um fardo de suporte. Documentação, orientação de prompting e expectativas de comportamento divergem numa cauda longa de modelos antigos.
O contra-argumento também é real: aposentadorias quebram reprodutibilidade. Se você publicou pesquisa ou lançou um produto cujo comportamento foi validado contra um modelo específico, a aposentadoria significa que aquele comportamento exato não é mais reproduzível em nenhum lugar. Esse é um custo genuíno da norma atual da indústria, e existe um debate em curso sobre se provedores deveriam manter snapshots congelados disponíveis a preço premium exatamente por esse motivo.
4. O outro prazo: preço do Sonnet 5 em 1º de setembro
A aposentadoria de modelo chama mais atenção, mas o prazo de preço é possivelmente mais consequente pra qualquer pessoa com volume real. O Sonnet 5 lançou a preços promocionais de US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída. A partir de 1º de setembro de 2026, valem os preços padrão de US$ 3 / US$ 15.
Isso é um aumento de 50% na tarifa por token, numa data, sem nenhuma mudança de código do seu lado. Se a economia unitária do seu produto foi modelada em US$ 2/US$ 10, ela está errada a partir de setembro.
Exemplo resolvido
Uma feature de assistente de suporte processando 200M tokens de entrada e 40M de saída por mês:
- No preço promocional: (200 × US$ 2) + (40 × US$ 10) = US$ 800/mês
- No preço padrão: (200 × US$ 3) + (40 × US$ 15) = US$ 1.200/mês
Mesmo tráfego, mesmo código, +US$ 400/mês. E isso antes do efeito de tokenizer abaixo.
5. O multiplicador escondido: tokenizers
Aqui está a parte que pega as pessoas, e é um conceito genuinamente útil muito além dessa mudança de preço específica. A cobertura do prazo do Sonnet 5 aponta que um tokenizer novo adiciona cerca de 30% mais tokens em algumas cargas de trabalho — o que significa que o aumento efetivo de custo a partir de 1º de setembro pode passar de 50%.
Por quê? Um tokenizer é o que pica seu texto nas unidades que o modelo de fato cobra e sobre as quais ele raciocina. A mesma frase pode ter 18 tokens em um tokenizer e 24 em outro, dependendo de como o vocabulário foi construído. Troque o tokenizer e você mudou sua fatura sem mudar um único caractere dos seus prompts.
Combinando os dois efeitos no exemplo acima: 260M de tokens cobrados virando ~338M na tarifa mais alta empurra aquela base de US$ 800 pra além de US$ 1.500 — mais perto de dobrar do que de um aumento de 50%.
A lição se generaliza: "preço por milhão de tokens" é só metade de uma estimativa de custo. A outra metade é em quantos tokens o seu texto real se transforma — o que é uma propriedade do modelo, não sua. Nunca compare dois provedores só pelo preço de token da manchete.
6. O que isso significa se você constrói sobre uma API
Nada disso exige pânico, mas exige alguns hábitos que separam sistemas que sobrevivem de sistemas que acordam alguém às 3 da manhã:
- Nunca escreva um ID de modelo fixo em mais de um lugar. Uma constante, um valor de configuração, uma variável de ambiente. Migração deveria ser uma mudança de uma linha, não um grep pela base de código.
- Leia os e-mails de descontinuação e coloque a data de aposentadoria num calendário. Uma janela de 60 dias é generosa se você percebe no dia 1 e brutal se você percebe no dia 55.
- Mantenha um conjunto de avaliação. Vinte ou trinta entradas representativas com saídas conhecidas como boas. Trocar de modelo só é assustador quando você não tem como saber se o novo ficou melhor ou pior na sua tarefa. Com um conjunto de avaliação, migração vira medição em vez de aposta.
- Re-teste os prompts na migração, não só troque a string. Modelos Claude mais novos são documentados como mais literais e mais aderentes a instruções — fazem o que você pediu e não mais que isso. Um prompt que dependia de um modelo antigo inferir sua intenção pode entregar menos, silenciosamente, num sucessor.
- Crie alerta de custo, não só de erro. Uma mudança de preço ou de tokenizer aparece como um gráfico de gasto entortando, nunca como uma exceção.
7. Fixar versão: um tradeoff de verdade
Os IDs de modelo da Anthropic carregam datas (claude-opus-4-1-20250805) justamente pra você poder fixar num snapshot exato. Isso é um recurso real — comportamento fixado não muda debaixo de você no meio do trimestre. Mas tem um custo simétrico, e vale afirmar os dois lados com clareza:
| Fixar num snapshot datado | Acompanhar o alias mais recente |
|---|
| Comportamento | Estável até a aposentadoria | Pode mudar sem você agir |
| Modo de falha | Parada abrupta no dia da aposentadoria | Deriva silenciosa de qualidade/comportamento |
| Melhor pra | Saída regulada, avaliada, de alto risco | Exploração, ferramentas internas, trabalho sensível a custo |
Fixar não elimina o problema de migração — agenda ele. O que, pra maioria dos sistemas em produção, é o melhor negócio: uma data conhecida que você pode planejar vence uma mudança de comportamento não anunciada. Mas você precisa de fato planejar pra essa data.
8. A conclusão
Duas datas, uma lição. O Opus 4.1 sendo aposentado hoje mostra que IDs de modelo são infraestrutura perecível, com prazo de validade documentado. A mudança de preço do Sonnet 5 em 1º de setembro mostra que o lado do custo é igualmente não-estático — e que o preço por token da manchete esconde uma variável de tokenizer que quase ninguém confere. Construir sobre essas APIs significa tratar "qual modelo, a que preço, tokenizado como" como uma decisão de configuração que você revisita numa agenda, não uma escolha que você faz uma vez no começo do projeto.
9. Fontes
Informação levantada por busca na web em 5 de agosto de 2026. Preços e datas mudam — confirme na documentação oficial da Anthropic antes de tomar uma decisão baseada neles.