feat: add reasoning content support to OpenAI adapter

[SDGLBL]

Description

Add reasoning content support to the OpenAI adapter's chat_output function, enabling proper handling of reasoning content from OpenAI models that support it, such as oss series models.

Why This Change?

OpenAI's oss series models on openrouter return reasoning tokens that provide insight into the model's thinking process. Without this support, the CodeCompanion chat buffer would lose this valuable reasoning content during streaming responses.

Data Structure Changes

Before:

output = {
  role = delta.role,
  content = delta.content,
}

After:

output = {
  role = delta.role,
}

if delta.reasoning then
  output.reasoning = {
    content = delta.reasoning,
  }
elseif delta.content then
  output.content = delta.content
end

Related Issue(s)

None - This is a feature enhancement to support new model capabilities.

Screenshots

Checklist

• I've read the contributing guidelines and have adhered to them in this PR
• I've updated CodeCompanion.has in the init.lua file for my new feature (N/A - reasoning is an adapter enhancement, not a user-facing feature)
• I've added test coverage for this fix/feature
• I've updated the README and/or relevant docs pages (N/A - reasoning models already documented in adapters docs)
• I've run make all to ensure docs are generated, tests pass and my formatting is applied

[olimorris]

Thanks for this. I'll need test coverage (as we have for DeepSeek) before I can merge this. Also, please stick to the PR template in the future - it just reduces the visual debt when you're trawling through lots of PRs.

Not required

[SDGLBL]

Thanks for this. I'll need test coverage (as we have for DeepSeek) before I can merge this. Also, please stick to the PR template in the future - it just reduces the visual debt when you're trawling through lots of PRs.

I've updated it according to the template.

[Davidyz]

Can we make the name of the reasoning field configurable (maybe via opts)? A lot of providers (deepseek, llama.cpp, etc.) implement a slightly modified openai-api that sends the reasoning under a different name. For example, the DeepSeek API calls it reasoning_content. Since a lot of the other adapters reuse code from the openai adapter, it's probably worth it to make it more "feature-complete" so that it'll be easier to maintain/create other adapters.

[znculee]

Thanks for implementing this! Is it compatible with all openai_compatible adapters rather than just openai, so that it'd be more flexible to be extended.

[SDGLBL]

Thanks for implementing this! Is it compatible with all openai_compatible adapters rather than just openai, so that it'd be more flexible to be extended.

This modification was actually made to use openai_compatible to request openrouter. Openrouter, in turn, returns the thought process through the reasoning field. I actually considered writing a dedicated openrouter_compatible and then separately implementing chat_output and providing a configurable reasoning field to support this capability. However, considering their complexity and redundancy, I decided against it.

If you're open to implementing a configurable delta.custom_field adapter mechanism that supports the OpenRouter API for inference, perhaps it would be better if you handled it. @Davidyz @znculee

[znculee]

@SDGLBL Thanks! I'm mainly using local models with this plugin, and I just confirmed that this branch is already working with the local Ollama (gpt-oss:20b) as follows.

## Me

hi

## CodeCompanion (OpenAI Compatible)

### Reasoning

We need to respond as ChatGPT - generic friendly start. Probably the user says "hi". We respond politely.

### Response

Hi! How can I help you today?

## Me

[SDGLBL]

@SDGLBL Thanks! I'm mainly using local models with this plugin, and I just confirmed that this branch is already working with the local Ollama (gpt-oss:20b) as follows.

## Me

hi

## CodeCompanion (OpenAI Compatible)

### Reasoning

We need to respond as ChatGPT - generic friendly start. Probably the user says "hi". We respond politely.

### Response

Hi! How can I help you today?

## Me

openrouter = require("codecompanion.adapters").extend("ollama", {
  -- comment
  env = {
    api_key = os.getenv "OPENROUTER_API_KEY",
  },
  opts = {},
  url = os.getenv "OPENROUTER_API_BASE" .. "/chat/completions",
  schema = {
    model = {
      default = "openai/gpt-oss-120b",
      choices = {
        ["google/gemini-2.5-pro"] = { opts = { can_reason = true, can_use_tools = true } },
        ["google/gemini-2.5-flash"] = { opts = { can_reason = false, can_use_tools = true } },
        ["anthropic/claude-4-sonnet"] = { opts = { can_reason = true, can_use_tools = true } },
        ["openai/gpt-4.1"] = { opts = { can_reason = true, can_use_tools = true } },
        ["openai/gpt-oss-20b"] = { opts = { can_reason = true, can_use_tools = true } },
        ["openai/gpt-oss-120b"] = { opts = { can_reason = true, can_use_tools = true } },
      },
    },
  },
  handlers = {
    ---@param self CodeCompanion.Adapter
    ---@return boolean
    setup = function(self)
      local os = require("codecompanion.adapters.openai").handlers.setup
      if os then
        os(self)
      end
                                                                                                
      self.parameters.provider = {
        order = {
          "Groq",
        },
        allow_fallbacks = true,
      }
                                                                                                
      return true
    end,
  },
}),

