If a Claude Code workflow now shows top_p deprecated after you switched to Opus 4.7, do not start by changing providers or assuming Claude Code itself suddenly broke. Anthropic now rejects non-default top_p, temperature, and top_k on Opus 4.7, so the real job is to find which layer still sends them.
The fastest safe fix is route-first: check your Claude Code version, confirm the backend path you are actually using, remove any wrapper or config that still injects the old sampling params, and retry the same task before you reach for a compatibility fallback.
Current Claude Code docs matter here because v2.1.111+ supports Opus 4.7 and because opus does not resolve the same way on every backend. On Anthropic API, Claude Code now maps opus to Opus 4.7; on Bedrock, Vertex, and Foundry, opus still points to Opus 4.6 unless you pin 4.7 explicitly.
Your verification move stays narrow: keep the same route, remove the deprecated fields, and rerun the same task. If the toolchain still cannot stop sending those fields after version, route, and cleanup checks are done, that is the point where a temporary compatibility fallback becomes reasonable.
Use the route board below to choose the right branch quickly. If your real problem turns out to be the broader Opus 4.7 migration decision or a different exact 400 break, switch to the sibling page only after the branch test makes that clear.
Start Here: Which Branch Are You In?
This error is narrow, but the safe first move is not. The phrase top_p deprecated makes people jump straight to "Claude Code is broken" or "my provider has not caught up." Sometimes that is close. Often it is not. The better question is simpler: which layer is still sending a request shape Opus 4.7 no longer accepts?
| What you are seeing | Most likely owner | Safest first move | Verify on the same path | Use fallback when |
|---|---|---|---|---|
Claude Code itself is older than v2.1.111 or the local path is stale | Outdated first-party client or local install drift | Update Claude Code and confirm the supported route | Run the same task again after the update | The current version still fails with the same deprecated-parameter message |
| You changed models or providers, but the backend route is not what you think | Anthropic API versus Bedrock / Vertex / Foundry alias mismatch | Check which backend the path is really using and whether opus really means Opus 4.7 there | Retry the same task after the route is corrected or pinned | The route is confirmed and the same request still fails |
A config, plugin, wrapper, or proxy still injects top_p, temperature, or top_k | Outer request-shaping layer, not current Claude Code defaults | Remove the old fields entirely and keep the rest of the path stable | Retry the same task on the same backend | The toolchain still cannot stop sending the removed fields |
| You cannot patch the toolchain today but still need the workflow running | Compatibility lag outside the first-party path | Use a temporary compatibility fallback only after version, route, and cleanup are ruled out | Confirm the fallback restores the same task without silently changing your real target contract | The fallback still fails or changes the job too much |
The route board matters because most wasted time happens before the reader identifies the active branch. Once you know whether the problem is version support, backend routing, or request cleanup, the fix usually becomes much smaller.
What Changed in Opus 4.7 and Why top_p Now Hard-Fails
Anthropic's migration guide for Opus 4.7 turns this from a fuzzy deprecation warning into a clear request rule. On Opus 4.7, non-default top_p, temperature, and top_k now produce a 400 instead of behaving like optional tuning knobs. Anthropic's safest migration advice is to omit those fields entirely.
That detail matters because many developers read top_p deprecated as "I should set a different number" or "I should force the old default." That is the wrong instinct. The migration path is not "tune the old knob differently." It is "stop sending the old knob." If the request path still contains one of those controls, the model contract and the request shape are out of sync.
The other subtle change is philosophical. Opus 4.7 pushes you away from low-level sampling fiddling and toward higher-level control such as prompting and effort. That does not mean you lost control over output quality. It means Anthropic wants the current model family to be steered with newer primitives rather than with the older sampling interface.
So if your exact symptom is top_p deprecated, your first correction is not "Claude Code got worse." It is "my request path still looks older than the model contract." The rest of the article is about finding where that mismatch lives.
If Claude Code Itself Is Outdated or Not on the Supported Route
As of April 17, 2026, Claude Code's official docs say Opus 4.7 requires Claude Code v2.1.111+. The April 16, 2026 changelog aligns with that support window. That is your first branch because there is no point debugging wrappers or aliases if the first-party client itself is old.
This is the quickest sanity check to run:
- Confirm the Claude Code version you are actually using.
- Update if the binary or local install path is older than
v2.1.111. - Rerun the same task without changing backend, env vars, or wrapper settings at the same time.
That last point matters more than it looks. If you update Claude Code and also change provider, shell config, or proxy settings in the same minute, you lose the clean answer you wanted most: did the current first-party client fix the symptom by itself?
If your real branch turns out to be a broken local install or stale binary path rather than the Opus 4.7 request contract, switch to our Claude Code install guide. This page should stay on exact deprecated-parameter recovery, not absorb general install debugging.
If Your Provider or Alias Route Is Not What You Think
Claude Code's current model configuration docs do not describe every backend the same way. On Anthropic API, opus now resolves to Opus 4.7. On Bedrock, Vertex, and Foundry, opus still resolves to Opus 4.6 unless you pin Opus 4.7 explicitly.
That means two readers can both say "I switched Claude Code to opus" and still be testing different contracts. One path is really on 4.7 and can legitimately hit the deprecated-parameter rule. Another path is still on 4.6 and is actually debugging a different mismatch entirely.
This is the safe reading of the backend split:
- If you are on the Anthropic API path, do not assume the problem is an old alias. It is more likely that some outer layer still sends the removed fields.
- If you are on Bedrock, Vertex, or Foundry and only changed
opuswithout pinning 4.7, verify whether you are really on the new model before you interpret the error. - If your wrapper or provider abstracts model routing, do not trust the UI label alone. Confirm the actual backend target before you debug the request body.
The goal is not to make you paranoid about every route. It is to stop you from fixing the wrong contract. If the backend is not actually on Opus 4.7, the deprecated-parameter story may not even be the right frame for the failure you are seeing.
If a Config, Plugin, or Wrapper Still Injects the Old Sampling Params
Once version and backend route are confirmed, this becomes the most likely branch. Current Claude Code support alone does not explain why the same path still shows top_p deprecated. A wrapper, proxy, plugin, or project-specific config often does.
Look for the old fields where request shaping still happens:
- local wrapper scripts that still set
top_p,temperature, ortop_k - provider adapters that translate from one schema into Anthropic's request shape
- proxy middleware that still stamps default generation controls onto every request
- old config fragments copied from pre-Opus 4.7 examples
The safest fix is boring and effective: remove those fields entirely. Do not set them to a guessed fallback value. Do not assume temperature: 1 is close enough. Anthropic's migration guidance is clearest on this point: omission is safer than trying to preserve the old tuning pattern.
If you still need stronger output control after removing them, use the newer levers that match the current model family. In practice that means clearer prompting, sharper task framing, and effort where that control exists. The main thing is to stop sending a request shape that the model now rejects.
This page should also stay narrower than the broader migration discussion. If you need the full model-choice question, pricing context, or the bigger "should I move to Opus 4.7 at all?" decision, the better sibling is Claude Opus 4.7 vs Claude Opus 4.6. Here the job is smaller: get the broken path working first.
Verify the Fix and Know When a Fallback Is Actually Reasonable
Same-path verification is what keeps this page honest. After you correct version, route, or request cleanup, rerun the same task on the same backend. Do not switch to a different provider, a different model family, or a different wrapper and then call the symptom fixed. That only proves some other path works.
The clean verification loop is short:
- Keep the backend and the task the same.
- Remove the deprecated fields from the path that actually sends the request.
- Retry once with the cleaned request shape.
- Save the cleaned configuration so those fields do not quietly come back later.
A temporary compatibility fallback is still a real option. It just belongs after the core checks are done. Use it when all of the following are true:
- the current Claude Code version is already supported
- the backend route is confirmed
- the request-cleanup branch is correct in theory
- but the toolchain still cannot stop sending the removed fields today
At that point, a fallback can be pragmatic. Examples include keeping an older model path temporarily or using a compatibility layer that strips the rejected fields before they hit Opus 4.7. Treat that as a bridge, not as the main fix. The better long-term outcome is still to align the request path with the current model contract.
If the failure you uncover is actually another exact 400 migration break, our Claude Opus prefill error fix is the better sibling. That page covers the older assistant-prefill removal path, which is related in spirit but not identical in cause or replacement workflow.
Frequently Asked Questions
Is top_p deprecated really a Claude Code bug?
Not in the simplest sense. Claude Code is the symptom surface readers see and search. The official contract change lives in Opus 4.7 rejecting non-default top_p, temperature, and top_k. Current Claude Code support is real; the bigger question is which layer still sends the old fields.
Why does opus not mean the same thing everywhere?
Because current backend mappings differ. In Claude Code on Anthropic API, opus now resolves to Opus 4.7. On Bedrock, Vertex, and Foundry, opus still resolves to Opus 4.6 unless you pin 4.7. That difference is why route verification belongs before body debugging.
Should I set temperature or top_p to a safer default instead of removing them?
The safer migration path is to omit them entirely. Anthropic's Opus 4.7 guidance is built around removing those older non-default controls rather than preserving them with a different numeric guess.
What should I use instead of those old sampling controls?
Use cleaner prompting and, where supported, effort. The goal is not to rebuild the old sampling interface with new numbers. It is to use the control surface the current model family expects.
When is a compatibility fallback reasonable?
Only after version, backend route, and request cleanup are already ruled out. If the current stack still cannot stop sending the removed fields, a temporary bridge can be reasonable. It should not be the first move.
The Working Rule
If Claude Code shows top_p deprecated on Opus 4.7, start by finding the layer that still sends the old sampling params. Check version, confirm the route, remove the old fields, retry the same task, and use fallback only if the stack still cannot stop sending them after the real checks are done.