Module II — opération en direct et sessions
Le module II est la vue de l’opération en direct du parc (estate) : ce que chaque session d’agent est en train de faire à l’instant présent, ses totaux de tokens et de coût en direct, un état Claude Code dérivé, et une chronologie reconstructible. Là où le module I (inventaire) matérialise le parc durable, le module II maintient une surcouche opérationnelle en direct par session au-dessus du même flux d’observations — et ne montre que ce que ce flux porte honnêtement.
Olivares 0.4 lance aussi les CLI officielles de fournisseur comme enfants
détenus sous un profil fournisseur. Ce
chemin géré est le même module. Il ne remplace pas la surcouche et ne fusionne
pas deux homes qui annoncent le même id de session fournisseur
(CHANGELOG.md [26.9.0] B1/B2).
Ce qu’il est
Section intitulée « Ce qu’il est »Le module II est un module de couche Core piloté par le bus, frère de l’inventaire. Il maintient un enregistrement en direct indexé par la référence externe de chaque session, construit à partir du flux d’observations coopératif — jamais interrogé par scrutation, jamais fabriqué. Par session, il suit :
- l’action en cours (le dernier outil utilisé) et la ressource/le mode qu’elle a touchés ;
- les totaux de tokens et de coût en direct, lus depuis les échantillons de coût (le journal de coût canonique et FinOps sont le module XI, pas ici — ceci n’est que le chiffre en direct) ;
- un état Claude Code dérivé (
cc_state) ; et - une chronologie à laquelle chaque événement observé est ajouté dans l’ordre d’ingestion.
Son contrat et ses entités
Section intitulée « Son contrat et ses entités »Le module enregistre deux entités à portée de tenant. sessions.live contient
l’enregistrement en direct par session — action/ressource/mode en cours, référence de
modèle, tokens d’entrée/sortie en direct, coût en direct, compteurs d’événements et d’appels
d’outils, et horodatages de premier/dernier événement. sessions.timeline contient une ligne
rejouable par événement, ordonnée par ingestion. Il n’y a aucune colonne de cycle de vie
stockée : le flux coopératif ne porte aucun signal de fin-ou-échec, de sorte que le seul
signal de vivacité honnête est le cc_state dérivé.
cc_state est dérivé au moment de la lecture à partir de la récence des événements —
active / idle / ended — et bascule vers un état d’évasion silencieuse lorsque le
connecteur émet ce finding (il n’est jamais écrit par le module lui-même). Les lectures sont
servies sous des routes de module (liste en direct, session unique, chronologie par session)
plus un flux SSE en direct ; chaque lecture exige la permission de lecture de session, et
l’ouverture du flux est auto-auditée. Le canal SSE est strictement isolé par tenant
(un client ne reçoit que des instantanés pour son tenant autorisé) et au mieux (best-effort)
(un client lent abandonne la trame intermédiaire et reçoit la suivante — l’ingestion ne bloque
jamais).
Provider profiles and live_ref
Section intitulée « Provider profiles and live_ref »Un profil fournisseur est l’identité durable d’une instance fournisseur
configurée sur un environnement d’exécution : pilote, environnement, et les
config_home / user_home canoniques. Ce n’est pas un compte fournisseur
authentifié. Enregistrer, renommer, désactiver/activer et retirer vivent sous
/v1/m/sessions/provider-profiles. Les chemins n’apparaissent que sur la
lecture admin configuration. Un lancement nomme provider_profile_ref ; le
serveur résout les homes et persiste un instantané non secret sur le run avant
le spawn (CHANGELOG.md [26.9.0] B1 ; web/src/features/agentops/types.ts).
Une observation se plie dans la ligne live de son canal, calculé par le
serveur à partir de l’enregistrement de source tamponné par l’hôte
(CHANGELOG.md [26.9.0] B2) :
| Channel | Meaning |
|---|---|
legacy |
no registration |
observed |
a source dedicated to a profile by a binding approved at host admission for the exact applied revision |
source |
a known registration with no verifiable profile |
managed |
a run the plane launched; the only row carrying canonical_sid and run_ref |
Chaque ligne live expose live_ref et attribution. Deux homes qui annoncent
le même identifiant de session fournisseur sont deux lignes avec deux
chronologies. Lisez une ligne avec GET /v1/m/sessions/live/by-id/{live_ref}
(et sa requête timeline / stream / runs). Les routes d’id externe nues restent
et sont legacy : elles répondent seulement pour la ligne legacy.
Les pilotes sont enregistrés sur chaque nœud au démarrage. Au lancement d’une
session, le moteur utilise l’installation gérée vérifiée la plus récente, puis
la CLI dans son PATH. OLIVARES_SESSION_RUNTIME_CLAUDE_BIN, _CODEX_BIN,
_GROK_BIN et _OPENCODE_BIN remplacent explicitement cette résolution
(voir Configuration). Si aucun exécutable n’est trouvé,
le lancement est refusé. Les autres vérifications, dont l’authentification du profil
et la politique de lancement, s’appliquent toujours. Étapes opérateur :
Exploiter une session de fournisseur.
Un message peut porter des images. olivares session send <session> --attach shot.png "what is wrong here?" et le composeur de la console (coller, déposer ou le trombone) stockent chaque
image PNG, JPEG, WebP ou GIF avec la session, à raison de quatre au plus par message et de
3,75 Mo chacune, puis les envoient avec le texte ; un message a besoin de son texte, donc une
image seule n’est pas envoyée (la CLI et le composeur le demandent). Claude Code reçoit un
bloc de contenu image et Codex sa propre entrée d’image ; un outil sans entrée d’image refuse
le message en le nommant avant que rien ne soit envoyé. L’API est
POST /v1/m/sessions/runs/{ref}/attachments (l’image, en base64),
GET .../attachments/{id} et attachments sur .../input. Les images résident sous le
répertoire de données, par tenant et par session, et sont supprimées avec la session.
Ce qu’il consomme (et ce qu’il dérive)
Section intitulée « Ce qu’il consomme (et ce qu’il dérive) »Le module II consomme le même flux d’observations à donnée minimale que l’inventaire —
edge.observed, cost.sampled et finding.reported. Seules les arêtes
dont l’origine est une session produisent de l’opération en direct ; les échantillons de
coût liés à une session s’ajoutent au chiffre de tokens/coût en direct (aucun CostRecord
n’est écrit ici) ; les findings dont le sujet est une session sont annotés, et un finding
anti-évasion marque l’état d’évasion. Deux champs sont dérivés en direct à partir de ces
mêmes signaux : agent_ref à partir de l’agent attribué à une session, et summary à partir
d’un finding de compaction de contexte (forensique) dont le titre est sûr pour le résumé par
contrat — jamais un résumé fabriqué par un LLM.
- Référence du bus d’événements — les événements
edge.observed,cost.sampledetfinding.reportedque ce module consomme. - Catalogue des modules — où se situe le module II et la répartition honnête de l’actionnement.
- Carte d’accès et de ressources — le module Core frère qui possède le graphe d’accès R/RW.
- Vue d’ensemble de l’architecture — le moteur et les couches.
- Connecter Claude Code — commencer à produire le flux en direct.
- Honnêteté et limites — ce que le produit fait et ne fait pas aujourd’hui.