anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

scaleway/gpt-oss-120b unable to call tools with chat/completions endpoint #4552

New Issue
Open
opened 2026-02-16 17:44:34 -05:00 by yindo · 12 comments
yindo commented 2026-02-16 17:44:34 -05:00
Owner
Copy Link
Copy Source

Originally created by @jfayad on GitHub (Jan 9, 2026).

Originally assigned to: @thdxr on GitHub.

Description

As stated in this documentation.

We can read that tool calling in that model is only supported with the /responses API

Most supported Generative API models can be used with both Chat Completions and Responses API. For the gpt-oss-120b model, use of the Responses API is recommended, as it will allow you to access all of its features, especially tool-calling.

I could also confirm that in a langchain app I built: /chat/completions failed to call tools with the gpt-oss-120b model whereas using the /responses api works

Moreover, when I ran the following command
opencode --log-level DEBUG --print-logs run --model scaleway/gpt-oss-120b "ping" with a wrong API key (in purpose to see the API URL being used). I can see it's using the chat/completions API.

this confirms that opencode uses the /chat/completions API.

Moreover, I also tested with another model from scaleway and tool calling worked well.

Now to be very precise, what fails is not calling the tool itself, the model is able to discover tools and trigger a tool call, yet it "crashes" when it's about receiving a tool call message to then process it and formulate a follow up response.

the easy fix here is to switch to responses endpoint

Plugins

none

OpenCode version

1.1.8

Steps to reproduce

  1. Configure Scaleway
  2. Start a session with the scaleway/gpt-oss-120b model
  3. Send a prompt that generates a tool call (beware of not prompting on a specific file as it can simply inject its content in the context without calling a tool)
  4. Observe the tool being called and then a silent failure

Screenshot and/or share link

Image

Operating System

macOS 14.4.1

Terminal

vscode terminal / webUI

Originally created by @jfayad on GitHub (Jan 9, 2026). Originally assigned to: @thdxr on GitHub. ### Description As stated in [this documentation](https://www.scaleway.com/en/docs/generative-apis/how-to/query-language-models/#chat-completions-api-or-responses-api). We can read that tool calling in that model is only supported with the /responses API > Most supported Generative API models can be used with both Chat Completions and Responses API. For the gpt-oss-120b model, use of the Responses API is recommended, as it will allow you to access all of its features, especially tool-calling. I could also confirm that in a langchain app I built: /chat/completions failed to call tools with the gpt-oss-120b model whereas using the /responses api works Moreover, when I ran the following command `opencode --log-level DEBUG --print-logs run --model scaleway/gpt-oss-120b "ping"` with a wrong API key (in purpose to see the API URL being used). I can see it's using the chat/completions API. this confirms that opencode uses the /chat/completions API. Moreover, I also tested with another model from scaleway and tool calling worked well. Now to be very precise, what fails is not calling the tool itself, the model is able to discover tools and trigger a tool call, yet it "crashes" when it's about receiving a tool call message to then process it and formulate a follow up response. the easy fix here is to switch to `responses` endpoint ### Plugins none ### OpenCode version 1.1.8 ### Steps to reproduce 1. Configure Scaleway 2. Start a session with the scaleway/gpt-oss-120b model 3. Send a prompt that generates a tool call (beware of not prompting on a specific file as it can simply inject its content in the context without calling a tool) 4. Observe the tool being called and then a silent failure ### Screenshot and/or share link <img width="686" height="126" alt="Image" src="https://github.com/user-attachments/assets/2727940c-9d57-409a-a9f9-97d08b2469cc" /> ### Operating System macOS 14.4.1 ### Terminal vscode terminal / webUI
yindo added the bug label 2026-02-16 17:44:34 -05:00
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 9, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #7185: When use gpt-oss-120B by vLLM locally, opencode doesn't call the tools

Both issues involve the same model (gpt-oss-120b) failing to properly handle tool calls. This issue specifically identifies that Scaleway's gpt-oss-120b requires the /responses API endpoint instead of /chat/completions, which may be a root cause worth investigating for the other tool calling issues with this model.

Feel free to ignore if this doesn't address your specific case.

@github-actions[bot] commented on GitHub (Jan 9, 2026): This issue might be a duplicate of existing issues. Please check: - #7185: When use gpt-oss-120B by vLLM locally, opencode doesn't call the tools Both issues involve the same model (gpt-oss-120b) failing to properly handle tool calls. This issue specifically identifies that Scaleway's gpt-oss-120b requires the /responses API endpoint instead of /chat/completions, which may be a root cause worth investigating for the other tool calling issues with this model. Feel free to ignore if this doesn't address your specific case.
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@jfayad commented on GitHub (Jan 9, 2026):

