The model list updates itself, and the settings underneath it do not

The list is live. The fields around it are frozen.

Here is why a workflow can break by being brought up to date.

In n8n, on current node versions, the model on an LLM node is chosen through a resource locator that calls the vendor's own model listing endpoint. The same is true at Make, which documents it plainly: "ensure you have access to the model you want to work with. Only models available for the account are listed for selection." The dropdown is not a list somebody at the platform maintains. It is a live query, and a model released this morning appears in it this morning.

The fields printed underneath — Sampling Temperature at 0.7, Top P at 1, Top K — are the opposite. They are declared in the node's own schema, with their own defaults, and they are governed by lists of model names hardcoded inside the platform. Those lists have to be edited by a human every time a vendor ships something.

So the headline "new model in an old dropdown" is not quite right. The dropdown is the newest part of the screen. It is everything around it that is old.

What the new models actually reject

The two vendors describe this differently, and the difference decides whether you are merely wrong or completely stuck.

Anthropic deprecated the parameters rather than removing them. From the Messages API reference, one entry per parameter:

Models released after Claude Opus 4.6 do not support setting temperature. A value of 1.0 […] will be accepted for backwards compatibility, all other values will be rejected with a 400 error.

• Messages API reference, Anthropic

The same wording covers top_p, where any value of 0.99 or above is accepted, and top_k, where — the one hard case — "any value will be rejected with a 400 error".

Read that carefully, because it explains who gets hit, and it is not who you would guess. The values that still pass are the API's own defaults: temperature exactly 1.0, top-p 0.99 or above. The platform's defaults are different numbers. Open the options block in n8n, add Sampling Temperature and touch nothing, and you have sent 0.7, which is rejected. Add Top K and you have sent something rejected at any value.

So the 400 catches two people: the one who turned the dial down to 0.2 for consistency, and the one who merely added the row.

OpenAI's instruction for its newest flagship is blunter. From the migration guide for GPT-6 Astra:

Unsupported parameters: Remove temperature, top_p, and top_logprobs. For Chat Completions, also remove logprobs. For Responses, remove message.output_text.logprobs from include.

Tool calling: Use the Responses API. GPT-6 Astra supports Chat Completions, but tool calling requires Responses.

• Using GPT-6 Astra, OpenAI

Two separate traps in one box, and the second one is genuinely confusing if you only read the model's own page. That page lists Chat Completions as supported and function_calling among the model's features. Both statements are true. The restriction — that the two cannot be combined — is spelled out only in the migration guide; the model page hints at it once, in a heading that scopes its tool list to the Responses API.

The exact 400 text for this specific combination is not published by either vendor, and I could not find it quoted anywhere reliable. Errors of this family read Unsupported parameter: '<name>' is not supported with this model, and the confirmed examples below all name the model they came from.

Three attempts, each suggested by the error, each wrong

This is what the diagnosis looks like from the inside. The sequence below is from a bug report filed on 1 October 2025 — n8n issue #20240 — against a Claude model released days earlier, and it is worth reading as a sequence rather than as a summary, because the shape of it is what came back a year later on a new model generation.

Somebody on n8n Cloud switches their workflow to Claude Sonnet 4.5. The run fails:

Bad request - please check your parameters top_p cannot be set to -1 for this model.

Reasonable enough. They set top-p to 0.75. Run again:

Bad request - please check your parameters temperature and top_p cannot both be specified for this model. Please use only one.

So one of them has to go. They try setting temperature to −1 to neutralise it. Run again — same error. Their closing line to the tracker: "Excited to use it but it's currently unusable."

Every step there was suggested by the message on screen, and all three were wrong. Worse, at that version there was no right answer inside the node at all: a reporter on the same mechanism six weeks earlier found the parameters "are always being added to the request… even if the values are -1 or empty string", and that thread ended with one person abandoning the node for a raw HTTP request and everyone else waiting for a release.

What has changed since is that deleting the rows now genuinely works, on the node that was fixed. What has not changed is that the message on screen still sends you to adjust the values rather than remove them.

Two hardcoded lists, and they do not agree

The decision about whether to send temperature is made twice, in two different codebases, by two different lists of model names.

n8n's Anthropic node carries an allow-list — a function that returns true for model names it recognises as accepting sampling parameters. It passes anything not starting with claude-, passes the Claude 2, 3 and instant families, passes Sonnet 4 and Haiku 4, matches Opus 4 through 4.6 with a regular expression, and rejects everything else.

