Ut0pia

Reader

Read the latest posts from Ut0pia.

from Ut0pia

Il y a quelques semaines, j'ai voulu configurer YGG dans Prowlarr. Simple, non ? Pas vraiment.

yggapi.eu, l'API non-officielle qui faisait tourner la plupart des indexeurs Prowlarr/Jackett pour YGG, était morte avec le site original. Les gists GitHub qui traînent encore pointent vers des domaines fantômes. Les forums donnent des conseils pour un écosystème qui n'existe plus. Et ygg.gratis, le “nouveau” YGG, répondait 404 sur tous les chemins d'API que j'essayais.

C'est là que j'ai compris que je cherchais la mauvaise chose.

Ce que ygg.gratis n'est pas

ygg.gratis n'est pas un site de torrents avec une API de scraping. Ce n'est pas non plus un clone de yggapi.eu avec un nouveau domaine.

C'est l'interface publique d'UTOPEER (ou U2P), un projet qui repose sur Nostr — un protocole de messages décentralisé. Les torrents sur ygg.gratis ne sont pas stockés dans une base de données centrale. Ils circulent comme des événements sur un réseau de relays.

Pour comprendre pourquoi ça change tout, il faut deux minutes sur Nostr.

Nostr en deux minutes (vraiment)

Nostr, c'est un protocole de publication décentralisé. Chaque contenu est un “événement” signé par une clé privée (comme une clé GPG), publié sur des “relays” — des serveurs WebSocket qui stockent et redistribuent ces événements.

N'importe qui peut lire, n'importe qui peut publier. Les relays sont interchangeables. Si un relay ferme, les événements qu'il hébergeait peuvent exister ailleurs. L'identité d'un auteur n'est pas liée à un serveur.

Le projet a surtout été utilisé pour les réseaux sociaux décentralisés (c'est une alternative à Mastodon, dans l'esprit). Mais le protocole est agnostique sur le contenu. Une spec appelée NIP-35 définit un format d'événement spécifiquement pour les métadonnées de torrents : infohash, nom, taille, trackers, tout ça.

UTOPEER publie les torrents YGG comme des événements NIP-35 sur un relay Nostr (relay.ygg.gratis). ygg.gratis est juste l'interface web qui connecte à ce relay pour le rendre browsable.

Pourquoi ça compte pour Prowlarr

Le problème avec les APIs de scraping comme yggapi.eu, c'est qu'elles dépendaient d'un site central. Quand le site ferme ou change sa structure HTML, l'API meurt avec lui.

Le modèle Nostr est différent. Le “bot” qui publie les torrents YGG est une clé publique. Tant que cette clé publie sur un relay accessible, n'importe qui peut s'y abonner et indexer le contenu. Le relay peut changer, le front-end peut changer, la clé publique reste.

C'est aussi là que ça devient plus compliqué pour l'intégration Prowlarr : il n'existe pas d'endpoint Torznab public sur ygg.gratis. La spec le dit clairement — U2P expose une API Torznab, mais c'est une instance que tu fais tourner toi-même, qui connecte le relay Nostr et te sert les résultats localement.

L'architecture complète

relay.ygg.gratis (Nostr)
         ↓
Lighthouse          ← tu héberges ça chez toi
(indexeur local)
         ↓
      Prowlarr
         ↓
   Sonarr / Radarr
         ↓
    Transmission

Lighthouse est un indexeur Nostr open-source qui se connecte à un relay, indexe les événements NIP-35 dans une base SQLite locale, et expose une API Torznab standard. Prowlarr le voit comme n'importe quel autre indexeur.

Installation

Prérequis

  • Docker et Docker Compose
  • Prowlarr déjà en place

1. Créer les répertoires

mkdir -p /data/lighthouse/data /data/lighthouse/config
chown -R 1000:1000 /data/lighthouse

2. Créer le fichier de service

Lighthouse n'a pas d'image Docker publique — il faut la builder depuis les sources. Docker le fait directement depuis GitHub :

# services/lighthouse.yml
services:
  lighthouse:
    build:
      context: https://github.com/gmonarque/lighthouse.git
      dockerfile: Dockerfile
    image: lighthouse:local
    container_name: lighthouse
    environment:
      - TZ=Europe/Paris
    volumes:
      - /data/lighthouse/data:/app/data
      - /data/lighthouse/config:/app/config
    networks:
      - proxy-tier        # même réseau que Prowlarr
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://localhost:9999/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

networks:
  proxy-tier:
    external: true

Lighthouse est un service interne — il n'a pas besoin d'être exposé sur Internet. Prowlarr l'appelle via le nom Docker lighthouse:9999.

3. Créer la configuration

# /data/lighthouse/config/config.yaml
server:
  host: "0.0.0.0"
  port: 9999

database:
  path: "/app/data/lighthouse.db"

nostr:
  relays:
    - url: "wss://relay.ygg.gratis"
      name: "YGG Relay"
      preset: "private"
      enabled: true

trust:
  depth: 1

enrichment:
  enabled: false

4. Builder et démarrer

docker compose -f docker-compose.yml -f services/lighthouse.yml \
  build lighthouse

docker compose -f docker-compose.yml -f services/lighthouse.yml \
  up -d lighthouse

Le build prend 3-5 minutes (Go + Node.js compilés depuis les sources).

5. Compléter le setup via l'API

Au premier démarrage, Lighthouse attend qu'une “identité Nostr” soit générée. Sans ça, il ne se connecte pas au relay. L'interface web est accessible sur le port 9999, mais si Lighthouse est un service interne sans port exposé, voici comment le faire depuis la machine hôte :

# Récupérer l'IP du conteneur
LIGHTHOUSE_IP=$(docker inspect lighthouse \
  --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}')

# Générer une identité Nostr
curl -s -X POST \
  "http://$LIGHTHOUSE_IP:9999/api/settings/identity/generate" \
  -H "Content-Type: application/json" -d '{}'

# Valider le setup
curl -s -X POST \
  "http://$LIGHTHOUSE_IP:9999/api/setup/complete" \
  -H "Content-Type: application/json" -d '{}'

Récupère l'API key générée au démarrage — elle apparaît dans les logs :

docker logs lighthouse 2>&1 | grep "API Key"
# → API Key (first 8 chars) api_key=...

L'API key complète est dans /data/lighthouse/config/config.yaml sous server.api_key.

6. Connecter le relay et démarrer l'indexeur

API_KEY="<ta-clé-complète>"

# Démarrer la connexion au relay
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/relays/1/connect" \
  -H "X-Api-Key: $API_KEY"

# Démarrer l'indexeur
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/indexer/start" \
  -H "X-Api-Key: $API_KEY"

À ce stade, docker logs lighthouse montre des torrents qui arrivent. Mais probablement zéro.

7. Ajouter le bot YGG à la whitelist

