Dev Tier BYOM - using Opus 5.5 fails due to incorrect reasoning parameter configuration

Ask the Community
1

Summary

I’m doing a lot of work on my dev tier stack with AI FDE and hitting rate limits regularly, so wanted to BYOM.

I’ve registered Claude Opus 5.5 (claude-opus-5-5) as a registered model (BYOM). It uses a REST API source pointing at api.anthropic.com, with API provider Anthropic and service Direct Anthropic. The connection works and requests reach Anthropic, but every call fails with a 400 because of the thinking field the connector sends:

  • With the Reasoning capability ticked, it sends thinking.type: "enabled" with a token budget.
  • With Reasoning removed, it sends thinking.type: "disabled".

Opus 5.5 accepts only adaptive thinking, either thinking: {"type": "adaptive"} or no thinking field at all, so it rejects both.

I couldn’t find a setting in the registration form that changes this. Capabilities offers only Reasoning, Structured outputs and Tool calling, and the Hyperparameters list has no effort or thinking option.

Setup

  • REST API source: api.anthropic.com, port 443, Bearer token auth, egress policy approved, both export toggles on
  • Registration: API provider Anthropic, service Direct Anthropic, model ID claude-opus-5-5, Anthropic Messages endpoint /v1/messages (streaming on, same path), modalities Text and Vision, hyperparameters maxTokens only
  • Tested in AI FDE

image
image1022×587 35.3 KB

Errors

With Reasoning ticked:

RegisteredModelExecution:RegisteredModelExecutionClientError (400)
"thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

With Reasoning removed:

RegisteredModelExecution:RegisteredModelExecutionClientError (400)
"thinking.type.disabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

Why this needs a connector change

  • Anthropic’s per-model table shows that Claude Opus 5.5 and Opus 5 reject both “enabled” and “disabled”, while Opus 4.7, Opus 4.8 and Sonnet 5 reject “enabled”: https://platform.claude.com/docs/en/build-with-claude/thinking-troubleshooting
  • Anthropic also says: “There is no header or setting that restores budget_tokens on these models—migration to type: “adaptive” is required.” https://platform.claude.com/docs/en/build-with-claude/extended-thinking
  • So the Additional headers option in the registration can’t work around it, because the problem is a field in the request body.
  • Claude 5.5 Opus is already a Palantir-provided model, so the native integration must handle adaptive thinking. The registered-model connector doesn’t seem to use that code.

Likely next issues (documented by Anthropic, not yet hit)

  • Any non-default temperature, top_p or top_k returns a 400 on Opus 4.7 and later. AIP Logic’s Use LLM block sends temperature 0 by default.
  • Opus 5.5 returns a 400 if tool_choice forces a tool call (“any” or a named tool). Structured outputs built on forced tool calls would fail; Anthropic’s alternative is output_config.format. https://platform.claude.com/docs/en/models/opus-5-5/migration-guide

Questions

  1. For the Palantir team: is support for adaptive thinking and output_config.effort planned for Anthropic registered models? A per-registration setting, such as a thinking mode under Reasoning plus an effort hyperparameter, would stop this happening again with each new Claude model.
  2. For the Community: Has anyone got a Claude 4.7+ model working as a registered model another way?

I can share stack url, RIDs or error instance IDs privately if that helps.