Ollama
Runtime local pour chat, raisonnement secondaire, extraction, code selon modèle disponible et embeddings. elora-ollama doctor/profiles/logs expose sa readiness sans appeler de modèle.
providers
Providers locaux
Le socle local donne à Elora une capacité d'opérer même sans provider cloud. Les APIs distantes restent utiles, mais elles sont candidates, pas propriétaires du système.
llama.cpp
Profil local alternatif pour llama-server, grands contextes, tuning fin et tests sur modèles GGUF. Il est déclaré comme profil, pas lancé implicitement par Elora en V1.
GPU distant privé
remote_ssh_llama_server prépare les machines 5090 ou autres hôtes GPU: lancement distant maîtrisé, tunnel SSH local, endpoint OpenAI-compatible consommé par Elora. Pas de bind public supposé sûr.
OpenAI-compatible
Interface standard pour brancher local ou distant sans réécrire toute l'architecture provider.
Runtime binding
elora-provider runtimes --json --probe relie chaque provider local à un profil runtime et une capacité: chat, reasoning ou code. elora-provider select --capability ... expose ensuite le candidat retenu sans appeler le modèle. Par défaut le lien est préférentiel, pas obligatoire: un endpoint local OpenAI-compatible reste valable même si Ollama est absent. Seul un provider marqué runtime_binding_required=true bloque si le runtime n'est pas exécutable.
local_code
Worker local qui produit artefacts de code/fichiers, plan, manifest, validation log et quality JSON, sans dépendre de Codex, Claude, Hermes ou d'un provider connecté. elora-code backends select --json distingue backend natif, modèle local de code/raisonnement et OpenCode. GLM-5.2 est le candidat recommandé pour le code agentique local quand il est installé et servi localement; Qwen ou d'autres modèles restent remplaçables. Le branchement se fait via endpoint OpenAI-compatible local ou tunnelé, mais Elora ne l'auto-lance pas.
OpenCode
Backend client optionnel pour comprendre, documenter, créer et modifier un repo local. Elora le pilote via local_code: analyse read-only par défaut, édition bornée ou trusted_free sur demande explicite, artefacts, diff et logs conservés. Le Patch Acceptance Gate rend le diff inspectable puis accepté, rejeté ou renvoyé en révision sans commit automatique. Il peut recevoir automatiquement le provider local elora_local_code branché sur Ollama ou tout runtime OpenAI-compatible local. OpenCode n'obtient ni mémoire, ni policy, ni autorité.
TimesFM
Capacité locale de forecasting de séries temporelles, appelée comme worker spécialisé et non comme modèle conversationnel.
Règle de sélection
Elora route par tâche, confidentialité, coût, latence, profondeur, readiness et preuve d'exécution. Un provider plus puissant n'est pas automatiquement meilleur si un worker local déterministe suffit.
Readiness locale
elora-readiness matrix contient un check local_runtime issu de elora-ollama doctor. Il indique si l'API locale répond, si le modèle configuré correspond au provider local, si le PID est stale et où lire les logs. elora-provider runtimes --json --probe ajoute la vue inverse: quels providers sont liés à quels runtimes, et si ce lien est bloquant ou seulement préférentiel. /api/provider-selection expose le même choix au cockpit sans mutation. Le cockpit expose ces contrats via /api/local-runtime, /api/provider-runtimes et /api/provider-selection.
Cette readiness ne prouve pas la qualité d'une réponse modèle. Un smoke OpenCode local peut valider le câblage runtime, le choix du modèle et la capture d'artefacts tout en produisant une réponse partiellement fausse. Les claims restent donc soumis au Claim Verification Gate et aux result/quality gates.