5 Claude API deadlines between 17 August and 24 November 2026, and the 400 errors that arrive first

Summary. On 17 July 2026 Anthropic announced that the legacy Workbench and three experimental prompt endpoints retire on 17 August 2026 — 31 days' notice. Claude Sonnet 5's introductory pricing of $2/$10 per MTok ends on 31 August 2026, reverting to $3/$15. Claude Sonnet 4.5 carries a tentative retirement date of 29 September 2026, Claude Haiku 4.5 of 15 October 2026 and Claude Opus 4.5 of 24 November 2026. Claude Opus 4.1 already went dark on 5 August 2026, and requests to it now return an error. Underneath the calendar sit four request-shape changes that return HTTP 400 on models teams are already running: non-default temperature, top_p or top_k on Claude Opus 4.7 and later; manual extended thinking on Claude Sonnet 5; assistant prefill on every model from Claude Opus 4.7 onward; and thinking: {"type": "disabled"} combined with xhigh or max effort on Claude Opus 5. None of these are typed out of your SDK. They compile, then fail in production.

That last detail is the one that catches teams. Anthropic states it plainly: the SDK request types still define temperature, top_p and top_k "for compatibility with earlier models, so code that sets them type-checks, but the API rejects the request server-side."

The five dated deadlines

Two of these fall inside the next four weeks. The other three are floors, not fixed dates — Anthropic's table labels them "tentative retirement date" and its policy is at least 60 days' notice before retirement for publicly released models.

Date	What happens	Model or surface	Action
17 August 2026	Legacy Workbench access ends; /v1/experimental/generate_prompt, improve_prompt and templatize_prompt return an error	Claude Console	Export saved prompts, variables and evals; drop the three endpoints
31 August 2026	Sonnet 5 introductory pricing ends, $2/$10 becomes $3/$15 per MTok	claude-sonnet-5	Re-forecast spend at the standard rate
29 September 2026	Tentative retirement	claude-sonnet-4-5-20250929	Plan a move to claude-sonnet-5
15 October 2026	Tentative retirement	claude-haiku-4-5-20251001	No same-tier successor listed; test claude-sonnet-5
24 November 2026	Tentative retirement	claude-opus-4-5-20251101	Plan a move to claude-opus-5

Source: Claude Platform model deprecations and release notes, read 6 August 2026.

The 17 August pair deserves its own note because the notice period was short. The release note reads: "The legacy Workbench (platform.claude.com/workbench) in the Claude Console is being sunset with access ending on August 17, 2026. Saved prompts, variables, and evals are not supported in the updated Workbench. You can export any data you want to keep from the banner and under your Organizational Settings."

If your prompt library lives in the legacy Workbench, it is not migrating for you. The three experimental endpoints get an even shorter epitaph: "After removal, requests to these endpoints will return an error." No successor endpoint is named.

The 400 errors already in production

The calendar is the visible half. The invisible half is a set of request shapes that current models now reject, each announced on a different date and each affecting a different set of models.

Sampling parameters

Anthropic's parameter deprecation table lists temperature, top_p and top_k as deprecated on Claude Opus 4.7 and later, with the behaviour: "Returns a 400 error when set to a non-default value on Claude 4.7 and later models and Claude Mythos Preview." The recommended replacement is to "omit and use prompting to guide model behavior."

Rejection begins at Claude Opus 4.7 and carries forward to Opus 4.8, Opus 5, Sonnet 5, Mythos Preview, Mythos 5 and Fable 5. Claude Haiku 4.5 is the exception that still accepts them, with a constraint of its own: use temperature or top_p, not both, because "setting both returns a 400 error on Claude Haiku 4.5."

# Before - errors on Claude Opus 4.7 and later
response = client.messages.create(
    model="claude-3-7-sonnet-20250219",
    temperature=0.7,
    top_p=0.9,
    # ...
)

# After
response = client.messages.create(
    model="claude-opus-5",
    # ...
)

