class
LLM::AdapterFactory
- LLM::AdapterFactory
- Reference
- Object
Overview
Factory for creating LLM adapters based on provider configuration.
Defined in:
llm/adapter.crClass Method Summary
- .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
- .native_tool_calling_enabled_for_provider?(provider : String, allowlist : Array(String) | Nil = nil) : Bool
-
.ollama_base_url(provider : String) : String
The native API lives at the server root.
-
.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/completionsevery other provider speaks, so this decision has to be precise.
Class Method Detail
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.
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.