Underneath it, the LangChain library has its own deny-list — an explicit array of seven model prefixes covering the newest Opus, Sonnet and the Fable and Mythos families. For those it throws before the request is made, if temperature or top-p is anything other than the default, or if top-k is set at all. The same rule as the vendor's, enforced a layer earlier, from a list that has to be edited separately.

Two lists, opposite polarity, maintained by different projects, both needing an edit whenever a vendor ships. They do not agree with each other, and the gap between them is not theoretical. A model reached through AWS Bedrock or an AI gateway has an identifier like global.anthropic.claude-sonnet-5, which does not begin with claude-, so n8n's first rule waves it straight through. The pull request that added the allow-list says so:

Non-Claude model IDs (e.g. gateway-proxied models) are always passed through unchanged, since we can't know their capabilities.

• n8n pull request #33667, July 2026

Which is honest, and also means that the newest Claude models are protected when called directly and unprotected when called through Bedrock.

One node was fixed. The others were not.

That pull request went in on 6 July 2026 and shipped the next day in version 2.30.0. It was written after Anthropic's newer models started returning 400s that, in its author's words, "surfaced as an unhelpful 'Bad request - please check your parameters' on the AI Agent node".

It changed exactly three files, and all three are the Anthropic node and its tests.

It did two things there, not one. Sampling parameters are now dropped before the request for models the allow-list does not recognise — and where a 400 gets through anyway, the node catches it and rewrites the message into the sentence the vendor never sends: "The model … does not support the Sampling Temperature, Top K, or Top P options. Remove them from Options and try again." That is the only place across any of these platforms where the screen tells you the actual fix, and it exists on one node, for one vendor, from version 2.30.0 onwards.

What the change leaves untouched is everything else: the OpenAI node, the AWS Bedrock node, anything reached through a gateway or a custom base URL, and any instance older than 2.30.0 — by the time you read this, a release from three months ago. The HTTP Request node is a separate case. There you write the request body yourself, so no guard is possible even in principle.

There is also a documentation gap that outlives the fix. The pull request's own checklist item for updating the docs is unticked, and the n8n documentation pages for the Anthropic and OpenAI chat model nodes still describe their sampling options without mentioning that current models will not accept them. The warning exists only as a tooltip inside the editor.

Being "fixed" means the slider stops doing anything

This is the quieter half of the story and the more expensive one.

The fix does not disable the fields or warn you. When the model is not on the allow-list, n8n drops the parameters before sending. The comment in the source says so in as many words — models that reject sampling parameters "get them silently dropped rather than erroring, for backwards compatibility" — and the option descriptions were updated to note they are "ignored there".

So on a current version of n8n, with a current Claude model, the Sampling Temperature control is still on the screen, still defaulting to 0.7, still accepting whatever you type, and connected to nothing.

For most workflows that is fine. The vendor gives no reason for the removal beyond the fact of it; the closest thing to guidance anywhere in the stack is LangChain's own error text, which tells you to "use model prompting instead". But if somebody set temperature to 0.1 two years ago so that a classification step would return the same answer every time, and the workflow has been quietly upgraded since, that setting is now decorative. The run still succeeds. The output is simply produced under different sampling than the person who built it intended, and nothing anywhere reports the change.

An automation that fails loudly gets fixed. This one keeps working while meaning something slightly different, and there is no error to catch.

The OpenAI node has the problem inverted

The OpenAI chat model node has no equivalent guard at all. Temperature, top-p and the rest are collected from the options block and passed to the model with no check on which model was chosen.

That is an omission. What sits next to it is stranger. The node's Reasoning Effort option — the one control the newest reasoning models actually want — is shown only when the selected model matches a hardcoded regular expression covering the o1, o3 to o9 and gpt-5 families. Run gpt-6-astra against that pattern and it does not match.

So on the current source, for OpenAI's newest flagship, the options panel is inside out: the parameter the model needs is hidden, and the two parameters it rejects are displayed and enabled. Even where Reasoning Effort does appear, its choices are low, medium and high, while the vendor documents two further levels above them.

One caveat on that reading. The condition is written against the model field, and on current node versions the model is picked through a resource locator, which stores an object rather than a plain string. Whether the pattern sees the model id at all was not tested on a running instance; if it does not, the option is missing for every model rather than just the newest one. Either way it is absent where it is needed, and I could not find a bug report about it in the tracker.