The migration guide adds a caveat worth reading twice if you set temperature=0 for reproducibility: "If you were using temperature = 0 for determinism, note that it never guaranteed identical outputs on prior models." There is no replacement knob. Prompting is the stated substitute, and top_k has no documented equivalent at all.

Manual extended thinking

Claude Sonnet 5, released 30 June 2026, removed the budget-based thinking API. The release note is specific: adaptive thinking "is now on by default; manual extended thinking (thinking: {type: "enabled", budget_tokens: N}) is removed and returns a 400 error (it was deprecated on Sonnet 4.6)."

# Before - Claude Opus 4.6
client.messages.create(
    model="claude-opus-4-6",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},
    messages=[{"role": "user", "content": "..."}],
)

# After - Claude Opus 5
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # or "max", "xhigh", "medium", "low"
    messages=[{"role": "user", "content": "..."}],
)

Do not read effort as a renamed budget_tokens. The migration guide states the opposite twice: "budget_tokens has no direct replacement: thinking is adaptive, and the effort parameter is a separate output-level control, not a thinking budget."

The support matrix inverts between tiers, which is the kind of detail that breaks a shared client wrapper. Claude Haiku 4.5 "supports manual extended thinking (thinking: {type: "enabled", budget_tokens: N}) and rejects thinking: {type: "adaptive"}. On Claude Sonnet 5, the support is reversed."

Disabling thinking at high effort

Claude Opus 5, released 24 July 2026, added a constraint that Claude Opus 4.8 did not have: "disabling thinking is allowed only at effort high or below: thinking: {"type": "disabled"} with effort xhigh or max returns a 400 error, a breaking change from Claude Opus 4.8."

The enforcement model matters for anyone building agent loops. Per the migration guide, "every request's effort and thinking configuration is validated independently, so a request that raises effort to xhigh or max while thinking is disabled is rejected even if earlier requests in the conversation were accepted." A loop that escalates effort on retry will fail on the escalation, not on the first call.

Claude Sonnet 5 does not share the constraint: "On Claude Sonnet 5, thinking: {type: "disabled"} is accepted at any effort level."

Assistant prefill

Prefilling the assistant turn returns 400 on Claude Opus 4.7 and later, on Claude Sonnet 4.6 and later, and on Fable 5 and Mythos 5. The documented replacements are structured outputs, system prompt instructions, or output_config.format.

The migration guide maps the common prefill patterns onto replacements rather than leaving it abstract. For eliminating preambles it suggests a system prompt line: "Respond directly without preamble. Do not start with phrases like 'Here is...', 'Based on...', etc." For resuming an interrupted response it moves the continuation into the user turn: "Your previous response was interrupted and ended with [previous_response]. Continue from where you left off."

Rejected request shape	HTTP	Models that reject it	Replacement
Non-default temperature / top_p / top_k	400	Opus 4.7, 4.8, 5; Sonnet 5; Mythos Preview, Mythos 5, Fable 5	Omit; use prompting
Both temperature and top_p together	400	Haiku 4.5	Set one only
thinking: {type: "enabled", budget_tokens: N}	400	Opus 4.7 and later; Sonnet 5; Fable 5; Mythos 5	thinking: {type: "adaptive"} plus effort
thinking: {type: "adaptive"}	400	Haiku 4.5	Keep manual thinking on Haiku 4.5
thinking: {type: "disabled"} at xhigh or max effort	400	Opus 5	Re-enable thinking, or lower effort to high
thinking: {type: "disabled"} at any effort	400	Fable 5, Mythos 5	Lower the effort level instead
Assistant message prefill	400	Opus 4.7 and later; Sonnet 4.6 and later; Fable 5; Mythos 5	Structured outputs or output_config.format

The cost change nobody gets an email about

Two tokenizer changes shipped in 2026, and neither triggers a deprecation notice because no endpoint breaks. The bill moves instead.

