providers
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.
Runtime local ergonomique pour chat, raisonnement secondaire, extraction, code selon modèle disponible et embeddings. elora-runtime status local_ollama expose la readiness générique; elora-ollama doctor/profiles/logs reste l'adaptateur de diagnostic Ollama sans appeler de modèle.
Runtime local haut débit pour modèles plus lourds, agents concurrents, scoring par lots et evals. elora-runtime install local_vllm prépare un environnement repo-local, sans télécharger de poids, sans lancer de serveur et sans muter provider, routing ou mémoire.
Runtime local bas niveau pour llama-server, grands contextes, tuning fin et modèles GGUF. elora-runtime install local_llama_cpp --gpu auto construit le binaire localement; Elora expose ensuite la readiness mais ne lance pas implicitement les modèles lourds.
local_dgx_gb10_llama_server décrit un hôte local lourd, par exemple une machine 128 Go unifiés, capable de servir de grands modèles quantifiés de code ou de raisonnement via llama-server. Cela ne suffit pas à faire de GLM-5.2 753B un modèle local ordinaire. Elora consomme l'endpoint; elle ne démarre pas implicitement le modèle.
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.
Interface standard pour brancher local ou distant sans réécrire toute l'architecture provider.
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.
elora-models select --task code --json joint tâche, capacité, provider retenu, runtime préféré, modèle configuré et famille recommandée. C'est un contrat d'inspection, pas un benchmark: aucune inférence, aucun téléchargement, aucune mutation de routing ou de provider.
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-4.7-Flash est installé comme spécialiste local pratique; GLM-5.2 reste réservé à un runtime frontier adapté. Qwen ou d'autres modèles restent remplaçables.
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é.
Capacité locale de forecasting de séries temporelles, appelée comme worker spécialisé et non comme modèle conversationnel.
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.
elora-readiness matrix contient un check local_runtime issu de elora-runtime, avec les détails Ollama lus via l'adaptateur elora-ollama. Il indique si le runtime local est déclaré, installé, prêt, aligné et actionnable. elora-runtime doctor --all --json donne l'état générique pour Ollama, vLLM, llama.cpp et les profils lourds; elora-runtime install local_vllm --json et elora-runtime install local_llama_cpp --gpu auto --json préparent les serveurs locaux sans les lancer. elora-ollama launch-plan --all --json ajoute la vue d'activation: variables, commande de lancement, probe, smoke et hints pour brancher local_code. elora-models select --task code --json expose ensuite le choix tâche/provider/runtime/modèle. 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. Le cockpit expose ces contrats via /api/local-runtime, /api/model-selection?task=code, /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.