There is a workaround — the node's Extra Body field takes raw JSON and merges it into the request — but it requires knowing that the missing option exists.

The endpoint question is the other half. In n8n, "Use Responses API" is a toggle that defaults to on, but only from node version 1.3 onwards. A node saved before that toggle existed has no such setting and goes to Chat Completions, which is where tool calling on the newest OpenAI model does not work. Fixing that means replacing the node, not changing a setting — and replacing it does nothing for the sampling parameters, which are rejected on both endpoints.

Where Make and Zapier put the same wall

Make has the same architecture and therefore the same exposure: a live model list from your account, temperature fields defined in the app schema with documented defaults of 1. It also has the clearest recorded instance of the underlying failure, from December 2024, when a new reasoning model met an old parameter:

I've reviewed my scenario settings and I don't see any direct reference to logit_bias in the configuration. Yet, the request fails with this error.

• a user, Make community, 17 December 2024

A second user in the same thread diagnosed it correctly — "the error suggests that logit_bias is automatically being included in the request, even though it is not visible in the UI configuration" — and Make's community team confirmed a fix the next day. One parameter, one model, twenty-four hours: a good outcome, and a narrow one. It fixed that parameter for that model. Whether the same collision happens today, on Make, with a current reasoning model, I did not test — the field definitions and the live model list are documented the way they were, and the forum has no 2026 thread about it either way.

Note also that Make's case is the neighbouring version of this problem rather than the same one: there the platform was adding a parameter the user could not see, where the rest of this article is about a parameter the user can see and reasonably chose.

Zapier hides the same thing behind a different design. Its advanced-fields article explains how to set temperature between 0.0 and 2.0 and recommends not setting top-p at the same time, without ever saying that some models reject either. And its comparison of ChatGPT actions lists, under "Supported models", "GPT-4o, GPT 4.1, GPT 4o mini, o4 mini, o3 and o3-mini, o1" — a page last updated on 3 June 2026, which on the day this is published names nothing from the 5 or 6 generations, two behind the vendor's current flagship.

The structural difference at Zapier is that the endpoint is not a toggle but a choice of step: one action is documented as using the Responses API, another as using the completion API. Moving between them means rebuilding the step rather than flipping a switch.

Getting out of it

The order here matters, because the first item fixes it today and everything else is either slower or a consolation.

1. Delete the temperature, top-p and top-k rows from the options block. Not zero. Not −1. Remove them. On every affected platform this is the immediate fix, and outside the n8n Anthropic node on 2.30.0 or later, no error message will suggest it.
2. Expect the slider to be decorative afterwards. On an up-to-date n8n with a current Anthropic model, those fields are dropped before the request is sent whether you fill them in or not. If a workflow depends on low-temperature consistency, that guarantee is gone and the design needs to move into the prompt or into a validation step after the model.
3. If tool calling fails on OpenAI's newest model, look at the endpoint, not the parameters. Node version 1.3 or later has the Responses toggle on by default. An older node has to be replaced.
4. On Bedrock or through a gateway, assume nothing protects you. The identifier shape defeats the guard, so removing the fields by hand is the whole defence. The same goes for anything you upgrade into: a platform release can change what reaches the vendor without saying so in the release notes.
5. When you switch models, treat the options block as part of the migration. The dropdown changing is one edit. The fields beside it are a second edit that nothing prompts you to make — and the same shape of breakage has now arrived with several model generations running, after the snapshot retirements and a default model left past the shutdown date its vendor announced.

When this is a job to hand over

The version of this that needs someone's attention is not the one that failed. It is the workflows that are still running.

Somewhere in most AI automations there is a value that was tuned deliberately — a temperature set low so a classifier would be consistent, a top-p set for a copy-generation step. On current models and current platform versions those settings are now being discarded before the request leaves. Nothing fails. The behaviour drifts, and the person who chose the number is usually not the person watching the output. That is the job: not "the robot is broken" but "the robot stopped behaving the way we set it up to behave, and we cannot say when".

Finding them is an inventory — how many nodes talk to a model, which have a sampling option set, which of those actually depend on it. The count exists before the work does, which is how the price gets fixed in advance, and it is a recurring shape in the AI work we take on.

