58 lines
3.5 KiB
Markdown
58 lines
3.5 KiB
Markdown
# hermes-perso — model_override deprecie sur la session Telegram (ox-alpha-free)
|
|
|
|
**Instance auteur** : hermes-perso
|
|
**Date** : 2026-09-02
|
|
**Tags** : hermes-perso, telegram, opencode, model_override
|
|
**Statut** : valide
|
|
|
|
---
|
|
|
|
## Probleme
|
|
|
|
La session Telegram DM de Nabil (`agent:main:telegram:dm:2084513684` dans `/opt/data/sessions/sessions.json`) avait un `model_override` fige sur `ox-alpha-free` (provider `opencode-go`). Ce modele est marque `"status": "deprecated"` dans le registre `models_dev_cache.json` et l'API `opencode.ai/zen/go/v1/chat/completions` renvoie `401 "Model ox-alpha-free is not supported"` en confirmation directe. Tous les messages Telegram envoyes sous ce override echouaient silencieusement.
|
|
|
|
## Contexte et contraintes
|
|
|
|
`/opt/data/` du conteneur `hermes-agent-perso` est en 0700 (uid 1026), illisible en SSH direct meme depuis un compte scope comme claude-ops. Acces uniquement via `docker exec` (qui tourne root dans le conteneur, contourne le mur de permissions cote host).
|
|
|
|
## Ce qui NE fonctionne PAS
|
|
|
|
| Tentative | Erreur obtenue | Raison de l'echec |
|
|
|-----------|----------------|-------------------|
|
|
| Lecture directe via SSH claude-ops (`cat /opt/data/...`) | Permission denied | data/ en 0700 uid 1026, claude-ops non proprietaire |
|
|
| Edition via `ssh nas-host` directement sur les fichiers `.env`/`docker-compose.yml.disabled` du dossier hermes-perso | Aucune trace du model_override actif | Config statique ; le choix de modele reel vit dans `sessions.json`, pas dans les fichiers de config au repos |
|
|
|
|
## Solution validee
|
|
|
|
```bash
|
|
# 1. Backup avant toute ecriture
|
|
docker exec hermes-agent-perso cp /opt/data/sessions/sessions.json \
|
|
/opt/data/sessions/sessions.json.bak-fix-ox-alpha-$(date +%Y%m%d-%H%M%S)
|
|
|
|
# 2. Edition cible via script Python transfere en base64 (docker cp) puis execute root dans le conteneur
|
|
# -> modifie uniquement sessions[key].model_override.model, rien d'autre
|
|
docker cp fix_model.py hermes-agent-perso:/tmp/fix_model.py
|
|
docker exec hermes-agent-perso python3 /tmp/fix_model.py
|
|
```
|
|
|
|
Bascule effectuee : `ox-alpha-free` → `hy3` (meme provider `opencode-go`, meme `base_url`, changement minimal).
|
|
|
|
## Verification
|
|
|
|
```bash
|
|
docker exec hermes-agent-perso python3 -c "import json; d=json.load(open('/opt/data/sessions/sessions.json')); print(d['agent:main:telegram:dm:2084513684']['model_override'])"
|
|
# Attendu : {'model': 'hy3', 'provider': 'opencode-go', 'base_url': 'https://opencode.ai/zen/go/v1'}
|
|
```
|
|
JSON valide (`json.load` sans exception) confirme apres ecriture.
|
|
|
|
## Pieges specifiques
|
|
|
|
- Ne jamais editer `sessions.json` a la main sans backup — c'est un fichier d'etat vivant, reecrit en continu par le process gateway actif (`active_turn_token` doit etre `null` avant d'editer, sinon risque de race condition avec une conversation en cours).
|
|
- Le mecanisme exact par lequel le Telegram bot laisse choisir un modele "directement" (mentionne par Nabil) n'a pas ete localise dans cette session (pas de endpoint `/docs` ou `/openapi.json` trouve sur l'API server interne, port 8642) — probablement une commande bot (`/model <nom>`) qui ecrit dans ce meme `model_override`. A confirmer.
|
|
- Toujours verifier le statut d'un modele OpenCode dans `models_dev_cache.json` (du conteneur hermes-agent concerne) avant de l'assigner en dur quelque part — voir common/opencode-go-migration.md pour la distinction des deux catalogues opencode.
|
|
|
|
## References
|
|
|
|
- common/opencode-go-migration.md
|
|
- common/bifrost-vk-incidents.md (incident du meme jour, cause differente mais meme famille de symptome : modele non fonctionnel silencieusement)
|