Skip to content

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

New issue
New issue
Closed
Closed
scaleway/gpt-oss-120b unable to call tools with chat/completions endpoint#7524
Assignees
thdxr
Labels
bugSomething isn't working

Description

@jfayad
jfayad
opened on Jan 9, 2026

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

Activity

  1. jfayad
    added
    bugSomething isn't working
    on Jan 9, 2026
  2. github-actions
    assigned
    thdxr
    on Jan 9, 2026

  3. github-actions commented on Jan 9, 2026

    @github-actions
    github-actionsBot
    on Jan 9, 2026 – with GitHub Actions
    Contributor

    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.

  4. jfayad commented on Jan 9, 2026

    @jfayad
    jfayad
    on Jan 9, 2026
    Author

    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

  5. kaizen403 commented on Jan 13, 2026

    @kaizen403
    kaizen403
    on 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.

  6. jfayad commented on Jan 14, 2026

    @jfayad
    jfayad
    on Jan 14, 2026
    Author

    @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.

  7. Gnoale commented on Jan 14, 2026

    @Gnoale
    Gnoale
    on 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

  8. jfayad commented on Jan 14, 2026

    @jfayad
    jfayad
    on Jan 14, 2026
    Author

    @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 ?

  9. Gnoale commented on Jan 16, 2026

    @Gnoale
    Gnoale
    on 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 😃

  10. jfayad commented on Jan 16, 2026

    @jfayad
    jfayad
    on Jan 16, 2026
    Author

    @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)

  11. Gnoale commented on Jan 16, 2026

    @Gnoale
    Gnoale
    on 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

  12. inv1s10n commented on Jan 27, 2026

    @inv1s10n
    inv1s10n
    on 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.

  13. jfayad commented on Jan 27, 2026

    @jfayad
    jfayad
    on Jan 27, 2026
    Author

    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

  14. kaizen403 commented on Jan 27, 2026

    @kaizen403
    kaizen403
    on 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.

  15. github-actions commented on Mar 30, 2026

    @github-actions
    github-actionsBot
    on Mar 30, 2026 – with GitHub Actions
    Contributor

    To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

  16. github-actions
    closed this as completedon Mar 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

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