The short version: two Anthropic changes can quietly break a working agent this week, and both have one-line fixes. On August 5, 2026, the model ID claude-opus-4-1-20250805 retires — calls to it fail, with no grace period. Separately, on Claude Opus 4.7 and later, setting temperature, top_p, or top_k to any non-default value now returns a 400 error instead of being ignored. If either is buried in your request builder, your users find it before you do.
| Change | Trigger | Error | Fix |
|---|---|---|---|
| Opus 4.1 retires (Aug 5) | Any call to claude-opus-4-1-20250805 after the date | Request fails | Switch to claude-opus-4-8 |
| Sampling params deprecated (Opus 4.7+) | temperature / top_p / top_k set to a non-default value | HTTP 400 | Drop the params; steer with the prompt |
1. claude-opus-4-1 retires August 5 — no grace period#
Anthropic deprecated claude-opus-4-1-20250805 on June 5, 2026 and set its retirement for August 5, 2026, with claude-opus-4-8 as the recommended replacement (Anthropic model deprecations). That's the standard 60-plus days of notice — but notice is not the same as a soft landing. After the retirement date, requests to that model ID fail; there is no read-only window and no automatic forward to a successor. Whatever still points at Opus 4.1 goes dark.
The fix is a one-string change to claude-opus-4-8 — if the ID lives in one place. The failures that hurt are the ones from a model string hard-coded in a cron job, a serverless function's env var, or a customer-specific config you set up months ago and never revisited. So before you change anything, audit what actually used the model: in the Claude Console, open Usage → Export and read the CSV, which breaks usage down by API key and model. That tells you whether Opus 4.1 was live in your last billing period and from which key — far more reliable than trying to remember.
Two caveats on the swap itself. First, treat claude-opus-4-8 as a migration, not a find-and-replace: re-run your own eval (task success, tool-call validity, output format) before trusting it, because verbosity and token counts shift between versions even when the API shape doesn't. Second — and this is where the two changes collide — if your old Opus 4.1 request set a sampling parameter, moving to 4.8 will trip the second change below the instant it lands.
Notice is not a soft landing. A model with 60 days' notice and a model with no notice both stop answering on the same kind of Tuesday — the only difference is whether you had time to grep for it.
2. temperature, top_p, and top_k now return a 400 on Opus 4.7+#
This one isn't dated, which is why it's easier to walk into. On Claude Opus 4.7 and later, the temperature, top_p, and top_k sampling parameters are deprecated, and setting any of them to a non-default value returns a 400 error rather than being silently accepted (Anthropic model deprecations). The parameters still exist in the SDK request types, so your code keeps type-checking — it compiles fine, then fails at runtime the moment it hits a 4.7-or-later model.
The trap is a near-universal habit: request builders that always attach temperature: 0 for "determinism." That line has been harmless for years. Against a 4.7+ model it's now a hard 400.
The fix: stop sending those fields for those models and guide behavior with the prompt instead. Anthropic's own guidance is to omit the parameters and use prompting — put the constraint in words ("Return only the JSON object, no prose") rather than in a sampling knob that was already a weak lever on modern Claude. Concretely:
# Before — 400s on claude-opus-4-8
resp = client.messages.create(
model="claude-opus-4-8",
temperature=0, # ← non-default sampling param → HTTP 400
max_tokens=1024,
messages=msgs,
)
# After — omit the sampling params; constrain via the prompt
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=msgs, # system/user prompt carries the "only JSON" instruction
)Then grep your whole codebase for temperature, top_p, and top_k — not just the app, but the SDK wrapper and the eval harness. The eval harness is the one people forget, and it's the one that turns a green CI run red right before a release.
The through-line: managed models come with a calendar#
Neither of these is a bug; both are the ordinary cost of running on someone else's model. Anthropic retires models on a steady cadence to free capacity for new ones — Opus 4 and Sonnet 4 retired June 15, Opus 4.1 goes August 5, and the current floors put Sonnet 4.5 at September 29 and Haiku 4.5 at October 15. The lesson isn't "self-host to escape it" (that trades a vendor's calendar for your own ops). It's that the teams who absorb these without a fire drill do two boring things: they audit real usage from the Console export instead of from memory, and they never hard-code a model ID or a sampling param at more than one call site.
Centralize the model config, prefer a swappable client where the provider and model are configuration, and the next retirement is a one-constant edit rather than a hunt. This week's two changes are a cheap reminder to do both — cheap because the fixes are one line each, and a reminder because there's another one on the calendar in September. (For the money side of that same calendar — the Assistants API sunset and the Sonnet 5 price rise — see the two August deadlines that raise your agent bill; and if Opus 4.8 is your new default, Sonnet 5 vs Opus 4.8 for agents sizes when to reach for which.)
