Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate/Related PRs Found

PR #8900: feat(opencode): add copilot specific provider to properly handle copilot reasoning tokens

• Related to reasoning/thinking token handling across different providers. May have addressed similar parameter formatting issues.

PR #5531: Feature/OpenAI compatible reasoning

• Directly related to OpenAI-compatible API reasoning features, which is the core focus of PR fix(provider): use snake_case for thinking param with OpenAI-compatible APIs #10109.

PR #8359: feat(opencode): add auto model detection for OpenAI-compatible providers

• Related to OpenAI-compatible provider handling and model detection, relevant to the provider-specific logic in this PR.

These PRs address related functionality around provider-specific parameter handling and reasoning tokens, but your PR (10109) appears to be the specific fix for the snake_case conversion issue with OpenAI-compatible APIs.

Which api are you using because I don't think this is the case for all providers?

Thanks for reporting on our behalf

L

Which api are you using because I don't think this is the case for all providers?

Correct we are getting when using litellm to proxy Anthropic thinking models and trying to switch using c-t thinking modes

Which api are you using because I don't think this is the case for all providers?

Hi, the fix is for Claude models accessed via OpenAI-compatible proxies like LiteLLM, OpenRouter, Portkey and more.

Before :

  { "thinking": { "type": "enabled", "budgetTokens": 16000 } }   ❌ OpenAI-compatible endpoints don't convert camelCase → snake_case   

After (fix):

{ "thinking": { "type": "enabled", "budget_tokens": 16000 } }    ✅ Correct format for OpenAI-compatible API spec 

Is it this PR that is responsible for blindly matching "claude" in the name and sending completely incorrect parameters because of that? Instead of reasoning effort it sends what is on the pic. What is even funnier is it sets max tokens to 1 if user specified 32k limit, which is just funny how wrong that is.

This is how it should look:

This is supposed to be openai-compatible and model-agnostic. Why is it arbitrarily changing what is sent based on blind string matching? This is completely wrong.

@Chesars

it's a gross but it's really annoying that openai compat providers all do it inconsistently should re-evaluate this

Problem with this is it completely breaks this config:

  "provider": {
    "llm-proxy": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LLM Proxy",
      "options": {
        "baseURL": "http://127.0.0.1:8000/v1",
        "apiKey": "VerysecretKey",
        "timeout": 300000
      },
      "models": {
        "antigravity/claude-opus-4-5": {
          "id": "antigravity/claude-opus-4-5",
          "name": "Claude Opus 4.5 (Antigravity)",
          "limit": {
            "context": 200000,
            "output": 32000
          },
          "reasoning": true,
          "variants": {
            "low": {},
            "medium": {},
            "high": {}
          },
          "modalities": {
            "input": [
              "image",
              "text"
            ],
            "output": [
              "text"
            ]
          }
        },

I am expecting reasoning effort to be sent, and instead.. i get that. User's decision on max tokens is not even respected - it resulted in.. 1 token set as max.

ill take a look at this today, apologies, im gonna be more stingy w/ prs now

@Chesars im going to revert this and we can handle per provider instead. I don't wanna force something across the board