>_ DevTrendsfr

Langue

Accueil

Langages

Sections

Frontend Backend Mobile DevOps AI / ML GameDev Blockchain Embarqué Sécurité
Rust

Comment basculer entre Claude Code et Codex sans perdre le contexte

ai-memory

Situation familière : vous êtes assis dans le terminal avec Claude Code, en train de déboguer un bug délicat dans une file d'attente distribuée pendant une heure et demie, vous avez essayé cinq hypothèses qui n'ont pas fonctionné, et vous avez enfin trouvé la bonne solution. Puis la session s'allonge, le contexte se comprime, ou les limites atteignent le plafond. Vous basculez vers Codex ou OpenCode dans le même dossier, et le cirque commence. Le nouvel assistant doit être briefé depuis le début : pourquoi vous ne pouvez pas toucher à la config NGINX, quels tests ont déjà échoué, et quelle structure de base de données nous avons choisie il y a vingt minutes.

Le projet ai-memory vise à résoudre ce problème une bonne fois pour toutes. Il a été créé par Fabio Akita (connu dans la communauté sous le nom d'AkitaOnRails). L'idée est de donner aux agents IA de console une mémoire partagée à long terme et un transfert automatique de contexte entre les sessions et les différents modèles.

En quoi consiste le concept

D'habitude, la « mémoire IA » désigne une base de données vectorielle où les journaux de dialogue bruts sont déposés sous forme d'embedding. En pratique, ces journaux sont remplis de déchets : appels d'outils intermédiaires, exécutions de tests répétées, erreurs de syntaxe.

L'auteur d'ai-memory a emprunté un chemin différent, inspiré du concept LLM Wiki de Karpathy. Ici, la mémoire est structurée comme un wiki classique composé de fichiers Markdown dans un dépôt Git. Le serveur intercepte les événements du cycle de vie des agents, les nettoie du bruit inutile et compile un résumé compressé à la fin de la session : ce qui a été fait, quelles conclusions ont été tirées, quelles tâches restent ouvertes.

Lorsque vous ouvrez un nouveau terminal avec un agent différent, l'outil lui transmet automatiquement un résumé structuré juste avant la première invite. Pas de copie manuelle depuis le presse-papiers.

Sous le capot et dans le terminal

Le serveur est écrit en Rust. Il démarre un service local avec support MCP (Model Context Protocol), des hooks de cycle de vie et une interface web intégrée.

Il prend en charge pratiquement tous les CLI d'agents actuels :

  • Claude Code
  • OpenAI Codex
  • Command Code
  • Devin CLI
  • OpenCode, Cursor, Zed
  • Gemini CLI, Grok Build CLI, Kimi Code, Kiro CLI, Pi / OMP

Les données sont stockées localement dans un seul répertoire :

<data_dir>/
├── wiki/    # Markdown-страницы под версионным контролем Git
├── raw/     # очищенные сегменты сессий
├── db/      # SQLite с индексами FTS5, сущностями и эмбеддингами
└── logs/    # логи работы

Chaque projet est isolé par chemin de dépôt ou via un fichier marqueur .ai-memory.toml. Si vous travaillez avec un monodépôt ou plusieurs worktrees Git, ils sont liés dans un contexte unifié.

Fonctionnalités clés en pratique

Basculement transparent entre les agents

ai-memory dispose d'un mode session géré ai-memory run. Cela fonctionne simplement :

cd /path/to/project
ai-memory run claude

# Закончили работу в Claude Code, продолжаем задачу в Codex:
ai-memory run codex --yolo

# А потом возвращаемся к сессии через Command Code:
ai-memory run command-code

L'agent lit le bloc « là où nous en étions » au démarrage. Il contient les décisions architecturales récentes, les questions ouvertes et les résultats des tests. Si vous ne spécifiez pas de nom d'agent, la commande ai-memory run sélectionne automatiquement la session active la plus récente dans le dossier actuel.

La commande ai-memory continue va encore plus loin : vous pouvez l'appeler depuis n'importe quel dossier, et elle vous ramènera au projet sur lequel vous travailliez.

Wiki au lieu de décharges de journaux

L'ensemble de la base de connaissances est stocké sous forme de texte brut. Vous pouvez l'ouvrir dans Obsidian, le lire avec grep, ou le parcourir dans le navigateur intégré sur le port 127.0.0.1:49374/web.

Si vous souhaitez enregistrer une règle de projet importante, dites simplement à l'agent : « sauvegarde en mémoire permanente que nous utilisons NATS JetStream pour les files d'attente ». L'agent appelle l'outil MCP memory_write_page, et un fichier Markdown versionné apparaît dans le dépôt.

La recherche dans la base de connaissances est hybride. La recherche full-text SQLite FTS5 s'exécute d'abord, puis la correspondance d'entités et les connexions de graphe entre les pages. Si vous connectez un modèle d'embedding, la recherche vectorielle est également ajoutée.

Dans le même temps, ai-memory peut distinguer les règles architecturales stables des notes de session temporaires, en privilégiant les pages stables des dossiers _rules/ et decisions/.

Fonctionnement sans LLM externes

Un détail intéressant : ai-memory démarre sans aucune clé API de réseau neuronal. En mode « zero-LLM », la recherche fonctionne via FTS5 et les entités, et les résumés de session sont assemblés à l'aide de règles déterministes.

Si vous configurez des clés (Anthropic, OpenAI, Gemini ou Ollama local via un point de terminaison compatible), l'outil active la consolidation intelligente des pages, la détection de conflits dans la base de connaissances et l'auto-apprentissage en arrière-plan pour le projet.

Démarrage rapide via Docker

Le moyen le plus rapide de déployer le serveur sur votre poste de travail :

# 1. Запускаем локальный сервер
docker run -d --name ai-memory \
    --restart unless-stopped \
    -p 127.0.0.1:49374:49374 \
    -v ai-memory-data:/data \
    -e AI_MEMORY_LLM_PROVIDER=anthropic \
    -e ANTHROPIC_API_KEY=sk-ant-... \
    akitaonrails/ai-memory:latest

# 2. Подключаем MCP и хуки для Claude Code
ai-memory install-mcp   --client claude-code --apply
ai-memory install-hooks --agent  claude-code --apply

Pour les utilisateurs d'Arch Linux, des paquets prêts à l'emploi ai-memory-bin avec des unités systemd sont disponibles dans l'AUR. Des binaires natifs pour Apple Silicon et Intel sont publiés pour macOS.

Si le serveur est déplacé vers un serveur domestique ou un réseau local, la sécurité est configurée via des jetons Bearer. Le serveur écoute les requêtes, vérifie l'autorisation et sépare la mémoire entre plusieurs développeurs via des slots d'opérateur.

À quoi cela sert

L'outil résout trois tâches spécifiques.

Premièrement — le développement multi-agents. Il est plus rapide de rédiger une tâche dans Claude, de la refactorer dans Codex et de faire la revue de code via Gemini. Sans une couche de mémoire partagée, ce flux de travail se transforme en routine de copie de contexte sans fin.

Deuxièmement — intégrer un agent à un ancien dépôt. La commande ai-memory bootstrap lit l'historique des commits, le README et la documentation du projet, en générant des pages initiales de la base de connaissances.

Troisièmement — l'audit local. À tout moment, vous pouvez ouvrir l'interface web, vérifier les notes générées, annuler une mauvaise modification via ai-memory restore-page, ou nettoyer les données obsolètes.

Résumé

ai-memory attire par son approche pragmatique. Au lieu de construire une autre pile lourde avec des bases de données vectorielles externes, l'auteur a pris Rust rapide, SQLite fiable et Git simple avec Markdown.

Si vous utilisez activement des assistants IA de terminal et que vous êtes fatigué de réexpliquer le contexte du projet aux modèles chaque jour, le dépôt mérite définitivement un coup d'œil. Commencez par une exécution locale couplée avec votre CLI agent principal pour évaluer le confort du transfert de contexte entre les tâches.

Projets similaires