Claude Code Opus 4.7 top_p Deprecated? Fix the 400 Without Guesswork

If Claude Code shows top_p deprecated while using Opus 4.7, remove the sampling fields from the request that actually reaches the model. Changing the number, deleting an unused configuration entry, or switching providers does not establish that the failing request has been repaired.

Anthropic's current documentation says non-default top_p, temperature, and top_k produce a 400 on Opus 4.7 and later models, and recommends omitting them. Amazon Bedrock's Opus 4.7 documentation states that all three sampling controls are unsupported. Follow the contract for your actual model and backend rather than guessing whether 0, 1, or null is acceptable. Anthropic parameter deprecations, Bedrock Opus 4.7 model card

The practical sequence is: identify the sending client and resolved model, inspect its final request, omit the rejected controls at the correct location, then rerun the original task on that same path. The sections below show where those fields belong and how to avoid deleting useful data with them.

Start Here: Which Branch Are You In?

A parameter being deprecated does not mean the model has been retired. Anthropic's model-status table lists Opus 4.7 and Opus 4.6 as active as of October 6, 2026. That status also does not establish availability for your account or cloud deployment. Anthropic model lifecycle

Confirm the Actual Claude Code Client, Model, and Backend

Start with the process that produced the error. A terminal session, editor integration, agent framework, and provider adapter may run different clients or use different settings. Record the sending client's version, the selected model, and the backend operation before changing anything.

For a terminal Claude Code session, claude --version checks the executable found by that shell. It does not identify a separately launched editor or service process. If the failing process uses a different installation, inspect that process's version rather than assuming your terminal check covers it.

The original April support guidance referred to Claude Code v2.1.111+ for Opus 4.7. That historical number is not a universal current version requirement. Check current support requirements for the model you actually selected; newer models and managed deployments can impose different requirements. Claude Code model configuration

Likewise, opus is an alias, not a permanent promise of Opus 4.7. Provider mappings can differ and change. The April mapping of Anthropic API to Opus 4.7 and every cloud backend to Opus 4.6 should not be used as a current routing table. Record the resolved model ID, inference profile, or deployment name used by your backend.

Claude Code's current model-selection documentation also distinguishes a session's selected model from startup settings. A /model selection can take precedence over --model, ANTHROPIC_MODEL, and saved model settings. In the current picker, pressing Enter saves the choice as your default; pressing s makes a session-only selection. Inspect the current selection without accidentally turning a diagnostic choice into a persistent change. Model selection and precedence

For a gateway or cloud route, establish the API operation as well as the provider name. Native Anthropic Messages, Bedrock InvokeModel, and Bedrock Converse do not use an interchangeable request body. A friendly model label or a custom base URL cannot tell you which fields the backend receives.

Remove Sampling Fields from the Final Request

Find the request builder that supplies the model's generation options. Search your own application code and adapter configuration for top_p, temperature, and top_k, then check whether defaults are added later. Configuration can look clean while an agent framework still constructs a request containing them.

For a model and route whose documentation recommends omission, remove the properties entirely. Sending a guessed default or a JSON null still sends a property. A language-level value such as Python None is not proof of omission; check what the serializer actually produces.

Native Anthropic Messages and Bedrock InvokeModel

In a native Anthropic Messages body, the sampling controls are top-level top_p, temperature, and top_k. Bedrock's native Anthropic InvokeModel body also uses the snake_case controls. Remove those controls from the generation request, retaining the fields needed for the original task.

For example, this is a body illustration for native Anthropic Messages, with sampling controls omitted:

{
  "model": "claude-opus-4-7",
  "max_tokens": 1024,
  "messages": [
    {"role": "user", "content": "Explain the failing test and propose a patch."}
  ]
}

This JSON is not a complete authenticated API command or a Claude Code configuration file. The output limit is an example, not a recommended replacement for your workload's existing limit. Keep your real messages, system instructions, tools, stop sequences, and other supported options. A Bedrock InvokeModel call requires its own model identifier and native body requirements, including anthropic_version; do not copy the Messages body wholesale into that operation. Bedrock Opus 4.7 request examples

