Feature Guide

A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.

What this does

Provider contracts, backend resolution, local vs remote Ollama, and the environment knobs that shape LLM runtime behavior.

Runtime Backends

How the module reaches an LLM

The built-in implementation focuses on Ollama, but the rest of the module talks to provider contracts, not to hard-coded curl calls scattered through commands.

Backend	Resolver path	Key env knobs	Operational note
Local Ollama	`LlmBackend::Local -> LocalOllamaProvider`	`LLM_BASE_URL, LLM_MODEL, LLM_TIMEOUT, LLM_RETRIES`	Default self-hosted path for local inference and fast development loops.
Remote Ollama	`LlmBackend::RemoteOllama -> RemoteOllamaProvider`	`LLM_REMOTE_OLLAMA_URL, LLM_REMOTE_OLLAMA_MODEL, timeouts, retries`	Useful when the model runtime lives on another host or heavier node.
Backend-agnostic commands	`LlmProviderInterface + LlmProviderResolver`	`backend key + provider factory`	The assistant loop only needs `healthCheck()` and `complete()` from the active provider.

LlmProviderInterface LlmProviderResolver local Ollama remote Ollama

Verified against Semitexa Ultimate 2026.09.19.1020

Providers & Backends

The provider layer isolates the assistant from any one backend. semitexa/llm talks to an LlmProviderInterface, while resolver and factory logic decide whether the active backend is local or remote.

How it works

LlmProviderResolver asks a provider factory for the backend selected by LlmBackend. The built-in Ollama providers map Semitexa env config into health checks, chat requests, retry behavior, and response normalization.

Why this matters

This keeps the assistant runtime swappable without changing the planner or executor. The command surface does not need to care which backend actually answered the model request.

Provider Rules

What the built-in providers already handle

The provider classes are thin, but they own several practical concerns that should not leak into planner or command code.

They build the provider-specific HTTP payload from `LlmRequest` and normalize the response into `LlmResponse`.

They run a health check before interactive use so the operator gets a clean failure early.

They expose retries, timeouts, base URL, and model selection through environment-backed config.

They report latency and token usage when the backend returns that metadata.