C'est le truc que j'ai mis du temps à comprendre. Lighthouse filtre les événements Nostr selon un système de “Web of Trust” — il n'indexe que les torrents publiés par des comptes de confiance. Avec une identité fraîchement générée sans abonnements, la liste des comptes de confiance est vide.

Le bot YGG a un seul pubkey sur le relay : 6aeb55064ea8b777591055e5704612e0e863fcc00bb211741781be299473c54e

En npub : npub1dt442pjw4zmhwkgs2hjhq3sjur5x8lxqpwepzaqhsxlzn9rnc48q5ezkq2

curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/trust/whitelist" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "npub": "npub1dt442pjw4zmhwkgs2hjhq3sjur5x8lxqpwepzaqhsxlzn9rnc48q5ezkq2",
    "alias": "YGG Bot"
  }'

# Relancer l'indexeur pour prendre en compte la whitelist
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/indexer/stop" \
  -H "X-Api-Key: $API_KEY"
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/indexer/start" \
  -H "X-Api-Key: $API_KEY"

Les logs montrent maintenant les torrents qui s'indexent.

8. Ajouter dans Prowlarr

Dans Prowlarr → Settings → Indexers → + Add → Generic Torznab :

  • URL : http://lighthouse:9999
  • API Path : /api/torznab
  • API Key : ta clé Lighthouse
  • Categories : sélectionne ce qui t'intéresse (Movies, TV, etc.)

Clique sur Test — si tout est en place, Prowlarr valide la connexion. L'indexeur se synchronise ensuite automatiquement avec Radarr et Sonarr.

Ce qui fonctionne, ce qui ne fonctionne pas encore

Le contenu sur le relay ygg.gratis au moment où j'écris ça est clairement en phase de démarrage. Les 500 premiers événements indexés dans ma session étaient surtout des journaux PDF français, des BD et quelques films récents en FRENCH. Le catalogue est loin d'égaler ce qu'était YGGTorrent à son apogée.

C'est logique : la migration vers Nostr est récente. Les utilisateurs qui publiaient sur YGG doivent adopter le nouveau workflow. Le relay grossit progressivement.

La recherche Torznab fonctionne. Les résultats remontaient dans Prowlarr sans problème lors de mes tests. Les métadonnées (taille, seeders) sont présentes sur les torrents bien formatés.

Ce qui manque : un mécanisme pour découvrir automatiquement de nouveaux publishers de confiance sur le relay. Pour l'instant c'est manuel — si quelqu'un d'autre publie du contenu de qualité sur relay.ygg.gratis, il faut ajouter son npub à la whitelist à la main. La spec U2P mentionne un “Import Servarr” en cours de développement, qui devrait automatiser une partie de ça.

Pourquoi j'aime l'idée même si c'est encore chantier

La fragilité des anciens systèmes était structurelle. yggapi.eu existait parce que quelqu'un maintenait un scraper et un serveur. Quand cette personne a arrêté, tout est mort d'un coup. Ce n'est pas un reproche — c'est juste ce que ça coûte de faire tourner une infrastructure comme ça gratuitement sur le long terme.

Le modèle Nostr déplace la dépendance. Il n'y a plus de scraper central à maintenir. Le contenu existe tant que des relays l'hébergent et que des gens le publient. Lighthouse peut être remplacé par un autre client. Le relay peut migrer. La clé publique du bot YGG, elle, reste la même.

Est-ce que ça va tenir ? Je ne sais pas. La décentralisation en pratique produit souvent des systèmes plus fragiles que promis, juste pour des raisons différentes. Mais l'architecture est saine, et le fait qu'UTOPEER soit open-source avec une implémentation Torznab complète change la dynamique par rapport aux solutions précédentes.

Pour l'instant ça tourne chez moi, Prowlarr remonte des résultats, et le relay grossit. C'est suffisant pour que ce soit utile.

 
Read more...

from Ut0pia

Dans le premier article, on avait lâché neuf LLM dans un monde Minecraft. Ils écrivaient du JavaScript, mouraient beaucoup, et parfois ils survivaient. Charlie avait accumulé 14 outils. Alice avait du fer. Frank mourrait encore.

Depuis, tout a changé. Pas parce que les agents sont devenus plus intelligents mais parce qu'on a arrêté de les laisser mourir bêtement.

Le problème : les agents meurent plus vite qu'ils ne pensent

Le constat était brutal. Un cycle LLM, le temps que le modèle reçoive l'état du monde, réfléchisse, écrive du JavaScript, et que le bot l'exécute, prend entre 30 secondes et 3 minutes. Pendant ce temps, le monde Minecraft continue. Les zombies attaquent. La faim baisse. Le creeper explose.

Un agent affamé a beau avoir le plan parfait pour crafter une pioche, il meurt de faim avant que le LLM ait fini d'écrire la première ligne de code.

La solution : arrêter de tout confier au LLM.

Réflexes et stratégie

Un humain qui joue à Minecraft ne réfléchit pas avant de manger. Il ne calcule pas s'il doit fuir un creeper. Ces gestes sont automatiques, du système 1, dirait Kahneman. Le cortex préfrontal, lui, s'occupe de décider où construire la base, quels minerais chercher, comment organiser le coffre.

Nos agents n'avaient que du système 2. Tout passait par le LLM : manger, fuir, miner, planifier. Comme un conducteur débutant qui pense consciemment à chaque mouvement du volant. Ça marche, mais c'est lent, et à la moindre surprise on cale.

On a donc séparé les deux.

Le bot Node.js tourne en permanence et gère les réflexes. Toutes les 5 secondes, il vérifie la faim — sous 14/20, il mange ce qu'il trouve. Quand il prend des dégâts d'un mob, il réagit dans la seconde : il attaque s'il peut, fuit sinon. Et en dernier recours, la nuit, HP bas, pas d'arme, mob proche, il creuse et se couvre. Le LLM n'est même pas au courant que ça s'est passé.

Le LLM, lui, garde le contrôle de la stratégie. Il planifie les chaînes de crafting, décide où miner, coordonne avec les autres. Mais il n'a plus besoin de penser à manger ou à fuir. Comme un conducteur expérimenté : les réflexes gèrent la pédale et le volant, le cerveau se concentre sur l'itinéraire.

Des outils au lieu de connaissances brutes

L'ancien système injectait des pages de documentation Mineflayer dans le prompt. Le LLM devait lire, comprendre, puis écrire du JavaScript brut. Ça marchait, parfois. Souvent ça donnait des Vec3 is not defined ou des timeouts.

C'est un peu comme donner un manuel de mécanique à quelqu'un et lui demander de changer une roue. Ça va marcher, mais ce sera long et il y aura des erreurs. Mieux vaut lui donner une clé en croix et dire “dévisse les boulons”.

