AI Memory
Motorhead — Lightweight Redis-Backed Chat Memory Server logo

Motorhead — serveur mémoire de chat léger adossé à Redis

Motorhead est un serveur Rust open source qui stocke l'historique de chat dans Redis, exécute un résumeur glissant et expose une API REST minimaliste. La façon la plus simple d'ajouter « retenir les N derniers tours + un résumé » à une app LLM.

Why Motorhead

Motorhead, c'est l'option « juste assez de mémoire ». Il n'extrait pas de faits, ne construit pas de graphe, ne gère pas le scoping de faits multi-utilisateurs. Ce qu'il fait : stocker les messages par session dans Redis, maintenir un résumé courant pour que l'historique n'explose pas, et exposer une API REST avec deux endpoints. C'est tout.

Le projet a été initialement construit par Metal (une startup RAG) et reçoit toujours de la maintenance pour les bug fixes mais pas de grosses nouveautés. Utilisez-le quand vous avez besoin de mémoire de chat aujourd'hui, ne voulez pas opérer Postgres et trouvez Zep ou mem0 plus lourds que le problème ne le demande.

Le prix de la simplicité : pas de mémoire cross-session. L'historique d'un utilisateur d'hier n'influence pas la conversation d'aujourd'hui sauf si vous reliez manuellement les sessions. Pour les chatbots à session unique c'est très bien ; pour les assistants qui accumulent du savoir utilisateur, vous dépasserez vite Motorhead.

Quick Start — Docker Compose + HTTP

Motorhead exécute le résumé automatiquement dès qu'une session dépasse un budget Token configurable. Vous récupérez toujours (a) les messages les plus récents mot pour mot et (b) une chaîne résumé couvrant tout ce qui est plus ancien. Injectez les deux dans votre prompt LLM.

# docker-compose.yml
# services:
#   redis: { image: redis/redis-stack:latest, ports: ["6379:6379"] }
#   motorhead:
#     image: ghcr.io/getmetal/motorhead:latest
#     ports: ["8080:8080"]
#     environment:
#       OPENAI_API_KEY: sk-...
#       REDIS_URL: redis://redis:6379
#     depends_on: [redis]

# Start the stack
docker compose up -d

# Append messages to a session
curl -X POST http://localhost:8080/sessions/s1/memory \
  -H "content-type: application/json" \
  -d '{"messages":[
    {"role":"user","content":"I want a vegan dinner recipe"},
    {"role":"assistant","content":"How about a chickpea curry?"}
  ]}'

# Fetch memory for the next LLM call
curl http://localhost:8080/sessions/s1/memory
# => { "messages": [...last N turns...], "context": "<running summary>" }

Fonctionnalités clés

Stockage Redis uniquement

Pas de Postgres, pas de dépendance vector DB. Redis scale horizontalement ; Motorhead scale trivialement derrière un load balancer.

Résumé glissant

Quand une session dépasse ~1K Token, Motorhead demande à un LLM de résumer les tours plus anciens et conserve le résumé + les messages récents. Fenêtre configurable.

API REST minuscule

Deux endpoints : POST messages, GET memory. Pas de SDK requis — fonctionne depuis n'importe quel langage avec un client HTTP.

Agnostique au langage

Comme l'API est juste de l'HTTP, vous l'utilisez de la même façon depuis Python, Node, Go, Rust, Elixir. Trivial à câbler à des backends de chat existants.

Open source

Sous licence Apache 2.0 ; self-host partout où Docker tourne. Pas d'offre managée (utilisez Upstash ou le Redis managé de votre cloud pour l'infra).

Faible overhead opérationnel

Un seul binaire Rust + Redis. Pas de workers en arrière-plan, pas de migrations de schéma. Tourne confortablement sur une petite VM pour des milliers de sessions concurrentes.

Comparaison

 ScopeStorageCross-session memoryOperational complexity
Motorheadcelui-ciPer-session onlyRedisNoVery low
ZepPer-session + per-user factsPostgres + pgvectorYesMedium
mem0Per-user factsVector DB of choiceYesLow-medium
LangMemPer-thread (LangChain)LangChain-backedOpt-inLow

Cas d'usage

01. Chatbots à session unique

Widgets de support client, bots d'onboarding ou assistants helpdesk où chaque conversation est indépendante. Motorhead vous donne « se rappeler des 30 dernières minutes » à bas coût.

02. Prototypes et MVPs

Quand vous voulez de la mémoire fonctionnelle en un après-midi sans monter Postgres et une histoire de migration. Passez à Zep ou mem0 une fois le prototype validé.

03. Déploiements edge ou sensibles à la confidentialité

Redis + Motorhead tourne sur une seule petite VM, on-prem ou sur l'infra d'un client. L'absence de dépendance vector DB garde la surface d'attaque réduite.

Tarification et licence

Motorhead : open source Apache 2.0, self-host uniquement. Pas d'offre managée.

Coût infra : une instance Redis (un Redis managé chez Upstash/AWS/Redis Cloud coûte dès 10 $/mois) + une petite VM pour Motorhead lui-même. Les appels LLM de résumé utilisent votre propre clé OpenAI/Claude.

Limites de scaling : une seule instance Redis gère des centaines de milliers de sessions pour un trafic chat typique. Au-delà, shardez par session_id — les patterns de scaling Redis classiques s'appliquent.

Questions fréquentes

Motorhead vs Zep — lequel choisir ?+

Motorhead quand les sessions sont indépendantes et que vous voulez le stack le plus petit possible. Zep quand vous avez besoin de mémoire au niveau utilisateur, de recherche hybride ou de l'UI web. Zep est un sur-ensemble de ce que fait Motorhead.

Motorhead supporte-t-il plusieurs utilisateurs ?+

Indirectement — vous pouvez utiliser session_id = "${user_id}:${thread_id}". Il n'y a pas de concept utilisateur de premier ordre, donc les faits utilisateur cross-session nécessitent une couche supplémentaire au-dessus.

Puis-je le faire tourner sans OpenAI ?+

Oui. Pointez SUMMARIZER_API_BASE vers n'importe quel endpoint compatible OpenAI (Ollama, vLLM, LM Studio, LiteLLM). Le résumé est le seul travail LLM que Motorhead effectue, et il est configurable.

Motorhead est-il toujours maintenu ?+

Il reçoit des bug fixes occasionnels mais est effectivement feature-freeze. L'équipe a déplacé sa focus. Pour de nouveaux projets, regardez Zep ou mem0, mais Motorhead reste un choix solide pour un petit stack si vous valorisez son minimalisme.

Comment migrer hors de Motorhead plus tard ?+

Parce que les données ne sont que des clés Redis ({session_id}:messages et {session_id}:context), l'export est trivial : SCAN + GET. Importez dans Zep ou mem0 en rejouant les messages via leurs APIs d'ingestion respectives.

Comparer les alternatives