Changer de modèle

Vous ouvrez cette page parce que le modèle en place ne convient pas, ou parce que vous voulez qu’un modèle différent serve à l’autocomplétion et au chat.

Dans un déploiement Lemniscate, le modèle se choisit sur la passerelle, pas sur le poste : un endpoint de la passerelle désigne le fournisseur, le modèle réel et la clé — et la clé du fournisseur ne descend jamais sur le poste. Le config.yaml du poste ne porte que des pointeurs vers ces endpoints, et le choix des rôles (chat, autocomplétion, indexation). Déclarer un modèle direct sur le poste, avec la clé du fournisseur, est la voie dépréciée — elle reste décrite en fin de page pour le seul poste isolé.

Changer le modèle servi : côté passerelle

Deux cas, selon ce que vous voulez obtenir.

Le même endpoint doit servir un autre modèle — par exemple claude-sonnet doit passer sur une version plus récente : c’est un geste d’administration de la passerelle ; le poste n’a rien à changer, les appels suivants partent vers le nouveau modèle.

Vous voulez basculer sur un autre endpoint — par exemple de claude-sonnet vers gpt-4o : le poste change le segment d’endpoint de son apiBase :

models:
  - name: GPT-4o (passerelle)
    provider: openai
    model: any
    apiBase: http://passerelle.interne:6001/gpt-4o/v1
    apiKey: sk-lemniscate-<la-clé-du-développeur>

Trois champs n’y veulent pas dire ce qu’ils paraissent dire — provider est le dialecte parlé par l’IDE, model est ignoré (la passerelle le réécrit), apiKey est la clé du compte sur la passerelle. Le détail champ par champ, et les codes de refus à reconnaître, sont dans Router l’IDE vers la passerelle. Un endpoint mal orthographié répond 404 en listant les endpoints existants.

Affecter un modèle à un rôle

Le champ roles décide de ce à quoi sert chaque entrée de models — y compris quand l’entrée pointe la passerelle. Un modèle peut porter plusieurs rôles, et plusieurs modèles le même rôle — le premier déclaré est alors retenu par défaut.

Rôle	Ce qu’il alimente
chat	la conversation
edit	les modifications demandées sur une sélection
apply	l’application d’un bloc de code proposé dans le chat
autocomplete	les suggestions en cours de frappe
embed	l’indexation du code et la recherche par similarité
rerank	le reclassement des extraits trouvés

models:
  - name: Chat (passerelle)
    provider: anthropic
    model: any
    apiBase: http://passerelle.interne:6001/claude-sonnet/v1
    apiKey: sk-lemniscate-<clé>
    roles:
      - chat
      - edit
      - apply
  - name: Complétion (passerelle)
    provider: openai
    model: any
    apiBase: http://passerelle.interne:6001/completion-rapide/v1
    apiKey: sk-lemniscate-<clé>
    roles:
      - autocomplete

Le piège du champ omis. Un modèle déclaré sans roles reçoit les rôles conversationnels — chat, édition, application — et ceux-là seulement. Un roles explicite est la seule façon d’obtenir autocomplete, embed ou rerank. Les deux rôles qui ouvrent d’autres fonctions ont leur propre page : activer l’indexation du code pour embed et rerank, régler l’autocomplétion pour autocomplete.

Basculer d’un modèle à l’autre en cours de session

Les entrées de config.yaml sont toutes chargées en même temps : passer de l’une à l’autre ne demande pas de rééditer le fichier. Dans lemni, la commande /model ouvre la liste des modèles portant le rôle chat et bascule sur celui que vous choisissez. Dans l’extension, le sélecteur au-dessus de la zone de saisie du chat fait la même chose.

Quand le changement prend effet

Dans l’IDE, l’enregistrement du fichier déclenche un rechargement de la configuration : la nouvelle entrée apparaît sans redémarrer l’éditeur. lemni lit sa configuration au démarrage — une modification faite pendant une session sera prise à la session suivante. Un changement fait côté passerelle (le modèle derrière un endpoint) est immédiat pour tout le monde : le poste ne recharge rien.

Une entrée dont le chargement lève une erreur n’interrompt pas les autres : elle est écartée, et l’erreur est signalée avec son nom. Un provider inconnu, en revanche, ne produit aucun message : le schéma accepte n’importe quelle chaîne, aucune implémentation n’y est associée, et l’entrée est écartée en silence. Un modèle qui n’apparaît nulle part est d’abord une faute de frappe dans provider.

Voie dépréciée : un modèle direct sur le poste

Déclarer un fournisseur et sa clé directement dans le config.yaml du poste fonctionne encore, mais c’est la voie dépréciée : la clé du fournisseur descend sur chaque poste, sans comptage ni plafond, et sa rotation impose de repasser sur chaque machine. Elle ne se justifie que pour un poste isolé — par exemple un modèle local :

models:
  - name: Qwen 2.5 Coder
    provider: ollama
    model: qwen2.5-coder:32b

La configuration est cherchée dans ~/.lemniscate/config.yaml ; la variable LEMNISCATE_GLOBAL_DIR déplace le dossier entier. lemni accepte aussi un fichier explicite : lemni --config ./config-experimental.yaml "…". L’écriture ${{ secrets.NOM }} évite d’inscrire une clé dans un fichier suivi par git — la valeur est cherchée dans ~/.lemniscate/.env, puis <projet>/.lemniscate/.env, puis <projet>/.env ; sous lemni, une variable d’environnement du même nom l’emporte.

Pour la liste complète des clés acceptées par le fichier, voir Fichier de configuration.