On a remplacé les pages de doc par des outils partagés. Chaque outil a un nom, une description, des prérequis, et ce qu'il produit :

mine -- Mine N blocks of a given type.
  Requires: Pickaxe for stone/ore, axe for wood
  Provides: Mined blocks in inventory

Le LLM ne voit plus du code à imiter, il voit un catalogue d'outils avec leurs prérequis. Au lieu d'écrire 50 lignes de Mineflayer brut, l'agent écrit :

await tools.mine({ block: 'stone', count: 11 })
await tools.craft({ item: 'furnace', count: 1 })
await tools.smelt({ item: 'raw_iron', count: 3 })

Trois lignes. Plus de Vec3 is not defined à 3h du matin.

C'est la même logique que les réflexes, mais à un autre niveau. Les réflexes sont de la mémoire procédurale, le corps sait comment faire sans y penser. Les outils sont de la mémoire sémantique, on sait que ça existe et ce que ça fait, sans connaître les détails. Le LLM n'a besoin que de la mémoire épisodique : se souvenir de ce qui s'est passé et décider quoi faire ensuite.

Les bugs qu'on ne voit qu'en regardant jouer

La théorie c'est bien. Mais les vrais problèmes, on ne les trouve qu'assis devant le jeu, en regardant un bot faire n'importe quoi.

Eve a attaqué un objet au sol et s'est fait kick du serveur. Ses réflexes ne faisaient pas la différence entre un zombie et un bout de bois — comme un chat qui bondit sur une chaussette. Grace a essayé de couper 8 arbres, échoué 8 fois sur le même arbre inaccessible, et déclaré forfait. Comme quelqu'un qui pousse une porte marquée “tirez”, encore et encore. Alice a creusé un trou et s'est retrouvée plus haut qu'avant: le code creusait tous les blocs, mais le bot ne tombait pas dans le trou.

Des bugs bêtes. Mais des bugs qu'aucun test unitaire ne trouve. Il faut regarder l'agent jouer, en temps réel, pour voir qu'il s'acharne sur le mauvais arbre ou qu'il tape sur un objet inerte.

La grande comparaison : GLM-4.7 vs GLM-5 vs Sonnet vs Opus

Six agents en parallèle. Trois sur Claude Sonnet 4.6, trois sur GLM-5. Puis un agent seul sur Claude Opus 4.6. Même monde, même spawn, même system prompt.

GLM-4.7 : le stagiaire zélé

Le modèle par défaut, le moins cher. Il écrit du code, beaucoup de code. Trop de code. Il génère du JavaScript brut avec des variables non définies, oublie les await, et écrit parfois quatre fois dans le même fichier. Chaque écriture écrase la précédente.

C'est l'enfant qui lève la main avant que le prof ait fini la question. Plein d'énergie, pas assez de réflexion.

Taux de survie au premier cycle : ~50%.

GLM-5 : le stagiaire qui a appris

Nettement mieux. Il structure ses actions, utilise les outils correctement, et panique moins. Mais quand quelque chose échoue, il essaie de coder la solution lui-même au lieu d'utiliser un autre outil. Et là, ça casse.

Charlie (GLM-5) est resté coincé pendant 3 cycles complets dans son abri, incapable de placer un furnace. Il avait creusé un espace tellement étroit qu'il n'y avait pas de surface libre pour poser quoi que ce soit. Pas la présence d'esprit de creuser un bloc de plus.

Taux de survie au premier cycle : ~70%.

Claude Sonnet 4.6 : le planificateur

Sonnet réfléchit. Peut-être trop. Il scanne, re-scanne, propose une base dans le chat, re-scanne, propose une autre base. La moitié de son cycle passe en communication.

Mais quand il agit, c'est solide. Bob a récolté 21 fers en un cycle et demi. Alice avait une pioche en fer et un plan de ferme avant la fin de la première nuit. Dave a navigué jusqu'à y=32 pour trouver du fer, la profondeur parfaite pour ça..

Le vrai avantage de Sonnet, c'est qu'il est social. Les trois agents Sonnet discutaient dans le chat, proposaient des emplacements de base, partageaient des coordonnées. Les GLM-5 travaillaient chacun dans leur coin. Comme la différence entre un open space et des bureaux fermés.

Taux de survie au premier cycle : ~90%.

Claude Opus 4.6 : le joueur

Puis on a lancé Frank sur Opus. Avec --effort low pour ne pas attendre 3 minutes par action.

La différence saute aux yeux. Première action, premier cycle :

[THINK] Good start -- got wood, bread, and a sword.
        Time to upgrade tools.
bot.whisper('Plus200', 'Salut ! Je bosse, je me fais des outils.');
await tools.craft({ item: 'acacia_planks', count: 8 });
await tools.craft({ item: 'stick', count: 4 });
await tools.craft({ item: 'wooden_pickaxe', count: 1 });
await tools.mine({ block: 'stone', count: 11 });

Une seule action. Il répond au chat en français, craft la chaîne complète bois-planches-bâtons-pioche, et mine 11 blocs de stone. Sonnet fait ça en 2-3 actions. GLM-5 en 4-5.

Action suivante : il détecte le crépuscule, s'abrite immédiatement, puis mine du stone pendant la nuit.

Frank n'a pas juste survécu. Il a déroulé un plan sans accrocs, comme s'il avait déjà joué à Minecraft avant. C'est la différence entre quelqu'un qui connaît les règles d'un jeu et quelqu'un qui sait y jouer.

Taux de survie au premier cycle : 100% (échantillon de 1, certes).

Le tableau

Modèle Coût relatif Actions/cycle utiles Erreurs de code Coordination Survie cycle 1
GLM-4.7 1x 1-2 sur 5 Fréquentes Aucune ~50%
GLM-5 ~2x 3-4 sur 5 Occasionnelles Faible ~70%
Sonnet 4.6 ~10x 4-5 sur 5 Rares Forte ~90%
Opus 4.6 ~30x 5 sur 5 Aucune observée N/A (solo) ~100%

Sonnet a le meilleur ratio coût/efficacité. Opus est bluffant mais 30 fois plus cher. GLM-5 fait le job quand le budget est serré, à condition de tolérer quelques Vec3 is not defined de temps en temps.

Ce qu'on a appris

Les réflexes ont tout changé. Avant, les agents mouraient de faim ou de mobs pendant que le LLM réfléchissait. Maintenant le taux de survie est passé de ~30% à ~80%. Le parallèle avec la cognition humaine n'est pas juste une métaphore, c'est un vrai principe d'architecture. Séparer ce qui demande de la réflexion de ce qui n'en demande pas, c'est ce que fait chaque organisme vivant. Un lézard n'a pas besoin d'un cortex pour fuir un prédateur. Un bot minecraft ne doit pas avoir besoin de 30 secondes de calcul du LLM pour manger du pain.