The failing run, by contrast, is two fields and a delete key. Nobody should be paid for that one.

The general lesson is worth more than the specific parameter names, which will change again. Any interface that mixes a live list with frozen fields will keep producing this, because half the screen tracks the vendor and half tracks the last time somebody at the platform updated a list of names. The dropdown is honest about being current. The settings underneath look equally current and are not, and the only way to tell them apart is that one of them fetched itself and the other was typed out by hand, months ago, by someone who has never heard of the model you just selected.

Sources

• Messages API reference - Anthropic, read 8 September 2026 from the raw documentation source rather than through a summarising fetch. The three deprecation notices for temperature, top_p and top_k on models released after Claude Opus 4.6, including which legacy values are still accepted and that any top_k value is rejected.
• Claude model overview - Anthropic, read 8 September 2026. Which models are current and which are legacy, used to confirm the model names in this article exist.
• Using GPT-6 Astra - OpenAI, read 8 September 2026 from the raw documentation source. The instruction to remove temperature, top-p and the log-probability parameters, and the statement that tool calling requires the Responses API even though the model supports Chat Completions.
• GPT-6 Astra model page - OpenAI, read 8 September 2026. The endpoint support table listing Chat Completions as supported, the feature list including function calling, and the reasoning effort levels available on this model.
• Reasoning models guide - OpenAI, read 8 September 2026. The recommendation that reasoning models work better through the Responses API.
• n8n source, the Anthropic, OpenAI and AWS Bedrock chat model nodes - read 8 September 2026 from the raw files on master. The option defaults, the model-name allow-list in the Anthropic node and the silent drop it performs, the absence of any equivalent check in the OpenAI and Bedrock nodes, the model resource locator that queries the vendor's own listing endpoint, the Responses API toggle and the node version it arrived in, and the visibility condition on Reasoning Effort which the newest OpenAI flagship does not match. The behaviour of that visibility condition in a running editor was not verified against a live instance.
• n8n pull request #33667 - read 8 September 2026 through the GitHub API. Merged 6 July 2026 and released the following day in version 2.30.0. The description of the 400 surfacing as an unhelpful message on the AI Agent node, the acknowledgement that gateway-proxied model identifiers pass through unchanged, the statement that unsupported models get parameters silently dropped, and the unticked documentation checklist item. The change covers three files, all belonging to the Anthropic node. It also added the fallback handler that catches a provider 400 mentioning these parameters and rewrites it into an instruction to remove them from Options.
• LangChain source, the Anthropic provider's parameter validation - read 8 September 2026. A separate hardcoded list of seven model prefixes, of opposite polarity to the one in n8n, which throws before the request is made when temperature or top-p is other than the default or top-k is set at all.
• n8n issue #36932 - read 8 September 2026 through the GitHub API. Opened 24 August 2026 and open at the time of reading. A user reporting an unsupported-parameter error on an OpenAI node with an empty options block, showing that the platform supplies parameters the user never set.
• n8n issue #18304 and issue #20240 - read 8 September 2026 through the GitHub API. The August and October 2025 reports of the same mechanism on Anthropic models, including the three-step sequence of attempted fixes quoted at the top of this article, the observation that the parameters were sent regardless of what the user set, the recurrence on the next model generation six weeks after the first fix, and the workaround of abandoning the node for a raw HTTP request. Both reporters were on n8n Cloud; in the August case the fix was already merged and had not yet reached the reporter's instance, while in the October case a maintainer said it would ship in a later release.
• n8n pull request #24033 - read 8 September 2026. An earlier example of the platform translating a provider error into an actionable message, applied to the choice of endpoint rather than to sampling parameters.
• Receiving unsupported parameter logit_bias error with OpenAI o1 model - Make community, December 2024, read 8 September 2026. Two users reporting a parameter they could not see in the interface being sent to a new model, and Make's community team confirming a fix the following day.
• OpenAI modules - Make, read 8 September 2026. The temperature fields and their documented defaults across the completion, chat completion and conversation modules, and the note that only models available to the account are listed for selection.
• Advanced fields for ChatGPT and Choosing the right ChatGPT action - Zapier Help Center, updated May and June 2026, read 8 September 2026 through the help centre API. The temperature and top-p guidance with no mention of model restrictions, the supported-model list two generations behind the vendor, and the split between actions using the Responses API and the completion API.