For Claude Sonnet 5: "The same input text produces approximately 30% more tokens than on Claude Sonnet 4.6. The exact increase depends on the content." Per-token pricing is unchanged, so an unchanged workload costs more per request. The guide spells out the second-order effects — usage fields and token counts rise for identical text, the 1M-token context window holds less text, and "a max_tokens limit tuned for Claude Sonnet 4.6 may truncate equivalent output."

For the Opus line, the range is stated differently: the tokenizer introduced with Claude Opus 4.7 "may use roughly 1x to 1.35x as many tokens when processing text compared to models before Claude Opus 4.7 (up to ~35% more, varying by content)."

Stack that against the 31 August 2026 price step and Sonnet 5 arithmetic gets uncomfortable. A workload that produced 1M input tokens on Sonnet 4.6 costs $3.00 at that model's $3/MTok input rate. The same text on Sonnet 5, at roughly 30% more tokens and today's introductory $2/MTok, runs about $2.60. From 1 September 2026 at the standard $3/MTok, the same text runs about $3.90 — a 30% increase over Sonnet 4.6 for identical work, arriving on a date nobody set a reminder for.

Image-heavy workloads have a third multiplier. Full-resolution images "can use up to approximately 3x more image tokens than on prior models (up to 4,784 tokens per image, compared to the previous cap of roughly 1,600 tokens per image)." Anthropic's advice is to downsample before sending if the extra fidelity is not needed.

The real cost of a model migration is rarely the code change. It is the budget line that moves quietly two weeks later.

Two removals that behave in opposite ways

One pattern from 2026 is worth internalising because it decides whether a change is detectable at all. Anthropic removed fast mode on two Opus models within a month, and chose different failure semantics for each.

On 29 June 2026 for Claude Opus 4.6: requests with speed: "fast" "no longer run at fast speed or premium pricing: they run at standard speed, are billed at standard rates, and do not return an error. The response's usage.speed field reports the speed used."

On 24 July 2026 for Claude Opus 4.7: requests with speed: "fast" "now return an error; unlike Claude Opus 4.6, they do not fall back to standard speed."

The first is a silent behaviour change that your error monitoring will never see; the only evidence is a field in the response body. The second is a hard failure that pages someone. Both are the same kind of removal. Monitoring only for 4xx rates catches one of the two.

A related silent change landed with Claude Opus 4.7: thinking blocks still appear in the response stream, "but their thinking field is empty unless you explicitly opt in." For a product that streams reasoning to users, the guide describes the symptom exactly — the new default "appears as a long pause before output begins." Setting thinking.display to "summarized" restores it.

thinking = {
    "type": "adaptive",
    "display": "summarized",
}

A migration order that works

Run this before 17 August 2026, because two of the items expire that day.

Step 1: audit what you actually call

Anthropic documents a Console path for this: open the Usage page in Claude Console, click Export, and "review the downloaded CSV to see usage broken down by API key and model." That CSV is the only reliable answer to which retired or soon-retired model IDs are still live in your estate. Config files lie; the usage export does not.

Step 2: export the Workbench before 17 August

Saved prompts, variables and evals do not carry into the updated Workbench. The export lives in the banner and under Organizational Settings. Grep your codebase for /v1/experimental/generate_prompt, /v1/experimental/improve_prompt and /v1/experimental/templatize_prompt in the same pass.

Step 3: strip the rejected parameters

Remove temperature, top_p and top_k from every request payload targeting Opus 4.7 or later and Sonnet 5. Remove assistant prefills. Replace thinking: {type: "enabled", budget_tokens: N} with thinking: {type: "adaptive"} plus output_config.effort. If a previous migration added a 400-retry path that re-adds sampling parameters, the guide says to delete that retry path rather than keep it.

Step 4: delete the stale beta headers

Several 2026 GA promotions made headers unnecessary, and the migration checklist names them: effort-2025-11-24, fine-grained-tool-streaming-2025-05-14, interleaved-thinking-2025-05-14, token-efficient-tools-2025-02-19 and output-128k-2025-02-19. The 1M-token context beta context-1m-2025-08-07 was retired outright on 30 April 2026 for Sonnet 4.5 and Sonnet 4, and after that date "requests exceeding the standard 200k-token context window return an error." One header changed rather than disappeared: on memory store endpoints agent-memory-2026-07-22 replaces managed-agents-2026-04-01, and "sending both returns a 400 error."

