temperature sent unconditionally on the OpenAI-compatible path to Anthropic (native-path fix at v0.1.14 doesn't cover it)

[turtle696966969696]

Summary

Next-generation Claude models (claude-opus-4-8, claude-sonnet-5, and per the code comment also claude-opus-5 — agent/src/providers/llm.py:808-809) reject requests carrying temperature with HTTP 400. As of v0.1.14 this is fixed for the native Anthropic Messages API path (provider == "anthropic", llm.py:1366) — the string-matching detector at llm.py:827-834 catches the error, strips temperature, retries, and remembers the outcome per model.

I ran into this on a different, unsupported-but-functional configuration: LANGCHAIN_PROVIDER=openai with OPENAI_BASE_URL pointed at https://api.anthropic.com/v1/, using Anthropic's own OpenAI-compatible endpoint rather than the native Messages API. I want to flag up front that this isn't the documented way to reach Anthropic — the README lists the native Messages API as the supported provider (README.md:742), and .env.example:26-30 documents ANTHROPIC_BASE_URL under a dedicated "Anthropic Messages API / compatible proxy" section as the intended route, including for compatible proxies. I got here because Anthropic's compat endpoint happens to work for everything else through the generic OpenAI branch, which makes the failure easy to mistake for a bug in a supported setup rather than the edge of an unsupported one.

On that branch, the generic ChatOpenAI kwargs dict sends temperature unconditionally:

kwargs: dict[str, Any] = {
    "model": name,
    ...
    "temperature": temperature,      # agent/src/providers/llm.py:1418 — unconditional, unchanged at v0.1.14

temperature always carries a value — agent/src/config/env_schema.py:141 declares it as a plain float with default=0.0, not Optional[float].

Live response, verbatim:

{"error": {"code": "invalid_request_error",
           "message": "`temperature` is deprecated for this model.",
           "type": "invalid_request_error",
           "param": null}}

Same param: null, same shape the native-path detector already handles by string-matching on message prose.

Given this isn't a supported configuration, I'm not sure whether the right fix is extending detection to the generic branch (the logic already exists two branches away and the error shape is identical) or just a docs note warning this specific combination isn't covered — happy to open a PR for whichever direction maintainers would rather have.

Side note for anyone on the native path: ANTHROPIC_API_KEY is read via a bare os.getenv call (llm.py:1037), not declared in env_schema.py — a missing/mistyped value won't be caught by provider doctor or preflight, only at first call.

[warren618]

Thank you for the unusually precise report — including being upfront that the configuration is off the documented path. Decision: we will not extend the strip-and-retry detection into the generic OpenAI-compatible branch. That branch is deliberately provider-agnostic, and teaching it Anthropic-specific error prose couples it to every provider quirk it currently stays clean of; the supported routes (native provider=anthropic, or ANTHROPIC_BASE_URL for compatible proxies) already handle this. What we will do: add a docs note (README + .env.example) warning that pointing OPENAI_BASE_URL at Anthropic's compat endpoint is unsupported and hits exactly this 400 on next-gen models. Your side note is a real find, tracked separately: ANTHROPIC_API_KEY read via bare os.getenv and absent from env_schema.py means provider doctor/preflight cannot catch a missing key — that gets fixed. If you want to send the docs-note PR you are welcome to; otherwise we will pick both up.

[warren618]

Reopening my own decision here: I said we would not extend the strip-and-retry detection into the generic OpenAI-compatible branch. That was wrong, and the reason is in the file I was defending — _STREAM_USAGE_UNSUPPORTED is already exactly that pattern in exactly that branch, landed for #1224. Thank you for the precise report; #1246 is merged.

Both of the side items are also done: ANTHROPIC_API_KEY is in env_schema now, so provider doctor and preflight can tell a missing key from a working one instead of leaving you with an opaque 401, and .env.example states that OPENAI_BASE_URL pointed at Anthropic's compatibility endpoint is not a supported route.