Mnemosyne OS
Nouveau La documentation explique chaque moteur, pas à pas. docs.mnemosyne-os.io →

Claude Code Cursor Antigravity OpenClaw

La session s'arrête.
Tes décisions restent.

Ton agent de code est brillant pendant deux heures. Puis le contexte sature. Tu ouvres une nouvelle conversation, et il repart explorer ton dépôt : grep, fichiers lus en entier, des milliers de tokens avant sa première réponse utile. Quand tu en as trois ouvertes en même temps, chacune refait le trajet, et aucune ne sait ce que les deux autres ont décidé.

Mnemosyne OS garde ce qu'une session a compris. Tu déclares un coffre mémoire sur le dossier de ton projet, et la session suivante le relit en local, par un serveur MCP ouvert. Elle démarre là où la précédente s'est arrêtée.

On l'a construit parce qu'on s'est pris le mur en premier, tous les jours, en fabriquant ce produit avec ces agents.

Ton IDE Claude Code · Cursor · Antigravity
Le serveur MCP sur ta machine, en boucle locale
App lancée tes coffres, le to-do, l'agenda, ta carte de session
Sans l'app tes sessions, les fichiers qu'elles ont écrits, les collisions
Ton agent parle à un serveur local. Ce qu'il atteint dépend de l'app.

La facture

Cinq coûts qui n'apparaissent sur aucune facture.

Ils viennent tous du même trou : le travail d'une session n'a nulle part où vivre une fois la session finie.

La conversation qu'on recommence

L'exploration recommence à zéro à chaque conversation neuve. Tu paies cette part avant même d'avoir posé ta question.

La décision que tu prends deux fois

Une fonctionnalité demande des dizaines de décisions. Un agent neuf les rouvre toutes, et en tranche certaines dans l'autre sens.

Le piège que tu as déjà payé

Un bug que tu as mis un après-midi à comprendre revient trois mois plus tard. Tu repaies l'après-midi.

Le travail qui sort du dépôt

« Ajoute cette migration à mes todos. » L'agent comprend la phrase. Il n'a aucun endroit où l'écrire.

Des agents qui ne savent rien les uns des autres

La session de ton terminal ignore ce que celle de ton éditeur a fait. Les deux écrivent dans les mêmes fichiers.

L'écosystème

Les serveurs MCP font très bien leur travail.

Il en existe des centaines. Chacun branche ton agent sur un outil précis et le fait bien : un dépôt, un ticket, une base, un navigateur, un terminal. On s'en sert tous les jours.

Ils donnent tous à ton agent des mains. Aucun ne lui donne une mémoire entière. Elle se divise en deux parties :

Celle que tes agents écrivent

Ce qu'une session a compris, tranché, raté. Aujourd'hui ça vit dans un transcript que personne ne rouvre, et la session suivante repart de zéro.

Celle que tu gouvernes

Tes coffres, tes décisions d'architecture, les pièges que tu as payés. Tu décides ce qui entre, ce qui se mélange et ce qui sort. Ton agent y lit et y écrit, sous ta règle.

Un agent qui écrit dans le vide n'apprend rien à personne. Et si ton agent ne peut pas lire ton carnet, tu le recopies à la main dans chaque prompt.

Les deux parties se rejoignent dans le même processus

Tout tourne sur ta machine. Ton éditeur lance un serveur MCP qui parle en boucle locale, sur 127.0.0.1:7799. Rien ne sort de là. Quand l'app est ouverte, c'est elle qui répond : ton agent lit les coffres que tu as sous les yeux, sans copie et sans synchronisation.

Le branchement va dans les deux sens. L'agent lit ce que l'app sait. L'app montre ce que l'agent fait. Une carte de session se pose sur ton plan : son état, sa durée, les fichiers qu'elle a écrits. Tu peux lui répondre sans couper ce qu'elle est en train de faire.

L'app est le serveur. Ferme-la, et la mémoire, le to-do, l'agenda et la carte de session n'ont plus personne à qui parler. Ils te le disent.

La taille du problème

Ce qu'une mémoire doit tenir.

Premier commit le 17 avril 2026. Passe les mêmes commandes sur ton propre dépôt pour connaître la taille du tien.

4 979

commits sur main

git rev-list --count HEAD

2 131

dont sur les 30 derniers jours

git log --since="30 days ago" --oneline | wc -l

800 222