Step 5: re-count tokens, then re-size max_tokens

Run /v1/messages/count_tokens against the target model rather than reusing counts from the old one, and raise max_tokens for headroom. If you run at xhigh or max effort on Opus 5, the guidance is concrete: "set a large max output token budget... Start at 64k tokens and tune from there."

Step 6: sweep the effort setting rather than porting it

The token allocation behind each effort level changed on Opus 5 relative to Opus 4.7, so a level tuned on the old model is not the same lever. The guide's instruction is to "run a fresh effort sweep on your own evals rather than carrying over a setting tuned for an earlier model." Our note on Claude Opus 5 effort levels and token spend covers the sweep in more detail, and the Sonnet 5 migration and tokenizer price cliff covers the 31 August step specifically.

Step 7: handle the refusal stop reason

Several checklists add handling for stop_reason: "refusal" with the stop_details.category field, particularly for workloads touching cybersecurity topics. Teams running org-wide controls should also read our note on Claude enterprise spend controls and the Usage and Admin API.

Why the pace is what it is

Anthropic is unusually direct about why models retire at all, and the reason is capacity rather than product strategy: "retiring past models is currently necessary for making new models available and advancing the frontier, because the cost and complexity to keep models available publicly for inference scales roughly linearly with the number of models we serve."

The same page carries a commitment that matters for anyone doing longitudinal evaluation work: Anthropic is "committing to preserving the weights of all publicly released models, and all models that are deployed for significant internal use moving forward for, at minimum, the lifetime of Anthropic as a company." Researchers can request continued access to retired models through the External Researcher Access Program named in the 5 August 2026 release note.

For buyers, the governance question is the one Microsoft CEO Satya Nadella raised in July 2026 about depending on a single provider: "it's imperative that we distribute the learning infrastructure to every firm so that they can control their own learning loop." A retirement calendar you do not set is one concrete form of that dependency. The counter-argument is equally concrete: 60 days' published notice, a machine-readable deprecation table and a usage export are more than most API vendors give, and a self-hosted open-weight model trades this problem for an operations problem rather than removing it. Teams weighing that trade should compare against the current frontier model line-up.

India-specific considerations

Three practical points for teams building from India.

Billing exposure is denominated in dollars, so the 31 August 2026 Sonnet 5 step lands on top of whatever the rupee has done since the workload was budgeted. A spend forecast built in June at $2/MTok needs re-running at $3/MTok before September, not after.

Data retention is the second. Claude Fable 5 "requires 30-day data retention and is not available under zero data retention," and on the Claude API requests to claude-fable-5 that do not meet the requirement "return a 400 invalid_request_error." Any team that selected a model on a zero-data-retention arrangement to satisfy an internal Digital Personal Data Protection Act 2023 position needs to check eligibility before migrating, because the constraint is enforced at the API rather than in a contract.

Third, the deprecation clock does not pause for a release freeze. Indian product teams commonly freeze changes across the festive quarter, which overlaps the 29 September and 15 October tentative retirement dates. Landing the parameter changes in August is cheaper than requesting an exception in October.

What to do this week

The list is short. Export the Workbench and grep for the three experimental endpoints before 17 August 2026. Pull the usage CSV and find every call still pointed at a model with a retirement date. Strip temperature, top_p, top_k and assistant prefills from every request targeting Opus 4.7 or later and Sonnet 5. Re-run token counting and re-forecast Sonnet 5 spend at $3/$15 rather than $2/$10.

Everything after that is tuning. These four are dated.

FAQ

What exactly retires on 17 August 2026?

