Qu'est-ce que maxOS

maxOS est une plateforme AI-native open source de l'entreprise ООО «Гарипофф», fonctionnant sur des modèles locaux. Son cœur ouvert est un agent : il lit et modifie les fichiers du projet et exécute des commandes dans le terminal, mais il le fait via un modèle de langage s'exécutant sur votre machine. Ni le code, ni les requêtes, ni le contenu des fichiers ne sont envoyés vers un cloud tiers.

Le cœur est ouvert sous licence Apache-2.0 : github.com/LLC-Garipoff/maxos. Commençons par là.

Un agent, pas une simple autocomplétion

L'autocomplétion suggère la ligne suivante. L'agent résout la tâche dans sa globalité : il analyse le projet, apporte des modifications à plusieurs fichiers, lance le build et les tests, lit la sortie et poursuit son travail.

Au cœur de maxOS se trouve une boucle simple. Une tâche et la description des outils disponibles sont transmises au modèle. Le modèle ne répond pas par du texte, mais par la décision d'appeler un outil. Il y a quatre outils :

• read_file — lire un fichier ;
• list_dir — afficher le contenu d'un répertoire ;
• write_file — créer ou écraser un fichier ;
• run_bash — exécuter une commande dans le terminal (build, tests, exécution).

maxOS exécute l'appel dans le répertoire de travail, renvoie le résultat au modèle, et la boucle se répète jusqu'à ce que le modèle cesse d'appeler des outils et fournisse un résultat final. Tous les chemins sont limités au dossier de travail — tout appel tentant d'en sortir est rejeté. Avant d'écrire un fichier ou d'exécuter une commande, maxOS demande par défaut une confirmation.

C'est tout le principe. Aucun orchestrateur cloud caché — la boucle, les outils et le prompt tiennent en quelques centaines de lignes sans dépendances d'exécution.

Uniquement des modèles locaux

maxOS ne gère pas lui-même le calcul du réseau de neurones. Il délègue l'inférence à un runtime local doté d'une API compatible OpenAI — par exemple Ollama ou llama.cpp. Vous lancez le modèle chez vous :

ollama pull qwen2.5-coder:7b

— et maxOS communique avec lui via http://localhost. Il n'y a aucun point de terminaison cloud dans ce schéma : si la machine supporte le modèle, l'agent fonctionne entièrement hors ligne.

Il y a ici une subtilité technique pour laquelle il a fallu écrire une couche spécifique. Certains modèles locaux renvoient proprement les appels d'outils dans le champ structuré tool_calls, comme l'attend le protocole compatible OpenAI. Mais beaucoup d'autres — y compris qwen2.5-coder — écrivent à la place l'appel sous forme de texte JSON directement dans la réponse. maxOS détecte les deux cas : si le champ structuré est absent, il extrait l'appel du texte (y compris le format avec les balises <tool_call>) et poursuit la boucle. C'est pourquoi le framework fonctionne avec différents modèles, et pas seulement avec un unique modèle « idéal ».

Où se connectent les modèles pour le code

maxOS est un orchestrateur : prompt, outils, boucle, bac à sable, confirmations. Le code lui-même est écrit et modifié par le modèle connecté. Pour le développement, on installe dans le runtime des modèles spécialisés — qwen2.5-coder, llama3.1 et similaires, capables d'appeler des outils. Changer de modèle se fait en une seule ligne (--model) ou via une variable d'environnement ; le reste de l'agent demeure inchangé.

Cette séparation est délibérée. La boucle de l'agent est limitée par le disque et le réseau, et non par les calculs, c'est pourquoi elle est écrite en TypeScript — pour itérer rapidement et s'installer facilement. Quant aux parties axées sur la performance et le système, qui ne sont pas encore prêtes, nous prévoyons de les porter vers un cœur natif en Rust : indexation de grands dépôts et recherche à l'intérieur, binaire unique sans dépendance à Node. La logique reste la même : choisir l'outil adapté à un besoin précis, plutôt que de réécrire en Rust ce qui dépend principalement des entrées-sorties.

Quel est le rapport avec SpotMax

SpotMax est l'application de bureau de l'équipe, née de la même idée : le modèle qui vous aide doit fonctionner à vos côtés, et non dans un centre de données tiers. Le nom lui-même vient de Spotlight + max : un outil étroitement intégré au système d'exploitation, toujours à portée de main.

Nous l'avons conçu initialement pour les ventes — pour nos propres présentations et pitchs : l'assistant écoute la conversation et propose des suggestions en temps réel pour garder le fil et le contexte. Il s'est avéré utile bien au-delà — il a servi aux candidats comme aux RH. Aujourd'hui, il est de plus en plus utilisé pour les négociations avec des partenaires étrangers : SpotMax reconnaît et transcrit la parole directement sur l'appareil et aide à mener la conversation sans en perdre le sens. Le fonctionnement exact de l'écoute des appels, de la transcription de la parole et des suggestions est détaillé dans un article dédié : Comment fonctionne SpotMax : transcription, traduction et suggestions pendant un appel.

La reconnaissance et la distinction des locuteurs fonctionnent localement — ce sont précisément ces modèles qui tournent sur l'appareil. maxOS en est le socle commun et ouvert : une couche d'agent que nous avons publiée en open source afin qu'elle puisse être lue, vérifiée et améliorée.

Pourquoi le choix du local

Les agents de code basés sur le cloud envoient votre code source, vos requêtes et souvent la sortie du terminal vers un serveur tiers. Pour une grande partie du travail — code propriétaire, données réglementées, NDA, ou tout simplement une mauvaise connexion réseau — cela est inacceptable. maxOS fait du fonctionnement local la seule voie possible : vous pouvez le vérifier directement dans le code source, car il est ouvert.

Le code, les rapports de bugs et les améliorations sont sur GitHub : github.com/LLC-Garipoff/maxos. Et pour des améliorations spécifiques des modèles locaux, nous proposons un programme de récompenses.