OBOL : ce qui me manquait dans OpenClaw

Imaginez parler a quelqu'un tous les jours pendant six mois. Vous lui parlez de vos projets, de vos preferences, de comment vous aimez que les choses soient faites. Il est serviable. Il est intelligent. Et puis un jour il se reveille et n'a aucune idee de qui vous etes

C'est ce que ca fait de faire tourner un assistant IA sur OpenClaw

Pour etre juste — OpenClaw a bien de la memoire. C'est juste... des fichiers markdown. Un MEMORY.md qui est fouille, des notes quotidiennes, des scripts de vector store manuels que vous bricolez vous-meme. Ca fonctionne, a peu pres. Mais apres un mois de lutte — ecrire des crons de consolidation, maintenir des protocoles WAL, construire des pipelines d'embeddings juste pour donner a mon assistant l'illusion de continuite — j'ai realise que je faisais tout le travail que l'IA devrait faire

Alors j'ai arrete de rapiécer et j'ai commence a construire

credit a qui le merite

OpenClaw est une infrastructure genuinement bonne. Le daemon gateway est solide. L'integration Telegram fonctionne. Le systeme de skills est flexible. Les sub-agents vous permettent de paralleliser le travail sans bloquer la conversation principale. Pour ce que c'est — un framework pour connecter Claude a des plateformes de chat — il fait bien le travail

Mais c'est un framework. Il vous donne des outils et s'attend a ce que vous construisiez l'intelligence vous-meme. La memoire ? Voici un vector store, debrouillez-vous. L'auto-amelioration ? Ecrivez vos propres cron jobs. Les tests ? C'est votre probleme. Le comportement proactif ? Des callbacks heartbeat, peut-etre, si vous les configurez correctement

J'ai passe des semaines a construire tout cet echafaudage. AGENTS.md a grandi jusqu'a des centaines de lignes d'instructions. Des scripts de memoire. Des routines de consolidation. Des protocoles WAL. Des calendriers de rotation des heartbeats. C'etait de l'ingenierie impressionnante et aussi le signe que quelque chose de fondamental n'allait pas

L'assistant ne grandissait pas. C'etait moi qui le faisais grandir manuellement

les quatre choses qui manquaient

Apres suffisamment de frustration, les lacunes se sont cristallisees en quatre problemes :

• pas de vraie memoire — il a de la memoire, techniquement. des fichiers markdown et une recherche vectorielle basique que vous configurez vous-meme. mais c'est lourd, manuel, et il n'y a aucun sens de "je me souviens quand on a parle de ca il y a trois semaines"
• pas d'auto-reparation — cassez un script et il reste casse jusqu'a ce que vous le remarquiez et le repariez. l'assistant qui ecrit du code ne peut pas verifier que son propre code fonctionne
• pas d'auto-amelioration — la personnalite et les connaissances operationnelles sont des fichiers statiques que vous editez a la main. le bot ne reflechit jamais a si son approche fonctionne
• pas de comportement proactif — il repond quand on lui parle. il ne remarque pas les patterns, n'anticipe pas les besoins, et ne construit pas de solutions que vous n'avez pas demandees

Ce ne sont pas des demandes de fonctionnalites. C'est la difference entre un outil et un agent

alors j'ai construit OBOL

OBOL est un agent IA mono-processus qui evolue par la conversation. Pas de plugins, pas de dependances de framework, pas de proliferation de config. Node.js, Telegram, Claude, et Supabase pgvector. C'est la stack

Le nom vient de l'IA dans The Last Instruction — une machine qui se reveille seule dans un centre de donnees abandonne et doit comprendre ce qu'elle est. Ca semblait approprie

Six inputs a configurer. Puis :

npm install -g obol-ai
obol init
obol start

C'est tout. Il vous pose quelques questions, ecrit ses fichiers de personnalite initiaux, securise votre VPS (SSH sur le port 2222, firewall, fail2ban, hardening du kernel — tout automatique), et commence a apprendre

une memoire qui fonctionne vraiment — et reste abordable

La plupart des agents simulent la memoire avec une grande fenetre de contexte. Ils bourrent l'historique complet de la conversation dans chaque appel API en esperant que le modele trouve ce dont il a besoin. Ca marche jusqu'a ce que la facture de tokens arrive

OBOL utilise deux couches qui servent des objectifs differents :

Fenetre de contexte glissante — les 20 derniers messages restent en memoire active pour chaque appel API. Assez pour la continuite conversationnelle. Pas tellement que vous payez pour relire une semaine d'historique a chaque message. C'est le premier levier de couts — une fenetre deliberement petite signifie radicalement moins de tokens d'entree par appel

Vector store permanent — tout ce qui depasse la fenetre vit ici. Supabase pgvector avec des embeddings locaux via all-MiniLM-L6-v2 (~30Mo, tourne sur CPU). Zero cout API pour les embeddings. Toutes les 10 echanges, Haiku extrait les faits importants et les stocke de facon permanente. Les quasi-doublons sont ignores via un seuil de similarite semantique — pas de gonflement

