Agent de code avec LLM local : Ollama et LM Studio

Un agent de code avec LLM local est une CLI de code, comme opencode, Aider, Goose, Qwen Code, Crush ou Codex, pointée vers un modèle qui tourne sur votre propre machine via Ollama ou LM Studio plutôt que vers une API hébergée. Vous démarrez un serveur local (Ollama écoute sur http://localhost:11434, LM Studio sur http://127.0.0.1:1234), vous choisissez un modèle qui gère l’appel d’outils, vous augmentez nettement sa longueur de contexte par rapport au défaut, et vous indiquez à la CLI d’utiliser cet endpoint. Ça marche, votre code reste sur votre machine, et il n’y a aucun coût par token. C’est aussi plus lent et moins capable que les meilleurs modèles hébergés, d’où un setup hybride pour la plupart des gens.

Ce que « local » veut vraiment dire ici

Un agent de code se compose de deux parties : la CLI qui lit les fichiers, exécute des commandes et modifie le code, et le modèle qui décide de la suite. Passer en local ne remplace que la seconde partie. La CLI exécute la même boucle ; elle envoie simplement ses requêtes à un serveur sur localhost au lieu de l’API d’un fournisseur.

Les deux serveurs locaux courants parlent une API compatible OpenAI :

La doc d’Ollama précise que les clients OpenAI exigent une valeur de clé API mais qu’Ollama l’ignore : n’importe quel texte fait l’affaire pour un serveur local.

Le réglage que tout le monde oublie : la longueur de contexte

Avant de choisir une CLI, réglez ceci. Les agents envoient beaucoup de contexte : un prompt système, des définitions d’outils, le contenu de fichiers et la sortie de commandes. Un serveur local avec une petite fenêtre en coupera discrètement la majeure partie.

La fenêtre de contexte par défaut d’Ollama dépend de votre VRAM : 4k tokens sous 24 GiB, 32k entre 24 et 48 GiB, et 256k à partir de 48 GiB. La doc d’Aider ajoute qu’Ollama ignore sans avertissement le contexte qui dépasse la fenêtre. La doc de Goose juge trop bas un défaut de 4096 tokens, et le guide Codex d’Ollama demande au moins 64k.

Augmentez-la au démarrage du serveur, puis vérifiez :

OLLAMA_CONTEXT_LENGTH=64000 ollama serve
ollama ps   # CONTEXT column shows the allocated length

L’application Ollama propose dans ses réglages un curseur de longueur de contexte qui fait la même chose. Si ollama ps montre le modèle en partie sur le CPU dans la colonne PROCESSOR, le contexte ou le modèle est trop gros pour votre GPU et tout va ralentir.

Quelles CLI prennent en charge les modèles locaux

Voici ce que la documentation de chaque outil confirme. Nous ne listons que les configurations que nous avons pu vérifier.

Codex

Codex offre le chemin le plus court. Sa doc indique qu’il peut tourner avec un provider « open source » local comme Ollama ou LM Studio quand vous passez --oss :

codex --oss                     # default local model
codex --oss -m gpt-oss:120b     # a specific model

Définissez le provider par défaut dans ~/.codex/config.toml avec oss_provider = "ollama" (ou "lmstudio"). Ollama propose aussi ollama launch codex, qui prépare un profil pour vous. Dans Codex, /model bascule entre les modèles installés capables d’appeler des outils.

opencode

opencode accepte tout serveur compatible OpenAI comme provider personnalisé dans opencode.json :

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": { "qwen3": { "name": "Qwen3 (local)" } }
    }
  }
}

Pour LM Studio, utilisez http://127.0.0.1:1234/v1 comme URL de base et l’identifiant de modèle affiché dans LM Studio. La doc d’opencode donne un conseil utile : si les appels d’outils ne fonctionnent pas, augmentez num_ctx dans Ollama, en partant d’environ 16k à 32k.

Aider

Aider dialogue directement avec Ollama. Sa doc recommande le préfixe ollama_chat/ :

export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/<model>

Pour LM Studio ou tout autre serveur compatible OpenAI, définissez OPENAI_API_BASE et OPENAI_API_KEY, puis utilisez aider --model openai/<model-name>. Une taille de contexte fixe se place dans .aider.model.settings.yml sous la forme num_ctx dans extra_params.

Goose

Goose liste Ollama et LM Studio parmi ses providers. Lancez goose configure, choisissez Ollama et saisissez un nom de modèle. Il utilise localhost:11434 sauf si OLLAMA_HOST indique autre chose ; LM Studio utilise par défaut localhost:1234 sans clé API. La doc de Goose est franche sur la contrainte principale : il utilise massivement l’appel d’outils, un modèle qui en est dépourvu ne peut donc que discuter.

Qwen Code

Qwen Code prend en charge tout endpoint compatible OpenAI, et son README cite les modèles locaux via Ollama ou vLLM. Pointez les variables standard vers votre serveur :

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama   # any placeholder for a local server
export OPENAI_MODEL=<model>
qwen

La même chose peut résider dans ~/.qwen/settings.json sous modelProviders, ou se configurer de façon interactive avec /auth.

Crush

Crush prend en charge ollama et lmstudio comme types de provider. Son README montre Ollama ajouté avec l’URL de base http://localhost:11434/v1. Choisissez le modèle dans Crush avec Ctrl+L.

Quand l’agent local se comporte mal

La plupart des problèmes avec un agent de code local tiennent à quelques causes. Vérifiez-les dans cet ordre :

• Il oublie des fichiers ou des instructions en cours de tâche. Le contexte est trop petit et le serveur tronque. Augmentez OLLAMA_CONTEXT_LENGTH (ou num_ctx) et confirmez avec ollama ps.
• Les appels d’outils échouent ou reviennent en texte brut. Le modèle ne gère peut-être pas l’appel d’outils, ou le contexte est trop court pour les définitions d’outils. Essayez un modèle capable d’appeler des outils et une fenêtre plus grande ; la doc d’opencode suggère de commencer vers 16k à 32k.
• La CLI dit que le modèle n’existe pas. Le nom dans la CLI doit correspondre exactement à l’identifiant du serveur : le tag donné par ollama list, ou l’identifiant dans le panneau serveur de LM Studio.
• Connexion refusée. Le serveur ne tourne pas, ou la CLI attend une autre adresse. Ollama utilise 11434, LM Studio 1234, et certaines CLI veulent le suffixe /v1 alors que OLLAMA_API_BASE d’Aider n’en veut pas.
• Tout est très lent. Le modèle ou le contexte ne tient pas sur le GPU. ollama ps montre la part de CPU ; choisissez un modèle plus petit ou un contexte plus court.

La réalité du matériel

C’est là que les attentes se brisent d’habitude. Un agent de code local est une tâche plus lourde qu’un chat local :

• Le modèle doit tenir en mémoire. VRAM du GPU sur un PC, mémoire unifiée sur Apple Silicon. Quand il ne tient pas, des couches débordent sur le CPU et la génération ralentit fortement.
• Le contexte coûte aussi de la mémoire. Une fenêtre de 64k en plus des poids du modèle demande bien plus de place qu’un chat à 4k. C’est pourquoi Ollama lie sa longueur de contexte par défaut à la VRAM.
• Les petits modèles peinent avec les outils. Les agents dépendent d’appels d’outils fiables et du respect d’un long prompt système. Les petits modèles produisent souvent des appels mal formés, tournent en boucle ou s’arrêtent trop tôt. Goose note que certains modèles, comme le DeepSeek-R1 natif, ne gèrent pas du tout l’appel d’outils.
• La lenteur s’accumule. Un agent fait de nombreuses requêtes par tâche, chacune avec un gros prompt. Un modèle agréable en chat peut rendre une tâche de dix étapes très longue.

Une façon pratique de commencer : prenez le plus grand modèle de code capable d’appeler des outils qui tourne entièrement sur votre GPU avec au moins 32k à 64k de contexte, confirmez avec ollama ps, et testez-le sur une petite tâche réelle avant de lui confier quoi que ce soit de plus gros.

Pourquoi passer en local : confidentialité et contrôle

La raison principale est que l’inférence reste sur votre machine :

• Vos prompts et votre code ne sont pas envoyés à un fournisseur de modèle.
• Ça marche hors ligne et dans des environnements isolés du réseau.
• Pas de facture au token ni de limites d’usage à atteindre.
• Le modèle ne change pas sous vos pieds ; vous décidez quand mettre à jour.

Deux réserves pour rester honnête. D’abord, la CLI peut quand même utiliser le réseau : Codex avec le profil de lancement d’Ollama dispose de la recherche web, et certaines CLI ont de la télémétrie. Vérifiez les réglages de chaque outil si rien ne doit sortir du tout de la machine. Ensuite, tourner en local ne rend pas l’agent lui-même plus sûr. Il exécute toujours des commandes et modifie des fichiers, donc les bonnes pratiques de sécurité des agents de code habituelles s’appliquent.

Compromis face aux modèles hébergés

L’écart est le plus faible sur des tâches circonscrites : écrire un test, expliquer une fonction, un petit refactoring, un message de commit. Il est le plus grand sur le travail long en plusieurs étapes sur de nombreux fichiers, où l’agent doit garder un plan et se rattraper après ses propres erreurs.

Un setup hybride qui fonctionne

Un partage fonctionne généralement mieux qu’un basculement tout ou rien :

1. Le travail sensible ou hors ligne va en local. Du code qui ne doit pas quitter la machine, des dépôts clients aux conditions strictes, le travail dans l’avion.
2. Les tâches courantes et circonscrites vont en local. Tests, docs, petits correctifs et explications.
3. Les tâches difficiles vont vers un modèle hébergé. Changements d’architecture, bugs retors, gros refactorings.
4. Relisez dans un contexte neuf. Laissez un second agent contrôler le diff du premier, quel que soit le modèle qui l’a écrit.

Le plus simple pour faire cela est de lancer deux agents ou plus en même temps : un sur un endpoint local, un sur un modèle hébergé, chacun dans son propre dossier ou worktree git pour qu’ils ne modifient pas les mêmes fichiers.

Agents locaux et hébergés côte à côte dans AgentVera

AgentVera est une application de bureau qui fait tourner de nombreux agents CLI côte à côte dans un seul espace de travail, ce qui convient au setup hybride ci-dessus. Pour être clair sur ce qu’elle fait et ne fait pas :

• Elle n’a pas d’intégration Ollama ou LM Studio native. Chaque agent utilise sa propre configuration de provider : goose configure pour Goose, la config propre d’opencode et /connect, les variables d’environnement ou .aider.conf.yml d’Aider, la connexion ou la clé API de Qwen Code, les réglages de Crush (Ctrl+L).
• Le champ « Model » est transmis à la CLI. Pour des agents comme Qwen Code, Goose et Aider, ce que vous y saisissez est passé à la CLI en --model. Pour Goose, l’indication dit : « If left empty, the model chosen with goose configure is used. »
• Les agents peuvent porter des variables d’environnement. Dans Settings → Accounts → Accounts of other agents, un compte ajouté « With an API key » stocke un « Variable name » et sa valeur. Pour Qwen Code, OPENAI_BASE_URL fait partie des noms suggérés, et tout autre nom peut être saisi. Cela fait partie de la bascule de comptes des offres Pro et Team.
• Les outils de contexte vont au-delà de Claude Code. La taille du contexte est mesurée à partir de l’historique propre de chaque CLI, et l’auto-compact utilise la commande de compactage de la CLI quand elle en a une. Avec une petite fenêtre locale, cela compte encore plus.

Le tableau réaliste est donc le suivant : vous configurez le modèle local dans la CLI comme sa doc le décrit, et AgentVera vous permet de faire tourner cet agent à côté d’un agent hébergé, de surveiller les deux et de séparer leur travail.