feat: add support for OpenAI-compatible third-party provider

[ChinaSiro]

Fixes #341

Key requirements:

• Accept OpenAI Chat/Completions request schema (model/messages/stream/etc.)
• Ensure compatibility with third-party providers using the OpenAI format (e.g., self-hosted gateways, multi-model routers)
• Support text, image, audio, video, and file inputs

[gemini-code-assist]

Summary of Changes

Hello @ChinaSiro, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new openai package that provides an OpenAI-compatible model adapter. This adapter allows the system to seamlessly integrate with a wide range of third-party LLM providers that adhere to the OpenAI Chat/Completions API specification. The implementation includes robust request and response conversion, enabling support for advanced features like streaming, function calling, and multi-modal inputs, significantly expanding the system's flexibility and interoperability with the broader AI ecosystem.

Highlights

• OpenAI Compatibility: Introduces a new openai package that acts as an adapter for OpenAI-compatible APIs, allowing the model.LLM interface to interact with various third-party LLM providers.
• Comprehensive Feature Support: The adapter supports the OpenAI Chat/Completions request schema, including system instructions, streaming responses, and function calling capabilities.
• Multi-modal Input Handling: Extends capabilities to process diverse input types such as text, images, audio, video, and PDF files by converting genai.Blob data into appropriate OpenAI content formats.
• Detailed Example: A new main.go example is added to showcase the usage of the OpenAI-compatible model, demonstrating all supported features and multi-modal inputs.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a well-implemented and robust adapter for OpenAI-compatible APIs. The code is comprehensive, covering various features like streaming, function calling, and multimodal inputs. The inclusion of compatibility workarounds for non-standard third-party providers is a thoughtful addition. The unit tests are thorough, and the example usage is clear and helpful. I have one suggestion to improve performance in the content conversion logic.

[ChinaSiro]

This update introduces two additional environment variables:

• OPENAI_API_KEY – the API key for the OpenAI-compatible endpoint
• OPENAI_BASE_URL – should include the full base path, e.g. https://api.example.com/v1

The API design intentionally keeps the same style as the existing Gemini adapter.
For example:

model, err := gemini.NewModel(ctx, "gemini-2.5-flash", &genai.ClientConfig{
    APIKey: os.Getenv("GOOGLE_API_KEY"),
})

When switching to the OpenAI provider, developers only need to replace:

• gemini.NewModel → openai.NewModel
• genai.ClientConfig → openai.ClientConfig
• GOOGLE_API_KEY → OPENAI_API_KEY

model, err := openai.NewModel(ctx, "any-model", &openai.ClientConfig{
    APIKey: os.Getenv("OPENAI_API_KEY"),
})

This keeps the usage consistent with the Gemini adapter and minimizes migration cost.

[cpunion]

Tested function calling examplesexamples/tools/multipletools (remove search tool) and examples/tools/loadartifacts with openai models (test both openrouter and openai), seems doesn't work. but agent tool works.

[cpunion]

Maybe ,make BaseURL optional?

[cpunion]

It's better for making BaseURL optional.

[ChinaSiro]

Tested function calling examplesexamples/tools/multipletools (remove search tool) and examples/tools/loadartifacts with openai models (test both openrouter and openai), seems doesn't work. but agent tool works.

Thanks for testing this!
I’ve now added ParametersJsonSchema support for function calls, and the updated implementation has been tested successfully. The agent tools continue to work as expected.

It's better for making BaseURL optional.

Since this implementation is primarily designed to be OpenAI-compatible, using an explicit BaseURL configuration is more appropriate. For that reason, we don't provide a default fallback when the value is missing.

[cpunion]

Thanks for testing this! I’ve now added ParametersJsonSchema support for function calls, and the updated implementation has been tested successfully. The agent tools continue to work as expected.

Thanks for your great work! I just tested OpenRouter and OpenAI models, it works!

Since this implementation is primarily designed to be OpenAI-compatible, using an explicit BaseURL configuration is more appropriate. For that reason, we don't provide a default fallback when the value is missing.

I understand.

BTW, some of latest models (e.g. gpt-5-codex) only supports responses API, would you plan to support both chat completion and responses API? maybe switch with a config field. There is another PR using responses API #242

[ChinaSiro]

BTW, some of latest models (e.g. gpt-5-codex) only supports responses API, would you plan to support both chat completion and responses API? maybe switch with a config field. There is another PR using responses API #242

Thanks for the suggestion! It’s true that some newer models (e.g., gpt-5-codex) only support the Responses API. But currently only OpenAI fully supports it, while most other providers — including local LLMs and third-party services — still rely on the traditional Chat Completions API.

Adding Responses logic directly into this file could introduce extra complexity and potentially affect compatibility with those providers. To keep things clean, I think it’s better handled in a separate follow-up.

My plan:

• Keep openai.go unchanged
• Add a UseResponsesAPI bool flag
• Route to a new openai_responses.go when enabled
• Ensure both paths stay clean and independent
• After this PR is merged, I’ll open another PR to add full Responses API support.

[cpunion]

@ChinaSiro I have tested on a demo but it stopped at function calling in streaming mode, maybe need a rich demo and integration test.

I attach my demo code for a example (AI generated), you can run it with options:

research.zip

➜  research git:(feat/openai-compatible-provider) ✗ go run . -help
Usage of research:
  -app string
    	App name for the session (default "research-demo")
  -model string
    	Model name with provider, for example: gemini:gemini-2.5-flash
  -prompt string
    	Prompt to send to the agent
  -session string
    	Existing session ID; leave empty to create one
  -stream
    	Enable streaming mode
  -user string
    	User ID to associate with the session (default "demo-user")

-model accepts gemini:GEMINI-MODEL-NAME, openrouter:OPENROUTER-MODEL-NAME, openai:OPENAI-MODEL-NAME, and you can switch streaming mode with stream.

I just tested (need set OPENROUTER_API_KEY, OPENAI_API_KEY, TAVILY_API_KEY, GEMINI_API_KEY (or GOOGLE_API_KEY):

# Works
$ go run . -prompt "search TESLA stock price, and get weather of New York" -model "openai:gpt-5-mini"`

# Doesn't work
$ go run . -prompt "search TESLA stock price, and get weather of New York" -model "openai:gpt-5-mini" -stream`

# Works
$ go run . -prompt "search TESLA stock price, and get weather of New York" -model "openrouter:openai/gpt-5-mini"`

# Doesn't work
$ go run . -prompt "search TESLA stock price, and get weather of New York" -model "openrouter:openai/gpt-5-mini" -stream`

# Works
$ go run . -prompt "search TESLA stock price, and get weather of New York" -model "gemini:gemini-2.5-flash"`

# Works
$ go run . -prompt "search TESLA stock price, and get weather of New York" -model "gemini:gemini-2.5-flash" -stream`

BTW: I can review and do some tests, but I have no write permissions.