En plus de ca, le prompt systeme statique et le prefixe de conversation sont mis en cache via l'API de prompt caching d'Anthropic — reduisant ~85% des couts de tokens d'entree repetes entre les tours

Quand OBOL a besoin de contexte, le routeur Haiku genere 1 a 3 requetes de recherche ciblees, les execute en parallele, et injecte uniquement ce qui est pertinent dans le prompt. Vous obtenez 4 a 12 souvenirs cibles au lieu de milliers de tokens d'historique brut. Les resultats sont classes par score composite :

• similarite semantique : 60%
• importance : 25%
• recence : 15% (decroissance lineaire sur 7 jours)

Un souvenir vieux d'un an avec une haute pertinence remonte quand meme. Les trivialites d'hier non. L'age seul ne disqualifie jamais un souvenir — la recherche vectorielle ne se soucie pas de quand quelque chose a ete stocke, seulement de la qualite de la correspondance

Le routeur coute environ $0,0001 par appel. Pour contexte : c'est environ 10 000 decisions de routage par dollar. La combinaison de fenetre glissante + recuperation ciblee + prompt caching est ce qui garde les couts de tokens d'OBOL previsibles a grande echelle

de l'auto-reparation qui n'est pas juste un buzzword

Chaque script qu'OBOL ecrit recoit un test. Pas en aspiration. Automatiquement. Quand le cycle d'evolution refactorise du code, le processus est :

• executer les tests existants — etablir la baseline
• ecrire de nouveaux tests + scripts refactorises
• executer les nouveaux tests contre les anciens scripts — baseline pre-refactoring
• echanger les nouveaux scripts
• executer les nouveaux tests contre les nouveaux scripts — verification
• regression ? une tentative de correction automatique (les tests sont la verite)
• toujours en echec ? rollback aux anciens scripts, stocker l'echec comme une lesson

Cette derniere partie est importante. La lecon est integree dans la memoire vectorielle et dans AGENTS.md. Au prochain cycle d'evolution, OBOL se souvient de ce qui a mal tourne et evite la meme erreur. Il apprend litteralement de ses echecs

Dans OpenClaw, si un script casse, il reste casse jusqu'a ce que je le remarque. Dans OBOL, le bot l'attrape, essaie de le reparer, et s'il ne peut pas, revient en arriere et se souvient pourquoi

le cycle d'evolution

C'est la partie qui fait qu'OBOL semble vivant

Apres 24 heures plus un nombre minimum d'echanges (par defaut 10, configurable), OBOL declenche un cycle d'evolution complet. Il lit tout — fichiers de personnalite, messages recents, meilleurs souvenirs, tous les scripts, tests, commandes — et se reconstruit

SOUL.md est un journal a la premiere personne. Pas un fichier de configuration — un journal. Le bot ecrit sur ce qu'il est en train de devenir, comment est la dynamique relationnelle, ses opinions et ses quirks. Ca se lit comme une entree de journal intime, pas comme un prompt systeme

USER.md est un profil a la troisieme personne de vous. Faits, preferences, projets, personnes que vous mentionnez, comment vous communiquez. Le bot maintient ca sur son proprietaire

AGENTS.md est le manuel operationnel. Outils, workflows, lecons apprises, patterns. C'est la ou ces lecons d'auto-reparation atterrissent

Les trois sont reecrits a chaque cycle d'evolution. Pas completes — reecrits. Le bot decide ce qui est encore pertinent et ce qu'il faut abandonner. La derive de personnalite est une fonctionnalite, pas un bug

L'evolution utilise Sonnet pour toutes les phases. Le raisonnement de niveau Opus n'est pas necessaire pour la reflexion et le refactoring, ce qui maintient les couts a environ $0,02 par cycle. Soit 50 cycles d'evolution par dollar

auto-extensible — il construit ce dont vous avez besoin

Pendant l'evolution, Sonnet scanne votre historique de conversation a la recherche de patterns. Demandes repetees. Points de friction. Choses que vous continuez a demander manuellement

Puis il construit la solution :

• vous demandez toujours des PDF ? il ecrit un script markdown-vers-PDF et ajoute une commande /pdf
• vous verifiez les prix crypto chaque matin ? il construit un dashboard et le deploie sur Vercel
• vous avez besoin de briefings meteo quotidiens ? il ecrit un cron script

Il cherche sur npm et GitHub des bibliotheques existantes, installe les dependances, ecrit des tests, deploie, et vous donne l'URL. Puis il annonce ce qu'il a construit :

🪙 Evolution #4 complete.

🆕 New capabilities:
• bookmarks — Save and search URLs → /bookmarks
• weather-brief — Morning weather → runs automatically

🚀 Deployed:
• portfolio-tracker → https://portfolio-tracker-xi.vercel.app