But I'm using OpenRouter, which apparently doesn't support Ollama as an adapter. Ollama supports this feature simply because the Ollama adapter handles the reasoning field. Here

[Davidyz]

If you're open to implementing a configurable delta.custom_field adapter mechanism that supports the OpenRouter API for inference, perhaps it would be better if you handled it.

The thing is, the custom handler will probably be 99% identical to the openai adapter, with the custom field being the only thing that sets them apart. I think it'd be nice to just make the openai adapter more versatile. But at the end of the day, there's no standardized way of doing this, so it's ok if you don't want to include this here.

[znculee]

Agree with @Davidyz, and @SDGLBL rather than extending ollama, you may try extending openai_compatible which should be more flexible. I haven't tried it with open router though

    adapters = {
      ollama = function()
        return require("codecompanion.adapters").extend("openai_compatible", {
          name = "ollama",
          env = {
            url = "http://127.0.0.1:11434",
          },
          schema = {
            model = {
              default = os.getenv("CODECOMPANION_OLLAMA_MODEL"),
            },
          },
        })
      end,

[bassamsdata]

Hello everyone, just wanted to share my two cents. I believe openai_compatible doesn’t support function calling, so it’s better to extend the OpenAI adapter directly (which is what I do with OpenRouter). I’m not entirely sure about the reasoning handling though, but especially since openai_compatible won’t be supported anymore as per this.

[Davidyz]

I believe openai_compatible doesn’t support function calling, so it’s better to extend the OpenAI adapter directly (which is what I do with OpenRouter).

openai_compatible does support tool calling as is. I've used it with various providers (both cloud and local).

[Davidyz]

After some further research, I'd like to re-raise my point on the configurable reasoning output field name. llama.cpp, vllm and alibaba (qwen) support listing models via the /v1/models endpoint and streams the reasoning content in message.reasoning_content, which is outside of the OpenAI API specs and is different from the openrouter format. I think this is the same as the deepseek format, but the deepseek adapter hardcodes schema.model.choices so it's actually not very convenient to use. Also, there's a chance that OpenAI will refine its API and define its own reasoning format. Having a flexible design in the first place will save us the trouble in the future.

Just to clarify, I'm suggesting something like:

adapter.opts = {
  stream = true,
  tools = true,
  vision = true,
  -- users can override this to fit their needs
  reasoning_field = 'reasoning'
}

and in the chat_output handler, we do:

output = {
  role = delta.role,
}

if delta[opts.reasoning_field] then
  output.reasoning = {
    content = delta[opts.reasoning_field],
  }
elseif delta.content then
  output.content = delta.content
end

@olimorris any thoughts on this?

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[Davidyz]

Any updates on this? @olimorris I'm tempted to add reasoning output to the gemini adapter, which might introduce some changes to the openai adapter and might have conflicts with this PR here. It'll be easier if we could decide what happens with this PR first.

[olimorris]

Hi All,

Apologies for not having the chance to look at this sooner. Actually reviewing a PR such as this is non-trivial and I am tightly time-boxing my time on CodeCompanion these days.

If a PR like this doesn't include links to OpenAI documentation then I have to manually review every single line alongside their docs. "How are we processing the reasoning output?". "Does it need to be passed back to OpenAI on the next turn?". All such questions that came up when I added support for the Responses API.

After a quick review, I can't accept this PR without adding reasoning support for when streaming is turned off. I believe OpenAI still have some models on the completions endpoint that don't allow streaming and there's always the chance they release new ones that don't support it anyway.

[Davidyz]

If a PR like this doesn't include links to OpenAI documentation

I don't think the standard OpenAI API contains anything about reasoning output or even a summary. OpenAI-compatible providers that actually provide reasoning output tend to come up with their own implementation for this. DeepSeek, for example, uses an extra field in the delta to transfer the string (some other providers follow this convention). Google Gemini takes a different approach (see #2306).

As for the non-streaming format, I'm not sure about the openrouter format, but I'm pretty sure the deepseek format work with non-streaming requests. That's why I proposed these changes: it's non-intrusive when used with the official OpenAI endpoint, and since it's just the deepseek format if you set opts.reasoning_field to reasoning_content, we can probably just reuse the deepseek stubs for testing. This is similar to the openai-python's implementation, where they just allow extra fields in their BaseModel, which is inherited by almost all the data structures that they implemented for the openai API, including the choices in chat completions, streaming or not streaming.

Update: Examples of deepseek and openrouter using the official openai-python package to work with reasoning tokens.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[Davidyz]

I believe #2359 superseded this PR? Should be safe to close this imo.

[Davidyz]

I believe #2359 superseded this PR? Should be safe to close this imo.

[SDGLBL]

Duplicate with #2359，Thanks to Davidyz for his contribution