Skip to content

bug: Claude thinking path forces temperature and extended-thinking, breaking Opus 4.7+ / Opus 5 / Sonnet 5 / Fable 5 #63

Description

@JNK234

Problem

ClaudeProvider.createProviderRequest unconditionally sets temperature = 1.0 and thinking: {type: "enabled"} whenever thinking is on (ClaudeProvider.scala:92, :98):

if (isThinking) {
  ...
  // Anthropic requires temperature=1.0 when thinking is enabled
  baseRequest("temperature") = 1.0
  ...
  baseRequest("thinking") = ujson.Obj(
    "type" -> "enabled",
    "budget_tokens" -> budget
  )
}

Both assumptions are now wrong for the current Claude generation (verified against Anthropic's model overview, Jul 2026):

  1. temperature is deprecated on Claude Opus 4.7 and later and returns HTTP 400 on any non-default value. Sending temperature = 1.0 to Opus 5, Sonnet 5, or Fable 5 makes the request fail outright.
  2. Extended thinking (thinking.type: "enabled") is not supported on Fable 5, Opus 5, or Sonnet 5, and is deprecated on Opus 4.6 / Sonnet 4.6. Those models use adaptive thinking instead, configured with an effort parameter (Fable 5 is always-on; Opus 5 / Sonnet 5 / Opus 4.6-4.8 accept effort, default high).

So the thinking path works only for the older family (claude-haiku-4-5, claude-sonnet-4-5, claude-opus-4-5, claude-opus-4-1) and hard-fails on everything newer.

Note Haiku 4.5 is the inverse of the newer models: extended thinking supported, adaptive not.

What needs to be done

  1. Branch on model generation in ClaudeProvider: extended-thinking models keep the current thinking block and temperature = 1.0; adaptive-thinking models get effort and no temperature key at all.
  2. Suppress temperature entirely for Opus 4.7+ even on the non-thinking path — the deprecation is not limited to thinking requests.
  3. Map our existing reasoning_effort config values (none|low|medium|high|xhigh) onto Anthropic's effort parameter.
  4. Decide where the generation split lives. ReasoningModelDetector already string-matches Claude versions, but adding another hardcoded family check there compounds the inconsistency noted in cleanup: remove or wire currently unused provider and registry helpers #31 — a ProviderDescriptor field or a models.yaml capability flag would be cleaner.
  5. Tests covering: extended-thinking model, adaptive-thinking model, and a non-thinking request to an Opus 4.7+ model (asserting no temperature key is sent).

Related

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions