Cline Desktop veut faire des modèles open-weight de vrais agents de travail

Cline ne veut plus seulement être l’agent IASystème qui planifie et enchaîne des actions (outils, APIs, code) pour atteindre un objectif, au-delà d’une seule réponse texte. qui vit dans VS Code. Avec Cline Desktop, le projet se dote d’une application dédiée, pensée notamment pour faire travailler des modèles open-weightModèle dont les poids sont publiés (ex. Llama, Mistral), par opposition à une API fermée uniquement. dans un environnement qui ne dépend plus directement d’un éditeur de code.

L’annonce compte d’autant plus que Cline affirme que son extension VS Code est utilisée par plus de 11 millions de développeurs. Ce chiffre figure directement dans l’annonce de Desktop et dans le retour d’expérience publié par Cline sur la migration de son extension vers son nouveau SDKSoftware Development Kit : bibliothèques et outils pour intégrer un service dans une application. (Cline, Cline).

L’intérêt dépasse donc largement la sortie d’une nouvelle application. Cline montre que l’écosystème des modèles ouverts commence à construire sa propre couche applicative : une interface, des outils, une gestion du contexte, des automatisations et un système capable de faire travailler plusieurs agents.

Mais derrière la promesse d’un modèle que l’on peut faire tourner chez soi arrive une question beaucoup plus concrète : de quelle machine a-t-on réellement besoin ?

Et juste derrière : combien de stockage faut-il prévoir, quelles performances espérer, et le local permet-il vraiment de faire des économies ?

Cline sort de VS Code

Cline a d’abord été connu comme une extension pour VS Code. Avec Desktop, l’éditeur propose désormais un espace de travail autonome dans lequel plusieurs agents peuvent travailler en parallèle, lancer des tâches planifiées, utiliser la recherche web ou encore recevoir de nouveaux outils via des plugins, des serveurs MCPModel Context Protocol : standard pour brancher des outils / données à un LLM (serveurs, resources, tools). et des skills (Cline).

L’application est proposée pour Mac et Windows, ce dernier étant indiqué en beta dans l’annonce de lancement. Cline précise que l’application Mac est entièrement open sourceLogiciel dont le code source est disponible sous une licence qui autorise étude, modification, redistribution., comme son extension et son CLI ; l’annonce ne formule pas la même affirmation à propos du build Windows (Cline).

Cline indique que Desktop donne accès à plus de 300 modèles via son propre fournisseur et permet aussi d’utiliser ses clés APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). avec plus de 50 fournisseurs. Il est également possible de connecter un modèle exécuté localement (Cline).

Autre fonction révélatrice de la stratégie : une conversation commencée dans Claude Code ou Codex peut être importée dans Cline avant d’être poursuivie avec un autre modèle, y compris un modèle open-weight (Cline).

Le modèle devient ainsi une pièce plus facilement interchangeable. Cline cherche, lui, à rester la couche qui organise le travail autour de ce modèle.

Un modèle ouvert ne suffit pas à faire un bon agent

Cline insiste beaucoup sur son agent harness. Le terme mérite une explication.

Un grand modèle de langage sait générer du texte ou du code. Mais un agent doit faire davantage : comprendre quels fichiers consulter, appeler un outil, exécuter une commande, conserver le contexte utile, constater qu’une action a échoué puis essayer autre chose.

Le harness est cette couche logicielle qui relie le modèle au monde extérieur.

Cline explique avoir retravaillé cette fondation autour de son SDK : promptsConsigne / contexte fourni au modèle pour orienter sa génération (system, user, exemples, outils). réécrits, boucle agentique simplifiée, gestion du contexte et des erreurs améliorée, et nouvelle manière pour les modèles de découvrir et appeler les outils (Cline).

C’est particulièrement important avec les modèles open-weight. Deux applications utilisant exactement le même modèle peuvent obtenir des résultats différents si elles ne lui présentent pas les mêmes informations ou ne pilotent pas ses appels d’outils de la même manière.

Cline publie un exemple parlant sur Terminal-Bench 2.0 : avec Kimi K3, Cline affiche 82,02 %, contre 71,9 % pour Hermes et 76,4 % pour OpenCode. Sur GLM 5.3 Flash, Cline affiche 64,0 %, contre 56,2 % pour Hermes et 61,8 % pour OpenCode (Cline).

La précision est importante : Cline indique lui-même que ces résultats sont ceux du harness Cline CLI, et non un benchmark distinct de Cline Desktop (Cline). Ces scores servent donc surtout à illustrer l’importance de la couche d’orchestration autour du modèle.

Open-weight : de quoi parle-t-on exactement ?

« Open-weight » et « open source » ne sont pas synonymes.

Dans un modèle open-weight, les poids entraînés du modèle sont disponibles. Il devient donc possible, lorsque sa licence le permet, de les télécharger et de faire fonctionner le modèle sur sa propre infrastructure.

Cela ne signifie pas nécessairement que toutes les données d’entraînement, le code utilisé pour entraîner le modèle ou l’intégralité de sa chaîne de fabrication sont ouverts.

Cette distinction compte ici : Cline présente explicitement l’application Mac comme open source, tandis que Desktop peut piloter différents modèles open-weight (Cline).

Combien de RAM faut-il aujourd’hui ?

La documentation actuelle de Cline est volontairement plus générale qu’elle ne l’était auparavant. Elle ne recommande plus un modèle précis pour chaque quantité de mémoire.

Son tableau « Hardware Requirements » distingue désormais trois catégories : 16 à 32 Go de RAM pour les petits modèles ou modèles quantifiés, 32 à 64 Go pour les modèles de code intermédiaires, et 64 Go ou plus pour les modèles plus gros et les grandes fenêtres de contexte (documentation Cline).

Cline recommande également d’activer son Compact Prompt, de garder les tâches ciblées et d’ouvrir une nouvelle tâche lorsque le contexte devient trop important ; la documentation résume ce compromis très simplement : un contexte plus petit donne des réponses plus rapides (documentation Cline).

Ce tableau est plus utile qu’un faux « minimum » universel. La mémoire nécessaire dépend en effet du modèle choisi, de sa quantification et de la taille du contexte que l’agent doit conserver.

Un exemple concret, mais daté : Qwen3 Coder 30B

Pour mettre des chiffres derrière ces catégories, il faut revenir à un guide publié par Cline le 30 septembre 2025, à partir de tests menés avec AMD. Il s’agit donc d’un exemple matériel daté, et non de la sélection de modèles de référence de Cline en 2026 (Cline, AMD).

Dans ce guide, Cline propose trois paliers : 32 Go de RAM avec Qwen3 Coder 30B en 4 bits, pour un téléchargement annoncé autour de 17 Go ; 64 Go avec le même modèle en 8 bits, autour de 32 Go ; et 128 Go ou plus avec GLM-4.5-Air en 4 bits, donné autour de 60 Go (Cline).

Un playbook AMD distinct consacré à Qwen3-Coder avec Cline et LM Studio exige lui aussi 32 Go de mémoire système au minimum pour la configuration qu’il documente. Ce document est centré sur des configurations Ryzen AI et Radeon sous Windows ou Linux (AMD).

Cline affirme de son côté, dans son billet de septembre 2025, que les enseignements tirés de ces tests sont plus larges et que les besoins en RAM restent les mêmes sous Windows, Mac ou Linux, même si le matériel et le runtime peuvent différer (Cline). Il faut donc distinguer le périmètre matériel du playbook AMD de la généralisation que Cline fait ensuite de ses ordres de grandeur.

Ces exemples de 2025 restent intéressants pour comprendre les ordres de grandeur : faire tourner un agent local capable de coder peut rapidement mobiliser plusieurs dizaines de gigaoctets de mémoire et de stockage. Ils ne disent en revanche pas quel est « le meilleur modèle local » à choisir en 2026.

Pourquoi parle-t-on de modèles « 4 bits » ou « 8 bits » ?

Un modèle contient des milliards de paramètres numériques. Pour l’exécuter plus facilement sur une machine personnelle, il est possible de réduire la précision avec laquelle ces nombres sont stockés. C’est ce que l’on appelle la quantification.

En simplifiant, passer à une représentation 8 bits ou 4 bits réduit fortement la quantité de données à conserver en mémoire et sur le disque, avec un compromis potentiel sur la qualité.

