Switch models

This page covers two needs: replacing the model in place, or serving a different model to autocompletion and to chat.

In a Lemniscate deployment, the model is chosen on the gateway, not on the workstation: a gateway endpoint designates the inference engine and the open-weights model it serves. The workstation’s workstation.yaml holds pointers to those endpoints, along with the choice of roles (chat, autocompletion). The workstation only knows the gateway’s address: only the gateway host reaches the inference engine (security white paper V3, sections 3.3 and 8.2).

Changing the model served: on the gateway side

Two cases, depending on what you want.

The same endpoint has to serve a different model, for example code-principal moving to a more recent open-weights model: this is a gateway administration task, described in Declare a model served by the gateway. The workstation has nothing to change; subsequent calls go to the new model.

You want to switch to a different endpoint, for example from code-principal to code-candidat: the workstation changes the endpoint segment in its apiBase:

models:
  - name: Code candidat (passerelle)
    provider: openai
    model: any
    apiBase: https://passerelle.interne:6001/code-candidat/v1
    apiKey: sk-lemniscate-<la-clé-du-développeur>

Three fields do not mean what they appear to mean: provider is the dialect spoken by the IDE, here that of the OpenAI-compatible API; model is ignored (the gateway rewrites it); apiKey is the account key on the gateway. The field-by-field detail, and the rejection codes to recognize, are in Route the IDE to the gateway. A misspelled endpoint answers 404 and lists the existing endpoints.

Assigning a model to a role

The roles field decides what each models entry is used for, including when the entry points at the gateway. A model can carry several roles, and several models the same role; the first one declared is then used by default.

Role	What it drives
chat	the conversation
edit	edits requested on a selection
apply	applying a code block proposed in the chat
autocomplete	suggestions as you type

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

Omitting the field has an effect worth knowing. A model declared without roles receives the conversational roles (chat, edit, apply and summarize), and those only. An explicit roles is the only way to get autocomplete; see tune autocompletion.

No role indexes the code: Lemniscate builds no index, and the agent explores the repository on demand; see What does not exist.

Switching from one model to another mid-session

The workstation.yaml entries are all loaded at the same time: moving from one to another does not require editing the file again. In lemni, the /model command opens the list of models carrying the chat role and switches to the one you pick. In the extension, the selector above the chat input box does the same thing.

When the change takes effect

In the IDE, saving the file triggers a configuration reload: the new entry appears without restarting the editor. lemni reads its configuration at startup; a change made during a session takes effect in the next one. A change made on the gateway side (the model behind an endpoint) is immediate for everyone: the workstation reloads nothing.

An entry that raises an error while loading does not interrupt the others: it is set aside, and the error is reported with its name. An unknown provider produces an error of that family: the message names the model, quotes the provider it received and lists the accepted identifiers. A model that appears nowhere is first of all a typo in provider.

A model can also be missing because your organization’s policy forbids its provider: an entry whose provider appears in the forbidden list is set aside at load time, and the configuration page says so (Model provider '…' is forbidden by your organization's policy). The model-adding screen does not offer these values and indicates how many it is hiding. The rule comes from the administrator, not from the workstation; the expected path is a gateway endpoint.

Where the configuration is looked up

The configuration is looked up in ~/.lemniscate/workstation.yaml; the LEMNISCATE_GLOBAL_DIR variable moves the whole folder. lemni also accepts an explicit file: lemni --config ./config-experimental.yaml "…". Writing ${{ secrets.NOM }} avoids putting the account key in a file tracked by git: the value is looked up in the environment of the window that launched the product, then in ~/.lemniscate/.env, then <projet>/.lemniscate/.env, then <projet>/.env. This order is the same on every surface.

For the full list of keys the file accepts, see Configuration file.