class

LLM::AdapterFactory

Factory for creating LLM adapters based on provider configuration.

Class methods

for(provider : String, model : String, api_key : String | Nil = nil, event_sink : Proc(String, Nil) | Nil = nil, native_tool_calling_allowlist : Array(String) | Nil = nil) : Adapter

Source

native_tool_calling_enabled_for_provider?(provider : String, allowlist : Array(String) | Nil = nil) : Bool

Source

ollama_base_url(provider : String) : String

The native API lives at the server root. The CLI's own help prints ollama -> http://localhost:11434/v1, and that /v1 is the OpenAI-compatible mount: appending /api/generate to it yields a 404, so it is dropped before LLM::Ollama builds the endpoint URL.

Source

ollama_native?(provider : String) : Bool

Ollama's native API (POST /api/generate) is a different protocol and a different body shape from the OpenAI-compatible /v1/chat/completions every other provider speaks, so this decision has to be precise.

It used to be provider.downcase.includes?("ollama") tested against the whole provider string. A path segment is chosen by whoever runs the gateway, so an OpenAI-compatible endpoint mounted at http://gw.example/ollama/v1 was handed the wrong API — and, because the same full string is used as the base URL, the request went to http://gw.example/ollama/v1/api/generate. The 404 came back as an empty result rather than an error.

Only the exact alias and the host decide now. A host named ollama that is explicitly serving the compatibility path is still an OpenAI-compatible endpoint.

Source