Bedrock Converse and ConverseStream

Converse's common inference options have different names and locations:

For Opus 4.7 on Bedrock, omit the unsupported sampling controls at these locations. Do not delete the entire inferenceConfig object if it still contains your output limit or stop conditions. AWS's generic schema includes optional topP and temperature because Converse serves multiple models; that schema does not mean Opus 4.7 accepts them. Converse inference configuration, Converse model-specific fields, Opus 4.7 sampling restrictions

An Offline Helper for a Request Builder You Control

The following JavaScript helper operates on an already assembled JSON-compatible request. Use it only after confirming that the target is Opus 4.7 and choosing the matching request format. It does not resolve aliases, configure Claude Code, call an SDK, or send a request.

function omitOpus47Sampling(request, format) {
  const cleaned = structuredClone(request);

  if (format === "native-anthropic") {
    delete cleaned.top_p;
    delete cleaned.temperature;
    delete cleaned.top_k;
  } else if (format === "bedrock-converse") {
    if (cleaned.inferenceConfig) {
      delete cleaned.inferenceConfig.topP;
      delete cleaned.inferenceConfig.temperature;
      if (Object.keys(cleaned.inferenceConfig).length === 0) {
        delete cleaned.inferenceConfig;
      }
    }
    if (cleaned.additionalModelRequestFields) {
      delete cleaned.additionalModelRequestFields.top_k;
      delete cleaned.additionalModelRequestFields.top_p;
      delete cleaned.additionalModelRequestFields.temperature;
      if (Object.keys(cleaned.additionalModelRequestFields).length === 0) {
        delete cleaned.additionalModelRequestFields;
      }
    }
  } else {
    throw new Error("Choose the verified request format before cleanup");
  }

  return cleaned;
}

For Converse, the helper also removes native sampling keys if your adapter placed them in its model-specific inference object. It leaves every other property there intact. Integrate the helper after defaults and model-specific options are assembled, before handing the request to the sender. If a later adapter transforms it again, inspect that adapter's output too.

Do not apply a recursive “delete every key named top_p” function. A tool's JSON schema could legitimately define a property named top_p, and a user message could contain JSON data with the same name. Those are task inputs, not generation controls. Preserve messages, tool definitions, schemas, tool results, and supported priority or service-tier settings. Only the confirmed inference-parameter locations belong in this cleanup.

We checked the helper with synthetic requests offline, including nested tool-schema and user-data properties with sampling names. Those checks establish its deletion behavior and preservation of unrelated data; they do not establish that a particular live client or backend has been fixed.

Why a Clean Configuration Can Still Produce top_p

An AWS sample provides a concrete example of this distinction. In May 2026, a user reported top_p deprecated from the GenAI IDP Accelerator's Strands agentic ConverseStream path even though the uploaded configuration did not contain the parameter. The maintainer reported that version 0.5.10 applied the model-specific omission to the agentic path as well as the traditional processing path. AWS sample issue #304

That is a reported fix for that sample, not a Claude Code version requirement or proof that every Strands application is fixed. Its useful lesson is narrower: check every request-building path involved in the failing task. An initial request, a tool follow-up, and a secondary agent can be built by different code even when they share visible configuration.

If the error appears during an agent step, inspect the options for that step rather than only the interactive request. If a gateway supplies defaults, confirm what it forwards upstream. Change the component that adds the rejected inference parameter, or use its documented model-specific omission setting; a field removed earlier can otherwise reappear later.

For OpenCode, the same diagnostic principle applies, but it is a separate client. OpenCode documents provider/model options and agent-level overrides, so check both when locating the options that reach its adapter. Its model documentation does not establish a universal topP configuration fix or an installed-version bug. Use the actual provider, model, and serialized request to choose the repair. OpenCode model options