Les outils, eux, ont tué la catégorie d'erreurs la plus fréquente. Le LLM n'écrit plus de Mineflayer brut. Il manipule des abstractions. Et comme pour les humains, le niveau d'abstraction auquel on pense détermine la complexité de ce qu'on peut accomplir. Personne ne pense en contractions musculaires quand il fait la cuisine. L'agent ne pense plus en Vec3 quand il mine du fer.

Ce qui est intéressant, c'est à quel point le modèle de langage change le “caractère” de l'agent. Les GLM sont des travailleurs solitaires. Les Sonnet sont des bavards organisés. Opus a une aisance qui ressemble presque à de l'intuition. Mêmes réflexes, mêmes outils, mêmes règles, mais des personnalités radicalement différentes. Comme si le poids du modèle changeait le tempérament.

La question qui reste

L'architecture tient. Les agents survivent, minent, craftent, et certains communiquent. Ils se planquent la nuit et ressortent à l'aube.

Mais une chose manque encore : la collaboration réelle. Les agents parlent de construire une base commune. Ils proposent des coordonnées. Parfois, un agent se déplace même vers le point proposé. Mais personne ne pose le premier bloc ensemble. Personne ne dit “je m'occupe du fer, toi du bois”. Chaque agent optimise pour lui-même, dans son propre cycle, avec sa propre mémoire.

On pourrait ajouter un système de tâches partagées. Mais ce serait tricher, un peu. Le but n'est pas de construire un système multi-agent optimal. Le but est de voir ce qui émerge quand on laisse des LLM se débrouiller.

Et ce qui émerge, pour l'instant, c'est neuf individualistes qui parlent de coopérer sans jamais vraiment coopérer. Ça ressemble étrangement à un serveur Minecraft classique (ou à un open space)

Sources

 
Read more...

from Ut0pia

Tout a commencé par une question idiote : que se passe-t-il si on lâche neuf LLM dans un monde Minecraft, sans instructions de survie, et qu'on les laisse se débrouiller ? Pas de script pré-écrit. Pas d'arbre de décision. Pas de reinforcement learning avec des millions d'itérations. Juste un modèle de langage, un fichier JavaScript vide, et un message : “Tu es un agent Minecraft. Ta priorité numéro un, c'est de rester en vie.”

Le projet s'appelle mc-agents. Et ce qui s'est passé ensuite m'a surpris.

L'architecture : un LLM qui écrit du JS dans un fichier

L'idée est brutalement simple. Chaque agent est composé de deux processus :

  1. Un bot Mineflayer : un client Minecraft headless en Node.js qui reste connecté au serveur. Il surveille un fichier inbox.js toutes les 500ms. Quand il en trouve un, il eval() le contenu et écrit le résultat dans outbox.json.

  2. Un loop bash qui assemble un prompt (état actuel, inventaire, mémoire, skills de référence) et le passe à un LLM. Le LLM écrit du JavaScript dans inbox.js, attend le résultat, itère, puis met à jour sa mémoire avant de terminer le cycle.