Le guide Cline de septembre 2025 donne pour Qwen3 Coder 30B des téléchargements d’environ 17 Go en 4 bits, 32 Go en 8 bits et 60 Go en 16 bits (Cline). Ce dernier chiffre de 60 Go concerne ici Qwen3 Coder 30B en 16 bits ; il ne faut pas le confondre avec les ~60 Go attribués plus haut à GLM-4.5-Air en 4 bits.

Ces valeurs sont des ordres de grandeur. La taille exacte dépend du format et de la méthode de quantification utilisée.

Un exemple le montre bien : une version GGUFRéduction de la précision numérique des poids pour diminuer mémoire et coût d’inférence, avec un trade-off qualité. de Qwen3-Coder-30B-A3B-Instruct publiée par TensorBlock pèse 18,557 Go en Q4_K_M, alors que sa version Q8_0 atteint 32,484 Go (TensorBlock sur Hugging Face).

Autrement dit, « 4 bits » aide à comprendre la catégorie de compression, mais ne permet pas à lui seul de connaître la taille exacte du fichier.

Le stockage : le modèle pèse bien plus lourd que l’application

Dans un usage local, l’espace à prévoir ne se limite pas à Cline Desktop.

Il faut stocker le modèle, son runtime et les éventuelles autres quantifications téléchargées pour les tester. La documentation Cline actuelle cite trois runtimes locaux : Ollama, LM Studio et Atomic Chat (documentation Cline).

Avec l’exemple TensorBlock précédent, un seul fichier Q4_K_M de Qwen3 Coder 30B occupe 18,557 Go, et la variante Q8_0 32,484 Go (TensorBlock).

En pratique, quelqu’un qui souhaite conserver plusieurs modèles ou plusieurs quantifications doit donc prévoir nettement plus que la taille d’un unique téléchargement.

Nous ne donnons en revanche pas de chiffre de « stockage minimum pour Cline Desktop » : l’annonce de Cline ne fournit pas de capacité disque minimale officielle pour l’application elle-même. Donner une valeur créerait une fausse précision.

RAM, VRAM et mémoire unifiée : ce n’est pas la même chose

Autre source de confusion fréquente : un fichier de modèle stocké sur un SSD n’est pas la même chose qu’un modèle chargé pour travailler.

Le stockage conserve le fichier lorsque le modèle ne tourne pas.

La RAM est la mémoire générale de la machine.

La VRAM est la mémoire disponible sur une carte graphique dédiée. Sur les Mac Apple Silicon, CPU et GPUProcesseur graphique massivement parallèle, standard de fait pour entraîner et servir des modèles de deep learning. partagent à la place une architecture de mémoire unifiée.

Sur une machine équipée d’un GPU dédié, la quantité de mémoire graphique disponible influence la quantité de calcul pouvant être accélérée sur le GPU. Sur une machine à mémoire unifiée, la même réserve doit également servir au système et aux autres applications.

C’est pourquoi deux ordinateurs affichant le même nombre de gigaoctets sur leur fiche technique peuvent offrir une expérience assez différente.

Et les performances ? Pas de chiffre universel

C’est l’un des endroits où il vaut mieux résister à la tentation d’un chiffre simple.

La documentation Cline actuelle ne publie plus d’ordre de grandeur universel du type « X tokensUnité de texte traitée par un modèle (souvent un morceau de mot). Les coûts et fenêtres de contexte se comptent en tokens. par seconde » ou « Y secondes de chargement » sur sa page consacrée aux modèles locaux. Elle se contente de rappeler que les petits contextes donnent des réponses plus rapides et conseille de garder les tâches ciblées (documentation Cline).

C’est cohérent avec la réalité de l’inférencePhase d’utilisation d’un modèle déjà entraîné : produire une sortie à partir d’une entrée (par opposition à l’entraînement). locale : la vitesse dépend du modèle, de sa quantification, du runtime, du CPU ou GPU, de la mémoire disponible et du volume de contexte à ingérer.

Le token reste l’unité élémentaire manipulée par le modèle. Mesurer des tokens par seconde est utile pour comparer deux configurations testées dans les mêmes conditions, mais beaucoup moins pour promettre une vitesse générale à tous les utilisateurs de Cline Desktop.