lignes de TypeScript, 44 apps

287 340 dans le produit principal

127

documents d'architecture

ls docs/architecture/*.md | wc -l

475

fiches de mémoire

find memory -name "*.md" | wc -l

Relevé du · commandes git, comptes de lignes et de fichiers, sur ce dépôt.

Aucun de ces nombres ne prouve qu'on travaille bien. Un commit peut être minuscule, une ligne peut être mauvaise, et une partie a été écrite par des agents. Ces nombres mesurent la quantité de décisions qui existent quelque part, et qu'il faudra retrouver.

L'IA a tenu sa promesse : on va plus vite. Elle en a tenu une deuxième dont on parle moins : la quantité.

On ouvre des chantiers qu'on aurait abandonnés avant de commencer, et on tient plusieurs surfaces en parallèle. Sur ce dépôt, ça donne les 2 131 commits des trente derniers jours.

Cette deuxième promesse dépend de l'architecture. Le même rythme mène à deux endroits opposés.

Architecture pensée

La quantité devient du produit. Chaque chantier ouvert s'appuie sur ce qui existe déjà.

Architecture absente

La quantité devient de la dette. Et la dette arrive à la même vitesse que le reste.

Et plus on produit, plus on décide. Chaque chantier ajoute ses arbitrages, ses pièges et ses raisons.

On est dans le même bateau que les modèles. Ils vont devenir bien plus capables, et ils n'avaleront pas tout le contexte d'un projet avant des années. Le corpus grossit plus vite que la fenêtre, et il ne survit pas à la session.

Il faut donc un serveur MCP efficace : garder le contexte dehors, et rendre le bon morceau au bon moment.

Du côté de l'agent

Comment un agent travaille ici.

Trois nombres, dans l'ordre où ils arrivent.

1. Il ouvre la session

≈ 50 000 tokens

Il charge le fichier de conventions, l'index de la mémoire et le travail en cours. C'est une carte du projet. Le contenu reste dehors.

2. Ce que la carte ouvre

≈ 12 000 000 tokens

127 documents d'architecture, 475 fiches et 800 222 lignes de code, indexés sur ta machine. Il sait qu'ils existent et où ils sont.

3. Il pose une question par MCP

≈ 1 100 tokens

Il reçoit la réponse et les fichiers d'où elle sort. C'est le prix d'un aller-retour, et il peut en faire plusieurs.

Tokens estimés à partir des octets comptés, jamais tokenisés · relevé du .

Les cinq coûts du haut de page, repris un par un.

La situation Sans mémoire Avec Mnemosyne OS
Ouvrir une session neuve L'agent explore le dépôt : grep, fichiers lus en entier. La facture monte avant la première réponse. L'agent charge une carte de ≈ 50 000 tokens, puis demande ce qu'il lui manque.
Retrouver une décision d'il y a trois semaines Tu la retrouves de tête, ou elle se rejoue dans l'autre sens. L'agent la retrouve pour ≈ 1 100 tokens, avec le fichier d'où elle sort.
Un piège déjà payé une fois Personne ne l'a écrit ailleurs que dans une conversation fermée, alors il revient. Il est écrit et daté, et l'agent le lit avant de retoucher la même zone.
Une tâche dictée en pleine conversation Elle reste dans le log du chat. Elle arrive dans ta liste ou ton agenda, dans un fichier qui t'appartient.
Deux agents sur la même branche Ils se découvrent au moment du merge. Un contrôle de collision te prévient avant que tu commites.

Les deux nombres de la colonne de droite sont ceux de l'échelle ci-dessus.

Un agent porte moins de 0,5 % de ce projet dans sa fenêtre et atteint n'importe quel fait du reste pour environ mille tokens. Même une fenêtre d'un million de tokens n'en tiendrait qu'un douzième.

La récupération rend les passages et nomme le fichier d'où chacun sort. Tu vérifies une affirmation contre la fiche.

Un chat renvoie son historique à chaque tour, donc plus la conversation est longue, plus la réponse suivante coûte. Une question posée à la mémoire coûte pareil au premier tour et au centième.

Par où commencer

Tu construis comment ?

Je vibe-code → Je suis un puriste →

La forme

Ton éditeur agit. Mnemosyne OS se souvient. C'est toi qui décides.

Ce sont trois métiers différents. Aujourd'hui, celui du milieu manque. Ton agent est très bon pour changer des fichiers. Il n'a aucun endroit où poser ce qu'il a appris en le faisant.

L'éditeur écrit le code.
Mnemosyne OS tient les coffres, les liens et l'historique.
Tu arbitres, parce que tu es le seul à savoir à quoi ça sert.

L'agent lit la mémoire, et il la répare. La semaine dernière, une passe de benchmark a laissé des lignes orphelines dans un index lexical. L'agent les a vues, corrigées, et a écrit pourquoi elles étaient apparues.

Les sessions se parlent aussi entre elles. Tu écris sur la carte d'une session sans l'interrompre, et elle lit le message à sa prochaine mise à jour. Câble le mnemosyne-cockpit-hook livré avec le serveur MCP et une session sur le point de s'arrêter lit son courrier avant de partir, donc deux sessions se préviennent par ce canal de ce qu'elles touchent.

Démarrer

Brancher Claude Code, Cursor ou Antigravity.

Claude Code

Par MCP. Avec Ariadne, Mnemosyne OS lit aussi les transcrits qu'il écrit déjà sur ton disque.

Cursor

Par MCP, et par le pont dédié qu'il partage avec VS Code.

Antigravity

Par MCP, et Ariadne lit ses transcrits comme ceux de Claude Code.

OpenClaw

Ses sessions vivent en SQLite. Tu exportes une trajectoire, Mnemosyne OS la lit.

Tout client MCP

Le même fichier suffit. Ce qu'est MCP, et les outils exposés.

Deux étapes pour brancher ton agent. Seule la première demande un téléchargement.

Télécharger Mnemosyne OS Le code sur GitHub

Ensuite, ajoute le serveur au .mcp.json de ton projet :

{ "mcpServers": { "mnemosyne": {
  "command": "npx",
  "args": ["-y", "@mnemosyne_os/mcp"],
  "env": {
    "MNEMO_DEFAULT_VAULT": "DEV",
    "MNEMO_VAULTS": "DEV,PERSONAL,SOCIAL",
    "CLAUDE_CODE_SESSION_ID": "${CLAUDE_CODE_SESSION_ID}"
  }
} } }

Pointe un coffre sur le dossier de ton projet. Ton agent peut maintenant lire ce que tu as décidé, et écrire ce qu'il a décidé. Tout reste sur le disque, dans des fichiers que tu peux ouvrir sans nous.

Déclarer ton IDE, et garder la main

Ton IDE écrit déjà des transcrits sur ton disque. Pour que Mnemosyne OS les lise, tu installes la cartouche Ariadne et tu lui désignes le dossier. C'est toi qui dis où lire, une fois.

Trois outils lisent des fichiers, donc ils répondent sans rien installer : la liste de tes sessions d'agent, les fichiers qu'elles ont écrits, et le contrôle de collision. Le reste demande l'app lancée. La question à la mémoire en fait partie, comme les cartes de session sur lesquelles tu écris à un agent qui travaille.

Ariadne est en bêta et s'ajoute à la main depuis son dépôt.

Le défaut qu'il faut connaître

Un agent branché sur le serveur MCP n'interroge pas la mémoire de lui-même. Il a les outils, personne ne lui a dit de s'en servir d'abord. Il fait donc ce qu'il sait faire depuis toujours : il grep, il lit des fichiers entiers, et il paie l'exploration que tu venais d'éviter.

La consigne tient en trois lignes, dans les règles de ton projet (CLAUDE.md, .cursorrules, l'équivalent chez toi) :

Avant de chercher dans le code, interroge la mémoire :
mnemosyne_memory_ask sur le coffre du projet.
Un grep coûte des milliers de tokens, une question en coûte mille.

Sur ce dépôt, on l'a mise en haut du fichier de conventions. L'agent le charge donc avec ses 50 000 tokens d'ouverture.

Si tu construis par-dessus Mnemosyne OS plutôt qu'à côté, la page des surfaces de dev t'oriente vers le bon paquet en deux lignes.

Essaie sur ton propre projet.

Pose une question à ton agent sur une décision que tu as prise le mois dernier. Ce test prend dix minutes.

Télécharger Mnemosyne OS Lire la documentation

Et si quelque chose ne marche pas, ou marche mieux que prévu, on est sur le Discord.

Laisse ton email si tu veux la suite : ce qui marche, ce qui casse, et les chiffres qui bougent.