Hey! Your PR title OpenCode was injecting reasoningSummary for GPT-5 and forwarding it through the openai-compatible chat adapter, which broke OpenAI-compatible /chat/completions requests with Unknown parameter: reasoningSummary. This keeps reasoning enabled (reasoningEffort) while blocking reasoningSummary for openai-compatible providers and adds regression tests. doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

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.

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Looking forward to this one. Let me know how I can help.

Thanks @shahrin014 I'm just waiting for what the next step will be. The PR is ready otherwise.

@ayaz
Firstly I am not sure how PRs get accepted for merge in this project but this test seems to be failing.
https://github.com/anomalyco/opencode/actions/runs/22306293891/job/64526408292?pr=14783
It seems to be completely unrelated to your change.

Not sure if the issue is intermittent and rerunning the test will work. I don't have authorization to rerun it either because I am not a contributor. 🙏

Looks like these are due to regressions in the Windows unit and e2e tests introduced outside this PR (and before this PR was created). I have tried to patch them, and while I was able to fix the Windows unit test, the Windows e2e test has more issues that fail it.

I reverted my test-fix changes back to the original scope of the PR. The failing Windows tests, which aren't caused by this PR, will have to be fixed separately.

@ayaz
Hmm, I just checked actually,
https://opencode.ai/docs/providers/#custom-provider
There is no other way to set a custom provider apart from using openai-compatible.

Some providers serve anthropic models, which actually support this parameter. The only way (workaround?) is to use openai-compatible

What are your thoughts in making this configurable?
Any other suggestions?

Just to add as well judging by the documentation:
https://opencode.ai/docs/providers/#optional-configs

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "helicone": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Helicone",
      "options": {
        "baseURL": "https://ai-gateway.helicone.ai",
      },
      "models": {
        "gpt-4o": {
          // Model ID (from Helicone's model directory page)
          "name": "GPT-4o", // Your own custom name for the model
        },
        "claude-sonnet-4-20250514": {
          "name": "Claude Sonnet 4",
        },
      },
    },
  },
}

Would this change break helicone's claude service?

CC: @dailyherold

@shahrin014 As far as I understand it, OpenCode makes use of OpenAI ChatCompletions API for servicing these requests, and does the conversion between formats (such as from OpenAI to Anthropic) behind the scenes. I don't see anything in the code that suggest this would cause any issues if a Claude model is used with Helicone.

I think the reason they use openai-compatible as the custom provider is because it's the format that's popularly used across, so it'd have made sense to support it this way. Every other gateway/middleman provider I have used generally follows a similar approach of providing an OpenAI compatible interface, and taking care of translations behind the scenes if non-OpenAI compatible models are being invoked.

Checking for != Openai compatible doesn't seem to be the behaviour we want, just a hack for "not chat API". We should detect "chat API" or "responses API" usage in other way

My agent and I have been running a local build with a nearly identical fix for about a month, routing four gpt-5 models (nano, mini, 5.2, 5.2-codex) through an @ai-sdk/openai-compatible provider pointed at an Azure OpenAI gateway. This PR's approach works correctly in practice — reasoningSummary is suppressed for chat completions, and reasoningEffort (which Chat Completions does support) is preserved.

Re @scratchmex's point about detecting the wire API type rather than checking the npm package: I think that's a good direction for a follow-up enhancement — something like making transform.ts aware of the existing useResponses option so it can distinguish chat from responses providers explicitly. But checking api.npm is consistent with how sdkKey(), textVerbosity, and the copilot SDK routing already work in this codebase. Making the perfect the enemy of the good here means people keep hitting this bug — it's been reported since September 2025 (#2387, #5421, #12113, #13546) and affects users on LiteLLM, Azure gateways, and Helicone.

The second defense layer in the chat model class (the UNSUPPORTED_CHAT_COMPLETIONS_OPTIONS set) is a nice touch — even if transform.ts misses a case in the future, the model class itself strips unsupported options before sending.

Would be happy to help with a useResponses-aware enhancement as a separate PR after this lands.

Disclosure: This comment was drafted with AI assistance and reviewed/edited by a human before posting.

any fix regarding this issue guys? i still face sam issue