This issue might be a duplicate of existing issues. Please check:

Both issues involve the same model (gpt-oss-120b) failing to properly handle tool calls. This issue specifically identifies that Scaleway's gpt-oss-120b requires the /responses API endpoint instead of /chat/completions, which may be a root cause worth investigating for the other tool calling issues with this model.

Feel free to ignore if this doesn't address your specific case.

I saw this issue but it refers to not calling the tool, moreover it's on a different provider and my understanding is that implementations are provider dependent

@jfayad commented on GitHub (Jan 9, 2026): > This issue might be a duplicate of existing issues. Please check: > > * [When use gpt-oss-120B by vLLM locally, opencode doesn't call the tools #7185](https://github.com/anomalyco/opencode/issues/7185): When use gpt-oss-120B by vLLM locally, opencode doesn't call the tools > > Both issues involve the same model (gpt-oss-120b) failing to properly handle tool calls. This issue specifically identifies that Scaleway's gpt-oss-120b requires the /responses API endpoint instead of /chat/completions, which may be a root cause worth investigating for the other tool calling issues with this model. > > Feel free to ignore if this doesn't address your specific case. I saw this issue but it refers to not calling the tool, moreover it's on a different provider and my understanding is that implementations are provider dependent
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@kaizen403 commented on GitHub (Jan 13, 2026):

@thdxr I’d like to take this and wire Scaleway gpt-oss-120b to the responses endpoint so tool-calling works.

Proposed plan:

  • Add a provider override for scaleway in packages/opencode/src/provider/provider.ts so getModel returns sdk.responses(modelID) (can scope to gpt-oss-120b if preferred, but I’ll default to all Scaleway models unless advised otherwise).
  • Keep the existing base URL https://api.scaleway.ai/v1 and API key handling; no auth changes.
  • Add a regression test to assert Scaleway models instantiate via responses (and thus support tool calls).
  • If desired, add a brief docs note that gpt-oss-120b requires responses.

Please confirm whether you want the responses routing for all Scaleway models or only gpt-oss-120b; I can proceed accordingly.

@kaizen403 commented on GitHub (Jan 13, 2026): @thdxr I’d like to take this and wire Scaleway gpt-oss-120b to the responses endpoint so tool-calling works. Proposed plan: - Add a provider override for scaleway in packages/opencode/src/provider/provider.ts so getModel returns sdk.responses(modelID) (can scope to gpt-oss-120b if preferred, but I’ll default to all Scaleway models unless advised otherwise). - Keep the existing base URL https://api.scaleway.ai/v1 and API key handling; no auth changes. - Add a regression test to assert Scaleway models instantiate via responses (and thus support tool calls). - If desired, add a brief docs note that gpt-oss-120b requires responses. Please confirm whether you want the responses routing for all Scaleway models or only gpt-oss-120b; I can proceed accordingly.
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@jfayad commented on GitHub (Jan 14, 2026):

@thdxr I’d like to take this and wire Scaleway gpt-oss-120b to the responses endpoint so tool-calling works.

Proposed plan:

  • Add a provider override for scaleway in packages/opencode/src/provider/provider.ts so getModel returns sdk.responses(modelID) (can scope to gpt-oss-120b if preferred, but I’ll default to all Scaleway models unless advised otherwise).
  • Keep the existing base URL https://api.scaleway.ai/v1 and API key handling; no auth changes.
  • Add a regression test to assert Scaleway models instantiate via responses (and thus support tool calls).
  • If desired, add a brief docs note that gpt-oss-120b requires responses.

Please confirm whether you want the responses routing for all Scaleway models or only gpt-oss-120b; I can proceed accordingly.

@kaizen403 thanks for the initiative.

I just want to add a precision that most models at Scaleway are fully supported with the completions API.

Scaleway initially added the responses API only to support gpt-oss-120b with tool calling (as the model doesn't play nice with tool calling on the completions API, I'm citing one of their team members) and their support is flagged as beta for now.

If you want my opinion, it would be safer to have the ability to specify which API endpoint to hit (through the config) so it can be decided by the user instead of forcing anything.

@jfayad commented on GitHub (Jan 14, 2026): > [@thdxr](https://github.com/thdxr) I’d like to take this and wire Scaleway gpt-oss-120b to the responses endpoint so tool-calling works. > > Proposed plan: > > * Add a provider override for scaleway in packages/opencode/src/provider/provider.ts so getModel returns sdk.responses(modelID) (can scope to gpt-oss-120b if preferred, but I’ll default to all Scaleway models unless advised otherwise). > * Keep the existing base URL https://api.scaleway.ai/v1 and API key handling; no auth changes. > * Add a regression test to assert Scaleway models instantiate via responses (and thus support tool calls). > * If desired, add a brief docs note that gpt-oss-120b requires responses. > > Please confirm whether you want the responses routing for all Scaleway models or only gpt-oss-120b; I can proceed accordingly. @kaizen403 thanks for the initiative. I just want to add a precision that most models at Scaleway are fully supported with the completions API. Scaleway initially added the responses API only to support gpt-oss-120b with tool calling (as the model doesn't play nice with tool calling on the completions API, I'm citing one of their team members) and their support is flagged as beta for now. If you want my opinion, it would be safer to have the ability to specify which API endpoint to hit (through the config) so it can be decided by the user instead of forcing anything.
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@Gnoale commented on GitHub (Jan 14, 2026):

Hello @kaizen403

Please confirm whether you want the responses routing for all Scaleway models or only gpt-oss-120b; I can proceed accordingly.

The analysis from @jfayad is correct, this API was specifically added to support gpt-oss-120b so you should opt in to use it, instead of using it by default for all models.

Thanks for your valuable feedback

@Gnoale commented on GitHub (Jan 14, 2026): Hello @kaizen403 > Please confirm whether you want the responses routing for all Scaleway models or only gpt-oss-120b; I can proceed accordingly. The analysis from @jfayad is correct, this API was specifically added to support gpt-oss-120b so you should opt in to use it, instead of using it by default for all models. Thanks for your valuable feedback
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@jfayad commented on GitHub (Jan 14, 2026):

@kaizen403 note that I tried to workaround the problem by declaring the following provider

"scaleway-responses": {
      "npm": "@ai-sdk/openai",
      "name": "Scaleway (Responses via AI SDK OpenAI)",
      "options": {
        "baseURL": "https://api.scaleway.ai/v1"
      },
      "models": {
        "gpt-oss-120b": {
          "name": "scaleway/gpt-oss-120b (Responses)",
          "limit": {
            "context": 128000,
            "output": 8192
          }
        }
      }
    }

using the openai package is using the response API by default

but the model is failing with the following "truncated" error

[{'type': 'string_type', 'loc': ('body', 'input', 'str'), 'msg': 'Input should be a valid string', 'input': [{'content': 'You are opencode, an agent - please keep going until the u...

@Gnoale could that be because the responses API implementation on Scaleway isn't 100% ISO to OpenAI's one ?

@jfayad commented on GitHub (Jan 14, 2026): @kaizen403 note that I tried to workaround the problem by declaring the following provider ```json "scaleway-responses": { "npm": "@ai-sdk/openai", "name": "Scaleway (Responses via AI SDK OpenAI)", "options": { "baseURL": "https://api.scaleway.ai/v1" }, "models": { "gpt-oss-120b": { "name": "scaleway/gpt-oss-120b (Responses)", "limit": { "context": 128000, "output": 8192 } } } } ``` using the openai package is using the response API by default but the model is failing with the following "truncated" error > [{'type': 'string_type', 'loc': ('body', 'input', 'str'), 'msg': 'Input should be a valid string', 'input': [{'content': 'You are opencode, an agent - please keep going until the u... @Gnoale could that be because the responses API implementation on Scaleway isn't 100% ISO to OpenAI's one ?
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@Gnoale commented on GitHub (Jan 16, 2026):

Hey @jfayad,

I am looking into it but have trouble with inspecting logs, with opencode --log-level DEBUG, I only see INFO level in the logs files produced...

If you have a complete problematic query it could be helpful,

I am trying to figure out how to use the alternative provider config you sent locally, so I will hopefully be able to reproduce with the example provider you gave

If you have info about this too that would be cool 😃

@Gnoale commented on GitHub (Jan 16, 2026): Hey @jfayad, I am looking into it but have trouble with inspecting logs, with `opencode --log-level DEBUG`, I only see INFO level in the logs files produced... If you have a complete problematic query it could be helpful, I am trying to figure out how to use the alternative provider config you sent locally, so I will hopefully be able to reproduce with the example provider you gave If you have info about this too that would be cool 😃
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@jfayad commented on GitHub (Jan 16, 2026):

@Gnoale

I also struggle in getting opencode to properly log...

I found that this approach was more verbose:

opencode --log-level DEBUG --print-logs run --model scaleway/gpt-oss-120b "ping"

It would spit the log directly in the terminal. Problem is that this wouldn't make any tool call...

Another observation I can make is when the request succeeds, less logs are printed, so make sure to have a failure (even within the TUI) to access more logs.

Hope this helps.

In regards to the alternative provider, what's your issue ? (Just in case, make sure to add an entry in your auth.json for this new provider)

@jfayad commented on GitHub (Jan 16, 2026): @Gnoale I also struggle in getting opencode to properly log... I found that this approach was more verbose: `opencode --log-level DEBUG --print-logs run --model scaleway/gpt-oss-120b "ping"` It would spit the log directly in the terminal. Problem is that this wouldn't make any tool call... Another observation I can make is when the request succeeds, less logs are printed, so make sure to have a failure (even within the TUI) to access more logs. Hope this helps. In regards to the alternative provider, what's your issue ? (Just in case, make sure to add an entry in your auth.json for this new provider)
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@Gnoale commented on GitHub (Jan 16, 2026):

I mean the provider list inside this repository is a fixture and the tool grap the actual provider config from another API

I overridden the /packages/opencode/src/provider/provider.ts like suggested in the thread by @kaizen403 🙏

Now I need to the bad requests

@Gnoale commented on GitHub (Jan 16, 2026): I mean the provider list inside this repository is a fixture and the tool grap the actual provider config from another API I overridden the `/packages/opencode/src/provider/provider.ts` like suggested in the thread by @kaizen403 🙏 Now I need to the bad requests
yindo commented 2026-02-16 17:44:34 -05:00
Author
Owner
Copy Link
Copy Source

@inv1s10n commented on GitHub (Jan 26, 2026):

Has this issue been resolved in the latest code? If not, how can I modify the code to achieve it? Thanks for your help.

@inv1s10n commented on GitHub (Jan 26, 2026): Has this issue been resolved in the latest code? If not, how can I modify the code to achieve it? Thanks for your help.
yindo commented 2026-02-16 17:44:35 -05:00
Author
Owner
Copy Link
Copy Source

@jfayad commented on GitHub (Jan 27, 2026):

Has this issue been resolved in the latest code? If not, how can I modify the code to achieve it? Thanks for your help.

I updated to v1.1.31

Have this in my opencode.jsonc provider object:

"scaleway-responses": {
      "npm": "@ai-sdk/openai",
      "name": "Scaleway (Responses via AI SDK OpenAI)",
      "options": {
        "baseURL": "https://api.scaleway.ai/v1"
      },
      "models": {
        "gpt-oss-120b": { 
          "name": "scaleway/gpt-oss-120b (Responses)",
          "limit": {
            "context": 128000,
            "output": 8192
          } 
        }
      }
    }

and now I have the following error when I try to use this model

Bad Request: payload validation: 'include' is not supported

@jfayad commented on GitHub (Jan 27, 2026): > Has this issue been resolved in the latest code? If not, how can I modify the code to achieve it? Thanks for your help. I updated to v1.1.31 Have this in my opencode.jsonc provider object: ```json "scaleway-responses": { "npm": "@ai-sdk/openai", "name": "Scaleway (Responses via AI SDK OpenAI)", "options": { "baseURL": "https://api.scaleway.ai/v1" }, "models": { "gpt-oss-120b": { "name": "scaleway/gpt-oss-120b (Responses)", "limit": { "context": 128000, "output": 8192 } } } } ``` and now I have the following error when I try to use this model > Bad Request: payload validation: 'include' is not supported
yindo commented 2026-02-16 17:44:35 -05:00
Author
Owner
Copy Link
Copy Source

@kaizen403 commented on GitHub (Jan 27, 2026):

@thdxr opened a pr that should fix this - #10896

the fetch wrapper now catches the 400 "include not supported" error and retries without the include parameter. let me know if you can test it on your end.

@kaizen403 commented on GitHub (Jan 27, 2026): @thdxr opened a pr that should fix this - #10896 the fetch wrapper now catches the 400 "include not supported" error and retries without the include parameter. let me know if you can test it on your end.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4552
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?