benchr

Reference·June 2026

Anthropic invalid_request_error: meaning, cause, and fix

Anthropic uses this 400 response when a request fails validation. The JSON can be valid while a parameter, assistant prefill, or thinking block is not accepted by the selected model.

By benchr Editorial Team · · · Verified against Anthropic's API error documentation, June 12, 2026

AnthropicHTTP 400severity: mediumrequest format

Three model-specific causes

1. Sampling parameters on Opus 4.7 and later

Anthropic deprecated temperature, top_p, and top_k on Claude Opus 4.7 and everything after it, Opus 4.8 included. Set any of them to a non-default value and the call fails with a 400 instead of the field being quietly ignored. The fix is removal, not tuning: drop the parameters and steer variability through the prompt.

2. Prefilled assistant messages

Ending the conversation with a partial assistant turn used to be the go-to trick for forcing output shape. Current models reject it. Claude Fable 5, Claude Mythos 5, Claude Mythos Preview, Claude Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6 all return a 400 with this exact message:

"Prefilling assistant messages is not supported for this model."

Anthropic's docs name three replacements: structured outputs, system-prompt instructions, or output_config.format. If your code starts replies with { to coax out JSON, that's the line to delete.

3. Edited thinking blocks

Extended thinking comes with a strict round-trip rule. If thinking or redacted_thinking blocks in the latest assistant message were edited, reordered, filtered, or reconstructed, the API returns a 400. The message starts with the offending block's position, such as messages.1.content.0, and then states the rule:

`thinking` or `redacted_thinking` blocks in the latest assistant message
cannot be modified. These blocks must remain as they were in the
original response.

With tool use, every thinking block must be passed back exactly as received, including empty ones. History-trimming middleware that strips "useless" blocks to save tokens is the usual culprit here, and it breaks quietly until the first tool call.

Common request-schema causes

Once the three modern traps are cleared, what's left is the original meaning of the error: malformed JSON, a missing required field like model or max_tokens, a wrong type, or a broken message structure. Whatever the trigger, the response rides the same envelope, and the request_id is your ticket number if you end up writing to support:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "..."
  },
  "request_id": "req_..."
}

Start with a minimal request

For the most common 2026 case, the entire repair is deleting fields. Before and after for an Opus 4.8 call:

# BEFORE: returns 400 on claude-opus-4-8
{
  "model": "claude-opus-4-8",
  "max_tokens": 1024,
  "temperature": 0.7,
  "top_p": 0.9,
  "messages": [{"role": "user", "content": "Summarize this contract."}]
}

# AFTER: same call, sampling parameters removed
{
  "model": "claude-opus-4-8",
  "max_tokens": 1024,
  "messages": [{"role": "user", "content": "Summarize this contract."}]
}

If the old temperature: 0.2 was there for consistency, say so in the prompt instead — "give the single most likely reading, don't brainstorm alternatives" — and reach for structured outputs when a parser consumes the result.

If you're migrating off Opus 4 or 4.1

Sampling parameters are an easy migration-related cause to miss. Opus 4 retired June 15, 2026, and Opus 4.1 followed on August 5. Anthropic's recorded replacement was claude-opus-4-8, now listed as legacy; for new code, benchr's editorial pick is claude-opus-5 at the same $5/$25 per 1M tokens. Whichever ID you move to, review the request builder in the same change rather than assuming the old temperature setting remains valid. The Opus 4 and 4.1 retirement guide covers the timeline, the Opus 4.8 pricing page records its rates, and the Opus 5 review covers the current Opus.

Frequently asked

Why does temperature break Opus 4.8 when GPT accepts it?

Provider divergence. Most OpenAI models still honor sampling parameters, though OpenAI lists no custom temperature or top_p for GPT-6 Astra; Anthropic deprecated temperature, top_p, and top_k on Opus 4.7 and later, and any non-default value returns a 400 by design. Same field name, different contract, so build requests per provider.

Can I still get consistent output without temperature?

Yes. Ask the prompt for the single most likely answer and forbid creative variation. For anything a parser consumes, structured outputs constrain the response more reliably than a sampling knob ever did.

Why does my agent loop hit a 400 right after tool use?

Almost always modified thinking blocks. Frameworks that trim or reorder history violate the rule that thinking blocks in the latest assistant message must come back unchanged. Pass them back verbatim, empty ones included.

Changelog

  • — Updated the Opus 4 and 4.1 migration note: Opus 4.1 retired August 5, 2026, Opus 4.8 is now legacy, and benchr's pick for new code is Claude Opus 5 ($5/$25). Noted that OpenAI's GPT-6 Astra also drops custom temperature and top_p.
  • — Published. Prefill restriction, thinking-block rule, and the Opus 4.7+ sampling-parameter deprecation verified against Anthropic's API error and deprecation docs.

Sources

Related