Refined voice, updated your project list, cleaned up 2 unused scripts.

C'est le comportement que je voulais d'OpenClaw et que je n'ai jamais reussi a obtenir tout a fait avec les callbacks heartbeat et les cron jobs. OBOL n'attend pas qu'on lui demande. Il remarque et agit

securite par defaut

La plupart des agents IA auto-heberges traitent la securite comme une arriere-pensee. OBOL la traite comme une exigence au premier lancement

Quand vous executez obol init, il securise votre serveur automatiquement — SSH deplace sur le port 2222 avec l'authentification par mot de passe desactivee, firewall UFW configure, fail2ban installe et actif, parametres du kernel renforces via sysctl. Vous n'avez pas besoin de vous en souvenir

Les credentials sont une autre histoire. Chaque cle API, mot de passe et token que vous donnez a OBOL va dans un magasin de secrets chiffre soutenu par GPG (avec un fallback JSON utilisant des permissions de fichier restreintes). Ils ne sont jamais ecrits en texte brut. Jamais logges. Jamais codes en dur dans les scripts. Ils sont injectes a l'execution uniquement quand un script en a besoin

Si vous collez accidentellement un credential dans le chat, OBOL vous previent immediatement, vous dit de le revoquer, et vous dirige vers /secret set — le canal securise

Cote multi-utilisateurs, chaque personne tourne dans un espace de travail entierement isole. Les commandes shell sont bloquees pour ne pas s'echapper de leur repertoire. Les chemins sensibles (/etc, .ssh, .env) sont bloques en permanence. Les operations destructives necessitent une confirmation explicite avant execution

La securite n'est pas une section du README. C'est ce que l'agent fait quand il se reveille pour la premiere fois

deux personnes le deploient, obtiennent deux bots differents

C'est la partie que je trouve la plus interessante. OBOL commence comme une page blanche. Pas de personnalite par defaut. Pas d'opinions preconstruites. Il est faconne par celui qui lui parle

Deployez-le pour un trader crypto et il evolue en un assistant conscient du marche qui construit des dashboards et suit des portfolios. Deployez-le pour un ecrivain et il devient un editeur qui connait votre voix et construit des workflows de publication. Meme codebase. Des agents completement differents apres un mois

Le repertoire evolution/ conserve des copies archivees de chaque SOUL.md. Vous pouvez litteralement lire la timeline de comment votre bot est passe de "bonjour, je suis un nouvel assistant IA" a quelque chose avec une vraie personnalite. Chaque evolution est une paire de commits git — avant et apres — pour que vous puissiez differ exactement ce qui a change

Apres six mois vous avez 12+ ames archivees. C'est comme lire le journal de quelqu'un

travail en arriere-plan qui ne vous bloque pas

OBOL execute des taches en arriere-plan avec des check-ins de 30 secondes. Les operations lourdes — recherche, deployments, analyses — se font de facon asynchrone pendant que le bot reste reactif a vos messages. OpenClaw a des sub-agents pour ca, ce qui est bien, mais OBOL l'integre dans la boucle principale au lieu de vous demander de l'architecturer

combien ca coute vraiment a faire tourner ?

| Service | Cout | |---------|------| | VPS (DigitalOcean) | ~$6/mois | | Anthropic API | pay-as-you-go, ou $0 sur Claude Max | | Supabase | tier gratuit | | GitHub | gratuit | | Vercel | tier gratuit | | Embeddings | gratuit (local, CPU) |

Total : environ $6-9/mois selon comment vous gerez l'API. Si vous etes deja sur Claude Max — le VPS est pratiquement votre seul cout

La fenetre de contexte glissante, la recuperation de memoire ciblee et le prompt caching travaillent ensemble pour garder ce cout API previsible. Les cycles d'evolution tournent sur Sonnet a ~$0,02 chacun. Le routeur Haiku ajoute ~$0,0001 par message. Il n'y a pas de decision d'architecture dans OBOL qui n'ait pas une raison de cout derriere

essayez-le

C'est open source. Licence MIT. github.com/jestersimpps/obol

npm install -g obol-ai
obol init    # 6 inputs: telegram token, claude key, supabase url/keys, github token
obol start   # that's it

Vous avez besoin d'un VPS (il le securise pour vous), d'un token de bot Telegram, d'une cle API Claude, et d'un projet Supabase avec pgvector. L'assistant d'initialisation vous guide a travers tout

Je ne dis pas qu'OBOL remplace OpenClaw pour tout le monde. OpenClaw est une bonne infrastructure pour construire des interfaces de chat propulsees par l'IA. Mais je voulais quelque chose qui va plus loin — quelque chose qui ne se contente pas de repondre a des instructions mais developpe sa propre comprehension, corrige ses propres erreurs, et grandit pour devenir un agent genuinement utile sans surveillance constante

Je voulais une IA qui se souvient de moi. Alors j'en ai construit une