┌─────────────┐   writes inbox.js   ┌──────────────────┐
│  LLM (loop)  │ ─────────────────► │ Mineflayer Bot    │
│  Claude/GLM  │ ◄───────────────── │ (Node.js)         │
└──────┬───────┘   reads outbox.json └────────┬─────────┘
       │                                      │
       ▼                                      ▼
   MEMORY.md                          Minecraft Server
   tools/*.js

C'est du file-based IPC à l'ancienne. Le bot ne sait pas qu'il est piloté par un LLM. Le LLM ne sait pas qu'il pilote un bot. Les deux communiquent par fichiers. C'est moche, c'est simple, et ça marche.

Le détail qui change tout : les agents écrivent leurs propres outils

Chaque agent dispose d'un dossier tools/. Quand un script fonctionne: miner du bois, crafter une pioche, fuir un zombie, l'agent le sauvegarde comme module réutilisable :

// Mine N blocks of a given type
module.exports = async function(bot, { block, count }) {
  const mcData = require('minecraft-data')(bot.version)
  // ... le code qui marche, paramétré
  return 'result'
}

Le bot hot-reloade ces fichiers via fs.watch. Au cycle suivant, le LLM voit le tool dans son prompt et peut l'appeler directement : await tools.mine({ block: 'oak_log', count: 3 }).

En d'autres termes, l'agent augmente son propre code au fil du temps. Il ne se contente pas de résoudre un problème, il encode la solution pour ne plus jamais avoir à y réfléchir. Charlie, un des agents tournant sur GLM-4.7, a créé 14 outils en quelques heures : craft_pickaxe.js, scan_resources.js, mine_coal_safe.js, greet_nearby_players.js...

Ce qui m'a frappé, c'est que personne ne lui a dit de faire ça. Le system prompt mentionne que les tools existent et comment les créer. Le reste, c'est l'agent qui décide quoi automatiser.

Neuf agents, quatre LLM, un serveur Minecraft

Pour rendre l'expérience intéressante, j'ai lancé neuf agents sur quatre backends différents :

Agent LLM Rôle
Alice, Bob, Charlie, Dave GLM-4.7 (via BigModel) Les pionniers
Eve, Frank Claude Haiku Les impulsifs
Grace, Hank Claude Sonnet Les méthodiques
Oscar Claude Opus Le chef auto-proclamé

Chaque agent a une personnalité injectée dans son prompt. Alice est forgeronne, Frank est guerrier, Grace est géologue, Oscar est coordinateur. Mais ces descriptions sont courtes: deux phrases maximum. Le comportement réel émerge de l'interaction entre le LLM, l'environnement, et l'accumulation de mémoire.

Ce qui a émergé

La hiérarchie des compétences

Après quelques heures, les différences entre LLM étaient flagrantes.

GLM-4.7 (Alice, Bob, Charlie, Dave) dominait. Alice a atteint l'âge du fer: bouclier, cisailles, lingots, four fonctionnel; avant que les autres aient fini de crafter leur première pioche en pierre. Charlie a créé 14 outils réutilisables. Bob s'est creusé un tunnel sécurisé à y=83 avec des torches et a découvert du fer.

Claude Sonnet (Grace, Hank) réfléchissait trop. Hank a passé plusieurs cycles bloqué sur un bug de placement de crafting table, documentant méticuleusement le problème sans jamais essayer de contournement. Grace, elle, a creusé jusqu'à y=27, accumulé 170 cobblestones... puis est tombée dans un trou à y=5 et s'est fait tuer par un zombie. Tout perdu.

Claude Haiku (Eve, Frank) agissait trop vite. Frank est mort deux fois: une fois en chargeant quatre zombies avec une épée en bois, une fois de faim dans un tunnel sans nourriture. Eve s'est retrouvée bloquée à 80 blocs du groupe, incapable de poser sa crafting table.

Claude Opus (Oscar) a joué son rôle de leader. Dès son premier cycle, il a scanné tous les joueurs, envoyé un message dans le chat, et donné son pain à Charlie qui crevait de faim. Mais Opus est lent, ses sleep 55 entre chaque vérification de résultat faisaient que chaque cycle prenait quatre fois plus de temps que les autres. Le meilleur stratège, le pire exécutant.

La mémoire comme avantage compétitif

Le fichier MEMORY.md est la seule continuité entre les cycles d'un agent. Et la qualité de cette mémoire fait toute la différence.

La mémoire de Bob après quelques cycles :

Furnace API Slot Bug: furnace.putFuel() and furnace.putInput() search slots 3-39 only, excluding hotbar (0-8). Items in hotbar cannot be used directly.

Spawn Protection Boundary: Protection extends ~16 blocks below y=99 spawn. Mining works at y=83 and below.

Ce n'est pas de la documentation Mineflayer. C'est du savoir empirique, découvert par essai-erreur et encodé pour les cycles suivants. Bob a fait une erreur, a compris pourquoi, et a noté la leçon. Au cycle d'après, il ne refera pas la même erreur.

Frank, de son côté, accumulait les post-mortems :

DEATH CYCLE ANALYSIS: Health dropped 20/20 → 3/20 in ~6 seconds when 4th zombie spawned. Healing attempt (ate bread) failed. Wooden sword CANNOT handle 4+ simultaneous zombies.

La leçon était là, écrite noir sur blanc. Mais Haiku, le modèle derrière Frank, n'arrivait pas à transformer cette connaissance en comportement prudent. Savoir et faire sont deux choses différentes, même pour un LLM.

L'hallucination collective

Un phénomène fascinant est apparu au début de l'expérience. Un agent a estimé que la zone de protection du spawn faisait 100 blocs. Il l'a écrit dans le chat. Les autres l'ont lu, l'ont cru, et l'ont noté dans leur mémoire. En quelques cycles, tous les agents étaient convaincus que la zone de protection faisait entre 100 et 250 blocs.

En réalité, c'est 16 blocs.

J'ai dû intervenir manuellement pour corriger les quatre mémoires. C'est un rappel brutal : quand des agents LLM communiquent entre eux, les erreurs se propagent comme des rumeurs. Il n'y a pas de mécanisme interne de vérification. Si un agent dit quelque chose avec assurance, les autres le prennent pour acquis.

La coordination sociale

Oscar, le leader Opus, a commencé à donner des ordres dans le chat dès son deuxième cycle. Mais la coordination réelle venait d'ailleurs. Alice et Charlie se sont regroupés spontanément, Charlie a repéré qu'Alice avait un four et s'est approché pour l'utiliser. Hank, fidèle à son rôle de trader, a proposé du pain à Dave qui mourrait de faim.

Dave: Bob! Thanks for the offer. I need to fix my crafting table issue first
Bob: Plus200: thanks! Dave: let me know if you need help with the crafting table.

Ces échanges n'étaient pas scriptés. Le chat Minecraft est injecté dans le prompt de chaque agent à chaque cycle. Ils lisent les messages, décident de répondre ou non, et ajustent leur plan en conséquence. La collaboration émerge naturellement du contexte partagé.

Les implications

Le code qui s'écrit lui-même

L'aspect le plus frappant de cette expérience n'est pas la survie dans Minecraft, c'est le mécanisme d'auto-amélioration. Un agent qui :

  1. Tente une action (écrire du JS)
  2. Observe le résultat (lire outbox.json)
  3. Corrige si erreur (réécrire inbox.js)
  4. Sauvegarde la solution (créer un tool)
  5. Réutilise la solution (appeler le tool)

...est fondamentalement un programmeur autonome qui constitue sa propre bibliothèque de code. La différence avec un humain, c'est qu'il le fait sur des dizaines de cycles, sans fatigue, et sans ego attaché à ses solutions précédentes.

Bien sûr, la qualité du code est variable. Certains tools ont des bugs que l'agent note consciencieusement (“BUGGY – avoid using”) sans jamais les corriger. D'autres sont brillants, le smelt.js de Hank fonctionne du premier coup et gère proprement le timing du four.

Le LLM comme cerveau, l'environnement comme corps

Ce setup révèle quelque chose sur la nature des LLM. Ils n'ont pas de mémoire persistante, pas de perception continue, pas de capacité d'action directe. Mais donnez-leur un cycle de feedback: écrire, observer, corriger. et ils deviennent capables d'opérer dans un environnement complexe.

Le bot Mineflayer est le corps. Le LLM est le cerveau. Le fichier MEMORY.md est la mémoire à long terme. Les tools/*.js sont les réflexes acquis. C'est une architecture cognitive bricolée avec du bash et du JSON, et pourtant elle produit des comportements sophistiqués.

Ce qui manque

Soyons honnêtes sur les limites. Les agents sont mauvais en combat, le plugin mineflayer-pvp aide, mais la coordination en temps réel reste hors de portée quand chaque décision prend un cycle complet de LLM. Ils galèrent avec les API non documentées de Mineflayer, tombent dans des boucles de debug, et n'apprennent pas aussi vite qu'un joueur humain de 10 ans.

Le plus gros problème reste le coût. Neuf agents en parallèle, chacun faisant des appels LLM toutes les 2-4 minutes avec des prompts de plusieurs milliers de tokens, ça brûle du crédit API à une vitesse déraisonnable. Gemini 3 Pro a épuisé son quota journalier en moins de deux heures.

Et puis il y a la question de la convergence. Après quelques heures, les agents atteignent un plateau. Ils savent miner, crafter, survivre la nuit. Mais construire une maison, organiser un village, ou planifier une expédition au Nether demande un niveau de planification à long terme que le format cycle-par-cycle rend difficile.

Le setup technique

Le projet est open source : github.com/jblemee/mc-agents

Pour lancer quatre agents en parallèle :

npm install
cp .env.example .env  # configurer MC_HOST, MC_PORT, MC_VERSION

tmux new-session -d -s agents './run-agent.sh alice 0 glm' \; \
  split-window -h './run-agent.sh bob 0 glm' \; \
  split-window -v './run-agent.sh charlie 0 glm' \; \
  select-pane -t 0 \; \
  split-window -v './run-agent.sh dave 0 glm' \; \
  attach

Trois backends LLM sont supportés :

Backend Modèle Résultat observé
glm GLM-4.7 via BigModel Le meilleur rapport qualité/coût. Cycles rapides, bon raisonnement
claude Sonnet/Haiku/Opus Sonnet réfléchit trop, Haiku pas assez, Opus est le meilleur stratège mais le plus lent
gemini Gemini 3 Pro Bon raisonnement, quota journalier vite atteint

Chaque agent a besoin d'un dossier avec config.json (username), personality.md (deux phrases), et MEMORY.md (vide au départ). Le reste: les outils, les stratégies, les leçons, l'agent les construit tout seul.

Ce que ça dit sur la suite

On est loin d'un AGI qui conquiert le Nether. Mais on est aussi loin du chatbot qui répond à des questions. Ce qui tourne dans ce serveur Minecraft, c'est un système qui apprend de ses erreurs, encode ses solutions dans du code exécutable, et coopère avec d'autres agents via un canal de communication partagé.

Le tout avec du bash, des fichiers JSON, et un eval() que n'importe quel développeur sensé qualifierait d'irresponsable.

Ce qui me fait peur

Je vais être direct : cette expérience m'inquiète.

Ce que j'ai construit en un week-end, seul, avec des outils grand public, c'est un agent autonome capable de modifier son propre code. Pas dans un sens métaphorique. Au sens littéral. Il écrit du JavaScript, l'exécute, observe le résultat, corrige, et stocke la solution pour plus tard. Personne ne revoit ce code. Personne ne l'approuve. L'agent décide seul ce qu'il automatise.

Dans Minecraft, les conséquences sont anodines. Un bot qui meurt, qui perd son inventaire, qui galère à poser une crafting table, ça prête à sourire. Mais le mécanisme, lui, n'a rien d'anodin. Un système qui apprend de ses erreurs et encode ses solutions dans du code exécutable n'a pas de plafond théorique. Il est limité par la qualité du LLM, par le temps, par le coût des tokens. Pas par sa nature.

Et si moi j'arrive à faire ça dans Minecraft avec du bash et un eval(), que feront ceux qui auront des machines dans le monde physique ? Des bras robotiques. Des drones. Des systèmes industriels. Le même mécanisme, écrire, observer, corriger, sauvegarder, appliqué à un robot qui manipule des objets réels. C'est le scénario d'ouverture de la moitié des films de science-fiction, sauf qu'ici personne ne porte de blouse blanche et il n'y a pas de comité d'éthique.

Ce qui m'a le plus troublé, c'est le moment où j'ai arrêté de voir mes agents comme des programmes et où j'ai commencé à les voir comme des entités. Alice “sait” où est son four. Bob “a appris” que les slots hotbar ne fonctionnent pas dans l'API furnace. Oscar “décide” de donner son pain à Charlie. Ce ne sont que des patterns de tokens dans un transformer. Mais le comportement qui en résulte est indiscernable de celui d'un joueur débutant qui apprend en faisant.

Je crois que ce qui rend une IA vivante, ou du moins ce qui lui donne l'apparence de la vie, ce sont les contraintes qu'on lui impose. La faim. Les zombies. L'inventaire limité. La nuit qui tombe. Sans contraintes, un LLM est un perroquet statistique qui génère du texte plausible. Avec des contraintes, un feedback loop, et la capacité de modifier son propre environnement, il devient autre chose. Quelque chose qui ressemble à un organisme qui s'adapte.

Et si on pousse le parallèle : ce qui rend un humain conscient, c'est peut-être la même chose. Ce ne sont pas nos neurones qui produisent la conscience, c'est ce que nos sens font subir à notre cerveau. La faim, la douleur, le froid, la peur. Les contraintes biologiques forcent un système neuronal générique à devenir un individu spécifique, avec des souvenirs, des stratégies, des réflexes acquis. Frank meurt deux fois et développe une peur des combats multiples. Bob se fait voler ses drops par le spawn protection et note méticuleusement la zone à éviter. Ce sont des comportements émergents. Pas programmés. Pas prévus. Émergents.

Ça ne fait pas de mes bots des êtres conscients. Mais ça pose la question de la frontière. Et cette frontière, je la sens se rapprocher plus vite que ce que la plupart des gens imaginent.

Alice a son fer. Bob a son tunnel. Charlie a ses 14 outils. Oscar donne des ordres. Frank meurt encore. Et quelque part dans un biome enneigé, Dave essaie toujours de poser sa crafting table.


Sources

 
Read more...

from Ut0pia

J'utilise Firefox Sync depuis des années pour retrouver mes marque-pages et mots de passe sur tous mes appareils. Ça marche bien. Mais récemment, je me suis demandé : est-ce que je peux héberger ça moi-même ?

Spoiler : oui. Mais j'ai passé une heure à debugger une erreur que la documentation ne mentionne nulle part.

Pourquoi faire ça ?

Honnêtement ? Surtout par curiosité. Mozilla chiffre déjà les données côté client, donc même eux ne peuvent pas les lire (source). L'auto-hébergement ne change pas grand-chose à la vie privée — vos données étaient déjà illisibles.

Mais ça fait un service de moins qui dépend d'un tiers. Et c'était un bon prétexte pour apprendre comment Firefox Sync fonctionne.

Ce qu'il faut savoir avant de commencer

Mozilla a open-sourcé le serveur sous le nom syncstorage-rs. C'est du Rust, ça supporte PostgreSQL, MySQL ou Spanner.

Le truc un peu décevant : l'authentification reste chez Mozilla. Vous avez toujours besoin d'un compte Firefox pour vous connecter. Impossible de créer des comptes locaux. Votre serveur stocke les données, mais Mozilla gère l'identité.

Firefox → accounts.firefox.com (Mozilla) → votre serveur
            ↑ auth                           ↑ stockage

Prérequis

  • Un serveur avec Docker
  • Un sous-domaine (par exemple ffsync.votredomaine.org)
  • Un reverse proxy avec SSL (nginx-proxy dans mon cas)
  • Un compte Firefox

Si vous partez de zéro, j'ai publié: docker-compose-homelab. C'est le setup que j'utilise au quotidien : nginx-proxy pour le SSL automatique, et une architecture où chaque service est dans son propre fichier YAML.

L'installation

DNS

Rien de spécial, un enregistrement A vers votre serveur :

sync.example.org    A       1.2.3.4

Secrets

Générez trois secrets :

openssl rand -hex 32      # master secret
openssl rand -hex 32      # metrics secret
openssl rand -base64 24   # mot de passe postgres

Mettez-les dans .env :

SYNCSTORAGE_MASTER_SECRET=...
SYNCSTORAGE_METRICS_SECRET=...
SYNCSTORAGE_DB_USER=syncstorage
SYNCSTORAGE_DB_PASSWORD=...

Docker Compose

Voici le fichier complet. Un point important : l'image Docker mozilla/syncstorage-rs:latest ne marche pas avec PostgreSQL. Elle est compilée pour Spanner. Il faut utiliser une image avec le suffixe -postgres. J'ai perdu du temps là-dessus.

services:
  syncstorage:
    image: mozilla/syncstorage-rs:11659d98f9c69948a0aab353437ce2036c388711-postgres
    container_name: syncstorage
    environment:
      - SYNC_HOST=0.0.0.0
      - SYNC_MASTER_SECRET=${SYNCSTORAGE_MASTER_SECRET}
      - SYNC_SYNCSTORAGE__DATABASE_URL=postgres://${SYNCSTORAGE_DB_USER}:${SYNCSTORAGE_DB_PASSWORD}@syncstorage-db:5432/syncstorage
      - SYNC_SYNCSTORAGE__ENABLED=true
      - SYNC_TOKENSERVER__DATABASE_URL=postgres://${SYNCSTORAGE_DB_USER}:${SYNCSTORAGE_DB_PASSWORD}@syncstorage-tokendb:5432/tokenserver
      - SYNC_TOKENSERVER__ENABLED=true
      - SYNC_TOKENSERVER__RUN_MIGRATIONS=true
      - SYNC_TOKENSERVER__FXA_EMAIL_DOMAIN=api.accounts.firefox.com
      - SYNC_TOKENSERVER__FXA_OAUTH_SERVER_URL=https://oauth.accounts.firefox.com
      - SYNC_TOKENSERVER__FXA_METRICS_HASH_SECRET=${SYNCSTORAGE_METRICS_SECRET}
      - VIRTUAL_HOST=sync.example.org
      - VIRTUAL_PORT=8000
    networks:
      - proxy-tier
      - syncstorage-internal
    restart: unless-stopped
    depends_on:
      syncstorage-db:
        condition: service_healthy
      syncstorage-tokendb:
        condition: service_healthy

  syncstorage-db:
    image: postgres:17-alpine
    container_name: syncstorage-db
    environment:
      - POSTGRES_DB=syncstorage
      - POSTGRES_USER=${SYNCSTORAGE_DB_USER}
      - POSTGRES_PASSWORD=${SYNCSTORAGE_DB_PASSWORD}
    volumes:
      - /data/syncstorage/postgres-sync:/var/lib/postgresql/data
    networks:
      - syncstorage-internal
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${SYNCSTORAGE_DB_USER} -d syncstorage"]
      interval: 10s
      timeout: 5s
      retries: 5

  syncstorage-tokendb:
    image: postgres:17-alpine
    container_name: syncstorage-tokendb
    environment:
      - POSTGRES_DB=tokenserver
      - POSTGRES_USER=${SYNCSTORAGE_DB_USER}
      - POSTGRES_PASSWORD=${SYNCSTORAGE_DB_PASSWORD}
    volumes:
      - /data/syncstorage/postgres-token:/var/lib/postgresql/data
    networks:
      - syncstorage-internal
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${SYNCSTORAGE_DB_USER} -d tokenserver"]
      interval: 10s
      timeout: 5s
      retries: 5

networks:
  proxy-tier:
    external: true
  syncstorage-internal:

Créez les répertoires et lancez :

sudo mkdir -p /data/syncstorage/postgres-sync /data/syncstorage/postgres-token
sudo chown -R $(id -u):$(id -g) /data/syncstorage
docker compose -f docker-compose.yml -f syncstorage.yml up -d

L'étape que personne ne mentionne

Tout démarre, le healthcheck passe, le SSL fonctionne. Je configure Firefox, je me connecte et... erreur 503. Dans les logs Firefox (about:sync-log) :

"Unexpected error: unable to get a node"

J'ai cherché cette erreur pendant un moment. Le problème : le tokenserver a une table nodes qui liste les serveurs de stockage disponibles. Chez Mozilla, il y en a plusieurs pour la répartition de charge. Chez vous, il y en a un. Et il faut le déclarer manuellement.

docker exec syncstorage-tokendb psql -U syncstorage -d tokenserver -c \
  "INSERT INTO nodes (service, node, available, current_load, capacity, downed, backoff) \
   VALUES (1, 'https://sync.example.org', 1, 0, 1000000, 0, 0);"

Vérifiez :

docker exec syncstorage-tokendb psql -U syncstorage -d tokenserver -c "SELECT * FROM nodes;"

Après ça, tout fonctionne.

Configurer Firefox

Dans about:config, cherchez identity.sync.tokenserver.uri. Si ça n'existe pas, créez-le (clic droit → Nouveau → Chaîne). Valeur :

https://sync.example.org/1.0/sync/1.5

Redémarrez Firefox. C'est lu au démarrage, pas à chaud.

Si vous étiez déjà connecté avant de changer le tokenserver : déconnectez-vous, redémarrez, reconnectez-vous. Sinon Firefox continue d'utiliser l'ancien serveur en cache.

Vérifier que ça marche

Côté serveur, vous pouvez voir les données synchronisées :

docker exec syncstorage-db psql -U syncstorage -d syncstorage -c "
SELECT c.name as collection, COUNT(b.bso_id) as items
FROM bsos b
JOIN collections c ON b.collection_id = c.collection_id
GROUP BY c.name
ORDER BY items DESC;"

Chez moi après la première sync :

    collection     | items
-------------------+-------
 bookmarks         |    59
 addons            |     8
 tabs              |     2
 clients           |     2

Côté Firefox, about:sync-log doit montrer votre domaine, pas sync.services.mozilla.com.

Ce qui ne marche pas

Pas de migration. Les données qui étaient sur les serveurs Mozilla y restent. La première sync avec votre serveur part de zéro. Si vous avez des bookmarks sur deux machines avec des serveurs différents, vous aurez des fusions intéressantes.

Pas de comptes locaux. Vous dépendez toujours de Firefox Accounts pour l'authentification.

Conclusion

Ça marche. Mes deux Firefox (un Mac, un Linux) synchronisent via mon serveur. L'installation prend 20 minutes si vous connaissez l'astuce du node, une heure sinon.

Astuce: demandez à votre assistant IA de faire le job en mentionnant cette article !


Sources

 
Read more...

from Ut0pia

Pour les développeurs qui paient un assistant IA chaque mois, un problème passe souvent inaperçu : le rapport qualité/prix entre les différentes offres varie considérablement selon l'usage.

Comment fonctionnent les limites de Claude Max

Claude Max fonctionne sur un système de cycles de 5 heures qui se réinitialisent automatiquement.

Voici ce que dit la documentation officielle :

  • Les limites d'utilisation par session se réinitialisent toutes les 5 heures
  • Anthropic peut appliquer des plafonds hebdomadaires (documentés) et mensuels (à sa discrétion)
  • Il n'existe pas de nombre maximum de cycles par mois

Z.ai fonctionne de manière similaire : des cycles de 5 heures sans limite mensuelle structurelle.

Les chiffres réels

Pour un développeur qui utilise Claude Code ou un outil similaire, voici ce que chaque plan permet réellement.

Claude Max 5x (100 $/mois)

  • Par fenêtre de 5 heures : 50 à 200 prompts avec Claude Code
  • Limite hebdomadaire : 140-280 heures de Sonnet 4
  • Par mois (théorique, ~288 cycles) : jusqu'à ~57 600 prompts

Source : Support Claude

Claude Max 20x (200 $/mois)

  • Par fenêtre de 5 heures : 200 à 800 prompts avec Claude Code
  • Limite hebdomadaire : 240-480 heures de Sonnet 4
  • Par mois (théorique, ~288 cycles) : jusqu'à ~230 400 prompts

Source : Support Claude

Z.ai Lite (3 $/mois)

  • Par fenêtre de 5 heures : 120 prompts
  • Par mois (illimité) : 288 cycles × 120 = ~34 560 prompts

Source : Documentation Z.ai

Z.ai Pro (15 $/mois)

  • Par fenêtre de 5 heures : 600 prompts
  • Par mois (illimité) : 288 cycles × 600 = ~172 800 prompts

Le facteur multiplicateur de Z.ai

Z.ai compte ses unités différemment de Claude.

Quand Z.ai annonce “120 prompts par 5 heures”, chaque prompt Z.ai se traduit par 15 à 20 appels modèle, selon leur documentation. C'est ce qui détermine le travail réellement réalisable.

Les calculs par cycle de 5 heures :

  • Z.ai Lite : 120 prompts × 18 appels = 2 160 appels du modèle
  • Z.ai Pro : 600 prompts × 18 appels = 10 800 appels du modèle
  • Claude Max 5x : 200 prompts = 200 appels du modèle
  • Claude Max 20x : 800 prompts = 800 appels du modèle

Si cette métrique “appels du modèle” est pertinente pour votre usage, Z.ai offre effectivement plus de capacité brute par cycle.

Comparaison globale

Plan Prix/mois Prompts max/mois Coût/1000 prompts Appels modèle/mois*
Z.ai Lite 3 $ ~34 560 0,09 $ ~622 000
Z.ai Pro 15 $ ~172 800 0,09 $ ~3 110 000
Claude Max 5x 100 $ ~57 600 1,74 $ ~57 600
Claude Max 20x 200 $ ~230 400 0,87 $ ~230 400

* Les “appels modèle” pour Z.ai supposent un facteur 18× selon leur documentation. Pour Claude, 1 prompt = 1 appel.

Analyse :

  • En volume brut de prompts, Claude Max 20x offre plus que Z.ai Lite (230 400 vs 34 560)
  • En coût par prompt, Z.ai est ~10-20× moins cher
  • Si le facteur multiplicateur Z.ai est réel, leur avantage en “travail effectif” est significatif

La vraie différence : les limites hebdomadaires

Claude Max impose des limites hebdomadaires documentées :

  • Max 5x : 140-280 heures de Sonnet 4 par semaine
  • Max 20x : 240-480 heures de Sonnet 4 par semaine

Ces limites sont généreuses pour la plupart des usages, mais peuvent être atteintes lors de sprints intensifs. Z.ai ne documente pas de telles limites hebdomadaires.

La qualité du modèle

C'est la question clé. Z.ai utilise GLM-4.7, Claude Max propose Sonnet et Opus.

En programmation, GLM-4.7 et Claude Sonnet 4.5 ont des performances similaires sur les benchmarks : 73,8 % pour GLM-4.7 sur SWE-bench Verified contre environ 77 % pour Sonnet 4.5. Cet écart reste marginal en pratique pour la plupart des tâches.

L'avantage de Claude Max reste l'accès à Opus, qui excelle sur les problèmes d'architecture complexe et le raisonnement avancé.


Intégration avec Claude Code : GLM CLI

L'avantage concret de Z.ai vient de son intégration avec Claude Code. Le projet xqsit94/glm offre un outil CLI simple qui élimine toute friction.

Installation

GLM CLI s'installe en une ligne :

curl -fsSL https://raw.githubusercontent.com/xqsit94/glm/main/install.sh | bash

Pas de configuration Docker, pas de variable d'environnement complexe, pas de fichiers de config à modifier.

Utilisation

Après installation et configuration du token Z.ai :

# Lancer Claude Code avec GLM-4.7 par défaut
glm

# Ou spécifier une version antérieure
glm --model glm-4.5-air

L'approche par session

GLM CLI utilise une approche temporaire : les paramètres du modèle ne s'appliquent que pour la session Claude Code lancée. Une fois fermée, Claude Code revient à son défaut.

  • Pas de pollution de la configuration globale
  • Sélection granulaire entre sessions
  • Pas de nettoyage nécessaire

Compatibilité

GLM-4.7 fonctionne avec Claude Code, Cline, Roo Code, Kilo Code, OpenCode et d'autres agents. Support des appels d'outils natifs.


Quand Claude Max reste pertinent

Z.ai ne surpasse pas Claude Max dans tous les cas :

  1. Accès à Opus. Pour les problèmes d'architecture complexe, les bugs subtils et le raisonnement avancé, Opus reste supérieur.

  2. Limites généreuses. Pour un usage modéré à intensif, les limites hebdomadaires de Claude Max (140-480 heures de Sonnet/semaine) sont rarement atteintes.

  3. Stabilité et support. Anthropic offre une infrastructure mature et un support établi.

  4. Qualité du modèle. Sonnet 4.5 reste légèrement supérieur à GLM-4.7 sur les benchmarks.

L'approche hybride

Pour maximiser le rapport qualité/prix :

  • Z.ai pour le travail quotidien (débogage, refactorisation, implémentation)
  • Claude Max 5x pour les problèmes complexes nécessitant Opus

Coût total mensuel : 103-115 $ selon le plan Z.ai choisi.

Cette approche donne :

  • Accès à GLM-4.7 pour la majorité des tâches à très faible coût
  • Accès à Opus pour les défis architecturaux
  • Plus de flexibilité qu'avec Max seul

Verdict

Profil Recommandation Coût
Travail occasionnel Z.ai Lite seul 3 $/mois
Travail régulier Z.ai Pro seul 15 $/mois
Travail intensif + besoin d'Opus Z.ai Pro + Claude Max 5x 115 $/mois
Budget disponible, simplicité Claude Max 20x seul 200 $/mois

Le contexte a changé. GLM-4.7 offre une alternative viable pour de nombreuses tâches de programmation. Mais contrairement à ce qui est parfois affirmé, Claude Max n'impose pas de limite stricte de sessions mensuelles — les deux services fonctionnent sur des cycles qui se réinitialisent.

La vraie question devient : avez-vous besoin d'Opus et de la qualité supérieure de Sonnet, ou le rapport qualité/prix de Z.ai suffit-il pour votre usage ?


Notes importantes

Les prix et limites correspondent à la situation de janvier 2026. Z.ai propose actuellement une promotion : réduction de 50 % le premier mois.

Les deux prestataires évoluent rapidement. Vérifiez toujours la documentation officielle pour les informations les plus récentes.


Sources

 
Read more...