Pour un agent, la vitesse de génération n’est de toute façon qu’une partie du problème : il doit aussi lire le projet, utiliser ses outils, exécuter des commandes et parfois recommencer après une erreur.

Le local est-il réellement moins cher ?

C’est ici que la promesse mérite le plus de nuance.

Dans un billet publié en août 2025 autour de Qwen3 Coder 30B et LM Studio, Cline présentait l’inférence locale comme un moyen de travailler sans coût d’API, sans données utilisateur quittant la machine et sans dépendance à Internet une fois l’environnement installé (Cline). Il faut lire cette affirmation dans le contexte de ce scénario local précis et de cette publication datée.

Le principe économique reste simple : un modèle exécuté sur sa propre machine ne facture pas chaque token généré via une API distante.

Mais cela ne signifie pas que son utilisation est gratuite.

Le coût est déplacé vers la machine, son stockage et l’électricité qu’elle consomme. Une personne possédant déjà un ordinateur suffisamment équipé n’a évidemment pas le même calcul économique qu’une personne devant acheter une nouvelle machine uniquement pour exécuter un grand modèle.

Et Cline propose lui-même une autre voie qui montre que le choix ne se résume pas à « local ou API chère ». ClinePass est affiché à 9,99 dollars par mois, avec des quotas sur une sélection de modèles open-weight hébergés (ClinePass).

La liste actuelle illustre aussi à quel point le marché a évolué depuis les guides locaux de 2025 : ClinePass propose notamment GLM 5.3, Kimi K3, DeepSeek V4 Pro et Qwen3.8-Max, aux côtés d’autres modèles de Z.ai, Moonshot AI, DeepSeek, MiniMax, MiMo et Qwen (ClinePass).

Cette gamme hébergée ne dit pas quels modèles peuvent être exécutés confortablement sur un PC personnel : les deux questions sont différentes. Elle rappelle simplement que Qwen3 Coder 30B et GLM-4.5-Air sont ici des exemples matériels historiques, pas un classement 2026 des meilleurs modèles open-weight.

Pour un utilisateur occasionnel, une offre hébergée ou une API peut coûter moins cher que l’achat d’un ordinateur plus puissant. Pour un utilisateur intensif disposant déjà du matériel, le modèle local peut au contraire éviter une facture proportionnelle au nombre de requêtes.

Il n’existe pas de seuil universel du type « le local devient rentable après X mois ». Il faudrait connaître le prix réel de la machine, son éventuel amortissement, sa consommation électrique, le volume d’utilisation et le tarif du service cloud auquel on le compare.

Sans ces données, annoncer un point de rentabilité précis serait artificiel.

Le vrai sujet : l’écosystème open-weight construit sa couche applicative

C’est finalement ce qui rend Cline Desktop plus intéressant qu’un simple changement d’interface.

Pendant longtemps, la discussion sur l’IA ouverte s’est concentrée sur les modèles : qui publie ses poids, avec quelle licence, et avec quelles performances ?

La question suivante arrive désormais : que peut-on réellement construire autour de ces modèles ?

Cline tente d’y répondre avec une couche qui ne dépend pas d’un modèle unique. Desktop peut utiliser un modèle local, une API externe ou l’offre de Cline ; l’utilisateur peut changer de fournisseur et faire circuler une tâche entre différents environnements (Cline).

Cette abstraction est peut-être la partie la plus importante de l’annonce.

Si les modèles deviennent interchangeables, une partie de la valeur se déplace vers les logiciels capables de leur fournir les bons outils, le bon contexte et une boucle de travail suffisamment robuste.

Les résultats publiés par Cline avec Kimi K3 sur Terminal-Bench 2.0 vont précisément dans ce sens : 82,02 % avec le harness Cline, contre 71,9 % avec Hermes, pour le même modèle testé dans des environnements agentiques différents (Cline).

Les modèles open-weight disposent alors de quelque chose qui leur manquait encore souvent face aux plateformes propriétaires : une expérience applicative pensée pour les transformer en agents utilisables au quotidien.

Reste une réalité très matérielle : l’ouverture des poids ne fait pas disparaître les besoins de calcul. Elle permet surtout de choisir où le calcul a lieu, qui contrôle la machine et comment son coût est payé.