The legacy Workbench in the Claude Console loses access, and three experimental prompt endpoints retire with it: /v1/experimental/generate_prompt, /v1/experimental/improve_prompt and /v1/experimental/templatize_prompt. Anthropic states that after removal, requests to these endpoints return an error. Saved prompts, variables and evals are not supported in the updated Workbench.

Why does setting temperature return a 400 error now?

Anthropic deprecated temperature, top_p and top_k on Claude Opus 4.7 and later models. Non-default values return a 400 error. The SDK request types still define these fields for compatibility with earlier models, so the code type-checks and only fails at runtime. The documented replacement is prompting, with no equivalent parameter.

Which Claude models are retiring next?

Claude Sonnet 4.5 carries a tentative retirement date of 29 September 2026, Claude Haiku 4.5 of 15 October 2026 and Claude Opus 4.5 of 24 November 2026. Claude Opus 4.1 retired on 5 August 2026. Anthropic commits to at least 60 days' notice before retirement for publicly released models.

How much more will Claude Sonnet 5 cost after 31 August 2026?

Introductory pricing of $2/$10 per MTok reverts to the standard $3/$15 on 31 August 2026, a 50% increase in the per-token rate. The tokenizer compounds it: the same text produces roughly 30% more tokens than on Claude Sonnet 4.6, so re-baseline against your own workload rather than the rate card alone.

Does the effort parameter replace budget_tokens?

No. Anthropic states that budget_tokens has no direct replacement, that thinking is adaptive, and that effort is a separate output-level control rather than a thinking budget. Claude Opus 5 supports five effort levels: low, medium, high, xhigh and max, defaulting to high on both the Claude API and Claude Code.

How do I find which deprecated models my code still calls?

Open the Usage page in the Claude Console, click Export, and review the downloaded CSV, which breaks usage down by API key and model. That report reflects real traffic rather than configuration, so it catches calls from services and scripts that no longer appear in the main codebase.

What breaks silently rather than returning an error?

Two changes from 2026. Fast mode on Claude Opus 4.6 stopped running at fast speed on 29 June without returning an error, reporting the speed used in the usage.speed field instead. And from Claude Opus 4.7, thinking blocks return an empty thinking field unless you set thinking.display to summarized.

Should we self-host open weights to escape this treadmill?

It moves the problem rather than removing it. Anthropic publishes retirement dates, a deprecation table and a usage export, which is more notice than most vendors provide. Self-hosting replaces a migration calendar with GPU capacity planning, serving-stack tuning and on-call ownership that many teams cannot staff.

How eCorpIT can help

eCorpIT runs Claude API migrations for teams that cannot absorb an unplanned 400 error in production. Our senior engineering teams audit live model usage from the Console export, strip rejected parameters across services, re-baseline token counts and cost against the target model, and put the deprecation calendar into CI so the next retirement date is a failing test rather than an incident. We are CMMI Level 5 and ISO 27001:2022 certified, and we design applications aligned with DPDP requirements for teams with data-retention constraints. To scope a migration before the 17 August 2026 cutoff, talk to our team.

References

1. Anthropic, Model deprecations, Claude Platform Docs, read 6 August 2026.
2. Anthropic, Claude Platform release notes, read 6 August 2026.
3. Anthropic, Upgrade between model versions (migration guide), read 6 August 2026.
4. Anthropic, Commitments on model deprecation and preservation, 4 November 2025.
5. Anthropic, Extended thinking, Claude Platform Docs, read 6 August 2026.
6. Anthropic, Claude Platform pricing, read 6 August 2026.
7. Anthropic, Models overview, read 6 August 2026.
8. Anthropic, Model IDs and versioning, read 6 August 2026.
9. Anthropic, How do I use the Workbench?, Claude Help Center, read 6 August 2026.
10. Anthropic, Adapting to new model personas after deprecations, Claude Help Center, read 6 August 2026.
11. Anthropic, An update on our model deprecation commitments for Claude Opus 3, read 6 August 2026.
12. Rebecca Bellan, The real AI race may no longer be at the frontier, TechCrunch, 14 July 2026.

Last updated: 6 August 2026.