[ADD] ai_connection_openai

[etobella]

No description provided.

[angelmoya]

Hi @etobella

Have you seen how I structured it in my branch?

What I did is create a base module that handles the OpenAI connection standard, and then separate modules for OpenAI and Ollama. This keeps the OpenAI standard logic isolated so we can reuse it across multiple modules.

Looking at your module, I saw you included a class that I could inherit and reuse, but it forces the direct installation of the OpenAI connector. A user might want the OpenAI standard connection without actually having OpenAI available or installed. Also, it feels a bit off to force an OpenAI dependency just to connect to Ollama.

How do you see having that intermediate base module? In my branch, the base module adds the custom endpoint configuration so it can be easily extended—which is exactly how I implemented the Ollama module as an example.

By doing it this way, it will be very easy to implement support for many other LLMs that use the exact same standard, such as:

• DeepSeek (DeepSeek-V3 / R1)
• Groq (Ultra-fast inference)
• Mistral AI
• OpenRouter (Multi-model aggregator)
• Local Engines (vLLM, Llama.cpp, LocalAI)

Let me know your thoughts!

[angelmoya]

Hi @etobella

Have you seen how I structured it in my branch?

What I did is create a base module that handles the OpenAI connection standard, and then separate modules for OpenAI and Ollama. This keeps the OpenAI standard logic isolated so we can reuse it across multiple modules.

Looking at your module, I saw you included a class that I could inherit and reuse, but it forces the direct installation of the OpenAI connector. A user might want the OpenAI standard connection without actually having OpenAI available or installed. Also, it feels a bit off to force an OpenAI dependency just to connect to Ollama.

How do you see having that intermediate base module? In my branch, the base module adds the custom endpoint configuration so it can be easily extended—which is exactly how I implemented the Ollama module as an example.

By doing it this way, it will be very easy to implement support for many other LLMs that use the exact same standard, such as:

• DeepSeek (DeepSeek-V3 / R1)
• Groq (Ultra-fast inference)
• Mistral AI
• OpenRouter (Multi-model aggregator)
• Local Engines (vLLM, Llama.cpp, LocalAI)

Let me know your thoughts!

base module: https://github.com/angelmoya/ai/tree/18.0-wip/ai_connection_base_openai
openai module: https://github.com/angelmoya/ai/tree/18.0-wip/ai_connection_openai
ollama module: https://github.com/angelmoya/ai/tree/18.0-wip/ai_connection_ollama

[etobella]

We isolated the OpenAI connection from the connection. I will not create base and non base without a clear need. openai api allows you to change the URL, so you don't require to use openai.

[angelmoya]

Hi @etobella , that makes sense — I agree there's no need for a separate base_openai module if openai is already self-contained. The base_url parameter already covers Ollama and any OpenAI-compatible provider.

The only thing I'd need for Ollama is a small extensibility point to inject provider-specific parameters into the request before it's sent. Specifically, Ollama supports an options key in the request body (e.g. num_ctx, num_predict, seed) that the OpenAI SDK doesn't expose natively.

A minimal, non-invasive change would be something like:

python
class OpenaiClient(AiConnectionClient):
    ...

    def _get_chat_completion_kwargs(self, messages):
        """Hook for subclasses to inject extra kwargs."""
        return {}

    def handle_message(self, messages=None, **kwargs):
        extra = self._get_chat_completion_kwargs(messages)
        response = self._client.chat.completions.create(
            model=self.model,
            messages=messages,
            tools=self.tool_definition or None,
            temperature=self.temperature,
            **extra,
        )
        ...

Then ai_connection_ollama would just override:

python
def _get_chat_completion_kwargs(self, messages):
    return {"extra_body": {"options": self.ollama_options}}

It's a one-method hook — zero impact on the OpenAPI module, zero additional dependencies, and keeps Ollama as a thin layer.

If you prefer to merge this PR as-is and let me open a follow-up PR with this hook + the ai_connection_ollama module on top, that works for me too. Either way I'm ready to adapt.

[etobella]

why? in ollama you can use ollama library and add all you need in the config.

[angelmoya]

why? in ollama you can use ollama library and add all you need in the config.

That's fair — if we're only talking about Ollama, using the ollama library directly and adding whatever config you need is a valid approach. No extensibility hook needed in ai_connection_openai.

My point wasn't really about Ollama specifically — it's about the general case. The OpenAI-compatible API (/v1/chat/completions) is supported by dozens of providers (vLLM, Groq, Together, DeepSeek, Mistral, local llama.cpp servers, LiteLLM proxies, …) and none of them have a Python library. They all work by hitting the same endpoint with one or two extra keys in the JSON body. Without a small injection point in OpenaiClient, every one of those future modules would need to copy-paste the entire handle_message method just to add extra_body: {"top_k": 40} or whatever their provider needs.

It's not an Ollama problem — it's a "don't make me fork the client class for one extra parameter" principle.

That said, if you prefer to keep ai_connection_openai closed and let Ollama be a separate independent module (either using the ollama library natively, or a standalone HTTP client like we originally had), that works too. Just wanted to flag the pattern before it's cast in stone.