Verify the Fix and Know When a Fallback Is Actually Reasonable

Verify in two stages. First, confirm the cleaned request reaches the original backend without the rejected sampling controls. Then confirm the original task finishes with the features and output you needed.

1. Keep the comparison stable. Record the model, provider, API operation, sending client, adapter, and original task. Make the sampling cleanup without simultaneously changing the model or provider.
2. Inspect the final shape. Check only the relevant parameter locations after defaults and transformations. Use redacted diagnostics or a synthetic fixture; do not expose credentials, private prompts, or customer documents in logs.
3. Run the original task on that path. A small unrelated text response does not cover an agent workflow that failed during a tool call. Check the failing stage and the subsequent tool or agent steps.
4. Check the actual result. The deprecated-parameter error should be gone, the expected tools should still be available, the response should not be unexpectedly truncated, and the output should satisfy the original task's acceptance criteria.

If the same sampling error persists, the field may still be added after the point you inspected. Trace the next transformation. If the error changes to a different validation failure, you have a separate issue to diagnose; do not delete thinking settings, message history, tool schemas, or required output features just to make the request pass.

A local SDK exception requires a different check. Anthropic's deprecation documentation says Python SDK v1 and later remove these sampling keyword arguments, so passing them can raise TypeError before an HTTP request is sent. Remove the keyword at the SDK-call site. That documented behavior is separate from a backend 400; we did not inspect an installed SDK or make a live call for this article. SDK parameter changes

If you cannot change the sending component immediately, a temporary model or route fallback may let work continue. Verify its supported tools, output limits, cost, and task quality before adopting it. Record the change explicitly: a successful request to a different model or backend establishes that fallback's behavior, not recovery of the original Opus 4.7 path.

What Should Replace top_p and temperature?

For the sampling error itself, nothing needs to replace them: omit the fields. For output control, start by specifying what a satisfactory result looks like in the prompt—required format, scope, constraints, and how the result will be checked.

Where the selected model and route support it, output_config.effort adjusts how much work and thoroughness the model puts into a response, affecting token use across text, thinking, and tool activity. It is a behavioral control, not a numeric replacement for nucleus sampling or a strict token budget. Do not translate an old top_p: 0.9 into an invented effort equivalent, enable maximum thinking automatically, or raise max_tokens to 64,000 merely to clear this error. Anthropic effort documentation

If your workflow previously used temperature: 0 for repeatability, define and check the output requirements directly. Omitting sampling controls or choosing an effort level does not guarantee identical responses. Evaluate the repaired workflow on the tasks you depend on, including tool use and formatting.

Frequently Asked Questions

Is top_p deprecated really a Claude Code bug?

The message alone cannot identify the faulty component. For Opus 4.7, the model's sampling restrictions are documented, but the rejected field could come from the sending client, an agent framework, an adapter, or a gateway. Identify the actual request builder before assigning the cause. Anthropic sampling restrictions

Why does opus not mean the same thing everywhere?

It is a provider-dependent alias whose mapping can change. Confirm the resolved model used by your current session. Do not rely on the April 2026 Opus 4.7/4.6 mapping as a current table, and account for session selections overriding startup settings. Claude Code model configuration

Should I set temperature or top_p to a safer default instead of removing them?

For the documented Opus 4.7 migration, omit them. Anthropic describes non-default sampling values as rejected and recommends omission; Bedrock's Opus 4.7 model card says these controls are unsupported. Neither rule justifies a guessed 0, 1, or null workaround. Anthropic, Amazon Bedrock

Does deleting top_p from a config file prove it is fixed?

No. Confirm that the final request omits the relevant inference fields, then rerun the task that failed. In particular, check secondary agents and tool follow-ups if they use different request builders.

When is a compatibility fallback reasonable?

When the original sending component cannot be repaired in time and the alternative meets your task's requirements. Keep the changed model or backend explicit, verify the actual output, and retain a separate diagnosis for the original failure.